QA@IT
«回答へ戻る

回答を投稿

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

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

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

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

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

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

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

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

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

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