├── .gitignore ├── README.md └── img ├── combo-de-cambios.png ├── espacios-raros.png ├── metrics-01.png ├── metrics-02.png ├── metrics-03.png └── service-auth-01.png /.gitignore: -------------------------------------------------------------------------------- 1 | # -------------------- 2 | # OSX Files 3 | # -------------------- 4 | .DS_Store 5 | .AppleDouble 6 | .LSOverride 7 | Icon 8 | ._* 9 | .Spotlight-V100 10 | .Trashes 11 | 12 | # -------------------- 13 | # Eclipse or Nodeclipse "Enide Studio" Files 14 | # -------------------- 15 | # recommended to add to Git SCM 16 | # or generate with `nodeclipse -p` command 17 | .project 18 | .settings/ 19 | .*.md.html 20 | 21 | 22 | # -------------------- 23 | # IntelliJ Files 24 | # -------------------- 25 | *.iml 26 | *.ipr 27 | *.iws 28 | .idea/ 29 | 30 | # -------------------- 31 | # Netbeans Files 32 | # -------------------- 33 | nbproject/private/ 34 | build/ 35 | nbbuild/ 36 | dist/ 37 | nbdist/ 38 | nbactions.xml 39 | nb-configuration.xml 40 | 41 | # -------------------- 42 | # SublimeText Files 43 | # -------------------- 44 | *.sublime-project 45 | *.sublime-workspace 46 | 47 | # -------------------- 48 | # Node Files 49 | # -------------------- 50 | .nodemonignore 51 | npm-debug.log 52 | node_modules/ 53 | 54 | # -------------------- 55 | # SASS Files 56 | # -------------------- 57 | .sass-cache/ 58 | 59 | # -------------------- 60 | # Bower Files 61 | # -------------------- 62 | .bower-*/ 63 | bower_components 64 | 65 | # -------------------- 66 | # Other Files 67 | # -------------------- 68 | *.log 69 | AMBIENTE-AMQP/ 70 | *.dump 71 | 72 | 73 | # Emacs rope configuration 74 | .ropeproject 75 | .project 76 | .pydevproject 77 | .settings 78 | 79 | # pyenv version file 80 | .python-version 81 | 82 | # Python 83 | *.py[co] 84 | 85 | ## Packages 86 | *.egg 87 | *.egg-info 88 | dist 89 | build 90 | eggs 91 | parts 92 | bin 93 | var 94 | sdist 95 | deb_dist 96 | develop-eggs 97 | .installed.cfg 98 | 99 | ## Installer logs 100 | pip-log.txt 101 | 102 | ## Unit test / coverage reports 103 | .coverage 104 | .tox 105 | 106 | ## Translations 107 | *.mo 108 | 109 | ## paver generated files 110 | /paver-minilib.zip 111 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Convenciones para mensajes de commits 2 | Git es una gran herramienta para llevar un control de los cambios realizados en nuestro código a lo largo del tiempo, sin embargo, esto se vuelve una tarea imposible de realizar si en cada repositorio encontramos mensajes de commits como los siguientes: 3 | 4 | ![combo-de-cambios](/img/combo-de-cambios.png) 5 | 6 | ![espacios-raros](/img/espacios-raros.png) 7 | 8 | ![metrics-01](/img/metrics-01.png) 9 | 10 | ![metrics-02](/img/metrics-02.png) 11 | 12 | ![metrics-03](/img/metrics-03.png) 13 | 14 | ![service-auth-01](/img/service-auth-01.png) 15 | 16 | Para terminar de una vez por todas con este tipo de prácticas y hacer un uso más correcto de la poderosa herramienta que es git, se han definido una serie de convenciones que deberás aplicar a la hora de redactar un mensaje de commit. 17 | 18 | ## Tabla de Contenido 19 | * [Objetivos](#objetivos) 20 | * [Log de cambios](#log-de-cambios) 21 | - [Comandos útiles](#comandos-útiles) 22 | * [Información clara y detallada de los cambios realizados](#información-clara-y-detallada-de-los-cambios-realizados) 23 | * [Formato del mensaje](#formato-del-mensaje) 24 | - [Primera línea del mensaje type, scope y subject](#primera-línea-del-mensaje-type,-scope-y-subject) 25 | - [Type](#type) 26 | - [Scope](#scope) 27 | - [Subject](#subject) 28 | - [Inicia el subject con mayúscula](#inicial-el-subject-con-mayúscula) 29 | - [No termines el subject con un punto](#no-termines-el-subject-con-un-punto) 30 | - [Usa el modo imperativo en el subject](#usa-el-modo-imperativo-en-el-subject) 31 | * [Body](#body) 32 | - [Cada linea del body no debe exceder los 72 caracteres](#cada-linea-del-body-no-debe-exceder-los-72-caracteres) 33 | - [El body debe responder las preguntas ¿qué cambió? y ¿por qué? en vez del ¿cómo cambió?](#el-body-debe-responder-las-preguntas-¿qué-cambió?-y-¿por-qué?-en-vez-del-¿cómo-cambió?) 34 | - [El body puede ser omitido](#el-body-puede-ser-omitido) 35 | * [Footer](#footer) 36 | * [Tips](#tips) 37 | - [El mensaje se redacto mal](#el-mensaje-se-redacto-mal) 38 | 39 | ## Objetivos 40 | Los principales objetivos que se buscan cumplir con la aplicación de estas convenciones son los siguientes: 41 | 42 | - Ofrecer información clara y detallada acerca de los cambios realizados 43 | - Poder generar, vía script, un log de cambios (CHANGELOG.md) que agrupe los commits más relevantes de cada versión 44 | 45 | ## Log de cambios 46 | 47 | Lo más probable es que alguna vez te hayas topado, en algún repositorio, con el archivo CHANGELOG.md y si has sido lo suficientemente curioso como para leerlo, te habrás dado cuenta de que este contiene la información de los cambios, correcciones, adiciones y mejoras que contempla la versión liberada del proyecto. 48 | 49 | Este tipo de archivos tiene cierta disposición, la cual hace más fácil ubicar dichos cambios y correcciones. 50 | 51 | En nuestro caso, el archivo CHANGELOG.md se encuentra compuesto por tres secciones principales: nuevas funcionalidades (new features), correcciones de bugs (bug fixes) y cambios a lógicas previamente establecidas (breaking changes); cambios que se tiene que considerar para no romper nada. Este es generado automáticamente cada vez que se libera una nueva versión (release). Es posible editar el log de cambios una vez generado. 52 | 53 | ### Comandos útiles 54 | ``` 55 | git log HEAD --grep 56 | ``` 57 | Lista todos los subjects (primera línea del mensaje del commit) agrupados por el tipo de cambios del último release (tag). 58 | 59 | *Nota: Se está trabajando en el script para lograr este objetivo* 60 | 61 | ## Información clara y detallada de los cambios realizados 62 | 63 | Como seguramente habrás leído o escuchado alguna vez, “la información es poder” y, en el caso de git, esta es una verdad aplicada, ya que con cada commit que realices, estás brindando el poder (tanto a ti como a los demás) de moverse en cualquier punto del ciclo de desarrollo del proyecto. Esto es algo bastante útil y valioso dado que nos permite regresar sobre nuestros pasos, probar nuevos caminos o simplemente observar la evolución de nuestro desarrollo. Pero para lograr obtener este poder, es necesario que nuestros mensajes de commits estén construidos de tal forma que cada línea redactada nos muestre cada cambio, adición o refactorización realizada. 64 | 65 | Esta forma la veremos a lo largo de los siguientes párrafos. 66 | 67 | ## Formato del mensaje 68 | El formato que debes de usar y respetar para todos los mensajes de commits es el siguiente: 69 | 70 | ``` 71 | (): 72 | 73 | 74 | 75 |