Flusso di lavoro preferito di Github per l'aggiornamento di una richiesta pull dopo la revisione del codice

Ho inviato una modifica a un progetto Open Source su Github e ho ricevuto commenti sulla revisione del codice da uno dei membri del team principale.

Vorrei aggiornare il codice tenendo conto dei commenti della recensione e inviarlo nuovamente. Qual è il miglior flusso di lavoro per farlo? Dalla mia conoscenza limitata di git / github, ho potuto fare una delle seguenti cose:

1. Aggiorna il codice come nuovo commit e aggiungi il commit iniziale e quello aggiornato alla mia richiesta pull.

2. In qualche modo (??) ripristinare il vecchio commit dal mio repository e creare un nuovo nuovo commit contenente tutto, quindi sollevare una richiesta pull per quello?

3. git commitha una funzione di modifica, ma ho sentito che non dovresti usarlo dopo aver spinto il commit al di fuori del tuo repository locale? In questo caso ho apportato la modifica sul mio PC locale e ho spinto il mio ramo github del progetto. Andrebbe bene usare "modifica"?

4. Qualcos'altro?

Sembra che l'opzione 2/3 sarebbe piacevole, dato che il progetto open source avrebbe un solo commit nella loro storia che implementerebbe tutto, ma non sono sicuro di come farlo.

Nota: non so se questo influisce o meno sulla risposta, ma non ho apportato le modifiche in un ramo separato, ho appena eseguito un commit in cima al master

Basta aggiungere un nuovo commit al ramo usato nella richiesta pull e spingere il ramo su GitHub. La richiesta pull verrà automaticamente aggiornata con il commit aggiuntivo.

# 2 e # 3 non sono necessari. Se le persone desiderano vedere solo dove è stata unita la filiale (e non i commit aggiuntivi), possono utilizzare git log --first-parentsolo per visualizzare il commit di unione nel registro.

Per aggiornare una richiesta pull

Per aggiornare una richiesta pull (punto 1), l'unica cosa che devi fare è controllare lo stesso ramo da cui proviene la richiesta pull e spingerla di nuovo:

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

Facoltativo: pulizia della cronologia di commit

È possibile che venga richiesto di eliminare i commit in modo che la cronologia del repository sia pulita o che si desideri rimuovere i commit intermedi che distraggono dal "messaggio" nella richiesta pull (punto 2). Ad esempio se la cronologia del commit è simile alla seguente:

$ 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

È una buona idea mettere insieme le cose in modo che appaiano come un unico commit:

$ git rebase -i parent/master 

Questo ti chiederà di scegliere come riscrivere la cronologia della tua richiesta pull, nel tuo editor sarà presente quanto segue:

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

Per ogni commit che desideri far parte del commit precedente, cambia pick in squash:

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

E chiudi il tuo editor. Git riscriverà quindi la cronologia e ti chiederà di fornire un messaggio di commit per il commit combinato. Modificare di conseguenza e la cronologia di commit sarà ora concisa:

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

Spingilo sulla forcella:

$ 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

e la tua richiesta pull conterrà un unico commit, incorporando tutte le modifiche precedentemente suddivise in diversi commit.

Cambiare la storia sui repository pubblici è una cosa negativa

Riscrivere la cronologia e utilizzarla git push -fsu un ramo che, potenzialmente, qualcun altro ha già clonato è una cosa negativa: causa la divergenza della cronologia del repository e di quella del checkout.

Tuttavia, modificare la cronologia del fork per correggere il cambiamento che si propone di integrare in un repository - è una buona cosa. In quanto tale, non hai riserve che eliminano il "rumore" dalle tue richieste pull.

Una nota sui rami

Nel precedente mostro la richiesta pull come proveniente dal masterramo del fork, non c'è nulla di sbagliato in questo necessariamente ma crea alcune limitazioni come, se questa è la tua tecnica standard, essere in grado di avere solo un PR aperto per repository . È comunque un'idea migliore creare un ramo per ogni singolo cambiamento che desideri proporre:

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