Un nouveau développeur n'arrive pas à suivre le rythme des fusions de branches

223

Je suis le nouveau développeur - ceci est mon premier poste en programmation.

Mon problème est le suivant: nous utilisons git- je coupe une branche de notre developbranche, puis je commence à travailler sur la tâche mineure qui m’a été confiée. C'est très lent, parce que je suis inexpérimenté. Au moment où je suis prêt à fusionner ma branche avec developles autres, de nombreux changements ont été apportés à la résolution des conflits (il semble en effet plus facile de supprimer mon travail et de recommencer la tâche, ce qui n’est bien sûr pas une solution durable )

Comment puis-je surmonter cela? Existe-t-il une tactique que je peux utiliser autrement que "être meilleur en codage"? J'ai l'intention d'en parler avec mon superviseur la semaine prochaine.

Marguerite
la source
165
vous n'avez pas besoin de fusionner votre branche pour ne développer que lorsque vous avez terminé. vous pouvez fusionner développer dans votre branche d'entités progressivement, à tout moment, pour réduire la fusion finale.
DavidB
16
Assurez-vous de bien faire le processus de fusion. Seuls vos fichiers doivent être affectés et seules vos modifications doivent être appliquées à la branche dev. Si vous obtenez des conflits aléatoires, il y a des chances que vous ayez mal fait la fusion ou que d'autres bousculent l'ordre de révision. C'est une bonne occasion de vous informer et éventuellement d'aider les autres à bien fusionner. Certaines personnes ont du mal à comprendre que ce sont des modifications, pas des fichiers en cours de fusion. Ainsi, les révisions désordonnées entraîneraient des conflits sur des fichiers que vous n'avez jamais touchés.
16
Assurez-vous également que votre éditeur est bien configuré. Parfois, les éditeurs "corrigent" les tabulations et les espaces. Ainsi, lorsque vous modifiez un fichier et tentez de le valider, le fichier entier est modifié. Avant de vous engager, assurez-vous que seules vos modifications sont validées dans la branche et corrigez votre éditeur.
32
Il y a une chose étrange ici "je commence à travailler sur la tâche mineure" et des tonnes de conflits de fusion ne correspondent normalement pas. Je viens de fusionner une branche de mise à jour majeure de 2 semaines dans un développement expérimental et nous avons eu 10 (!) Conflits qui n'étaient pas auto-résolvables. Vous n'obtenez pas des tonnes de conflits à moins que votre tâche ne consiste à "changer les noms de variables sur tous les fichiers". Pas pour les tâches mineures.
TomTom
50
Xkcd
ED

Réponses:

5

Vous obtenez des conflits de fusion si les modifications que vous avez apportées dans votre branche sont proches des modifications que vos collègues ont apportées dans la developbranche entre-temps, c'est-à-dire si vous et vos collègues avez modifié les mêmes lignes de code ou des lignes adjacentes dans le même fichier.

Par conséquent, pour réduire les risques de fusion, vous pouvez essayer de fusionner plus tôt afin que vos collègues modifient moins de lignes entre-temps ou d'essayer de modifier moins de lignes vous-même.

Pour modifier vous-même moins de lignes, veillez à n'apporter que les modifications liées à votre tâche.

Si vous devez expérimenter différentes manières d'atteindre votre objectif, certaines de vos expériences ont peut-être modifié des lignes qu'il n'est pas vraiment nécessaire de modifier. Annulez ces modifications avant la fusion.

Certaines commandes Git peuvent également vous aider à modifier le moins de lignes possible:

  • git diffet git diff --stagedpour voir quelles lignes vous avez changées.
  • git add -p d'ajouter uniquement certaines de vos modifications dans un fichier.
  • git commit --amendet git rebase -ide modifier les commits que vous avez déjà effectués dans votre branche de fonctionnalité locale avant de les transférer dans d'autres référentiels Git.

(Changer de quelques lignes que possible peut également faciliter la révision de votre travail ou à utiliser des outils qui fonctionnent sur les différences entre les engage par exemple git cherry-pick, git rebase, git bisectet git blame.)

Cependant, même si vous réduisez le risque de fusion, vous rencontrez parfois des conflits de fusion. Alors n’ayez pas peur d’eux, mais apprenez à résoudre les conflits.

Toxaris
la source
1
Aussi, avant de fusionner, a git fetchet git diff origin/developvous montrera un aperçu de votre fusion (en quelque sorte). Vous donne une chance de nettoyer vos modifications avant d'avoir une tonne de conflits inutiles.
Max
287

Je suppose que vous utilisez git. Si oui, utilisez git rebase -i(le -imoyen interactif). Faites-en une tâche quotidienne (encore plus fréquemment, si nécessaire) pour rebaser votre branche contre la branche en développement. Cela apporte les modifications progressivement tous les jours (au moins) pour que votre branche de fonctionnalités reste à jour. S'il y a des conflits lors de votre rebase quotidienne, vous devez discuter avec votre équipe de qui travaille sur quoi.

