Git Fusion - ce qui arrive à la fusion de deux branches en même temps

Question

J'ai une compréhension peu claire de la fusion sur git, que je voudrais comprendre correctement. Disons que j'ai un fichier F sur la branche master, qui a déjà 100 LOC. Je crée une branche A à partir du maître, et j'écris 50 LOC, commence de la ligne 101e à la ligne 150e. Je crée une demande de fusion pour fusionner la branche A en master. Donc, si la branche A sera fusionnée, alors le fichier F sur le maître aura 150 LOC

Supposons que la branche A n'est pas encore fusionnée avec le maître, toujours en attente. Et je crée une nouvelle branche B à partir du maître. J'écris aussi 50 LOC, commence aussi de la ligne 101 à 150 (parce que la branche A n'est pas encore fusionnée). Je crée aussi une MR pour la branche B

Que se passera, si 2 personnes avis 2: et MRs

1. Ils fusionnent 2 MRs en même temps? Le maître aura-t-il un conflit, parce que les deux branches veulent fusionner entre la 101e et la 150e? Si la branche A est fusionnée en premier, signifie que le maître a déjà 150 LOC, mais que la branche B commence toujours de la ligne 101 à la 150, car elle a été créée à partir du maître alors qu'elle avait encore 100 LOC. Y aura-t-il également un conflit lorsque B sera fusionné? Ou comment Git les gère-t-il?

Merci à l'avance (je ne suis pas un troll, je veux juste comprendre des choses, dans le cas où certaines personnes vont marquer cette question)

Answer 1

Quelque chose à préciser que je pense: les conflits et fusionner les stratégies sont un concept de git lui-même. "Merge request", OTOH, est un concept de gitlab (et d'autres hôtes de repo ont des concepts similaires) mais ne veut rien dire du tout. Il est préférable de répondre à votre question en parlant de git; il suffit donc de savoir qu'une requête de fusion est un workflow par lequel une opération de fusion peut être démarrée dans git. Alors, nous allons prendre votre question en deux parties:

séquentielle Fusionne

Réponse courte: il y aura probablement un conflit.

L'existence d'un conflit dépend de la stratégie de fusion. Mes tests suggèrent qu'il y aurait typiquement un conflit, comme git voit des changements alternatifs dans les lignes 101-150. Puisque les deux ensembles de changements sont des ajouts, je suppose que vous pourriez concevoir les deux ensembles de lignes ajoutées sans conflit - bien que l'ordre irait po. Vous pouvez faire git essayer de le faire en utilisant le pilote de fusion union; Vous pouvez dire à git de résoudre les fusions de différentes manières via les arguments de la ligne de commande, mais comme ces instructions s'appliquent à la totalité du commit - pas seulement le fichier où cette condition est configurée - vous ne voudriez généralement pas à. Vous pouvez utiliser .gitattributes pour influencer comment git fusionne juste le fichier, si vous pouvez savoir à l'avance quand cette approche sera correcte pour le fichier (entier). Donc, il y a beaucoup d'options pour changer le comportement de merge - trop de détails à détailler ici sans connaître un résultat spécifique désiré. Mais généralement, cela fonctionne bien d'utiliser les paramètres de fusion par défaut et de résoudre les conflits quand ils se produisent, dans mon expérience de toute façon.

simultanées Fusionne

Il est pas vraiment possible pour deux fusions de se produire « en même temps » dans un seul repo. Si un hôte fournit un moyen de démarrer une fusion directement sur le repo hébergé (origin) - ce que je ne sais pas que quiconque le fait, mais pour des raisons d'argument - alors une fusion devrait être complétée en premier, et l'autre voir le résultat de cette fusion comme point de départ; Donc, voir la partie précédente de la réponse pour cela. Cela peut arriver, une personne peut effectuer une fusion sur un dépôt, et une autre personne peut effectuer une autre fusion sur un second dépôt, et il peut y avoir des conflits quand ils essaient tous deux de se synchroniser avec la télécommande. Et voici comment cela pourrait ressembler:

(Notez que tout au long de cet exemple, je suis en supposant vrai fusionne - à savoir ce qui se passerait si vous utilisez l'option no-ff Les graphiques de fusion pourrait être plus simple, mais les résultats seraient. même aussi loin que les conflits vont, si ont été autorisés se confond rapidement vers l'avant.)

Ainsi, le repo commence avec

  B <--(branch_B) 
     /
x -- x -- O <--(master) 
      \ 
      A <--(branch_A) 

Tous les commits contiennent un seul fichier. Dans O ce fichier a 100 lignes. A et B ajoutent chacun 50 nouvelles lignes à la fin du fichier.

Maintenant Alice fusionne branch_A et Bob fusionne branch_B, chacun dans leur dépôt local. Alors Alice a

  B <--(branch_B) 
     /
x -- x -- O -- MA <--(master) 
      \/
      A 
      ^-(branch_A) 

et Bob a

  v-(branch_B) 
      B 
     /\ 
x -- x -- O -- MB <--(master) 
      \  
      A <--(branch_A) 

Pour partager leur travail, ils essaient de toujours push-origin; et tout comme avec merge s, l'un terminera le premier avant que l'autre ne commence, même s'il essaie de commencer à pousser exactement au même moment. Alice obtient son push, et origin est mis à jour pour ressembler à son locale. Lorsque Bob essaie de pousser, il obtient une erreur parce que son master est derrière le master sur origin (ou, on pourrait dire, derrière origin/master une fois qu'il a été mis à jour, en supposant des mappages typiques). Donc, Bob doit pull (ou fetch et merge) avant de pouvoir le push. Pour illustrer le plus clairement, supposons qu'il est fetch es. Maintenant, il a

 v-(branch_B) 
      B 
     /\ 
x -- x -- O -- MB <--(master) 
      |\ 
      | MA <--(origin/master) 
      |/ 
      A <--(branch_A) 

et pour compléter l'effet d'un pull, il doit fusionner origin/master dans master - même si ce cas se résume au scénario « de fusion séquentielle » couverte d'abord. En fait, si vous tracez le même scénario en utilisant des fusions rapides, il sera clair que la "deuxième fusion" nécessaire ici est exactement la même que la "deuxième fusion" si tout a été fait par un utilisateur dans un repo.