Pull Request分割について探る

PR分割方法とissueの管理方法について考えていく

目的

でかい修正（新規API開発）などは変更箇所もおおいためレビューが大変
変更が多いと、あたらしくチームに入ったひとがレビューできない
- ドメイン知識が複雑に絡んでいる修正が、すこしでも混ざっているとその時点でレビューできなくなってしまう
- 分割しておけば、ドメイン知識が伴わない場所も出てくるため、そのPRに関してはレビューできる
スキマ時間にレビューができない
- レビューという重いタスクがのしかかる
- 結果レビューがすすまず仕事が滞る
他社もPR分割してうまく回している記事がある

他チームでは分割運用してうまくいっているようなので、われわれもTryしてみようとなった。
しかし、流儀がオレオレなので守破離の「守」を検討したい

いまやっている運用はこのような感じ

umbrella issue -> umbrella PR
- partial task issue 1 -> partial task PR 1
- partial task issue 2 -> partial task PR 2
- parial task issue 3 ->partial task PR 3

umbrella issueに,使用ややりたいこと、タスク一覧をまとめていく
umbrella PRは最初はブランチだが、すべてのpartial task PRが umbrella PR にマージされていく

最後にumbrella PRをdevelopにマージする

矢印の元は親ブランチと、先は子ブランチ
1つの機能を分割すると、一つ前のタスクの修正が必要になることがおおいので、親、子、孫、ひ孫とブランチが作成されていく

develop -> umbrella PR -> partial task PR1 -> partial task PR2 -> partial task PR3

最終的には、partial task PRはすべてumbrella PRへとマージされていく

develop
     +- umbrella PR
             +- partial task PR1
             +- partial task PR2
             +- partial task PR3

こんな感じでブランチ切れると最高だが、ここまでキレイな粒度でタスクを着るのは難しい。

これはレビューのためではなく、機能改善を小さくやるためにPRを分割していったおはなし。