Si vous l'exécutez quotidiennement, vous n'aurez probablement pas besoin de la partie interactive. Laissez-le faire son travail.

Je suis un développeur assez expérimenté, et il me faut encore pas mal de temps pour me mettre au courant d'un nouveau projet. Dans votre cas, il semble que plusieurs personnes travaillent simultanément sur le même projet. Il s’agit donc d’un projet très volumineux ou d’un nouveau projet qui évolue rapidement. Dans les deux cas, ne vous inquiétez pas si cela vous prend plusieurs mois pour entrer dans le flot. Si je change de projet pendant 2 ou 3 semaines puis que je change, je peux prendre quelques heures (ou même un jour ou deux) pour devenir pleinement "de nouveau" dans un projet que j'ai écrit à 100% tout seul!

En bref, ne vous inquiétez pas d'être lent maintenant. La meilleure façon de s’améliorer est de continuer à pratiquer. N'hésitez pas à interroger d'autres développeurs sur des aspects des projets que vous ne comprenez pas.

MODIFIER:

Ou utiliser merge. C'est aussi une option. Ainsi, ce qui précède serait: "utiliser git rebase -i(les -imoyens interactifs) ou git merge". En ce qui concerne lequel utiliser, parlez-en avec le reste de votre équipe. Ils peuvent (ou non) avoir de fortes préférences de toute façon. Il est clair que certaines personnes n'ont des préférences fortes.

