

GitHubで、あるOSSに対してプルリクエストを行った結果、レビュー指摘を受けた場合の適切な指摘反映方法を教えていただきたいです。ただし、最終的にプルリクエストは1コミットにまとめないといけないとします（おそらく、どのOSSでもそうだと思いますが）。

私の方法では指摘をローカルのソースコードに反映して、以下を実施しています。

[code]

    $ git commit -am "レビュー指摘の反映"
    $ git rebase -i HEAD~2
    ・・・squashで2つのコミットをまとめる（上記コミットメッセージは削除）・・・
    $ git push -f origin [プルリクのためにつくったブランチ]
    
[/code]

この場合、プルリクエストは1コミットにまとめられますが、レビュー指摘前のソースコードが完全になくなってしまうので、レビュアーは適切にレビュー指摘を反映したのか判断しづらいと思います。

レビュー指摘前後の変更内容が確認できて、かつ最終的なプルリクエストを1コミットにまとめることはできるのでしょうか？


CC BY-SA 4.0
2019-09-30T08:53:44.333
59357
2019-10-01T02:11:14.193
2019-10-01T02:11:14.193
3060
23994
question
git github
GitHubのプルリクエストでレビューを受けた後の適切なコミット反映方法は？


> おそらく、どのOSSでもそうだと思いますが

果たしてそうなのでしょうか、確かに複数コミットに分かれているとリベースを強要されたプロジェクトの話は聞いたことはありますが、懸念されている通りこの時点でコミットを纏めてしまうのは私は適切とは思いません。

GitHubのプルリクエストのマージは単純なツリーのマージ以外にもRebase，Squashの選択肢が用意されています。squashは1つのコミットとしてマージされるのでメンテナがこれを使っているのであればコントリビューターは意識する必要ありません。（それ以外においてもプルリク段階でsquashする必要があるのは稀な気はします。）

当然ながらこの辺りはプロジェクトの方針次第ですが……


CC BY-SA 4.0
2019-09-30T10:11:42.010
59359
2019-09-30T10:11:42.010
2376
59357
answer


指摘事項が単純なタイプミスなど、変更点が軽微なものであれば `rebase`
でまとめてしまうのもありかもしれませんが、そうでなければ「プルリクエストは必ず1コミットにまとめる」は必ずしも正しいとは言えません。

最終的にマージでどう取り込むかはオーナー次第ですが、コミットは "意味のある" 単位で分けるべきです。(今回の例なら、レビュー"前"と"後")

* * *

なお、GitHubのヘルプページには以下のような注意書きがありました。

<https://help.github.com/ja/articles/about-pull-requests>

> プルリクエストにコミットをプッシュする場合、フォースプッシュはしないでください。 フォースプッシュをすると、プルリクエストが壊れることがあります。

`rebase` を行うと新しいコミットハッシュが生成されるためでしょう。


CC BY-SA 4.0
2019-10-01T01:26:32.673
59374
2019-10-01T01:26:32.673
3060
59357
answer