QA@IT

Pull Request送信後に修正があった場合の作法について

28095 PV

Pull Requestそのものの作法については色々な方が書かれており参考に
させていただいたのですが、その後の対応について質問させてください。

GitHubでプロジェクトに何らかの貢献をしたくPull Requestを行ったあと、
相手から「ここをこう直してくれませんか?」と言われた場合についてです。
前提としてPull Request用にブランチは別に切っています。

1.ローカルで修正を行いコミット→リモートのPull Request用ブランチにプッシュ

2.いったんリモートのPull Request用ブランチは削除。
  ローカルで修正を行い commit amendでコミット上書き。
  →再度リモートにPull Request用ブランチとしてプッシュ

一般的な作法として1.で良いのでしょうか?
シンプルなやり方ですがこれだとちょっとしたスペルミス等の修正などでも
コミットが増えてしまい、最終的にマージされた際に余計なコミットが
残ってしまうのを気にする人もいるのでは…と迷っています。

2.だとコミットは綺麗になりますが、いったんリモートにプッシュしたブランチを
削除してしまっているので追跡が困難になる気がします。

どちらが良いのか、あるいは他に定石があるのか。。
お分かりになる方が居れば教えてください。

回答

1.ローカルで修正を行いコミット→リモートのPull Request用ブランチにプッシュ

原則としてこのやり方でコミットを重ねていくほうが良いと思っています。

field_onion さんが書かれていることと重複しますが、通常 pull request のブランチは --no-ff でマージされるので、マージコミットを見れば「そのブランチで起きた変更は何か」は追跡可能です。なので、個別のコミットが多少細かかったり汚かったりしても、いちいち細かく見ることはしないはずです。

逆にいうと、マージコミットを見ただけでは把握できないようなブランチは大きすぎる、ということです。可能な限り、小さい単位で pull request を出していくのが良いように思います。
(ただし、ある程度活発なリポジトリだとマージする側の負担がばかにならないので、小分けにしていくスタイルは嫌われるかもしれません)

pull request で議論してブランチが大きく育ってしまうのは、本来のテーマから外れてしまっているサインだと思います。そういう場合はある程度のところで破棄してしまい、仕切りなおすのがよさそうです。
(そもそもテーマが変わっているので、元のコミットの改変では済まないはずで、新しいブランチを切ってやり直したほうがよい)

編集 履歴 (0)

個人的には好みの範囲なのかなぁとは思います。
作法といいますか、リポジトリをどうしたいか次第ですよね。

あえて一般的という言葉を使うなら、一般的には公開されているリポジトリの改変はしない方が良いとされているかと思います(すでにPullしている人がいるかもしれないから)。
その可能性がないのであれば履歴の改変によって履歴を綺麗にしてもいいでしょうね。

追跡が困難になるかどうかはなんともいえませんが、修正用ブランチであればそもそも修正用ブランチの途中で起こってることってあまり気にしないような気がします(そのブランチをマージしたときに起きてる変化にしか注目しないような。もちろんマージ後の話です。)

フォーク元がそういう部分を気にするならやりますけど、その場合はそもそもリジェクトされるかなぁと思いますので、その時考えると思います。

編集 履歴 (0)
ウォッチ

この質問への回答やコメントをメールでお知らせします。