Jacob Robbins
la source
22
J'imagine que c'est la bonne réponse, mais, IMO, ce n'est qu'un autre exemple de la mauvaise conception et de la mauvaise terminologie de Git. Qu'est-ce que vous "rebasez"? Cela ne devrait-il pas s'appeler "mise à jour" ou "extraction" ou "fusion" ou quelque chose du genre ??? (Une réponse ci-dessous plaide pour "fetch") Quel est le but du contrôle de code source si vous êtes obligé de mettre à jour tous les jours ???
user949300
95
Il ne s'agit pas d'une mise à jour ou d'une vérification. Il prend tout ce qui se trouve exclusivement dans votre branche et ajoute vos modifications comme si vous veniez de les effectuer sur l'autre branche. C'est-à-dire que vos modifications sont maintenant "basées sur" l'autre branche. De plus, il n’existe aucun système de contrôle de source magique connaissant votre code et sachant fusionner les modifications lorsque plusieurs personnes modifient les mêmes fichiers. Vous mettez à jour tous les jours pour que les conflits restent petits et faciles à gérer, et que les changements restent frais dans l'esprit de chacun pour qu'ils sachent comment les gérer.
Vectorjohn
54
Le rebasage de @ user949300 est différent de la fusion, il est beaucoup plus nuancé et nécessite une meilleure compréhension de Git qu'un simple workflow de fusion. C'est pourquoi je ne recommande jamais de flux de travail impliquant un changement de base à un novice de Git, car il conduit à l'hypothèse que le changement de base est le seul moyen par défaut de mettre à jour une branche et entraîne de nombreux pièges et difficultés inutiles. Dans ce cas, la fusion résoudra le problème de la même manière et aucune ne résoudra le problème des conflits de fusion dans deux branches d’entités parallèles de longue durée.
Ant P
14
@ user949300 git pullqui est juste une combinaison de git fetchet git merge(ou vous pouvez ajouter --rebasepour faire une rebase au lieu d'une fusion). En supposant que vous ayez seulement environ un jour de retard, sur un réseau local, cela se terminera probablement en moins d'une seconde, cela peut prendre quelques secondes sur Internet. Même sur Internet et avec des conflits de fusion mineurs, vous pouvez généralement être mis à jour et fusionné proprement en moins d'une minute. Passer cinq minutes sur toute la semaine est bien mieux qu’une heure à la fin de la semaine pour faire face à un conflit de fusion effroyable.
Derek Elkins
66
Aucun vote positif de ma part car cette réponse est entièrement centrée sur le rebasement. Le changement de base peut être un outil utile, mais il ne faut jamais l'utiliser sans réfléchir. Pour la mise à jour quotidienne, il est préférable de fusionner. Pourquoi? Parce que chaque rebase est un mensonge . Vous racontez l'histoire d'une manière qui ne s'est jamais produite. Cela peut totalement nuire à des outils puissants tels que git bisect: Les éléments rebasés ne peuvent même pas être compilés, de sorte qu'ils git bisectne valent rien sur les commits brisés résultants. @maaartinus: Pour ma part, je préfère l'histoire vraie à l'histoire linéaire. Si vous vous rebasez, vous devez absolument vérifier chaque nouveau commit pour des raisons de santé afin d'éviter des mensonges dommageables.
cmaster
131

Cela pourrait être le signe d'une mauvaise ingénierie logicielle de la part de l'entreprise. Trop de dépendances réciproques, différents problèmes avec des fonctionnalités qui se chevauchent, la tentative de résoudre des problèmes dans le mauvais ordre, etc. peuvent provoquer la situation que vous décrivez. Je suggère de fusionner régulièrement developdans votre branche au cours du développement

Ivan Anatolievich
la source
9
Ceci code 101 choses comme vous l'avez mentionné. Pas nécessairement une réflexion précise sur le nouvel employé.
Mister Positive
2
@ Ivan Anatolievich OP dit qu'ils se sont séparés du développement, pas du maître, FYI
Matthew FitzGerald-Chamberlain
6
Cette réponse montre exactement pourquoi je n’aime pas GIT: c’est là encore un autre outil permettant aux équipes d’éviter une gestion adéquate et une planification décente. La réponse à tout est "peu importe, vous pouvez toujours utiliser cette commande plus tard", au lieu d'éviter les problèmes avant qu'ils ne surviennent.
motoDrizzt
7
ma première pensée était aussi un signe de mauvaises pratiques, les développeurs ne devraient pas travailler sur les mêmes fichiers pour la plupart. Si un petit projet a autant de conflits, tous les autres doivent simplement résoudre des conflits toute la journée sans faire de travail!
Aequitas
14
@motoDrizzt Quoi? Je n'ai jamais entendu personne présenter cet argument.
jpmc26
95

Je pense que les réponses acceptées sont plus techniques: "comment utiliser mieux Git", je pense qu’il s’agit plus d’un problème d’équipe que d’un problème d’ingénierie ou d’outillage.

Si vous rencontrez beaucoup de conflits de fusion, cela signifie que vous et un autre membre de l'équipe marchez l'un sur l'autre.
Vous ou eux devriez viser à développer un espace personnel lors du codage et éviter de travailler dans des zones déjà occupées.

Dans mon équipe, nous avons tendance à avoir une grande part de responsabilité dans les tâches.
En général, je suis pleinement propriétaire de deux ou trois fichiers à la fois et je les travaille dans une succursale pendant un jour ou deux au plus.
Généralement, si quelqu'un d'autre touche à ces fichiers, c'est seulement si cela est absolument nécessaire pour leurs propres tâches, nous ne travaillons généralement pas ensemble sur le même bloc de tâches!

Si vous constatez que vous devez fusionner beaucoup, alors soit le code de tous vos équipes se trouve au même endroit (ce qui est quelque chose à éviter en soi), soit toutes vos tâches.

Cela dit, en tant que nouveau développeur, vous n'êtes probablement pas en mesure d'appliquer, de demander ou même de suggérer une quelconque restructuration.
Ce à quoi je m'attendrais, c'est que vos tâches ont été assignées en tant que choses "apprendre à la tâche" qui devraient être raisonnablement abordables selon votre niveau de compétence afin de vous intégrer plus facilement dans l'équipe. Ils ont probablement été choisis parmi les tâches d'un collègue qui travaille toujours dans le même domaine, d'où vos conflits de fusion.
La solution à ce problème consiste alors à y remédier, à résoudre les problèmes, à gérer les conflits de fusion du mieux possible et ne vous inquiétez pas trop, tant que vous faites de votre mieux, c'est à votre supérieur de vous inquiéter. vos progrès.
Vous serez plus rapide et plus confiant au fur et à mesure,

Rowan
la source
4
Je pense que vous avez frappé le clou avec le conflit entre collègues. Les conflits de fusion sont chose courante, mais ils se limitent généralement à une poignée de fichiers.
Matthieu M.
10
Cela ressemble à un corollaire de la loi de Conway et du principe de responsabilité unique , à savoir que si des personnes travaillent sur des problèmes différents, elles éditeront idéalement des parties séparées du code source.
ChrisW
7
Bien que je convienne qu'un processus médiocre ou une conception médiocre peut conduire à un grand nombre de conflits, je suis assez convaincu que le problème est simplement que le PO ne fusionne pas régulièrement dans la ligne principale. Je ne suis pas d'accord pour dire que "prendre l'entière propriété" des fichiers est bien sûr approprié. Je ne veux pas que mon équipe ait la charge constante de garder la trace de qui "possède" quoi, maintenant, de demander "la permission" d'apporter des modifications, ou de deviner quels fichiers elle devrait "réclamer". Ce n'est que rarement, lors de la réécriture significative d'un composant, que j'ai demandé aux membres de l'équipe de me dire s'ils allaient modifier certains fichiers.
Derek Elkins
1
ChrisW a la bonne idée de ce à quoi je conduisais. En règle générale, la propriété de mon entreprise prend la forme de fonctionnalités d’application. Je suis entièrement responsable du système de filtre de recherche et, dans la pratique, personne ne doit toucher aux fichiers associés dans la plupart des circonstances. Mon sentiment est qu'il est très probable que l'OP en tant que nouveau débutant ait été confié à des tâches mineures étroitement liées à un ensemble de tâches en cours par un autre dev. Cela signifie que l'autre développeur travaille dans la même partie de la base de code et qu'ils se gênent mutuellement.
Rowan
1
@Rowan Cool ouais je pensais autant. La séparation des fonctionnalités peut également aider à la séparation des fichiers (ensembles de fonctions dans différents fichiers, etc.) et cette OMI facilite la fusion.
SaltySub2
28

La chose la plus importante dans la fusion est que plus vous attendez, plus cela devient douloureux. Et le problème devient plus que linéaire. Trois fois plus de conflits représentent neuf fois plus de travail. Il y a quelques stratégies:

Fusionner avec la branche de développement chaque fois que cela change, afin que vous soyez toujours proche et que vous n’ayez jamais un nombre énorme de conflits.

Si vous prenez beaucoup de temps, c'est peut-être parce que vous passez la plupart du temps à déterminer quels sont les changements, puis peu de temps à mettre en œuvre les changements. Si tel est le cas, fusionnez avec la branche de développement avant de commencer les modifications de code réelles.

Discutez avec vos collègues des stratégies pour éviter les conflits. Vous obtenez des conflits si deux personnes modifient le même code. Pas simplement le même fichier, mais le même code. J'ai donc besoin d'une nouvelle fonction functionA et vous avez besoin d'une nouvelle fonction functionB, et nous l'ajoutons tous les deux à la fin du même fichier, nous avons un conflit. Si on l'ajoute à différents endroits, pas de conflit. Si nous l'ajoutons tous les deux à un emplacement du fichier auquel il appartient logiquement, il y a de fortes chances que nous n'ayons aucun conflit.

Si vous avez des conflits, procurez-vous un bon outil de comparaison afin de pouvoir comparer la branche de développement avant votre fusion, votre code avant la fusion, votre code d'origine et le code fusionné, et fusionnez à la main.

Dans le pire des cas: vous ne perdez pas votre travail, mais utilisez un bon outil de diff pour savoir exactement quels changements vous avez apportés, reliez-vous de développer et appliquez tous les changements que vous avez effectués manuellement au lieu de les retaper.

gnasher729
la source
Les branches d’entités se présentent comme une autre forme de dette technologique, où les modifications en amont depuis la branche mère ressemblent à une refactorisation.
Dan Lyons
Sauf que vous devez payer cette dette. Maintenant.
gnasher729
15

Au moment où je suis prêt à fusionner ma branche dans développer (emphase le mien)

Le traitement des conflits dans git mergeest souvent plus simple que dans git rebase. Dans la fusion Git, vous pouvez voir la liste complète des fichiers qui ont été modifiés en même temps. Peu importe le nombre de commits effectués par d'autres collègues, vous devrez fusionner une fois . Avec le flux de travail ReBase, vous pouvez finir par avoir les mêmes conflits encore et encore et devoir les examiner manuellement. Vous pouvez finir par réparer le 13ème commit et avoir l’impression que vous ne pouvez pas voir la lumière du tunnel .

D'après mon expérience, lorsque j'ai tenté de résoudre naïvement des conflits de rebase répétés, j'ai fini par perdre les modifications de quelqu'un ou par une application qui ne compilait même pas. Souvent, mes collègues et moi-même travaillions beaucoup, mais nous étions tellement submergés par la complexité de la répétition de conflits que nous avons dû abandonner et perdre notre travail précédent après une poignée d'engagements de réassurance.

Je vais vous suggérer quelques techniques, mais elles ne peuvent que rendre la fusion plus facile que d’automatiser la tâche.

  • Fichiers de ressources / langues . Si vous avez additives modifications apportées à un fichier de ressources, assurez-vous de les déplacer toujours à la fin du fichier afin que vous puissiez facilement rappeler vos changements contre les autres les changements de. Vous pourrez peut-être copier / coller vos modifications en bas ou simplement supprimer les marqueurs de conflit.
  • Faire. Ne pas. ABSOLUMENT. RE-format . Ni vous ni vos collègues développeurs ne devez effectuer un "reformatage massif du code" au cours de votre travail quotidien. Le reformatage du code ajoute un nombre excessif de faux positifs dans la gestion des conflits. Le reformatage du code peut être fait
    • De manière incrémentielle, par exemple par chaque développeur à chaque commit, dès qu’ils utilisent un outil automatisé (par exemple, Eclipse a une option de reformatage lors de l’enregistrement, vanilla Visual Studio n’en a pas). Absolument, chaque développeur doit utiliser les mêmes normes de formatage de code, codées dans un fichier de format mangé par votre IDE. Pour vous donner une idée, que ce soit 4 espaces ou 2 onglets, cela n'a pas d'importance, mais c'est vraiment important si tout le monde utilise la même chose.
    • Juste avant la libération, par un chef d'équipe. Si un commit de "reformatage du code" se produit lorsque les personnes ne travaillent pas sur les branches, c'est-à-dire avant qu'elles ne se ramifient, cela facilitera la tâche.
  • Passez en revue le partage du travail entre vos collègues. Celui-ci est la partie où la plupart des travaux d'ingénierie vient. Comme le soulignent d’autres réponses, il ya une odeur de conception lorsque plusieurs développeurs effectuant des tâches différentes doivent toucher les mêmes ressources. Vous devrez peut-être discuter avec votre chef d'équipe de la partie qui doit être modifiée par chaque développeur simultané.

J'ai également constaté de mauvaises habitudes dans les flux de travail Git dans mes équipes. Souvent, les gens s'engagent trop dans leurs branches. J'ai personnellement vu un développeur ajouter 10 à 20 commits nommés "correctif", chacun commettant une ou deux lignes. Notre politique est que les commits sont étiquetés avec des billets JIRA pour vous donner une idée.

@JobobRobbins suggère de faire git rebaseune tâche quotidienne. Je voudrais pousser son approche en avant.

Tout d’abord, utilisez rebase une fois pour réduire le nombre de commits à une poignée. Et ne vous basez que sur la branche de développement d' origine , qui est le commit à partir duquel vous avez dérivé. Quand je dis poignée, je pourrais signifier 3 ou 4 (par exemple, tous les correctifs de base, tous les correctifs de base de données) ou tout chiffre humainement raisonnable. Une fois que vous les avez consolidées, utilisez fetchet travaillez votre base sur la branche en amont. Cela ne vous évitera pas les conflits à moins que votre équipe revoie sa propre approche, mais rendra votre vie moins pénible.

Si vous avez des questions supplémentaires sur les tâches spécifiques, n'hésitez pas à effectuer une recherche et à poser des questions sur Stackoverflow.

[Edit] à propos de la règle du non reformatage et du scoutisme. J'ai légèrement reformulé le format RE pour souligner que ce que je veux dire est la tâche de formater à partir de zéro l'ensemble du fichier source, y compris le code qui n'a pas été touché par vous. En face de formater toujours votre propre code, qui est parfaitement boy-scouty, un certain nombre de développeurs, y compris moi-même, sont utilisés pour reformater le fichier entier avec les capacités de l'EDI. Lorsque le fichier est touché par d'autres personnes, même si le contenu et la sémantique des lignes concernées ne sont pas modifiés, Git le considérera comme un conflit. Seul un éditeur très puissant prenant en charge le langage peut suggérer que le conflit est uniquement lié au formatage et à la fusion automatique du fragment le mieux formaté. Mais je n'ai aucune preuve d'un tel outil.

Après tout, la règle du scoutisme ne vous oblige pas à nettoyer les dégâts des autres. Seulement le vôtre.

usr-local-ΕΨΗΕΛΩΝ
la source
3
C'est en grande partie une question d'opinion, mais je ne suis pas d'accord sur le fait que les conflits de fusion sont plus faciles à gérer que les conflits de base. Lorsque vous redéfinissez la base, vous appliquez essentiellement des commits un par un, en gardant la portée des conflits de fusion beaucoup plus petite et plus facile à suivre (vous appliquez VOS modifications que vous connaissez - et non celles de quelqu'un d'autre que vous ne connaissez pas). Vous devrez peut-être résoudre davantage de conflits de fusion de cette façon (en raison du contact répété avec les mêmes fichiers à travers les validations), mais ils seront plus petits et plus faciles à résoudre.
user622505
3
En ce qui concerne le reformatage, VS ne peut pas le faire automatiquement lors de la sauvegarde, si vous définissez "Quand je colle" sur "Retrait et format" dans "Outils" -> "Options" -> "Éditeur de texte" -> "< Votre langue de choix> "->" Formatage ", cela signifie que les formats sont automatiquement collés. Cela permet à la séquence de trois frappes: ctrl-A, ctrl-C, ctrl-V d'avoir le résultat souhaité. Cela dit, +1 pour Do. Ne pas. ABSOLUMENT. Reformater. Sauf que vous décrivez dans des conditions très soigneusement contrôlées.
dgnuff
1
Les lecteurs de Bob Martin doivent noter que la règle du scoutisme doit être appliquée avec modération si vous travaillez en équipe (si vous travaillez seul, vous avez beaucoup plus de flexibilité). Si vous interprétez la règle comme suit: "Il est de mon devoir de coder de corriger littéralement tout ce qui n'est pas parfait à l'instant où je le découvre, que ce soit quelqu'un d'autre qui travaille." Une quantité gigantesque de conflits difficiles à résoudre, et ce sera un désordre géant, peu importe la qualité de vos intentions.
Jrh
2
Vous sentez le besoin de reformater ou de reformuler légèrement le code, faites-le avant ou après votre validation significative. Cela réduira non seulement les conflits, mais aidera également le futur lecteur de votre commit, y compris les relecteurs
max630
1
Dans ma culture C #, le "reformatage" désigne l'action de formater un fichier de code complet ou même un référentiel entier lorsque le formatage est uniquement lié à la lisibilité . Si votre langue utilise les espaces de manière significative, vous ne devriez pas jouer avec des espaces dans des LDC qui ne vous appartiennent pas. Inversement, votre langue de choix peut toujours autoriser des espaces non significatifs (par exemple, devant une accolade) qui peuvent être "reformatés" conformément à une norme de lisibilité
usr-local-ΕΨΗΕΛΩ
5

Premièrement, ne pensez pas à abandonner vos modifications. Vous perdrez des occasions d'apprendre le processus de fusion.

Deuxièmement, trouvez une personne qui a travaillé sur les fichiers en créant un conflit. Vous pouvez voir l'histoire. Parlez à la personne et résolvez les conflits dans ces fichiers. Faites de même pour les autres conflits.

S'il y a trop de conflits, votre tâche peut être mineure, mais répétitive. Essayez de trouver un motif. Cela aiderait à résoudre les conflits avec les outils clients de Git UI. J'utilise TortoiseGit. Cela aide à fusionner.

Et pour éviter à l'avenir,

  • C'est une très bonne pratique de fusionner régulièrement la branche de développement avec votre branche principale.

  • Si vous avez activé le CI, vérifiez si l'outil de CI fournit une structure de branche. Cela devrait s'appuyer sur chaque enregistrement effectué dans votre branche de fonctionnalité, mais après la fusion, développer la branche.

PKV
la source
1
+1 Les autres suggestions pour mieux utiliser Git sont bonnes, mais discuter des conflits de fusion avec les autres développeurs est un autre aspect clé pour développer l'efficacité de OP.
Dragonel
1
"Vous pouvez voir l'histoire" Peut-être! Cela dépend de la façon dont tout est écrasé et rebasé: P
Courses de légèreté en orbite
1

Vous devez exécuter régulièrement (quotidiennement) la commande 'git fetch' (pas git pull) à partir de votre branche de développement. Cela permettra aux autres personnes d’engager des modifications et de les intégrer à votre branche sans avoir à les intégrer.

C’est un sujet sur lequel vous devriez parler avec le développeur principal (pas nécessairement avec votre responsable), car votre entreprise peut avoir ses propres normes ou méthodes recommandées pour traiter ce problème; c'est très commun. N'attendez pas la semaine prochaine - découvrez le processus maintenant et demandez si vous pouvez commettre des travaux triviaux (tels que le formatage de code ou l'ajout de commentaires) afin de pouvoir tester le processus.


la source
21
Je ne suis pas sûr que c'est correct. Git fetch obtiendra les télécommandes / origine / maître à jour, mais vous devrez ensuite fusionner les télécommandes / origine / maître dans votre branche principale (ou les télécommandes / origine / développement si tel est le flux utilisé)
Richard Tingle
En supposant qu'il utilise git, c'est aussi une bonne idée d'apprendre à écraser votre engagement en des parties significatives. Ainsi, lorsque vous êtes prêt à faire une demande d'extraction, votre engagement est simple, simple et facile à comprendre.
@ RichardTingle Correct, il pense à une option de rebase. Vous allez simplement chercher et rebaser votre branche avec la branche dev. Cela synchronisera tout.
6
@ Dan Je pense que cela peut être une question d'opinion. Personnellement, je déteste les commits massifs. Essayez de couper ça en deux!
Richard Tingle
2
@PeteCon "et importez-les dans votre branche sans essayer d'intégrer les modifications dans votre branche". Cela semble être une déclaration contradictoire. Je pense que vous voulez dire les importer dans votre référentiel local sans les intégrer à votre branche de fonctionnalité, mais je ne sais pas en quoi cela peut vous aider ...
Jason Goemaat
1

Évidemment, la première chose à faire est d'éviter que plusieurs personnes travaillent sur les mêmes fichiers, au moins d'une manière qui entraîne des conflits difficiles. L'ajout d'éléments dans les énumérations ne pose aucun problème tant qu'un bon format de code est utilisé. Changer le flux de contrôle de différentes manières et déplacer le code est beaucoup plus compliqué. Parfois, cela est néanmoins inévitable. Vous devrez poser des questions lors de la résolution de conflits réellement complexes.

Cela dit, je vois beaucoup de réponses recommandant de fusionner / rebaser pour se développer régulièrement. Je serais beaucoup moins enthousiaste pour ce genre de conseil. Votre objectif à ce stade est de rendre le processus de résolution de conflit aussi simple et sûr que possible. Une chose qui va énormément aider dans ce processus est d'avoir autant de tests de régression disponibles immédiatement, y compris les nouveaux qui font partie de votre nouvelle fonctionnalité. Si vous synchronisez votre branche très régulièrement avec develop, vous finirez inévitablement par résoudre des conflits alors que vous avez presque terminé la mise en œuvre de votre fonctionnalité. Et cela signifie qu'il sera beaucoup plus difficile d'essayer de comprendre ce que le code est censé faire, car vous n'en aviez pas fini. Avant de tenter de fusionner, assurez-vous que votre branche est une unité de changement cohérente. Encore mieux,

J'ai essayé de ne pas entrer dans les mérites de la fusion de base, ce qui est probablement pour une autre question. Dans ce contexte, les outils importent peu.

Kafein
la source
1

Au moment où je suis prêt à fusionner ma branche pour développer, les autres ont fait tellement de changements que la résolution des conflits est écrasante

Cela ressemble à un scénario idéal pour la programmation en binôme !

Plus d'informations sur les avantages et les approches de base:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Vous travaillerez naturellement plus vite avec le temps, mais cela peut être décourageant jusqu'à ce que ce soit le cas, et c'est parfois très long. De plus, même si les gens peuvent apprendre rapidement en étant dans un environnement stressant, ils sont toujours obligés de rattraper leur retard, mais ceux qui n'apprennent pas bien sous une pression constante seront gênés.

Au lieu de travailler vous-même sur une branche et d'essayer de suivre le rythme d'autres développeurs qui sont évidemment beaucoup plus rapides que vous, vous travaillerez directement (sur le même PC) avec un autre développeur. De cette façon, vous obtenez des conseils instantanés et vous obtiendrez probablement des conseils pour accélérer, etc.

Vous auriez trouvé la meilleure approche pour le code particulier de votre projet, car la programmation en binôme n'a pas toujours de sens pour certains projets - même si cela a toujours du sens pour apprendre même si vous restez assis à regarder quelqu'un de plus expérimenté que vous. (tant qu’ils sont de bons développeurs, leur expérience ne signifie pas nécessairement qu’ils utilisent de bonnes pratiques).

S'asseoir avec un dev plus rapide et plus expérimenté peut aider:

  • Réduira probablement les conflits de fusion, car le fait de travailler avec une personne plus expérimentée augmentera le temps de traitement par opposition au fait de travailler seul
  • Au fur et à mesure qu’ils vous enseigneront, ils seront probablement plus lents qu’ils ne travailleraient seuls. Il peut donc encore y avoir des conflits de fusion, vous pouvez donc les résoudre avec une personne chevronnée et, par conséquent, trouver des conseils pour gagner du temps, etc.
  • Vous aider à voir les astuces et les moyens possibles pour être plus rapide (bien que la lenteur soit parfois simplement un manque d'expérience plutôt que de manque de bonnes pratiques)
  • Peut poser des questions immédiatement lorsque quelque chose n'a pas de sens ou n'est pas clair à 100%
  • Travailler en 1: 1 est un apprentissage précieux, car la personne à qui vous demanderiez de l’aide comprend déjà le code et le scénario exacts car elle y travaille. Sans programmation par paires, vous devez expliquer le code et le scénario, ce qui aboutit souvent à un problème et de sorte que vous perdez leur temps et leur attention à obtenir des conseils indispensables
  • Apprenez à connaître le processus de réflexion d'une personne plus expérimentée et expérimentée et, avec de bonnes communications, vous apprendrez certainement de nouvelles choses.

Existe-t-il une tactique que je peux utiliser autrement que "être meilleur en codage"? J'ai l'intention d'en parler avec mon superviseur la semaine prochaine.

Mon conseil est de discuter de la programmation en binôme avec les autres développeurs, puis d’approcher votre superviseur. S'ils sont décents, ils apprécieront votre initiative qui vous donnera plus de chances de faire valoir les avantages de la programmation en binôme (s'ils en ont besoin, la plupart des gens le savent et tout le monde sait pourquoi cela aide).

James
la source
Honnêtement, qui a voté à la baisse :( ce n’est pas un hasard, c’est ce qui se passe sur mon lieu de travail et qui a fait ses preuves! Incidemment, j’ai travaillé dur sur d’autres réponses sur d’autres questions de ce site pour pouvoir avoir 10 représentants (au-dessus de mon représentant associé). ), juste pour pouvoir suggérer une "programmation en paire" dans cette vidéo parce que personne ne l’a suggéré. J'ai travaillé très fort pour répondre à cette question.
James
1

Il y a quelques problèmes sous-jacents ici. Vos problèmes de fusion ne sont probablement pas de votre faute et sont le plus souvent un symptôme de mauvaises pratiques.

1) L’idéal serait de fusionner votre branche chaque jour. Essayez d’avoir un code de travail au moins une fois par jour qui passe tous les tests afin que vous puissiez le fusionner.

2) Si vous n'avez pas de code de travail à un moment quelconque de votre journée de travail habituelle, vous avez probablement trop de gros morceaux de code sur lesquels travailler. Vous devez diviser votre tâche en tâches plus petites qui peuvent être terminées (idéalement indépendamment les unes des autres) plus rapidement afin que vous puissiez fusionner.

