Buenas prácticas

Recopilación de aquellas cosas que solemos pasar por alto u olvidar en nuestras actividades cotidianas como desarrolladores.

Los números de versión.

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes. semver.org

Asi, la versión x.y.z representa:

x : Nueva versión.
y : Agregamos una nueva característica.
z : Solucionamos un bug.

Ejemplo:

v0.1.0: Versión de desarrollo inicial con sus primeras características funcionales.
v0.2.0: Versión de desarrollo inicial con nuevas características funcionales.
v0.2.1: Versión de desarrollo inicial que soluciona un bug.
v1.0.0: Versión 1 estable.
v1.0.1: Soluciona bugs de la versión 1.
v1.2.0: Agrega nueva características a la versión 1.
v2.0.0: Versión 2 estable y no compatible con la versión 1.

El nombre de las ramas

Asumiendo que nuestro workflow es gitflow, tenemos:

Ramas fijas

Estas ramas estan bloqueadas para recibir push directos y eliminación.

master: Solo deben recibir cambios desde un PR de una rama release/***.
development: Solo deben recibir cambios desde un PR y pueden venir de cualquier rama.

Ramas temporales

feature/ : Nueva característica.
hotfix/ : Corrección urgente, por lo general sale de master, vuelve a master y a development.
bugfix/ : Corrección no urgente que va a development.
release/ : Rama congelada que se origina desde development y es candidata a lanzamiento.
experimental/ : Usada para hacer pruebas y luego sera descartada.

Ejemplo:

feature/barcode-in-webview
hotfix/crash-login-facebook
bugfix/render-payment-component
release/v1.2.0
release/v1.2.1
experimental/add-material-ui

Usando tags

Importante usar tags para llevar el control de nuestros releases.
Usar semver.
Crear los tags en master (despúes del merge) que viene de la rama release.
El nombre del tag (v2.0.1) debería tener relación con el nombre de la rama release/v2.0.1 que origina el merge

Tipos de merge

Merge a development se sugiere usar squash.
Merge a master con merge normal.
Despúes del merge, eliminar la rama de origen para evitar dejar ramas huerfanas.

Mensajes en nuestros commits

Las siete reglas de un gran mensaje de Git. ref

Separar el asunto del cuerpo con una línea en blanco.
Limite la línea de asunto a 50 caracteres (usa de referencia el parrafo de ejemplo del editor).
Capitalizar la línea de asunto.
No termine la línea de asunto con un punto.
Utilice el modo imperativo en la línea de asunto.
Cada línea del cuerpo no debe exceder los 72 caracteres por línea.
Usa el cuerpo para explicar qué y por qué en lugar del cómo.

Ejemplo

Resume los cambios en alrededor de 50 caracteres o menos

Texto explicativo más detallado, si es necesario. Envuélvelo a unos 72
caracteres más o menos. En algunos contextos, la primera línea se trata
como el asunto y el resto del texto como cuerpo. La
línea en blanco que separa el resumen del cuerpo es crítica (a menos
que omitas el cuerpo por completo); Varias herramientas como `log`,
`shortlog` y `rebase` pueden confundirse si no hay línea en blanco.

En el cuerpo explica el problema que este commit está resolviendo.
Centrarse en por qué usted está haciendo este cambio en lugar de cómo
(el código explicara el cómo).

¿Hay efectos secundarios u otras consecuencias no intuitivas de este
cambio? Aquí puedes explicarlos.

Otros párrafos vienen después de líneas en blanco.

 - Puedes poner listas.

 - Normalmente se usa un guión o un asterisco para la lista, precedido
   por un solo espacio, con líneas en blanco en el medio, pero las convenciones
   variar aquí.

Si utiliza un rastreador de issues, ponga referencias a ellos en la parte inferior,
Algo como esto esto:

Resuelve: #123
Vea también: #456, #789

Pull Request

PR pequeños: Son más fáciles de razonar y aprobar para quien los revisa y tienen menos posibilidades de entrar en conflicto con la rama base. (Referencia)

Gracias a Fernando por las revisiones y aportes a este artículo.