recherche

Maison  >  Questions et réponses  >  le corps du texte

github - Existe-t-il un moyen de fusionner correctement le code de deux entrepôts dans git?

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

Pourquoi 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 ?

PHPzPHPz2770 Il y a quelques jours854

répondre à tous(5)je répondrai

  • PHPz

    PHPz2017-05-02 09:47:39

    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 :

    refuser de fusionner des histoires sans rapport

    Mais si vous utilisez l'option --allow-unrelated-histories pour 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 clone pour cloner directement l'entrepôt, afin de pouvoir conserver les soumissions historiques de l'entrepôt, et d'utiliser la commande git pull pour éviter de signaler erreurs.

    répondre
    0
  • 天蓬老师

    天蓬老师2017-05-02 09:47:39

    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 clone directement. De cette façon, votre hôte distant sera toujours celui de l'auteur et vous pourrez utiliser <. 🎜> pour le tenir à jour à l'avenir git pull

    répondre
    0
  • 黄舟

    黄舟2017-05-02 09:47:39

    C'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 »

    répondre
    0
  • 怪我咯

    怪我咯2017-05-02 09:47:39

    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.

    répondre
    0
  • PHPz

    PHPz2017-05-02 09:47:39

    @Fighting_Bird
    Après le test, vous avez raison Le piège est que

    est défini dans le fichier .gitattributes du projet de l'auteur original.

    • 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

    répondre
    0
  • Annulerrépondre