web-dev-qa-db-fra.com

GitHub n'arrête pas de dire "Cette branche est X commet devant, Y commet derrière"

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

Supposons qu'il existe un référentiel GitHub auquel je souhaite contribuer ... .. Je branche ce référentiel dans mon compte GitHub et je clone le fork de mon compte sur mon PC. Bien.

Avant de travailler sur un problème, je souhaite d’abord synchroniser mon fork avec le référentiel "original". Je vais sur mon compte fork, clique sur la demande de nouveau retrait, m'assure de sélectionner le mien comme base et le maître d'origine comme fourche, je vois les différences (tous les commits que les utilisateurs ont effectués dans le référentiel d'origine ne sont pas dans le mien) . Ensuite, je crée la demande d'extraction sur ma branche et je fusionne ces modifications dans ma branche. .. Je vais à mon dépôt local et effectue un git pull, et tout est synchronisé. Bien.

Le problème vient maintenant, dans mon compte GitHub maintenant, il est toujours dit "Cette branche est X commet à venir", où "X" est le nombre de fois que j'ai effectué le processus de synchronisation que j'ai décrit ci-dessus. Ainsi, chaque fois que je fais une requête d'extraction dans le référentiel d'origine (pas mon fork), cela montre que je commets mon code plus X autres commits, qui sont les fusions que j'ai effectuées sur mon fork pour se synchroniser avec le référentiel d'origine.

Bien sûr, je ne souhaite pas intégrer ces modifications dans le référentiel d'origine, car elles ont déjà ces modifications en place. Je ne comprends donc pas pourquoi GitHub n'arrête pas de me dire que des modifications doivent être validées.

Je pense que c'est quelque chose qui doit être résolu sur mon compte GitHub, parce que dans mon référentiel local, il n'y a pas de changement ni de problème, en fait je l'ai même supprimé et re-cloné à nouveau.

Avez-vous des idées?

gitgithub
28
Fernando Garcia

Comme vous l'avez deviné, ces commits supplémentaires sont probablement les commits de fusion issus des demandes d'extraction que vous avez créées.

À l'avenir, il existe un moyen beaucoup plus simple de synchroniser votre fork avec le référentiel d'origine. Dans votre référentiel local, après le clone initial, faites:

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

Ensuite, chaque fois que vous souhaitez synchroniser les modifications en amont, procédez comme suit:

git pull --rebase upstream master
git Push --force-with-lease Origin master

(Les options --rebase et --force-with-lease ne seront nécessaires que si vous avez des commits qui n'ont pas été fusionnés dans le référentiel en amont.)

Obligatoire warning : Depuis une réécriture réécrit l'historique, cela peut être dangereux/dérangeant pour quiconque travaille sur cette branche. Assurez-vous de communiquer clairement ce que vous avez fait avec les personnes avec lesquelles vous collaborez. Puisqu'il s'agit d'une fourchette personnelle, je suppose que cela ne sera pas un problème pour vous.

Maintenant, pour résoudre votre problème actuel après le fait.

  1. Ajoutez la télécommande en amont comme décrit ci-dessus.

  2. Réinitialisez votre branche locale pour qu'elle corresponde à upstream:

    git checkout master
git reset --hard upstream/master

  3. Si vous avez créé des commits dans votre fork, vous pouvez cherry-pick les dans votre version mise à jour de master. Si vous ne vous en souvenez plus ou si vous avez besoin d’aide pour les retrouver,

    git log --oneline master Origin/master

    devrait vous montrer tous les commits pas en amont.

J'ai supposé ci-dessus que vous n'utilisez qu'une seule branche, master. Si vous ne l'êtes pas déjà, je vous recommande fortement de créer une nouvelle branche pour chaque fonctionnalité/correction de bogue sur laquelle vous travaillez. Entre autres avantages, cela vous permet de commencer à travailler sur une autre fonctionnalité/correction de bogue lorsque vous attendez encore la fusion d’un PR précédent. Si vous ne vous engagez jamais directement dans master, vous pouvez alors synchroniser sans le --rebase ou le --force-with-lease:

git checkout master
git pull upstream master
git Push Origin master

Pour mettre à jour une branche de fonctionnalité après avoir mis à jour master, procédez comme suit:

git checkout myfeature
git rebase master
git Push --force-with-lease Origin myfeature # if you have already pushed
47
Scott Weldon

Juste addition à la réponse ci-dessus, 

Si vous utilisez bit-bucket au lieu de Github, lors de la création de fork, cochez la case correspondante. 

Ceci est une fonctionnalité prête à l'emploi fournie où toutes les branches fourchues sont maintenues à jour par les bits du référentiel d'origine. Pas besoin de mettre à jour les branches de fourche par nos propres moyens. Il suffit d’appliquer une approche de branche locale et de ne pas gâcher les branches de fourche.

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

2
RoshanKumar Mutha

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

Pour résoudre ceci:

1) 'Réinitialisez' votre repo locale au moment précédant les engagements importants

2) Créer une nouvelle succursale en utilisant ce référentiel local modifié

3) "Publiez" ce rapport local modifié dans votre rapport github 

4) Faites les changements que vous voulez PR sous github dans le repo local modifié

5) 'Commit' ce repo local

6) 'Tirez' le commit vers votre repo github

7) Sur votre nouvelle branche github repo, soumettez la demande d'extraction au référentiel en amont.

J'espère que cette réponse pourrait aider. 

0
Adam