Est-il préférable d’utiliser la fusion ou le rebase lorsque deux personnes se trouvent sur la même branche d’applications distante et ont des conflits qui seront validés sur svn - git, git-svn, git-rebase, git-merge

Mon collègue et moi discutons activement des stratégies de fusion et j’espère que nous pourrons obtenir de l’information pour résoudre ce problème.

Le tl: dr est: Devons-nous utiliser la fusion ou la rebase pour extraire les modifications d’une branche distante afin de ne pas refaire constamment la résolution du conflit?

• svn: notre référentiel maître
• trunk: suivi des branches distantes git svn. Utilisé pour mettre en scène le changement de git avant de s’engager à subversion.
• feature-branch: branche distante git où le travail de 2 collègues ou plus sur une fonctionnalité est combiné
• collègue1: succursale locale du premier collègue
• collègue2: branche locale du deuxième collègue.

Nous utilisons l’excellent flux de travail de Sébastien Varette de Est-ce que git-svn dcommit après la fusion de git est dangereux?.

Le problème que nous avons est que chaque foiscollègue1 rebase à partir de svn (en rebasant sur le tronc, puis en revenant à collègue1 avant de passer à la branche de fonctionnalité une fois l'opération terminée), puis valide les modifications de branche qui doivent être répétées. La même résolution de conflit doit être faite maintes et maintes fois - chaque fois que le workflow svn rebase est effectué.

Notez que nous utilisons git rebase mirror un-3451 pour cette rebase.

Mon argument est que nous devrions utiliser git merge mirror un-3451. Je crois comprendre que cela produirait un commit qui est marqué par la fusion de deux commits précédents. Par conséquent, git saurait ne pas utiliser les validations précédentes, mais plutôt utiliser le commit de fusion.

Mon collègue, en revanche, soutient queutiliser la fusion rendra la fusion éventuelle avec svn beaucoup plus difficile et préfèrera utiliser rebase. Il trouve cela facile - malheureusement, ce n’est pas lui qui résout tous les conflits. Il soutient que l’utilisation d’un commit squash produirait le même effet.

Mon argument est que la fusion a le même effet qu’un squash, mais inclut le marquage des commits qui ont été inclus.

Etat 1

svn-trunk:      A

git-trunk:       A"

remote-feature:   A"-----C
     /
c1-feature:        A"--C

c2-feature:         A"--D

Etat 2

C est en conflit avec D sur le fichier 1 (F1). F1 a résolu le conflit, donc D devient D ".

git pull --rebase remote feature
git add F1
git rebase --continue
git push

Graphique de validation:

svn-trunk:      A-----B
     (svn rebase)
git-trunk:       A"----B"

remote-feature:   A"-----C---------D"
     /        /
c1-feature:        A"--C        / (git push)
           /
c2-feature:         A"-------C--D"

Etat 3

À présent, collègue1 souhaite intégrer les modifications apportées à svn-trunk:

git checkout trunk
git svn rebase

puis les rebasonner sur c2-feature

git checkout feature-branch
git rebase trunk

Le rebase place B1 sur c2-feature, puis C et ensuite saisit D "et force la même résolution de conflit à devenir D" "

Graphique de validation:

svn-trunk:      A--------B
         (svn rebase)
git-trunk:       A"--------B"
         
remote-feature:   A"-----C-------D"
     / ----  
c1-feature:        A"--C          
               
c2-feature:         A"----------B"-C--D""

Chaque fois le git checkout trunk; git svn rebase; git checkout feature-branch; git rebase trunk; git push remote cycle se produit toutes les résolutions de conflit doivent être fait encore et encore.

Des questions

1. si vous rebase de svn, poussez vers la télécommandebranche, demandez à collègue2 de transmettre certains commits à la branche distante, puis, plus tard, collègue1 effectuera une fusion extraite à partir de la branche distante.
2. Quel est le meilleur dans le scénario ci-dessus: rebase ou fusion?
3. La fonctionnalité rerere serait-elle plus utile?

Merci beaucoup!

Réponses:

0 pour la réponse № 1

Tout d'abord, je vais omettre les nœuds identiques et réorganiser les nœuds de manière à ce que chaque branche ait sa tête comme nœud le plus à droite, pour mieux représenter l'arbre. (corrigez-moi si l'arbre est faux). Mes commentaires sont en gras.

Etat 1

svn-trunk:     A

git-trunk:       A"

c1/remote-feature: ----C



c2-feature:            --D

Ensuite, D a été rebasé en tant que D "sur C. C’est la partie la plus facile (à comprendre). Cela aurait pu être cherrypick (ou" simple "D) s’il n’y avait pas conflit.

Etat 2

C est en conflit avec D sur le fichier 1 (F1). F1 a résolu le conflit, donc D devient D ".

svn-trunk:     A-----B
     (svn rebase)
git-trunk:       A"----B"


c1-feature:         C

c2/remote feature:    D"

Nous arrivons maintenant à la partie difficile.

Etat 3

À présent, collègue1 souhaite intégrer les modifications apportées à svn-trunk:

git checkout trunk
git svn rebase

puis les rebasonner sur c2-feature

git checkout feature-branch
git rebase trunk

Le rebase place B1 sur c2-feature, puis C et ensuite saisit D "et force la même résolution de conflit à devenir D" "

Graphique de validation:

svn-trunk:     A

git-trunk:       A"----B"
     
     
c1-feature:         C     
     
remote feature:       D"    

c2-feature:                   C----D""

J'ai du mal à comprendre lepassage de l’État 2 à l’État 3, car vos commentaires ne semblent pas correspondre à l’état du graphique (ce qui ressemble davantage à une tentative de rebaser une entité c2 / distante sur le tronc (en B "), avec Je crois que ce que tu voulais vraiment, c’est:

Etat souhaité 3

svn-trunk:     A-----B
     (svn rebase)
git-trunk:       A"----B"


c1-feature:               C

c2/remote feature:          D"

ce qui signifie que vous avez été incapable de rebaser A "-C-D"sur A "-B" sans autre résolution du conflit concernant D ", ce qui est étrange, car cela ne devrait pas arriver (j’ai tenté de reproduire cela sur un dépôt git-svn et cela fonctionne comme prévu). même un problème de git-svn puisque vous vous contentez de rebaser une branche de git contre une autre. On dirait vraiment que vous essayez de rebaser correctement, alors je ne peux que présumer que certaines informations manquent, c’est-à-dire que ce que j’ai décrit n’est pas ce qui s’est réellement passé.

---

0 pour la réponse № 2

Je suis collègue2.

Ma position est que ce sont les rebases fréquentes deSVN à notre branche de fonctionnalité qui causent la douleur. Chaque fois que nous modifions à nouveau le jeu de modifications, il est répété par-dessus les modifications apportées au SVN. Les conflits réels sont dans notre ensemble de modifications rejoué.

Idéalement, nous "réduirions notre ensemble de modifications en un seul commit afin que les conflits apparus dans l'ensemble de modifications soient résolus et ne doivent plus être résolus après une nouvelle réinitialisation."

Alternativement, nous pourrions attendre que la branche de fonctionnalité soit terminée et prête à être validée pour pouvoir nous baser sur SVN.

Je ne suis pas convaincu que le fait de changer de baselorsque nous nous attelons à la fusion améliorera notre processus. Le point douloureux est les rebases fréquentes de SVN et je ne crois pas que la fusion entre la branche principale et nos branches locales améliorera la rebase de SVN.

---