Résoudre une partie du conflit dans un fichier dans GIT

Question

Le scénario dont je voudrais discuter est J'ai un référentiel de fusion qui est un référentiel partagé dans lequel les développeurs vont cd pour résoudre les conflits de fusion.

1. Il existe deux ou plusieurs conflits de fusion dans un seul fichier.
2. chaque conflit doit être résolu utilisateur différent.
3. chaque développeur cd dans ce référentiel pour résoudre les conflits de fusion.
4. laisser dire foo.c a 3 conflits de fusion
5. un utilisateur résout un conflit foo.c et n'enregistre dans un outil de fusion graphique

Maintenant GIT reconnaît que « git add » bien qu'il y ait sont encore des conflits dans d'autres parties du fichier. Ensuite, si un autre développeur fait "git mergetool foo.c" cela ne fait pas apparaître foo.c pour les conflits.

Existe-t-il un outil graphique qui résout ce problème? Permet à plusieurs utilisateurs de résoudre et d'enregistrer des conflits dans le même fichier.

Answer 1

Ce scénario ne fait pas vraiment de sens ...

Tout d'abord, s'il y a un conflit, alors que le conflit existe uniquement sur une commit de fusion, qui n'existe pas encore! (Il est toujours sur la machine de l'utilisateur, éventuellement dans l'index, mais certainement pas même dans son arbre local).

Les autres utilisateurs n'ont aucun conflit, jusqu'à ce qu'ils effectuent une fusion ou rebase.

Supposons que trois utilisateurs effectuent exactement la même fusion, quelle qu'en soit la raison, et qu'ils ont donc les mêmes conflits. Supposons en outre qu'ils ont, comme vous le suggérez, chacun un conflit qu'ils sont seuls à pouvoir réconcilier, puis qu'ils doivent chacun rebaser leur travail sur la dernière version du code, et réconcilier tout conflit dans le processus.

la situation que vous semblez décrire est-à-dire, comme suit: (corrigez-moi si je me trompe):

1. Nous avons trois devs, Charlie, John et Matt, qui sont tous travailler hors de la branche maîtresse, qui est au commit aaaaaaa.
2. Ils fonctionnent tous également sur une branche 'instable', qui est à commit bbbbbbbb, qui a divergé de 'master'.
3. Ils tous, en même temps, décident qu'ils doivent fusionner la branche 'unstable' en 'master', individuellement.
4. Ils tous, en même temps, se rendent compte qu'ils ont des engagements qu'ils ne peuvent pas réconcilier.

Idéalement, ce qui devrait être fait dans cette situation, c'est que 'unstable' devrait être fusionné par n'importe quel développeur qui sait comment faire la fusion. Peut-être qu'ils choisiront de fusionner quelques commits à la fois, plutôt que de fusionner directement les deux têtes, ou peut-être qu'ils choisissent de rebaser le tout - peu importe, mais un seul développeur a besoin de faire cela.

The more frequently this is done, the easier the merge/rebase operation will be. 

Les développeurs restants pourront ensuite utiliser la validation de fusion.