Preferowany przepływ pracy Github do aktualizowania żądania ściągnięcia po sprawdzeniu kodu

Przesłałem zmianę do projektu Open Source na Githubie i otrzymałem komentarze do recenzji kodu od jednego z głównych członków zespołu.

Chciałbym zaktualizować kod, uwzględniając komentarze do recenzji, i ponownie go przesłać. Jaki jest najlepszy przepływ pracy w tym celu? Z mojej ograniczonej wiedzy na temat git / github mogłem wykonać jedną z następujących czynności:

1. Zaktualizuj kod jako nowy zatwierdzenie i dodaj zarówno początkowe, jak i zaktualizowane zatwierdzenie do mojego żądania ściągnięcia.

2. Jakoś (??) wycofaj stary zatwierdzenie z mojego repozytorium i utwórz pojedynczy nowy zatwierdzenie zawierający wszystko, a następnie wygeneruj żądanie ściągnięcia?

3. git commitma funkcję zmiany, ale słyszałem, że nie powinieneś jej używać po wypchnięciu zatwierdzenia poza lokalne repozytorium? W tym przypadku dokonałem zmiany na moim lokalnym komputerze i przesłałem do mojego oddziału github projektu. Czy użycie „zmiany” byłoby w porządku?

4. Coś innego?

Wygląda na to, że opcja 2/3 byłaby fajna, ponieważ projekt open source miałby tylko jedno zatwierdzenie w swojej historii, które implementowałoby wszystko, ale nie jestem pewien, jak to zrobić.

Uwaga: nie wiem, czy to wpływa na odpowiedź, czy nie, ale nie wprowadziłem zmian w osobnej gałęzi, po prostu zrobiłem zatwierdzenie na master

Wystarczy dodać nowy zatwierdzenie do gałęzi użytej w żądaniu ściągnięcia i przekazać gałąź do GitHub. Żądanie ściągnięcia zostanie automatycznie zaktualizowane o dodatkowe zatwierdzenie.

# 2 i # 3 są niepotrzebne. Jeśli ludzie chcą zobaczyć tylko miejsce, w którym scalono Twój oddział (a nie dodatkowe zatwierdzenia), mogą użyć git log --first-parenttylko do wyświetlenia zatwierdzenia scalania w dzienniku.

Aby zaktualizować żądanie ściągnięcia

Aby zaktualizować żądanie ściągnięcia (punkt # 1), jedyne, co musisz zrobić, to wyewidencjonować ten sam oddział, z którego pochodzi żądanie ściągnięcia i wcisnąć ponownie:

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

Opcjonalnie - czyszczenie historii zatwierdzeń

Możesz zostać poproszony o zmiażdżenie twoich zatwierdzeń, aby historia repozytorium była czysta, lub sam chcesz usunąć pośrednie zatwierdzenia, które odwracają uwagę od „wiadomości” w twoim żądaniu ściągnięcia (punkt # 2). Na przykład, jeśli historia zatwierdzeń wygląda następująco:

$ 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

Dobrym pomysłem jest zgniecenie rzeczy razem, aby pojawiły się jako pojedyncze zatwierdzenie:

$ git rebase -i parent/master 

Spowoduje to monit o wybranie sposobu przepisania historii żądania ściągnięcia, w edytorze pojawi się:

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

Dla każdego zatwierdzenia, które chcesz być częścią poprzedniego zatwierdzenia - zmień wybierz na squash:

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

I zamknij edytor. Git przepisze historię i poprosi o podanie komunikatu zatwierdzenia dla jednego połączonego zatwierdzenia. Zmień odpowiednio, a twoja historia zmian będzie teraz zwięzła:

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

Wciśnij to do widelca:

$ 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

a twoje żądanie ściągnięcia będzie zawierać pojedynczy zatwierdzenie, zawierające wszystkie zmiany wcześniej podzielone na kilka zatwierdzeń.

Zmiana historii publicznych repozytoriów to zła rzecz

Przepisywanie historii i korzystanie git push -fz gałęzi, która potencjalnie już została sklonowana przez inną osobę, jest złą rzeczą - powoduje, że historia repozytorium i historia kasy rozbieżne.

Jednak poprawienie historii rozwidlenia w celu skorygowania zmiany, którą zamierzasz zintegrować z repozytorium - jest dobrą rzeczą. W związku z tym nie ma zastrzeżeń wyciskających „hałas” z twoich wniosków ściągania.

Uwaga na temat oddziałów

Powyżej pokazuję, że żądanie ściągnięcia pochodzi z mastergałęzi twojego widelca, niekoniecznie nie ma w tym nic złego, ale stwarza pewne ograniczenia, takie jak, jeśli jest to twoja standardowa technika, możliwość posiadania tylko jednego PR otwartego dla repozytorium . Lepiej jest jednak utworzyć gałąź dla każdej zmiany, którą chcesz zaproponować:

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