Maintenant qu’on a vu ce qui différencie merge de rebase, comment peut-on appliquer tout ça dans nos workflows ?

On va voir qu’on peut généraliser certains principes, et donc on aura plus qu’à acquérir certains réflexes pour les mettre en pratique. Voici donc quelques conseils qui pourront t’être utiles.

Quand je fusionne une branche…

La première habitude à prendre est d’analyser ce qu’on va fusionner et de voir ce qu’on veut en faire par rapport aux éventuelles règles qu’on a pu mettre en place pour régir notre historique.

La question la plus facile revient à déterminer si je veux voir où a commencé et où a fini ma branche dans l’historique et ce qu’elle contient.

Pour m’aider à répondre à cette première question, je peux me demander si j’avais créé cette branche localement en vue d’isoler temporairement un travail, auquel cas je voudrai l’aplanir, et en cas de divergence je la rebaserai pour permettre la fusion en fast-foward.

À l’inverse, si je sais que ma branche représente un travail isolé, par exemple parce qu’elle traite d’une fonctionnalité particulière, alors je voudrai préserver sa visualisation dans mon historique en faisant ce qu’on appelle un “true merge”.

Quand je m'apprête à « pusher » mon travail local…

Ensuite on peut acquérir d’autres réflexes utiles, à commencer par le nettoyage systématique avant le partage. Dans la pratique on peut aussi nettoyer un historique qui est déjà partagé, puisque Git n’impose aucune contrainte à ce niveau. Par contre ça risque être plus galère si d’autres ont pushé entre temps, ou s’ils sont en train de travailler sur la partie qu’on veut nettoyer. Reste donc à savoir comment s’y prendre pour éviter ces galères.

Il arrive souvent aussi que le push soit refusé car nos collègues ont partagé des évolutions entre-temps. Dans ce cas la procédure nous est donnée par Git, on pull et on pushe. Ma recommandation ici est de faire un pull en mode rebase pour garder un historique clean. On reverra ce point en détail plus tard dans ce cours dans le chapitre sur le pull

Enfin, si j’ai partagé trop vite, je peux quand même faire mon rebase localement et forcer le push. Il faut par contre que je sois très vigilant et que j’utilise l’option --force-with-lease, car l’option que les gens ont tendance à utiliser par défaut, le --force, écrase ce qu’il y a en face sans se poser la question de savoir si quelqu’un d’autre a pushé entre-temps

Voilà pour mes petites recommandations de bonnes habitudes à prendre, on reverra certains de ces aspects dans la suite du cours. Maintenant reste bien concentré, on attaque le détail de la fusion…

Bien utiliser Git merge vs rebase

Produire un historique cohérent et utile nécessite de savoir aussi bien nettoyer notre travail que fusionner des branches. Les commandes rebase et merge se complètent parfaitement quand on sait bien les utiliser…