J'ai directement téléchargé un code depuis un certain entrepôt A, puis j'ai construit moi-même un entrepôt B. Notez qu'il n'était pas forké à l'époque. Du coup, j'espère maintenant synchroniser le dernier code de l'auteur. entrepôt A, puis j'ai trouvé que la méthode de synchronisation en ligne est inutile
/q/10...
La méthode que j'ai utilisée consistait à déposer d'abord un rapport fatal : refuser de fusionner des historiques sans rapport
Après une recherche sur Google, j'ai ajouté le paramètre --allow-unrated-histories
Maintenant, il peut s'exécuter, et le résultat de la fusion du code source est stupéfiant. Git semble incapable de reconnaître la différence du code source dans ce cas. Par exemple, il y a un fichier de code que je n'ai pas du tout modifié, mais l'auteur source l'a mis à jour lui-même
La mienne La version est
111
222
La version de l'auteur est
111
222
333
Théoriquement, la fusion devrait simplement fusionner 333 directement dans mon code source. Cependant, dans ce cas, git considère mon contenu et celui de l'auteur comme étant complètement. Deux copies différentes, donc ça a changé le code en ceci
<<<<<<<<<head
111
222
========
111
222
333
>>>>>>>>>>aasdasfsdfsdfPourquoi cela se produit-il ? N'y a-t-il pas de solution ? Existe-t-il un moyen de synchroniser le référentiel source uniquement pour les forks, mais les non-forks ne peuvent pas se synchroniser même s'ils ont des modifications mineures ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Le code source téléchargé depuis github n'est pas un entrepôt git par défaut, vous initialisez donc le code téléchargé dans un entrepôt git. Un tel entrepôt n'a pas d'historique de soumission. Si les deux entrepôts n'ont pas le même historique , ils ne peuvent pas être fusionnés dans l'entrepôt distant en utilisant
git pull, donc la méthode que vous avez utilisée au début provoquera l'erreur suivante :Mais si vous utilisez l'option
--allow-unrelated-historiespour forcer la fusion, cela résout le problème.Cependant, le problème que vous avez rencontré plus tard est normal. Git ne pense pas que votre contenu et celui de l'auteur sont deux copies complètement différentes, c'est juste que les deux sont en conflit, c'est-à-dire qu'il y a des différences aux mêmes endroits. Si vous rencontrez un conflit, résolvez-le simplement manuellement. Et selon moi, la raison du conflit est probablement due au fait que le caractère de nouvelle ligne Windows et le caractère de nouvelle ligne Unix ne sont pas unifiés (bien sûr, nous ne pouvons pas le voir à l'œil nu). Cela dépend de la façon dont vous gérez le caractère de nouvelle ligne. dans vos paramètres git. Peut-être que le caractère de nouvelle ligne de l'entrepôt distant utilise uniformément le caractère de nouvelle ligne Unix (LF) ou le caractère de nouvelle ligne Windows (CLF), et vous êtes exactement le contraire. Concernant la façon de gérer les sauts de ligne dans les paramètres de git, vous pouvez vous référer au document d'aide officiel de github. Bien sûr, il existe également de nombreuses informations sur Internet.
De plus, comme le maître l'a déjà dit, il est préférable d'utiliser la commande
git clonepour cloner directement l'entrepôt, afin de pouvoir conserver les soumissions historiques de l'entrepôt, et d'utiliser la commandegit pullpour éviter de signaler erreurs.Cela marque vos parties en conflit, et vous pouvez choisir quelle partie conserver pour résoudre le conflit.
De plus, si vous copiez simplement une copie du code et que vous ne voulez pas la copier, vous devez simplement
git clonedirectement. De cette façon, votre hôte distant sera toujours celui de l'auteur et vous pourrez utiliser <.> pour le tenir à jour à l'avenirgit pullC'est parce que GIT ne peut pas reconnaître et fusionner la même ligne après l'avoir modifiée. C'est ce qu'on appelle
dans GIT.冲突Vous devez résoudre manuellement le conflit, puis valider. Comment résoudre le conflit, veuillez également rechercher « Résolution des conflits GIT »
la réponse du membre est déjà correcte. .
Vous pouvez utiliser git add -u pour ajouter des fichiers en conflit. Ensuite, git commit -m commits puis git pull
Quant à la raison pour laquelle la situation que vous avez mentionnée se produit.
Il est possible que votre code soit
222
Il y a en fait des retours chariot, des sauts de ligne ou d'autres symboles ici
La version de l'auteur est
111
222
333
Dans ce cas, git reconnaîtra qu'il s'agit d'un conflit et ne fusionnera pas automatiquement. Pas tout à fait sûr. git ne fusionne pas automatiquement le code.
@Fighting_Bird
est défini dans le fichier .gitattributes du projet de l'auteur original.Après le test, vous avez raison Le piège est que
text=auto
Cette option, s'il y a cette option dans les paramètres, git modifiera tous les sauts de ligne du document texte qu'il considère en LF avant de le soumettre, puis lors de l'extraction Ensuite, reconvertissez-le, mais mon propre projet n'a pas ce paramètre, il n'y a donc pas d'opération de conversion de ce type, ce qui entraîne des sauts de ligne différents et l'échec de la fusion