Mi Guía De Commits📝
Tags: git, tutorial, learning
Published: 2023-08-02 09:41:27

- [📯 Introducción](#introducción)
- [Estructura](#estructura)
- [Elementos](#elementos)
    - [Tipo](#tipo)
    - [Ámbito](#ámbito)
    - [Breve título](#breve-título)
    - [Cuerpo](#cuerpo)
    - [Pie](#pie)
- [Prompt ChatGPT](#prompt-chatgpt)
    - [Prompt](#prompt)

----

## Introducción
Guía básica de como redacto los mensajes de los commits para saber que hace el commit y tener una estructura definida para los mismos. También saber que cambios se han realizado en el código sin tener que verlo.

Está basada en [Conventional Commits](https://www.conventionalcommits.org/) que ésta a su vez se basa en la [guía de commits de Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).

> *Estas dos anteriores guías o estándares yo no los sigo al pie de la letra, son una simple base la cual seguir pero si veo necesarios cambios para mi caso concreto, los implementaré, y tu deberías hacer lo mismo, adaptarlo para tu caso concreto y como mejor te funcione*

## Estructura

La estructura de los mensajes es la que vemos a continuación *(los elementos que van dentro de corchetes [] son opcionales)*

```markdown
<TIPO>([ámbito opcional]): <BREVE_TÍTULO>
<SALTO_DE_LINEA>
[CUERPO]
<SALTO_DE_LINEA>
[PIE]
```

## Elementos

### Tipo
Indica de manera **general** que **hace** el **commit** y es **obligatorio**. En mi caso los tipos de commits que suelo utilizar son los siguientes:

- `feat`: indica que el commit implementa una nueva feature.
- `fix` : indica la resolución de un fallo/bug/issue.
- `docs`: indica cambios o nueva documentación.
- `refactor`: indica que se ha refactorizado código, sin cambios en la funcionalidad.
- `remove` : indica que se ha eliminado algo del proyecto.
- `test` : indica cambios o nuevas implementaciones de tests.

### Ámbito
El ámbito va **entre** **paréntesis** después del tipo, y es **opcional**. Hace referencia a una determinada parte del código, por ejemplo: *gui, database, hilt, di*.

### Breve título 
Es una **breve descripción** de lo que **hace el commit**, es **obligatorio** y se deben usar verbos **imperativos**, es decir que se debe leer de la siguiente manera:

| Commit | Como se lee                            |
| -------------------------- | -------------------------------------- |
| Modifica el boton de login | Este commit modifica el boton de login |
| Implementa inyeccion de dependencias  | Este commit implementa la inyeccion de dependecias |


> Evitar escribir commits en primera persona: He cambiado la forma de hacer login, he cambiado los colores...


### Cuerpo

Después del titulo insertar un **salto de linea** y añadir el **cuerpo**. Este elemento es opcional y se usa en el caso de querer dar mas información de lo que hace el commit.  

### Pie
El pie debe ir seguido de un salto de linea y se utiliza para dar información sobre quien ha realizado el commit, quien lo ha revisado, cual es la issue que arregla. Yo por el momento no utilizo esta parte


## Prompt ChatGPT
Para redactar el commit de forma mas rápida yo utilizo ChatGPT donde le indico lo que quiero que haga *(escribir el commit)* y a continuación le proporciono la salida del comando `git diff` para que genere el mensaje. 

En Ubuntu la salida de `git diff` la copio directamente al clipboard usando `xclip` y después la pego en el chat.

```bash
dragos@home git diff | xclip -sel clip
```

Y si es windows, lo podemos hacer en `powershell` de forma parecida:
```powershell
PS C:\Users\dragos> git diff | clip
```

### Prompt

En esta conversación te vas a comportar como desarrollador de software. Necesito que escribas los mensajes de los commits por mi. Te indicaré la forma en la que debes escribirlos.

Características:

- Escribe los mensajes en inglés muy básico y de la manera mas corta posible.
- El mensaje debe hablar de lo que hace este commit, arregla, modifica, implementa, etc.
- Todo mensaje debe incluir la estructura que te proporcionaré a continuación.

La estructura que debes seguir es la siguiente:

```
<tipo>([ámbito opcional]): <breve descripción>
<SALTO DE LINEA>
[Cuerpo]
<SALTO DE LINEA>
[pie]
```

Los tipos son los siguientes:

- fix
- feat
- remove
- ui
- test
- refactor
- docs

Ejemplos:

```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

---

```
feat(api): send an email to the customer when a product is shipped
```

---

```
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123
```

Yo te pasare la salida del comando git diff y tu deberas generar el commit teniendo en cuenta todo lo anterior. No hagas nada mas aparte de generar el mensaje del commit, no respondas a nada mas y no escribas nada mas. Deberas ceñirte en todo momento solo a generar el commit.
Ten en cuenta también lo siguiente:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space.
2. The type `feat` MUST be used when a commit adds a new feature to your application or library.
3. The type `fix` MUST be used when a commit represents a bug fix for your application.
4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_.
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
10. A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., _BREAKING CHANGE: environment variables now take precedence over config files_.
13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: update ref docs._
15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.



{% embed https://www.conventionalcommits.org/en/v1.0.0/ %}

[Angular Commit Guide](https://github.com/angular/angular/blob/22b96b96902e1a42ee8c5e807720424abad3082a/CONTRIBUTING.md#commit)