Le squashing pull request casse-t-il l'algorithme de fusion de git?

Je travaille actuellement pour une entreprise qui utilise VSTS pour gérer le code git. La méthode "recommandée" de Microsoft pour fusionner une branche consiste à effectuer une "fusion de squash", ce qui signifie que toutes les validations pour cette branche sont écrasées dans une nouvelle validation incorporant toutes les modifications.

Le problème est, que se passe-t-il si je fais des changements dans une branche pour un élément de backlog, puis que je veux immédiatement commencer à faire des changements dans une autre branche pour un autre élément de backlog, et ces changements dépendent du jeu de changements de la première branche?

Je peux créer une branche pour cet élément de backlog et la baser sur la première branche. Jusqu'ici tout va bien. Cependant, quand vient le temps de créer une demande de tirage pour moi, la deuxième branche, la première branche a déjà été fusionnée dans master et parce que cela a été fait comme une fusion de squash, git signale un tas de conflits. C'est parce que git ne voit pas les validations d'origine sur lesquelles la deuxième branche était basée, il voit juste la fusion d'un seul gros squash et donc afin de fusionner la deuxième branche pour la maîtriser, il essaie de rejouer toutes les validations de la première branche dans sommet de la fusion de squash, provoquant de nombreux conflits.

Donc ma question est, existe-t-il un moyen de contourner cela (autre que de ne jamais baser une branche de fonctionnalité sur une autre, ce qui limite mon flux de travail) ou la fusion de squash brise-t-elle simplement l'algorithme de fusion de git?

Avec Git, s'engage

• sont immuables,
• et former un graphique acyclique dirigé.

Le squashing ne combine pas les commits. Au lieu de cela, il enregistre une nouvelle validation avec les modifications de plusieurs autres validations. Le reclassement est similaire, mais ne combine pas les validations. L'enregistrement d'un nouveau commit avec les mêmes modifications qu'un commit existant est appelé réécriture de l'historique . Mais comme les commits existants sont immuables, cela doit être compris comme «écrire une histoire alternative».

La fusion essaie de combiner les modifications de deux historiques (branches) de commit à partir d'un commit ancêtre commun.

Regardons donc votre histoire:

                                 F  feature2
                                /
               1---2---3---4---5    feature1 (old)
              /
-o---o---o---A---o---o---S          master

A est l'ancêtre commun, 1–5 la branche de fonction d'origine, F la nouvelle branche de fonctionnalité et S la validation écrasée qui contient les mêmes modifications que 1–5. Comme vous pouvez le voir, l'ancêtre commun de F et S est A. En ce qui concerne git, il n'y a pas de relation entre S et 1–5. Ainsi, la fusion de master avec S d'un côté et feature2 avec 1–5 de l'autre sera en conflit. Résoudre ces conflits n'est pas difficile, mais c'est un travail inutile et fastidieux.

En raison de ces contraintes, il existe deux approches pour gérer la fusion / écrasement:

• Soit vous utilisez la réécriture de l'historique, auquel cas vous obtiendrez plusieurs validations qui représentent les mêmes changements. Vous devez ensuite rebaser la deuxième branche de fonctionnalité sur la validation écrasée:

                                   F  feature2 (old)
                                  /
                 1---2---3---4---5    feature1 (old)
                /
  -o---o---o---A---o---o---S          master
                            \
                             F'       feature2
  

• Ou vous n'utilisez pas la réécriture de l'historique, auquel cas vous pourriez obtenir des commits de fusion supplémentaires:

                                   F  feature2
                                  /
                 1---2---3---4---5    feature1 (old)
                /                 \
  -o---o---o---A---o---o-----------M  master
  

  Lorsque feature2 et master sont fusionnés, l'ancêtre commun sera validé 5.

Dans les deux cas, vous aurez un effort de fusion. Cet effort ne dépend pas beaucoup de laquelle des deux stratégies ci-dessus vous choisissez. Mais assurez-vous que

• les branches sont de courte durée, pour limiter la distance à laquelle elles peuvent dériver de la branche principale, et que
• vous fusionnez régulièrement master dans votre branche de fonctionnalité, ou rebasez la branche de fonctionnalité sur master pour garder les branches synchronisées.

Lorsque vous travaillez en équipe, il est utile de coordonner qui travaille actuellement sur quoi. Cela permet de limiter le nombre de fonctionnalités en cours de développement et de réduire le nombre de conflits de fusion.

La fusion de squash interrompt l'algorithme de fusion pour toutes les branches contenant des commits supprimés par le squash. Autrement dit, les rebases sont virales. Si vous rebase une branche, vous devez rebaser toutes les autres branches qui dépendent de cette branche. Si vous utilisez rerere , les conflits de fusion que vous avez résolus manuellement dans votre référentiel local n'auront plus besoin d'être résolus manuellement, mais cela n'aide pas les conflits résolus par d'autres personnes.

C'est pourquoi notre règle non écrite ici est qu'il est correct de squash tant que personne d'autre n'a jamais dépendu de votre branche de fonctionnalité, ce qui est peut-être le cas dans 90% des cas. Sinon, une fusion directe aide tout le monde à éviter les problèmes.