Comment éviter les conflits de git en équipe?
Nous sommes des développeurs qui travaillent sur le même projet et nous utilisons git pour le projet. Si deux ou plusieurs d'entre nous travaillent sur le même fichier, nous recevons des conflits git difficiles à gérer, parfois les modifications apportées par un développeur sont perdues lorsque ces conflits surviennent.
Comment travaillent-ils avec git en équipe? Quel devrait être le bon flux afin d'éviter les conflits de git?
Merci d'avance.
Eh bien, pour être vraiment honnête, le bon flux de travail implique une bonne communication et une bonne gestion. Les membres de l'équipe ne devraient pas souvent travailler sur la même chose et provoquer des conflits. Des choses comme les affrontements quotidiens, et un manager attentif qui sait ce que fait chaque membre de l'équipe - du moins en général - vont beaucoup dans la plupart des cas pour limiter cela.
Cela dépend de la nature exacte du produit, bien sûr, mais il s’agit plus d’un problème d’organisation que d’un problème de git. En fait, les conflits sont souvent considérés comme de «bonnes» choses, car ils amènent les gens à se lever de leur bureau ou à s’appeler pour s’expliquer sur la raison d’un conflit et sur les mesures à prendre. C'est l'occasion de comprendre qu'une personne devrait posséder un domaine ou un ensemble de fichiers, ou du moins être le point de contact pour discuter des modifications apportées à cette section.
En dehors de la création d'un plan initial, il n'y a aucun moyen d'éviter les conflits de git, mais ce serait le même problème dans n'importe quel système de gestion de versions. Chaque fois que deux personnes changent la même section de code, vous devez déterminer qui gagne. C'est pourquoi il n'est pas vraiment approprié de rechercher la solution dans le versionneur, mais plutôt dans les méthodes et les pratiques de votre équipe. Deux voitures ne peuvent pas traverser une intersection en même temps, mais il est extrêmement difficile d'inventer des voitures qui peuvent se traverser. C'est pourquoi nous avons inventé les systèmes de contrôle des panneaux d'arrêt et des feux de circulation. C'est un problème similaire. Nous ne pouvons pas vraiment apporter deux modifications à la même chose sans créer de conflit, nous devons donc contrôler la façon dont nous travaillons avec les fichiers.
Vous pourriez considérez l’un des frontaux permettant le verrouillage en git, mais je ne suis pas vraiment d’accord avec le concept, en dehors des types de fichiers non fusionnables. Je pense qu'il est préférable de trouver un meilleur flux de travail d'équipe et, en attendant, de profiter de cette opportunité pour vraiment bien fusionner des fichiers. C'est ce que j'ai fait et maintenant, après des mois, les conflits ne me dérangent pas.
Il n'y a qu'un moyen d'éviter les conflits: ne pas demander à différentes personnes de modifier le même fichier en même temps. Chaque fichier a essentiellement un propriétaire qui est responsable de toutes les modifications et qui peut transférer la propriété à un autre. La propriété d'un fichier peut être transmise en fonction d'une entité/branche particulière ou au jour le jour, à condition que la propriété soit clairement définie.
Si vous constatez que vous ne pouvez pas attribuer un propriétaire à chaque fichier, alors:
- vous devez diviser vos fichiers en fichiers plus petits pouvant être attribués à un propriétaire
- il faut absolument que les conflits GIT soient résolus (tous les éditeurs s'assoyant ensemble pour résoudre les conflits individuels).
- Utilisez un bon outil de fusion multiple pour visualiser puis résoudre les conflits.
Commande.
Il y a quelques autres choses que vous pouvez faire qui pourraient vous aider aussi… .. Ce sera plus clair si je les publie séparément.
Le lieu où vous insérez de nouvelles choses vous aidera à déterminer si vous créez des conflits.
Imaginez une liste de noms d'employés
Andy,
Oliver,
Ivan,
Ensuite, Brad et Patrick se joignent à eux et leurs noms sont ajoutés à la liste ..__ Vous ajoutez Brad et moi ajoutez Patrick. Nous ajoutons tous deux les noms au bas de la liste, puis utilisons git pour fusionner nos listes. Le résultat sera familier aux utilisateurs de git: -
Merge branch 'Patrick' into Brad
Conflicts:
names.txt
@@@ -1,4 -1,4 +1,8 @@@
Andy,
Oliver,
Ivan,
<<<<<<< HEAD
+Brad,
=======
+ Patrick,
>>>>>>> Patrick
Supposons maintenant que nous ayons fait la même chose mais que nous ayons imposé une simple règle de classement alphabétique sur notre liste. Maintenant, lorsque nous venons de fusionner les deux branches, les résultats sont un peu plus satisfaisants:
Andy,
Ivan,
Oliver,
Ajoutez vous-même un nom, puis fusionnez la modification de l'autre personne avec git pour ajouter l'autre nom.
Auto-merging names.txt
Merge made by the 'recursive' strategy.
names.txt | 1 +
1 file changed, 1 insertion(+)
Et nous obtenons
Andy,
Brad,
Ivan,
Oliver,
Patrick,
Comme nous ne savons pas qui va prochainement rejoindre la société, nous ajoutons effectivement la liste au hasard et, en l'insérant dans des emplacements aléatoires, les conflits d'emplacement dans les fichiers sont moins probables.
Utiliser le bloc ajouté commence
Dans un logiciel comme celui-ci ...
function chess()
{
while (!end_of_game)
{
make_move()
les lignes des blocs de départ avec des accolades d'ouverture vont facilement être confondues avec d'autres lignes du logiciel consistant en des accolades d'ouverture simples. Si le même logiciel est écrit ainsi, ajouter le bloc aux lignes précédentes ...
function chess() {
while (!end_of_game) {
make_move()
ce que je n'aime pas personnellement, mais Git si, / il y a beaucoup moins de lignes qui ressemblent à Git et se font prendre pour mutuelles, c'est-à-dire que Git est plus susceptible de percevoir l'édition de la même manière que nous, ce qui conflits beaucoup plus faciles à résoudre.
Et des commentaires sur les fins de blocs
Utilisez les commentaires pour distinguer les lignes qui se ressemblent.
Si vous écrivez beaucoup de javascript et de JSON, vous aurez peut-être beaucoup de lignes qui ressemblent un peu à ceci.
}
}
}
)
Si vous commentez des choses, elles peuvent devenir distinctes.
}
}
}
) // end of weekdays()
et
}
}
}
) // end of weekend()
ne ressemble plus à git. Cela peut aider Git à mieux comprendre vos changements. Si vous ajoutez quelque chose, comme
function a()
{
...
} // end of a()
git est plus susceptible de voir cela comme une unité de changement et de ne pas penser que vous avez ajouté quelque chose comme
}
function a()
{
...
juste avant la fin d'une autre fonction. Même si cela n’empêche pas les conflits, si git voit et présente vos changements de manière judicieuse (c’est-à-dire la façon dont nous les voyons mentalement), vous pourrez peut-être résoudre les conflits plus facilement. Un en-tête descriptif commentant les fonctions, les paramètres, etc. aidera à empêcher git de confondre le contenu des fonctions voisines.
Informez vos collègues lorsque vous avez poussé vos modifications
Une autre façon de réduire la douleur liée aux conflits consiste simplement à informer vos collègues lorsque vous avez poussé vos changements. Cela leur permet d'extraire vos modifications et de résoudre certains conflits sur-le-champ. Tous les conflits sont susceptibles d’être entre votre changement récent, frais dans votre esprit et ce sur quoi ils travaillent, frais dans leur esprit.
Si les personnes ne retirent pas les modifications de la branche principale avant d'avoir terminé un grand développement et qu'elles soient ensuite en conflit avec les modifications apportées par un certain nombre de personnes, toutes situées dans la même zone, la tâche sera plus difficile à résoudre.
Utiliser un outil de fusion
L'un des objectifs de Git est le contrôle de version. D'autres programmes sont spécialisés dans la fusion de fichiers et la résolution de conflits. Si vous configurez un outil merget à utiliser avec git, il résoudra automatiquement de nombreux problèmes considérés par git comme un conflit ou, du moins, vous donnera une très bonne idée de l'inspection et la laissera simplement intacte s'il semble bon ou si vous faites confiance à l'outil. .
Cela laisse moins de conflits authentiques pour lesquels une résolution intelligente est nécessaire.
Utilisez des fichiers plus petits
J'ajoute un nouveau contrôleur au bas de mycontrollers.js et vous ajoutez un nouveau contrôleur au bas de yourcontrollers.js: aucun problème.
Nous avons tous deux ajouté un nouveau contrôleur au bas de allcontrollers.js: conflict.
(Cependant, souvenez-vous également de l'ordre alphabétique des commandes. MyNewController () commençant par M peut être placé au milieu d'un fichier et yourNewController () commençant par Y peut se trouver à la fin du même fichier, encore une fois sans conflit.)
Pour réduire le nombre de conflits dans le contrôle de version sans se soucier de qui édite quoi, il vous suffit d’apporter des modifications plus petites et de les valider/pousser de manière incrémentielle. Divisez le problème en suffisamment de petites parties pour que vous puissiez rapidement modifier les fichiers et les remettre au coffre. Plus vos succursales ont une vie courte, moins il y aura de risques de fusion.
Même alors, à un moment donné, deux personnes éditeront le même fichier en même temps sans que ce soit leur faute. La question évidente lorsque cela se produit est la suivante:
"Comment puis-je me libérer de la résolution de conflits géniaux?"
La réponse est que vous devez tirer le tronc et rebaser votre branche dessus fréquemment, et vous remarquerez les conflits le plus tôt possible, alors qu'ils sont encore petits. À ce stade, les deux développeurs doivent s'asseoir ensemble et discuter calmement de la meilleure façon de procéder, alors que les changements sont frais dans leur esprit.
Contrastez cette approche en essayant de résoudre les conflits sur d'énormes branches longtemps vivantes et en panique juste avant la date limite de publication, lorsque les développeurs ont du mal à se rappeler la pensée qui sous-tend tous les changements qu'ils ont apportés il y a quelque temps.
Utilisez UTF-8 et non UTF-16 pour les fichiers texte.
De nombreuses versions de Git (toutes les versions que j'ai utilisées, autant que je sache) peuvent traiter les fichiers UTF-16 comme des fichiers binaires en raison de la présence de nombreux octets nuls dans un fichier texte UTF-16 typique.
Une fois que Git considère qu'un fichier est un fichier binaire, il est susceptible de continuer à le traiter comme un fichier binaire, même s'il est modifié. Cela signifie que le contrôle de version est effectué en stockant les versions complètes du fichier plutôt que les différences entre elles et les avantages d'un système de contrôle de version sont perdus. (Edit: Non. J'ai récemment testé cela en modifiant un fichier UTF-16 en UTF-8, en le validant, en le modifiant et en le validant à nouveau - et il a commencé à traiter les modifications comme des modifications de texte une fois que les fichiers originaux et modifiés étaient au format UTF-8. )
La plupart des éditeurs modernes reconnaissent l’encodage des caractères et le style de fin de ligne d’un fichier et enregistrent le fichier dans le même format. Certains éditeurs (Babelpad, par exemple) vous permettront de choisir si vous enregistrez votre fichier au format UTF-8 ou UTF-16, avec ou sans marque d'ordre d'octet, etc.
Si le fichier que vous souhaitez contrôler par la version est (i) au format UTF-16 et (ii) fonctionnerait aussi bien en UTF-8 - par exemple, un programme source pour un compilateur moderne décent - cela vaut la peine de le convertir en UTF-8.
Si Git pense que votre texte source est un fichier binaire avant sa toute première validation, examinez-le et voyez s'il vaut la peine de le charger dans un éditeur et de l'enregistrer dans un format différent que Git reconnaît en tant que texte.
(Remarque: les fichiers Linux ont tendance à être au format UTF-8 par défaut. Certains programmes Windows avaient pour habitude de créer le format UTF-16. Ce sont donc les utilisateurs de Windows qui risquent le plus de rencontrer le problème. Notez également que vous souhaitez le corriger avant le même moment. premier commit du fichier, avant que Git ne pense avoir un fichier binaire!)
Utilisez Git rerere
Réutilisez la résolution enregistrée!