超でかいPRのmerge方法

Tonny Xu -

可能であれば、でかいPRを作らないでください

Tonny Xu

まず、上記の通り、でかいPRは作らないでね！を念頭に入れてもらえれば。

実際の開発に、うっかり超でかいPRを作ってしまうことはあるんでしょう。その時は、まず、念入りしてもらいたいのは、rebaseがいい友達だよ。要は、定期的に、他の方の作業をrebaseして、解消しづらいconflictを回避すべきだね。

目安

普通のPR

  • commits <= 10
  • changed files <= 10

でかいPR

  • commits <= 20
  • changed files <= 20

これ以上のPRは超でかいと言えるんでしょう！

それ以上に大きくなりそうな場合には、可能であれば、機能を分割して実装する。それでも必要なら、やるしかない。

分割

  • cherry-pick

分割可能なCommitをpickして、別のブランチにするのは一つ良いアイディアだね。この場合、順番が重要だ。

  1. でかいブランチKの元のブランチDから別のブランチAを作る
  2. cherry-pickしたいcommitをAに入れる
  3. ビルドや、テストなどを実行して、通ったら、AをPRにする
  4. Kブランチでrebase -i HEAD~<n>を使って、cherry-pickしたブランチを外す
  5. Kでビルドやテストを確認する

rebase -iが友達

rebase -iを使う。どんなrebaseをしても-i入れて使えばなんとかなると思う。rebaseは本当に強力なツールなので、必ず習得してください。

（仮にdevelopブランチにrebaseしたい場合）

(your-branch)$ git rebase -i develop

手動修正+マージ

rebaseをする際に、ローカルのconflictが多いかもしれないが、特に、他の方が自分が修正したコード周りにrefactoringなどをした場合は辛いと思う。その場合、僕の経験ではconflict内容を一旦残す。

//>>>>>>> HEAD
//some modifications by others
//=======
//your modifications
//<<<<<<< {SHA1} {your commit message}

こういう方法で、後ほど他のconflictを一緒に見てみたら、他のチームメンバーがどんな修正を入れたのかわかりやすい。そのconflictを解消するのも簡単になる。

push --force

あとは、rebase後のlocalブランチとremoteブランチをどうする問題だ。

rebase前にKブランチがすでにPRとして出した場合、rebase後は同じremoteのブランチK'にpush --forceを使ってください。なぜなら、remoteのK'ブランチはrebase前のものなので、各Commitの内容は少し違うかもしれない（ローカルにconfilicを修正したなど）。従って、remoteのK'ブランチは破棄しても大丈夫のようなものになる。逆に、push --forceを使わないと、大変なことになる。（興味があれば、自分で試してみてね）

(your-branch)$ git push --force origin K

最後に、もう一度言う

可能であれば、でかいPRを作らないでください

Tonny Xu