git-rerere - Réutilise une résolution enregistrée de fusions conflictuelles

Dans un workflow employant des branches de sujet relativement longues, le développeur a parfois besoin de résoudre les mêmes conflits encore et encore jusqu’à ce que les branches de sujet soient faites (soit fusionnées à la branche "release" ou envoyées et acceptées en amont).

Cette commande aide le développeur dans ce processus en enregistrant des résultats d’autofusion en conflit et les résultats correspondants de la fusion manuelle initiale, et en appliquant des résolutions à la main précédemment enregistrées à leurs résultats d’autofusion correspondants.

Normalement, git rerere est exécuté sans arguments ou intervention utilisateur. Cependant, il a plusieurs commandes qui lui permettent d’interagir avec son état de fonctionnement.

Lorsque votre branche de sujet modifie une zone de chevauchement que votre branche principale (ou amont) a touchée depuis que votre branche de sujet en a divergé, vous pouvez la tester avec le dernier master, même avant que votre branche de sujet soit prête à être poussée en amont :

Pour un tel test, vous devez fusionner master et la branche thématique d’une manière ou d’une autre. Une façon de le faire est de tirer master dans la branche thématique :

Les commits marqués de * touchent la même zone dans le même fichier ; vous devez résoudre les conflits en créant le commit marqué +. Ensuite, vous pouvez tester le résultat pour vous assurer que votre travail en cours fonctionne toujours avec ce qui est dans le dernier master.

Après cette fusion de test, il y a deux façons de poursuivre votre travail sur la branche thématique. Le plus facile est de construire par dessus le commit de fusion test +, et lorsque votre travail dans la branche thématique est enfin prêt, fusionner la branche thématique dans master, et/ou demander à l’amont de tirer de vous. A ce moment-là, cependant, le master ou l’amont aurait pu être avancé depuis la fusion de test +, auquel cas le graphe final de commits ressemblerait à ceci :

Lorsque votre branche thématique est au long cours, cependant, votre branche thématique finirait par avoir beaucoup de tels commits de "fusion depuis master" sur elle, qui encombreraient inutilement l’historique de développement. Les lecteurs de la liste de diffusion du noyau Linux se rappellent peut-être que Linus s’est plaint de fusions de tests trop fréquentes lorsqu’un mainteneur d’un sous-système a demandé de tirer d’une branche pleine de « fusions inutiles ».

Comme alternative, pour garder la branche thématique exempte de fusions d’essai, vous pourriez exploser la fusion d’essai, et continuer à construire sur le sommet de la branche avant la fusion d’essai :

Cela ne laisserait qu’un seul commit de fusion lorsque votre branche thématique est enfin prête et fusionnée dans la branche master. Cette fusion vous obligerait à résoudre le conflit introduit par les commits marqués d’un *. Cependant, il s’agit souvent du même conflit que celui que vous avez résolu lors de la création de la fusion de test que vous avez explosée. git rerere vous aide à résoudre cette fusion finale conflictuelle en utilisant les informations de votre résolution à la main précédente.

Lancer la commande git rerere immédiatement après une autofusion conflictuelle enregistre les fichiers d’arbres de travail en conflit, avec les marqueurs de conflit habituels <<<<<<<, ======= and >>>>>>>. Plus tard, après que vous avez fini de résoudre les conflits, exécuter git rerere à nouveau enregistrera l’état résolu de ces fichiers. Supposez que vous avez fait cela lorsque vous avez créé la fusion de test de master dans la branche thématique.

Next time, after seeing the same conflicted automerge, running git rerere will perform a three-way merge between the earlier conflicted automerge, the earlier manual resolution, and the current conflicted automerge. If this three-way merge resolves cleanly, the result is written out to your working tree file, so you do not have to manually resolve it. Note that git rerere leaves the index file alone, so you still need to do the final sanity checks with git diff (or git diff -c) and git add when you are satisfied.

As a convenience measure, git merge automatically invokes git rerere upon exiting with a failed automerge and git rerere records the hand resolve when it is a new conflict, or reuses the earlier hand resolve when it is not. git commit also invokes git rerere when committing a merge result. What this means is that you do not have to do anything special yourself (besides enabling the rerere.enabled config variable).

In our example, when you do the test merge, the manual resolution is recorded, and it will be reused when you do the actual merge later with the updated master and topic branch, as long as the recorded resolution is still applicable.

The information git rerere records is also used when running git rebase. After blowing away the test merge and continuing development on the topic branch:

you could run git rebase master topic, to bring yourself up to date before your topic is ready to be sent upstream. This would result in falling back to a three-way merge, and it would conflict the same way as the test merge you resolved earlier. git rerere will be run by git rebase to help you resolve this conflict.

[NOTE] git rerere relies on the conflict markers in the file to detect the conflict. If the file already contains lines that look the same as lines with conflict markers, git rerere may fail to record a conflict resolution. To work around this, the conflict-marker-size setting in gitattributes[5] can be used.

Fait partie de la suite git[1]

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .