78 votes

GitHub continue de dire "Cette branche est X s'engage devant, Y s'engage derrière"

Je sais qu'il y a plusieurs questions similaires, mais je pense que ma situation est un peu différente.

Disons qu'il s'agit d'un dépôt GitHub qui je veux contribuer. Je fourche qui référentiel dans mon compte GitHub et je clone de la fourche de mon compte sur mon PC. Des beaux.

Avant de travailler sur un problème, je veux d'abord synchroniser ma fourchette avec le référentiel. Je vais à mon compte fourche, cliquez sur Nouveau Pull request, assurez-vous que je sélectionne la mine de base et le master d'origine en tant que tête de fourche, je vois les différences (tous les commits que les gens ont fait dans l'original référentiel qui ne sont pas sur le mien). Puis-je créer la pull request sur ma fourchette et je fusionner ces changements dans ma fourchette. Je vais à mon local de pensions et de faire un git pull, et j'ai tout synchronisé. Des beaux.

Le problème vient maintenant, dans mon GitHub compte maintenant, c'est toujours en disant: "Cette branche est de X s'engage à suivre", où " X " est le nombre de fois que j'ai fait de synchroniser les processus que j'ai décrit ci-dessus. Donc, chaque fois que je fais une demande d'extraction dans le dépôt original (pas ma fourchette), c'est de montrer que je commets mon code plus X plus s'engage, qui sont les fusionne je l'ai fait sur ma fourchette pour se synchroniser avec le dépôt original.

Bien sûr, je ne veux pas pousser ces changements dans le dépôt original, puisqu'ils ont déjà ces changements en place, donc je ne comprends pas pourquoi GitHub garde en me disant que j'ai des modifications à s'engager.

Je pense que c'est quelque chose qui doit être résolu sur mon compte GitHub, parce que dans mon dépôt local il n'y a pas de changements ou de questions, en fait j'ai même supprimé et re-cloné à nouveau.

Avez-vous des idées?

131voto

Scott Weldon Points 62

Comme vous l'avez deviné, ces commits sont probablement la fusion s'engage à partir de la liste des Demandes que vous avez créé.

Dans l'avenir, il y a un moyen beaucoup plus facile de synchroniser votre fourche d'origine avec le référentiel. Dans votre repo, après le premier clone de faire:

git remote add upstream https://github.com/upstream/repo.git

Ensuite, chaque fois que vous souhaitez synchroniser les modifications à partir de l'amont, de faire:

git pull --rebase upstream master
git push --force-with-lease origin master

(L' --rebase et --force-with-lease options ne seront nécessaires que si vous avez s'engage à ce que n'ont pas été fusionnés en amont des pensions.)

Obligatoire avertissement: Depuis un rebase réécrit l'histoire, cela peut être dangereux / perturbateurs pour quelqu'un d'autre travail dans cette branche. Assurez-vous de communiquer clairement ce que vous avez fait avec quelqu'un que vous êtes en collaborant avec des. Car c'est à vous de fourche, je suppose que ce ne sera pas un problème pour vous.


Maintenant pour corriger votre problème après le fait.

  1. Ajouter de l'amont à distance, comme décrit ci-dessus.
  2. Réinitialiser votre agence locale pour correspondre upstream:

    git checkout master
    git reset --hard upstream/master
    
  3. Si vous avez créé des commits dans votre fourchette, vous pouvez cherry-pick sur votre version mise à jour de master. Si vous ne vous souvenez pas ou besoin d'aide pour les trouver, quelque chose comme

    git log --oneline master origin/master
    

    devrait vous montrer tout s'engage à ne pas en amont.


Ci-dessus, je suppose que vous êtes seulement en utilisant une branche, master. Si vous ne l'êtes pas déjà, je vous recommandons fortement de créer une nouvelle branche pour chaque fonctionnalité / correction de bug que vous travaillez sur. Parmi d'autres avantages, cela vous permet de commencer à travailler sur une autre caractéristique / correction d'un bug lorsque vous êtes toujours en attente pour une version antérieure du PR être fusionnés. Si vous n'avez jamais s'engager directement pour master, puis, vous pouvez synchroniser sans l' --rebase ou --force-with-lease:

git checkout master
git pull upstream master
git push origin master

Pour mettre à jour une branche après avoir mis à jour master, ne:

git checkout myfeature
git rebase master
git push --force-with-lease origin myfeature # if you have already pushed

2voto

RoshanKumar Mutha Points 669

Juste ajout à la réponse ci-dessus,

Si vous utilisez bit-bucket au lieu de Github, alors lors de la création de fork, vous aurez une case à cocher pour synchroniser fork.

Il s'agit d'une fonctionnalité prête à l'emploi fournie où toutes les branches fourchues sont mises à jour par bit-bucket à partir du référentiel d'origine. Pas besoin de mettre à jour les branches de fourche par nos propres moyens. Utilisez simplement une approche de branche locale et ne vous trompez pas avec les branches de fourche.

J'espère que cela ajoute de la valeur.

1voto

Adam Points 1

J'ai le même problème avec vous et vient de résoudre ce problème.

Pour résoudre ce problème:

1) "Reset" de votre région repo à l'instant d'avant l'abondante s'engage

2) Créer une nouvelle branche à l'aide de cette modification locale des pensions de

3) "Publier" cette modification locale des pensions de votre dépôt github

4) Faire les changements que vous souhaitez PR sur github dans la version modifiée de locaux repo

5) 'Commit' ce local repo

6) "l'attraction" de la validation de votre dépôt github

7) Sur votre dépôt github nouvelle branche, soumettre pull request à l'amont, pensions

Espérons que cette réponse pourrait aider.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X