GIT - Réécriture du code principal sur une branche séparée

Question

J'ai ce scénario que je ne pense pas être rare mais j'ai du mal à trouver un exemple de comment cela est fait correctement sur le net.

Nous avons notre projet, avec une branche principale. Pour mon exemple, disons que l'état actuel de la branche principale identifie la version 1.5.0 du projet.

Maintenant, nous décidons d'écrire la version 2.0.0, pour laquelle des changements massifs et des réécritures vont se produire, des fichiers seront complètement supprimés. Cette réécriture se déroule maintenant sur une nouvelle branche que nous appellerons instable.

Environ une semaine après le début du développement sur instable, une fonctionnalité et/ou une correction de bug doit être ajoutée à la version 1.5.0, pas de problème nous disons nouvelle branche - écrire la fonctionnalité - fusionner avec la branche principale. La branche principale est maintenant à la version 1.6.0.

Maintenant, cette correction/fonctionnalité ne s'applique pas à la nouvelle version du projet car le projet entier est en train d'être réécrit.

Nous terminons la version 2.0.0 sur la branche instable qui était initialement basée sur la version 1.5.0 de la branche principale qui est maintenant, disons... à la version 1.8.4 - comment fusionneriez-vous la branche instable avec la branche principale sans : détruire l'historique des versions de 1.5 à 1.8.4 ou laisser des artefacts des versions antérieures à 2.0.0 dans la branche fusionnée et potentiellement casser le nouveau code écrit dans la version 2.0.0?

Answer 1

Vous connaissez probablement déjà git merge -s ours, qui fait exactement le contraire de ce que vous voulez faire : il ignore les modifications de la branche source et permet au résultat de fusion d'être exactement identique au contenu de la branche cible. Il n'y a cependant pas de -s theirs correspondant, pour des raisons que je ne vais pas expliquer ici.

Donc, nous devrons improviser quelque chose qui a le même effet. En gros : effectuer une fusion sans valider, mélanger magiquement le code 2.0.0 et finaliser ensuite la fusion.

Tout d'abord, assurez-vous de ne pas avoir de modifications non validées. Nous allons utiliser des astuces amusantes ici ; garantie annulée et tout le reste.

1. sur master, git merge -n unstable. Le -n garantira que la fusion ne sera pas validée pour le moment, même s'il n'y a pas de conflits (bien sûr, vous rencontrerez des conflits en raison de vos modifications étendues, mais restons prudents).
2. voici la magie : git read-tree --reset -u unstable (lire unstable dans l'index et mettre à jour l'arborescence de travail en conséquence, en ignorant tout conflit)
3. git commit pour finaliser la fusion. Maintenant, l'historique aura à la fois l'ancien et le nouveau, mais seul le contenu 2.0.0 dans l'arborescence.
4. Vérifiez que toute cette manipulation n'a laissé aucun reste de votre version précédente de master en tant que fichiers non suivis. Je ne suis pas sûr que cela puisse se produire, mais cela ne fait pas de mal de vérifier.

Answer 2

C'est tout à propos de comment gérer de grandes branches divergentes. Voici quelques options :

• fusionner : moins qu'idéal car vous obtiendrez de nombreux conflits, et si le noyau a changé, il sera difficile de résoudre et de s'assurer que tout fonctionne.
• fabriquer à la main : inspectez les changements apportés sur master depuis que unstable a divergé, et recodez-les. C'est le cas lorsque vous réalisez que la divergence entre les branches est trop grande, et fusionner n'a aucun sens. Cependant, vous pouvez toujours choisir les commits qui s'appliquent encore. Vous feriez mieux de disposer d'un suivi des problèmes séparé qui répertorie les choses appliquées sur master depuis la séparation des branches.

Remarquez que le rebasage n'est pas une option car la branche master est déjà publiée.

En passant, un projet très intéressant est en version bêta mais semble utilisable : git-imerge. Ce projet permet de fusionner les commits un par un, et de résoudre des conflits beaucoup plus petits.