Par exemple, il existe deux branches, master et develop. Pour les fichiers 1.txt,
master分支:
222
3333 66
555
develop分支 :
222
4444 77
888
Il y a d'abord master, puis j'ai créé la branche de développement, puis modifié 1.txt sous la branche de développement, puis ajouté et validé, puis je suis revenu à la branche principale, puis j'ai fusionné, seuls 66 et 77 conflits ont été signalés, et autres Aucun conflit signalé entre les deux lieux
Pourquoi y aurait-il un conflit s'il n'y en a que 66 et 77 ? Et 4444 et 3333, et 555 et 888 ne sont pas en conflit ? Je ne comprends pas
Regardez l'image ci-dessus, la branche master est 555555, je l'ai changée en dev en 5445, puis j'ai ajouté un commit, puis revenez à la branche master, fusionné, il n'y a pas de conflit, et enfin fusionné vers 5445. Est-ce qu'est ce que tu as dit ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
L'apparition de conflits dépend de l'ordre des modifications de validation
Mon ami à l'étage a mentionné la fusion automatique, ce qui signifie qu'aucun conflit ne se produira :
.Sur master, vous avez un commit avec le contenu "1234"
A ce moment, vous avez créé une nouvelle branche basée sur master , appelée
avec le contenu "1234"develop, puis cette branchedevelopa également le commitEnsuite, vous soumettez un nouveau commit et remplacez "1234" par "1234 666". Ensuite, si vous
.mergeà ce moment-là, il n'y aura pas de conflitAutre exemple de situation conflictuelle :
masterIl y a un commit à l'intérieur, le contenu est "1234"Vous avez créé une nouvelle branche après ce commit, appelée
develop. Puis à ce moment, votre branchedevelopa le premier commit avec le contenu "1234"Puis vous avez soumis un commit dans
Si vous fusionnez à nouveau à ce moment-là, il y aura un conflit, car git constate que les deux branches ont un ancêtre commun (ancêtre), qui est le "1234", mais git ne sait pas ce que vous voulez fusionner maintenant . "666" ou "777"developavec le contenu "1234 777"Pendant cette période, votre
mastera été mis à jour. Vos collègues ou amis, ou vous-même, ont soumis un nouveau commit sur <.> et l'a mis à jour en "1234 666"masterPour en revenir à votre question, je vous suggère d'abord de regarder l'historique des commits de vos deux branches et de les comparer. Voyez si vous pouvez trouver une situation similaire à celle-ci, c'est-à-dire que deux branches ont un commit commun comme point de départ (ancêtre), mais les commits suivants divergent (pert)
Si vous ne parvenez toujours pas à expliquer votre problème, envoyez-moi votre adresse github si cela vous convientParce qu'il y a une fusion automatique. Avez-vous constaté le conflit lors de la fusion manuelle des branches ?
Je l’ai essayé et j’ai constaté que cela ne fonctionnait pas. Voici la réponse originale.
C'est tout à moi devinez.
Au début le maître ressemble à ceci :
Ensuite, vous créez un développement et le modifiez comme ceci :
À l'heure actuelle, develop peut être directement fusionné avec master sans conflit, car develop est une modification maître après maître.
Mais vous n'avez pas fusionné le développement, mais avez changé de master :
En ce moment, il y a un conflit entre 66 et 77. Parce que git sait que 4444 en développement a été modifié par rapport à 3333 et que 888 a été modifié par rapport à 555, la position principale actuelle a toujours 3333 et 555. Mais 77 a été initialement modifié de 22, mais maintenant le 22 du maître est devenu 66. Il y a deux modifications contradictoires et git ne peut pas fusionner 77 en 66.
En d'autres termes, master et develop étaient à l'origine sur la même ligne, mais si vous changez de master, le nouveau master n'est pas sur la même ligne que le développement original.