GIT: mejores prácticas - lacoderia/iuvare GitHub Wiki

Flujo de trabajo

Para colaborar efectivamente entre varios desarrolladores necesitamos convenciones y un flujo de trabajo. Inglés es el idioma estándar en programación, así que todos los identificadores, comentarios y código se escribirán en inglés.

¿Cómo comenzar una nueva tarea?

Haz checkout de master y haz pull de master desde el remote de github. En este punto no debería haber conflictos.
Crear branch de trabajo. Haz un branch utilizando la convención indicada más adelante en este documento.

¿Cómo hacer commits?

Cada commit debe tener un título de unas cuantas palabras.
El cuerpo del commit de preferencia debe tener bullets desglosando lo que se hizo a grandes rasgos. Un buen commit encapsula un cambio concreto dentro del feature.

¿Cómo terminar la tarea?

Asegúrate de que tu branch quede limpio. Si quieres experimentar dentro de tu branch de trabajo, puedes crear sub-branches para probar y hacer commits libres. Cuando acabes el trabajo limpia tu branch borrando sub-branches experimentales y haciendo rebase para quedarnos sólo con los commits importantes. Quieres dejar sólo commits con cambios claros y mensajes definidos.
Haz merge de master a tu branch. Un branch está terminado cuando el cambio fue probado manualmente por el developer y tiene debida cobertura con tests automatizados. En ese momento actualiza tu branch con master y resuelve conflictos, después empuja el branch a github y espera a que la herramienta de integración continua Semaphore corra la suite de tests y declare el branch en verde. Entonces estará listo para hacer un pull request a master en github.

Staging

Configurando el automatic deployment de Heroku, master terminará en staging donde el desarrollador volverá a probar el cambio manualmente antes de empujarse a producción.

Producción

Cuando se empuje a producción, el desarrollador le dará una última revisión al cambio para asegurarse de su buen funcionamiento.

¿Qué hacer si algo sale mal en producción?

Si hay algún problema con un cambio en producción, se hará un rollback del cambio, y se comenzará de nuevo desde production en un branch fix. Si el rollback es imposible, podrán hacerse parches o hotfixes sobre producción directamente con consenso del equipo completo de desarrollo.

Nombrado de branches

Nombrar correctamente los branches nos permitirá entender que hay en ellos, ahora y en el futuro. Utilizaremos una convención con diagonales categoria/nombre.

GIT: mejores prácticas - lacoderia/iuvare GitHub Wiki

Flujo de trabajo

Nombrado de branches

Categorías