Flux de travail Github préféré pour la mise à jour d'une requête de tirage après révision du code

Question

J'ai envoyé un changement à un projet Open Source sur Github, et a reçu la révision du code des commentaires de l'un des principaux membres de l'équipe (github de la revue de code est génial!). La plupart du code est OK, mais un peu les choses doivent changer.

De toute façon, je voudrais mettre à jour le code en tenant compte de l'examen des commentaires, et de la soumettre de nouveau. Quel est le meilleur flux de travail pour faire cela? De mon peu de connaissance de git/github, je pouvais faire tout ce qui suit:

1. Mettre à jour le code comme un nouveau commit, et ajouter à la fois la première et de la mise à jour s'engagent à ma demande d'extraction.

2. D'une certaine manière (??) restauration de l'ancien commit de mon référentiel, et de créer un nouveau commit contenant tout ce qui, puis de soulever un pull request pour qui?

3. git commit a un amendement, mais j'ai entendu dire que vous ne devriez pas l'utiliser après que vous avez poussé le commettre à l'extérieur de votre dépôt local? Dans ce cas, j'ai fait le changement sur mon PC local et poussé à mon github direction du projet. Serait-ce OK pour l'utilisation de "corriger"?

4. Quelque chose d'autre??

Il semble que l'option 2/3 serait bien, comme le projet open source n'aurait qu'un commit dans leur histoire qui serait tout mettre en œuvre, mais je ne suis pas sûr de la façon de le faire.

Note: je ne sais pas si cela a une incidence sur la réponse ou pas, mais je n'ai pas fait les modifications dans une autre direction, j'ai juste fait un commit sur le dessus de maître

Answer 1

Pour mettre à jour un pull request

Pour mettre à jour une demande d'extraction (point n ° 1), la seule chose que vous devez faire est de la caisse de la même branche de la demande d'extraction, et les pousser à nouveau:

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

Option de Nettoyage à commettre l'histoire

Il peut vous être demandé à la courge votre s'engage afin que le référentiel de l'histoire est propre, ou vous-même souhaitez supprimer intermédiaire qui s'engage à en distraire "le message" votre demande d'extraction (point #2). Par exemple, si votre commit l'histoire ressemble à ceci:

$ git remote add parent git@github.com:other-user/project.git
$ 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 de squash choses ensemble afin qu'ils apparaissent comme un seul commit:

$ git rebase -i parent/master 

Il vous invite à choisir la façon de réécrire l'histoire de votre pull request, la suite sera dans votre éditeur de texte:

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

Pour toute validation que vous souhaitez faire partie de la précédente livraison de changement de sélection de la courge:

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

Et fermez votre éditeur. Git va réécrire l'histoire et vous invite à fournir un message de validation pour l'un commit combiné. De modifier en conséquence et votre commit l'histoire va maintenant être concis:

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

Poussez-le à votre fourche:

$ 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 pull request contient un commit, incorporant toutes les modifications précédemment divisée en plusieurs commits.

Changer l'histoire publique repos est une mauvaise chose

Réécriture de l'histoire et à l'aide de git push -f sur une branche qui, potentiellement, quelqu'un d'autre a déjà cloné est une mauvaise chose, il provoque le référentiel de l'histoire et celui de la caisse à diverger.

Toutefois, la modification de l'histoire de votre fourche pour corriger le changement que vous proposer pour être intégré dans un référentiel est une bonne chose. En tant que tel n'avons aucune réserve à l'écrasement du "bruit" de votre pull requests.

Une note sur les branches

Dans l'au-dessus-je montrer le pull request comme venant de l' master de la branche de la fourche, il n'y a rien de mal à cela nécessairement, mais il n'est pas sans créer certaines limitations telles que, si c'est votre technique standard, seul être capable d'avoir un PR ouvertes par le référentiel. C'est une bonne idée pour créer une branche pour chaque changement 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

Answer 2

Il suffit d'ajouter un nouveau commit à la branche utilisée dans la requête pull et de pousser la branche vers GitHub. La requête de tirage sera automatiquement mise à jour avec la validation supplémentaire.

# 2 et # 3 sont inutiles. Si les personnes ne veulent voir que l'endroit où votre branche a été fusionnée (et non les commits supplémentaires), elles peuvent utiliser git log --first-parent pour afficher uniquement la validation de fusion dans le journal.

Answer 3

Mon avis sur la meilleure pratique: une fois que vous êtes prêt à emballer un pull request, il doit obtenir son propre sujet unique de la branche, en particulier pour ce but, au départ. Vous commencez par pousser cette branche à votre github par exemple

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

et en fondant la demande d'extraction hors de cette branche. Après avoir fait cela, tout s'engage à vous pousser à cette branche sera automatiquement ajouté à la demande d'extraction. Vous utilisez cette branche pour rien d'autre.

Certains préfèrent que vous avez de l'espace de noms tels branches avec votre github userid. De cette façon, ils peuvent librement vérifier localement pour l'essayer, avec des avantages comme

• moins peur de la direction de la collision de nom
• plus facile de se rappeler ce que c'est

J'ai l'habitude de le nom de mon pull request branches quelque chose comme

claybridges-do-the-things