Contribuer au projet sur github, comment «rebaser ma pull request au-dessus de master»

Ok donc je contribue à un projet sur github. Le projet sur github est upstream, mon repo forké sur github est origin, et mon localrepo sur mon ordinateur.

git checkout -b feature
# Working on feature
git commit -a -m 'only commit on feature'

puis je soumets une pull request

git push origin master

La demande d'extraction est examinée et une modification non liée doit être apportée. Quelqu'un d'autre fait un commit et fusionne dansupstream/master

Maintenant, le upstreammainteneur me demande de "rebaser ma demande d'extraction par-dessus le maître"

Ceci est mon histoire (insérer l'effet sonore Law and Order) .....

Je n'ai apporté aucune modification à la demande d'extraction et c'est toujours la même fonctionnalité de validation sur la branche.

git checkout master
git fetch upstream
git checkout feature
git rebase master
=> "Current branch feature is up to date."
git push origin feature
=> "Everything up-to-date"

Je ne comprends pas. Comment est-ce possible quand je sais que quelqu'un s'est engagé et a fusionné upstream/masteraprès avoir poussé ma pull request vers origin/feature?

Quelqu'un peut-il me dire quelle devrait être la procédure correcte dans cette situation?

Vous affichez uniquement une récupération sur le dépôt en amont. Cela ne met à jour aucune de vos succursales locales. Cela ne fait que mettre à jour vos connaissancesupstream . Vous devez vous assurer qu'il upstream/masterest entièrement fusionné dans votre master, comme avec a git pull, avant de rebaser sur master, ou plus simplement simplement de rebaser sur upstream/master.

C'est à dire:

git checkout master
git pull upstream master
git checkout feature
git rebase master

ou

git checkout feature
git rebase upstream/master

Mettre à jour:

Après avoir réparé votre featurebranche locale , vous devrez la repousser originpour terminer la mise à jour de la demande d'extraction. Puisque vous avez déjà poussé featureune fois, vous ne pouvez pas simplement à pushnouveau parce qu'un rebase change l'historique, et ce n'est pas longtemps une avance rapide. Normalement, quand un push échoue avec un "non-fast-forward", vous le résoudriez en faisant un pull, mais un pull combinera simplement les deux histoires divergentes, ce qui n'est certainement pas ce que vous voulez. Cela signifierait que votre ancienne featurebranche (pré rebase) serait combinée avec la nouvelle (post rebase). Vous voulez écraser origin/feature avec l'état de la nouvelle featurebranche, en vidant tout enregistrement de l'ancienne. Cela signifie que vous voudrez forcer la poussée à se produire, même si ce n'est pas une avance rapide, en utilisant git push -f origin feature. Remarque:dangereux , et vous pouvez perdre des engagements avec lui. Ne l'utilisez que si vous êtes absolument sûr de savoir ce que vous faites, comme ici, où vous voulez intentionnellement supprimer les anciens commits inutiles dans la featurebranche pré-rebase .

Maintenant, le responsable en amont me demande de "rebaser ma demande d'extraction au-dessus du maître"

Notez que depuis septembre 2016, le mainteneur peut déclencher le rebase lui-même.

Voir " Rebase and merge pull requests "

Lorsque vous sélectionnez la nouvelle option «Rebase and merge», les validations de la branche de la demande d'extraction sont rebasées sur la pointe de la branche de base, puis la branche de base elle-même est rapidement transférée vers cette tête nouvellement rebasée. Les rebases définissent automatiquement le committer des commits rebasés sur l'utilisateur actuel, tout en conservant les informations d'auteur intactes. La branche de la demande d'extraction ne sera pas modifiée par cette opération.

Si un rebase ne peut pas être effectué en raison de conflits, nous vous en informerons afin que vous puissiez les résoudre manuellement si nécessaire.