Tutoriel git : Git Workflow

Git est un formidable outil qui a permis de rendre le versioning populaire (et autant dire que ce n'était pas gagné...). Mais il est parfois difficile, surtout au début, de comprendre comment bien organiser son dépôt. Entre les branches, les tags et les commits on se retrouve vite un peu perdu.

On s'accroche aux branches

Je ne parle pas ici des branches juste pour caser mon jeu de mot bien pourri. Les branches constituent la pierre angulaire d'un bon Workflow sur Git.
Lorsque l'on commence un nouveau projet on se retrouve sur un branch master. Cette branche servira à la version production de notre projet. On va donc souvent commencer par créer une nouvelle branche servant au développement (on peut la nommer dev ou utiliser un numéro de version).

git branch dev
# On se rend alors sur notre nouvelle branche
git checkout dev

Mais même sur cette branche on ne commitera jamais nos modification on créera systématiquement une nouvelle branche pour chaque feature que l'on va rajouter à notre projet

# Je vais travailler sur ma homepage
git branch dev-homepage
git checkout dev-homepage

Et là vous pouvez vous en donner à cœur joie et enchainer les commits. Une fois que vous êtes satisfait de votre travail vous pouvez fusionner votre branche de feature avec la branche de développement

# On passe sur la branche de travail
git checkout dev
# On fusionne la branche de la feature
git merge dev-homepage

Et ainsi de suite, on crée une branche pour la feature que l'on souhaite développer, on travaille dessus, on fusionne à la fin. Si vous le souhaitez vous pouvez vous concerter avec les autres développeurs avant de gérer la fusion en question (ça peut être l'occasion de se faire une réunion autour de la machine à café, et parler merge avec george clooney).

Pourquoi une branch par feature ?

Alors là je vous vois venir, pourquoi s'emmerder à créer des branches tout le temps ? Il y a plusieurs avantage avec cette méthode de travaille :

• A plusieurs ça évite d'avoir des conflits tous les 3 commits. Chacun travaillant sur sa branche les conflits ne vont avoir lieux que lors des fusions. Moins de conflit = Moins de perte de temps.
• En un coup d'oeil on peut voir sur quoi les différents intervenant travail
• On évite les commits affectant bcp de modules