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

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.

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.

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.

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

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,

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.

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.

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.

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.

É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.

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).

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).

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.

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. .

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.