3) Vos fichiers de projets sont probablement trop gros. S'il existe de nombreux conflits de fusion pour un fichier, trop de personnes travaillent sur un fichier. Idéalement, quelque chose sur lequel une personne travaille devrait être séparé de ce sur quoi tout le monde travaille.

4) Votre équipe est peut-être trop grande. Si vous trouvez plus facile de supprimer une fonctionnalité complète et de recommencer, il est probable que trop de personnes engagent du code dans le même référentiel.

5) Il est possible que vos normes de formatage du code ne soient pas cohérentes. Si vous n'utilisez pas tous systématiquement le même formatage de code, vous obtiendrez de nombreux conflits différents pour le même code. En fonction de la configuration de votre git, ces conflits peuvent même résulter en des conflits d'espaces (fins de lignes, indentations, tabulations / espaces).

6) Les gens pourraient pousser leurs modifications directement vers la branche en développement.

Voici ce que vous pouvez faire: 1) Si vous ne pouvez pas vous fusionner tous les jours, fusionnez / rebassez dans votre branche tous les jours (ou plus souvent).
2) Essayez de séparer votre code du code de chacun.
3) Discutez avec le reste de l'équipe de fonctionnalités plus petites, de normes de codage cohérentes et d'une meilleure organisation du code (fichiers plus petits, fonctions plus petites).

