コードレビュー後にプルリクエストを更新するための優先Githubワークフロー

Githubのオープンソースプロジェクトに変更を送信し、コアチームメンバーの1人からコードレビューコメントを受け取りました。

レビューコメントを考慮してコードを更新し、再送信したいと思います。これを行うための最良のワークフローは何ですか？git / githubに関する私の限られた知識から、私は次のいずれかを行うことができました。

1. コードを新しいコミットとして更新し、プルリクエストに初期コミットと更新されたコミットの両方を追加します。

2. どういうわけか（??）リポジトリから古いコミットをロールバックし、すべてを含む単一の新しいコミットを作成してから、そのプルリクエストを発生させますか？

3. git commit修正機能がありますが、ローカルリポジトリの外にコミットをプッシュした後は使用しないでください。この場合、私はローカルPCで変更を行い、プロジェクトのgithubブランチにプッシュしました。これは「修正」を使用しても問題ありませんか？

4. 他に何か？

オープンソースプロジェクトはすべての履歴を実装するコミットが1つしかないため、オプション2/3がいいようですが、これを行う方法がわかりません。

注：これが回答に影響するかどうかはわかりませんが、別のブランチで変更を加えなかったので、マスターの上でコミットを行いました

プルリクエストで使用されるブランチに新しいコミットを追加し、ブランチをGitHubにプッシュするだけです。プルリクエストは追加のコミットで自動的に更新されます。

＃2と＃3は不要です。ブランチがマージされた場所だけを表示したい場合（追加のコミットgit log --first-parentは表示しない場合）は、ログでマージコミットを表示するためだけに使用できます。

プルリクエストを更新するには

プルリクエストを更新するには（ポイント＃1）、プルリクエストの元のブランチと同じブランチをチェックアウトして、もう一度プッシュするだけです。

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

オプション-コミット履歴のクリーニング

リポジトリの履歴がきれいになるようにコミットをまとめて潰すように求められる場合や、プルリクエストの「メッセージ」から気が散る中間コミットを削除したい場合があります（ポイント＃2）。たとえば、コミット履歴が次のようになっているとします。

$ 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

物事を一緒に押しつぶして、1つのコミットとして表示することをお勧めします。

$ git rebase -i parent/master 

これにより、プルリクエストの履歴を書き換える方法を選択するように求められます。エディターには次のようになります。

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

以前のコミットの一部にしたいコミットについては、ピックをスカッシュに変更します。

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

エディタを閉じます。次にGitは履歴を書き換え、1つの結合されたコミットのコミットメッセージを提供するように求めます。それに応じて修正すると、コミット履歴が簡潔になります。

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

それをフォークにプッシュします。

$ 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

そしてプルリクエストには単一のコミットが含まれ、以前にいくつかのコミットに分割されたすべての変更が組み込まれます。

公開レポの歴史を変えることは悪いことです

履歴を書き直しgit push -fて、潜在的に他の誰かが既にクローンを作成している可能性のあるブランチで使用することは悪いことです。リポジトリの履歴とチェックアウトの履歴が分岐する原因になります。

ただし、リポジトリへの統合を提案している変更を修正するためにフォークの履歴を修正することは良いことです。そのため、プルリクエストから「ノイズ」を押し潰すような予約はありません。

枝に関するメモ

上記の例では、プルリクエストがmasterフォークのブランチからのものであることを示していますが、これは必ずしも問題ではありませんが、これが標準の手法である場合、リポジトリごとに1つのPRしか開くことができないなど、特定の制限が生じます。 。ただし、提案する個々の変更ごとにブランチを作成することをお勧めします。

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