github: Ajout de commits à une requête pull existante

J’ai ouvert une demande de tirage sur rails repo sur github en utilisant Fork & Edit ce bouton de fichier.

Maintenant, après avoir reçu des commentaires sur mon PR, je voulais append d’autres commits. alors voici ce que j’ai fini par faire

$ git clone git@github.com:gaurish/rails.git #my forked repo $ git rebase -i 785a2e5 #commit hash of my commit using which PR was opened $ git checkout patch-3 #branch name I had to send my commits under to be shown in that PR $ git commit -am "Changes done as per feedback" $ git push origin patch-3 

Cela a bien fonctionné mais semble tout à fait complexe. Peut-être que je me trompe, quelque chose ne va pas ici?

ma question est la suivante: est-ce que je le fais correctement? sinon, quelle est la bonne façon de le faire?

Puisque vous utilisez les outils de GitHub et que vous modifiez simplement un fichier, vous pouvez également accéder au fichier sur GitHub, sélectionnez la twig appropriée dans le coin supérieur gauche sous le menu déroulant “tree:” ( patch-3 dans votre cas), et maintenant choisissez “Editer ce fichier”. Maintenant, vos modifications seront validées dans cette twig et apparaîtront dans votre demande d’extraction.

Je viens juste de bloguer sur ce sujet:

Comment pouvons-nous garder cette twig à jour? La fusion des nouveaux commits en amont est facile, mais vous voulez éviter de créer un commit de fusion, car cela ne sera pas apprécié en amont: vous ré-engagez efficacement les modifications en amont et ces commits en amont obtiendront un nouveau hash ( comme ils obtiennent un nouveau parent). Ceci est particulièrement important, car ces validations fusionnées seraient reflétées dans votre requête Github lorsque vous transférez ces mises à jour dans votre twig d’entités github personnelle (même si vous le faites après avoir émis la demande d’extraction).

C’est pourquoi nous devons nous rebobiner 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 

Tant l’option de rebase que la commande rebase à git garderont votre arborescence propre et éviteront de fusionner des commits. Mais gardez à l’esprit que ces premiers commits (avec lesquels vous avez émis votre première requête d’extraction) qui sont rebasés, et qui ont maintenant un nouveau hachage de validation, différent des hachages d’origine encore présents dans votre twig repo distante github.

Désormais, pousser ces mises à jour dans votre twig d’entités Github personnelle échouera ici, car les deux twigs sont différentes: l’arborescence locale et l’arborescence distante sont «désynchronisées» en raison de ces différents hachages de validation. Git vous dira de commencer par tirer –rebase, puis de pousser à nouveau, mais ce ne sera pas une simple poussée 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 twig locale. En raison de l’état de désynchronisation, cette traction ne s’applique pas proprement. Vous obtiendrez un historique complet où vos commits apparaissent deux fois. Lorsque vous poussez tout cela dans votre twig d’entités github, ces modifications seront répercutées sur la requête d’extraction d’origine, qui sera très très moche.

AFAIK, il n’y a pas de solution totalement propre à cela. La meilleure solution que j’ai trouvée consiste à forcer la diffusion de votre twig locale vers votre twig github (en forçant une mise à jour non rapide):

Selon 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 comme ceci:

 git push svg +user-non-unique 

ou:

 git push svg user-non-unique --force 

Cela écrasera clairement votre succursale distante, avec tout ce qui se trouve dans votre twig locale. Les commits qui se trouvent dans le stream distant (et ont provoqué l’échec) restront là, mais restront en attente, ce qui finirait par être supprimé par git-gc (1). Pas grand chose

Comme je l’ai dit, c’est la solution la plus propre d’AFAICS. L’inconvénient de ceci est que votre PR sera mis à jour avec les nouveaux commits, qui auront une date ultérieure, et qui pourrait apparaître désynchronisé dans l’historique des commentaires du PR. Pas de gros problème, mais pourrait être déroutant.

Vous pouvez également créer une nouvelle requête pull qui est liée à master au lieu d’une révision abc1234 spécifique.

De cette façon, tout nouvel commit / push sur votre référentiel sera ajouté à la requête pull.