xyious
la source
1

Il semble en fait plus facile de supprimer mon travail et de recommencer la tâche, ce qui bien sûr n’est pas une solution durable)

La plupart du temps, c'est ce que je fais. La première fois que je corrige un bogue ou modifie le système, j'apprends à le faire. La prochaine fois que je corrige le même bogue, cela ne prend que 1% du temps, car je comprends maintenant le problème.

Je trouve aussi que quand je refais un peu de travail, j’écris un meilleur code .....

Il n’ya donc rien de mal à créer une nouvelle branche à partir du maître, à y refaire votre travail, tout en utilisant votre "branche privée" pour vous rappeler ce que vous devez faire.

Il est également possible que vous ayez découvert un moyen de scinder votre modification en parties logiques et correctes, chacune étant fusionnée dans la branche principale une fois terminée. Par exemple, les tests unitaires et les modifications du code backend peuvent être effectués et fusionnés. Ensuite, dans une opération distincte, vous pouvez effectuer les modifications de l'interface utilisateur qui les utilisent, réduisant ainsi le risque que quelqu'un d'autre modifie le même fichier d'interface utilisateur.

Ian
la source
1

Si vous ne souhaitez pas fusionner trop souvent la branche develop dans votre branche, vous pouvez obtenir un flux de travail qui ressemble davantage à svn en utilisant git pull --rebase. Cela va tirer les nouveaux commits et rebase vos commits sur eux. Cela signifie que lorsque vous fusionnerez votre branche dans develop, ce sera une fusion rapide (comme si vous aviez ajouté tous vos commits passés en même temps, l'un après l'autre), sans aucun conflit de fusion, car vous les avez tous résolus au cours de git pull --rebase.

