Workflow Github préféré pour la mise à jour d’une requête d’extraction après révision du code

J’ai soumis une modification à un projet Open Source sur Github et reçu des commentaires de révision de code d’un des membres de l’équipe principale.

Je souhaite mettre à jour le code en tenant compte des commentaires de la revue et le soumettre à nouveau. Quel est le meilleur workflow pour ce faire? De ma connaissance limitée de git / github, je pourrais faire l’une des choses suivantes:

  1. Mettez à jour le code en tant que nouvelle validation et ajoutez à la fois la validation initiale et mise à jour à ma demande d’extraction.

  2. D’une manière ou d’une autre (??), annulez l’ancien commit à partir de mon référentiel et créez un nouveau commit contenant tout, puis lancez une requête d’extraction pour cela?

  3. git commit a une fonctionnalité de modification, mais j’ai entendu dire que vous ne devriez pas l’utiliser après avoir poussé la validation en dehors de votre repository local? Dans ce cas, j’ai effectué le changement sur mon PC local et je suis passé dans ma twig github du projet. Serait-ce OK d’utiliser “amender”?

  4. Autre chose?

Il semble que l’option 2/3 serait bien, car le projet open source n’aurait qu’un seul commit dans son historique qui implémenterait tout, mais je ne suis pas sûr de savoir comment faire.

Note: Je ne sais pas si cela affecte la réponse ou pas, mais je n’ai pas apporté les modifications dans une twig séparée, je viens de faire un commit en plus de master

Ajoutez simplement un nouvel commit à la twig utilisée dans la requête pull et poussez la twig vers GitHub. La requête d’extraction sera automatiquement mise à jour avec le commit supplémentaire.

# 2 et # 3 sont inutiles. Si les utilisateurs veulent voir uniquement où la twig a été fusionnée (et non les commits supplémentaires), ils peuvent utiliser git log --first-parent pour afficher uniquement la validation de fusion dans le journal.

Pour mettre à jour une requête d’extraction

Pour mettre à jour une requête de tirage (point n ° 1), la seule chose à faire est de vérifier la même twig d’où provient la requête de tirage et de la relancer:

 cd /my/fork git checkout master ... git commit -va -m "Correcting for PR comments" git push 

Facultatif – Nettoyage de l’historique de validation

Vous pouvez être invité à écraser vos commits pour que l’historique du référentiel soit propre ou pour supprimer vous-même les commits intermédiaires qui distraient “le message” dans votre requête d’extraction (point n ° 2). Par exemple, si votre historique de validation ressemble à ceci:

 $ git remote add parent git@github.com:other-user/project.git $ git fetch parent $ git log --oneline parent/master..master e4e32b8 add test case as per PR comments eccaa56 code standard fixes as per PR comments fb30112 correct typos and fatal error 58ae094 fixing problem 

C’est une bonne idée d’écraser les choses ensemble pour qu’elles apparaissent en un seul engagement:

 $ git rebase -i parent/master 

Cela vous invitera à choisir comment réécrire l’historique de votre requête d’extraction, les éléments suivants seront dans votre éditeur:

 pick 58ae094 fixing actual problem pick fb30112 correct typos pick eccaa56 code standard fixes pick e4e32b8 add test case as per PR comments 

Pour tout commit que vous voulez faire partie du commit précédent – changez le choix de squash:

 pick 58ae094 fixing actual problem squash fb30112 correct typos squash eccaa56 code standard fixes squash e4e32b8 add test case as per PR comments 

Et ferme ton éditeur. Git réécrira alors l’historique et vous demandera de fournir un message de validation pour le commit combiné. Modifiez en conséquence et l’historique de votre engagement sera maintenant concis:

 $ git log --oneline parent/master..master 9de3202 fixing actual problem 

Poussez ça sur votre fourchette:

 $ git push -f Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (11/11), 978 bytes, done. Total 11 (delta 9), reused 7 (delta 6) To git@github.com:me/my-fork.git f1238d0..9de3202 HEAD -> master 

et votre requête pull contiendra un seul commit, incorporant toutes les modifications précédemment divisées en plusieurs commits.

Changer l’histoire des pensions publiques est une mauvaise chose

Réécrire l’historique et utiliser git push -f sur une twig que quelqu’un d’autre a déjà cloné est une mauvaise chose – cela fait diverger l’historique du référentiel et celui de l’extraction.

Cependant, modifier l’historique de votre fork pour corriger le changement que vous proposez d’être intégré dans un référentiel est une bonne chose. En tant que tel ne pas avoir de réserves écrasant le “bruit” de vos demandes de tirage.

Une note sur les twigs

Dans ce qui précède, je montre que la requête de tirage provient de la twig principale de votre fork, cela ne pose aucun problème, mais cela crée certaines limitations, par exemple, si c’est votre technique habituelle, vous ne pouvez ouvrir qu’un seul PR par repository. Il est préférable de créer une twig pour chaque changement individuel que vous souhaitez proposer:

 $ git branch feature/new-widgets $ git checkout feature/new-widgets ... Hack hack hack ... $ git push # Now create PR from feature/new-widgets 

Mon avis sur les meilleures pratiques: une fois que vous êtes prêt à regrouper une demande d’extraction, celle-ci doit avoir sa propre twig thématique, spécialement à cet effet, au départ. Vous commencez par pousser cette twig dans votre repository github, par exemple

 git push origin name-of-pull-request-branch 

et baser la requête de tirage sur cette twig. Ayant fait cela, tous les commits que vous poussez sur cette twig seront automatiquement ajoutés à la requête d’extraction. Vous utilisez cette twig pour rien d’autre.

Certains préfèrent que vous nommiez ces twigs avec votre identifiant github. De cette façon, ils peuvent librement le vérifier localement pour l’essayer, avec des avantages comme

  • moins de crainte de collision de noms de twig
  • plus facile de se rappeler ce que c’est

Je nomme habituellement mes twigs de demande de tirage comme

 claybridges-do-the-things