Antes de ponernos a trabajar con ningún repositorio, debemos de configurar las opciones generales de Git para nuestro flujo de trabajo.
Configura nombre y correo asociados a los commits:
$ git config --global user.name ‘Nombre’
$ git config --global user.email ‘[email protected]’
Configuramos las opciones por defecto para pull y merge.
$ git config --global merge.ff false
$ git config --global branch.autosetuprebase always
Con merge.ff false, hacemos que todos los merges sean –no-ff, es decir que siempre se genere un nuevo commit al hacer un merge. Por defecto los commits en Git son fast-forward, es decir, que si no tienen la necesidad crear un nuevo commit dejarán las cabezas de las dos ramas a mergear en el mismo punto, dejando la rama mas limpia, pero la historia menos descriptiva. Nosotros preferimos optar por tener toda la información posible en la historia, así podremos ver de que rama estaba viniendo un commit.
Con branch.autosetuprebase always forzamos que el comando git pull haga siempre un rebase para actualizar las ramas remotas con las locales. Al tener el merge como no-ff, siempre nos dejaría un commit al hacer pull, y en este caso no aporta nada a la historia global del repositorio.
NOTA: mucho ojo si ya has empezado a trabajar con Git y activas el autorebase posteriormente. Esta opción añade la opción cundo se crea una rama, por lo que las ramas ya creadas anteriormente no la tendrán. Para añadirla, edita el fichero .git/config del proyecto en cuestion y añade rebase = true en las ramas que no lo tengan. Por ejemplo:
[branch "master"]
remote = origin
merge = refs/heads/master
rebase = true
.github/pull_request_template.md del proyecto la plantilla para las pull requests. De esta forma todas las pull requests que se generen en el proyecto tendrán la misma estructura lo que ayudará a unificar criterios y facilitar las revisiones.Con el fin de ayudarnos a revisar antes de hacer un commit, un push, etc, podemos añadir hooks de ayuda por defecto en nuestros proyectos:
Los hooks no deben depender del proyecto, sólo al propio repositorio, por lo tanto hooks que pasen pruebas, formateos y demás que dependan del stack de cada uno, deberan de ser gestionados personalmente. Aqui puedes encontrar una guía de instalación y algunos hooks interesantes.