Mais plus vous vous engagez avant de fusionner votre branche en développement ou de développer votre branche, plus le rebase suivant sera compliqué et subvertira un peu le sens des branches de fonctions, car votre branche n'existe que tant qu'elle n'est pas fusionnée. .

allo
la source
1

Lorsque vous travaillez dans des fichiers communs, de toute façon, vous ou vos coéquipiers devez résoudre tous les conflits avant que la fusion ne se termine, par conséquent, ne soyez pas bouleversé . Vous travaillez toujours dans le cadre de projets et soyez fier de votre travail. Maintenant, pour faire un geste plus intelligent, vous pouvez suivre quelques suggestions ci-dessous.

  1. Diviser les tâches indépendamment:

    Avant de commencer votre travail, planifiez et divisez des tâches entières de manière à ce que la tâche assignée à chaque membre de l'équipe soit aussi indépendante et modulaire que possible (pour éviter les conflits potentiels tout au long du développement). Vous pouvez vous adresser à votre responsable Scrum pour vous assigner des tâches indépendantes en tant que novice.
  2. Fusionner les commits fréquents granulaires:

    N'attendez pas que la tâche complète soit terminée avant la marge finale. Bien sûr, toutes les tâches plus importantes peuvent être partitionnées en plusieurs sous-tâches. Il est donc préférable de fusionner des commits plus petits pour des sous-tâches plus petites en même temps, afin d’éviter une résolution volumineuse des conflits.
  3. Rebase ta branche fréquemment:

    Faites une pratique de rebase fréquente à votre branche locale avec celle distante. Vous pouvez utiliser la commande ci-dessous pour rebaser fréquemment votre branche locale avec celle distante,

    git pull --rebase #or
    git pull --rebase origin dev #when dev is remote branch
    

    C’est à ce jour la commande git la plus utile pour moi dans ma vie de développement.

  4. Travailler en étroite collaboration avec ses coéquipiers:

    Si vous avez vraiment besoin de travailler en parallèle avec votre coéquipier dans une tâche commune, veuillez travailler en collaboration. Elle peut attendre quelque temps pour éviter la résolution de conflits complexes pour votre commodité, car vous êtes novice et elle est experte.

  5. Être habitué avec les options git:

    Utilisez le pouvoir des outils de fusion git. Il existe de nombreux moyens pratiques de résoudre les conflits lors de la fusion. Les stratégies de fusion peuvent parfois aider beaucoup. Soyez habitué et intrépide avec les commandes git.

Sazzad Hissain Khan
la source