What is this?

• チームで開発を進める上で、レビューが溜まったり、ビュー中のブランチに依存する機能を実装する際のブランチの管理方法などを考えていく場所
• ポイント：ブランチの分け方・命名規則、コミット・プルリクの命名規則、プルリクの粒度をコントロール

困りごと

• プルリクエストのサイズが大きいとレビューが重くなり、後回しにされる
• ブランチの命名規則もメンバーによって異なる
• レビュー中のブランチに依存する機能を実装する際のマージ作業が面倒

解決案

プルリクエストのサイズをコントロールする

プルリクエストのサイズが大きくなるケース

• 新規機能開発で変更箇所が多い↑フロントエンド、バックエンドでプルリクエストを分ける↑さらに、CRUD単位など機能として分割できる粒度でプルリクエストを分ける
  • ↑レビューしてもらうことができる最小の粒度で、ソースコードの変更の意図を説明できる粒度(粒度が小さすぎると、変更意図が分かりづらくなる)
• 別ブランチからチェリーピックが必要となる
  • ↑チェリーピック用のブランチを切り、プルリクエストを出す

ブランチの命名規則を設定する

ブランチをディレクトリ構造で作成し、関連するプルリクエストを分かりやすくする
ブランチ名は関連する機能に着目して設定
↑プルリクエスト時に詳細は書くので、ブランチ名はシンプルでいい

• 機能開発:feature/
  • 認証機能の例
    • 親ブランチ:feature/auth
    • 子ブランチ:
      • feature/auth/email
      • feature/auth/google

親ブランチの変更を子ブランチへリベースする

• 親ブランチのレビュー中に変更が発生した場合、子ブランチへ変更をリベースする必要がある場合がある(子ブランチの実装が親ブランチに依存している場合)
• マージではなくリベースすることで、子ブランチの変更前に履歴を追加できる
• 子ブランチへのリベース
  • https://git-scm.com/book/ja/v2/Git-のブランチ機能-リベース

コミットにも命名規則をつけて、プルリクエストを出しやすくする

適切な粒度でコミット、プレフィックスで分類することで、コミット単位で管理しやすくする

• 作業用の開発ブランチをきる
• 開発ブランチで定期的にコミット
• プルリクエスト用のブランチをきる
• コミットから対象コミットをチェリーピック

コミットメッセージについて

1. Prefixをつける
   • feat: 新しい機能
   • fix: 修正
   • bug-fix: バグの修正
   • docs: ドキュメントのみの変更
   • style: 空白、フォーマット、セミコロン追加など
   • refactor: 仕様に影響がないコード改善(リファクタ)
   • perf: パフォーマンス向上関連
   • test: テスト関連
   • chore: ビルド、補助ツール、ライブラリ関連
2. 理由を書く
   コミットメッセージの例：ESLintの設定を追加した場合
   chore:ESLintの設定を適用するために、設定ファイルを追加

参考

https://qiita.com/konatsu_p/items/dfe199ebe3a7d2010b3e
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type

余談

チームに共有してみて、コミットのプレフィックスとかブランチ名で管理するのはちょっとやりすぎ感ある(少人数だし)ので、githubの機能使って分類うまくできないか？と意見を頂いたので、別途そちらでも検討してみようかな