Recomendamos encarecidamente no usar clientes gráficos hasta no tener un control total de los comandos básicos en consola.
Antes de usar un cliente gráfico, debemos de investigar qué hacen internamente las acciones. Puede haber clientes que implementen ciertas acciones de forma distinta a la que esperamos, ocasionando situaciones inesperadas.
Escribe los nombre en inglés y sólo con letras y números, nada de acentos, ñ’s, # o caracteres que puedan dar problemas.
Agrupa las ramas en función del tipo de trabajo, para eso, nombra la rama empezando con el tipo y /, por ejemplo feature/, bugfix/, hotfix/, etc.
NOTA: Mantener la consistencia del proyecto, revisar las agrupaciones que se están usando ya para no crear nuevas.
Usa guiones para separar palabras.
Usa nombres cortos y descriptivos:
# bien
$ git checkout -b oauth-migration
# poco preciso
$ git checkout -b login_fix
Siempre que sea posible, añade el número de ticket:
# Ticket #36500
$ git checkout -b feature/36500--oauth-migration
NOTA: Si no hay número de ticket, es un buen indicador de que debería de haber un ticket, créalo.
Para grandes funcionalidades en las que van a trabajar varias personas, crear una rama específica y crear subcarpetas para las distintas tareas:
# Rama común
$ git checkout -b feature-redesign/master
# Trabajo de back
$ git checkout -b feature-redesign/back
# Trabajo de front
$ git checkout -b feature-redesign/front
NOTA Cuidado con crear múltiples anidaciones ya que puede bloquear ramas. Si existe la rama feature/oauth-migration y se crea la rama feature/oauth-migration/front, la primera será un directorio para Git y no se podrá hacer checkout a ella.
Borra tus ramas personales en local y del repositorio remoto cuando acabes de trabajar en una tarea y ya esté mergeada a master, a no ser que exista alguna razón para mantenerla. Mantengamos los repositorios limpios, ¿acaso no borras tus ramas en casa?
Puedes listar las ramas mergeadas en master con:
$ git branch --merged master | grep -v "\* master"`
Puedes limpiar las ramas remotas que han sido borradas en el repositiorio con:
$ git remote prune origin
CONSEJO: Borra siempre las ramas locales desde master con -d, en el caso de no estar mergeadas no te dejará.
Cada commit debe englobar el menor cambio “lógico” posible en vez de juntar múltiples cambios en un solo commit grande.
Haz commits con lógica cada poco tiempo. Con commits pequeños y atómicos será más fácil entender la historia y revertir cambios si se producen problemas.
Si has acumulado varios commits, al hacerlo procura mantener el orden lógico, es decir si un cambio en un commit depende de otro, el dependiente deberá de hacerse después. Y describe la dependencia en los comentarios.
Escribir mensajes descriptivos y consistentes:
Asunto de menos de 50 carcteres
Explicación detallada de lo acontecido en el ticket
sin pasar de los 72 caracteres. La línea de separación
hará que algunos clientes traten la primera línea como
el asunto y esto como el cuerpo.
Separar más párrafos con saltos de línea.
- También está bien usar bullets.
Información sacada de http://git-scm.com/book/es/v1/Git-en-entornos-distribuidos-Contribuyendo-a-un-proyecto
Por esto, es más recomendable usar un editor para escribir los commits que los commits en línea (-m)
Una alternativa al punto anterior que nos ayude a mantener la consistencia en los mensajes de commit a lo largo de la vida de un proyecto es utilizar una plantilla específica que utilicen todas las personas del equipo de desarrollo y que nos ayude a la hora de trazar cambios en el repositorio.
Para utilizar una plantilla concreta es necesario modificar la configuración de git. Por ejemplo:
git config --global commit.template ~/.gitmessage
Un ejemplo de plantilla podría ser:
# [<jira id>][<tag>] <subject> (Max 72 char)
# |<---- Preferably using up to 50 chars --->|<------------------->|
# Example:
# [PY03173-198][feature] Implement automated commit messages
# (Optional) Explain why this change is being made
# |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->|
# (Mandatory) Provide links or keys to any relevant tickets, articles or other resources
# Example: Jira #23
# --- COMMIT END ---
# Tag can be
# feature : new feature
# fix : bug fix
# refactor : refactoring code
# style : formatting, missing semi colons, etc; no code change
# perf : code improved in terms of processing performance
# docs : changes to documentation
# test : adding or refactoring tests; no production code change
# hack : temporary fix to make things move forward (please avoid it)
# devexp : changes to development tooling
# WIP : Work In Progress (for intermediate commits to keep patches reasonably sized)
#
# Note: Multiple tags can be combined, e.g. [fix][jsr292] Fix issue X with methodhandles
# --------------------
# Remember to:
# * Capitalize the subject line
# * Use the imperative mood in the subject line
# * Do not end the subject line with a period
# * Separate subject from body with a blank line
# * Use the body to explain what and why vs. how
# * Can use multiple lines with "-" or "*" for bullet points in body
# --------------------
Debemos unificar el idioma a usar en código y mensajes como commits, issues…
Está bien intentar escribirlo todo en inglés para forzarnos y practicar, de echo si trabajásemos en un solo producto parecería el caso ideal, pero en ocasiones puede derivar en comentarios cortos, imprecisos o mal explicados. Para cumplir con el objetivo de comunicar la información de la mejor manera a los compañeros que están o llegan a un proyecto aplicaremos las siguientes reglas: