Je viens de bloguer sur ce sujet:
Comment garder cette branche de fonctionnalités à jour? La fusion des derniers commits en amont est facile, mais vous voulez éviter de créer un commit de fusion, car cela ne sera pas apprécié lorsqu'il est poussé vers l'amont: vous recommencez alors effectivement les changements en amont, et ces commits en amont recevront un nouveau hachage ( comme ils obtiennent un nouveau parent). Ceci est particulièrement important, car ces validations fusionnées seraient reflétées dans votre demande d'extraction GitHub lorsque vous transmettez ces mises à jour à votre branche de fonctionnalités GitHub personnelle (même si vous le faites après avoir émis la demande d'extraction.)
C'est pourquoi nous devons rebaser au lieu de fusionner:
git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel
L'option rebase et la commande rebase de git garderont votre arbre propre et éviteront d'avoir des validations de fusion. Mais gardez à l'esprit que ce sont vos premiers commits (avec lesquels vous avez émis votre première pull request) qui sont rebasés, et qui ont maintenant un nouveau hachage de commit, qui est différent des hachages d'origine qui se trouvent toujours dans votre branche de dépôt github distante .
Maintenant, pousser ces mises à jour vers votre branche de fonctionnalité GitHub personnelle échouera ici, car les deux branches diffèrent: l'arborescence de la branche locale et l'arborescence de la branche distante sont «désynchronisées», à cause de ces différents hachages de validation. Git vous dira d'abord git pull --rebase, puis de pousser à nouveau, mais ce ne sera pas une simple avance rapide, car votre historique a été réécrit. Ne fais pas ça!
Le problème ici est que vous récupérerez à nouveau vos premiers commits modifiés tels qu'ils étaient à l'origine, et ceux-ci seront fusionnés au-dessus de votre branche locale. En raison de l'état de désynchronisation, cette extraction ne s'applique pas proprement. Vous obtiendrez un historique cassé où vos commits apparaissent deux fois. Lorsque vous poussez tout cela dans votre branche de fonctionnalités GitHub, ces modifications seront reflétées sur la demande d'extraction d'origine, qui deviendra très, très moche.
AFAIK, il n'y a en fait pas de solution totalement propre à cela. La meilleure solution que j'ai trouvée est de forcer le transfert de votre branche locale vers votre branche GitHub (en forçant en fait une mise à jour non rapide):
Comme pour git-push (1):
Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.
Alors ne tirez pas, forcez simplement à pousser comme ceci:
git push svg +user-non-unique
ou:
git push svg user-non-unique --force
Cela écrasera clairement votre branche distante, avec tout ce qui se trouve dans votre branche locale. Les commits qui sont dans le flux distant (et qui ont causé l'échec) y resteront, mais seront des commits suspendus, qui seront finalement supprimés par git-gc (1). Pas grand-chose.
Comme je l'ai dit, c'est AFAICS la solution la plus propre. L'inconvénient de cela, c'est que votre PR sera mis à jour avec ces derniers commits, qui auront une date ultérieure, et pourraient apparaître désynchronisés dans l'historique des commentaires du PR. Pas de gros problème, mais cela pourrait être déroutant.