masterブランチへの変更適用ガイドライン

masterブランチへの変更適用ガイドライン

この文書ではmasterブランチに変更を加える際の基本的なルールやマナー、実際の作業の流れについて説明する。

基本ルール

• masterへの直接コミットは禁止する
• masterに変更を加えたい場合は、GitHub上でPull Requestを送り、自分以外のProject Hatoholメンバーのレビューを受けること
• レビュー完了後のmasterへのマージ作業はレビューした者が行うこと

議論ポイント

• 単純なtypoの修正など、簡単な修正も直接コミットを禁止するのか?
• 今のところ基本ルールは最低限に止めて、他に気をつけたいポイントはマナーの項目に追い出そうとしているが、どこまでをルールとするのがよいか。
• 「Project Hatoholメンバー」の箇所は「レビュアー」にすべきか? (現状はメンバー全員がレビューしているわけではないので)
• 「レビュアー」にはどうすればなれるのか?

マナー

Pull Requestの準備

• トピックブランチの作成
  • Project Hatoholへのコミット権がある場合は、トピックブランチはProject Hatoholのリポジトリに作成しよう
    • コミットメールを流すことにより、作業していることや、その内容をチームメンバーに通知するため
• コーディングスタイル
  • コーディングスタイルがProject Hatoholのルールに合致していることを確認しよう
    • https://github.com/project-hatohol/hatohol/blob/master/CodingConvention.md
• masterへの追従
  • トピックブランチとmasterブランチがコンフリクトしている場合は、Pull Reqeustを送信する前にコンフリクトを解決しよう
• ビルドとテストの確認
  • Pull Requestを送信するまえに、ビルドとテストが通ることを確認しよう

Pull Request送信時

• Pull Requestの粒度
  • 差分が大きすぎる場合は、Pull Requestの粒度を細かく分割するようにしよう
• 依存関係がある複数のPull Reqeustを送りたい場合
  • 依存関係がある複数のPull Requestを送信した場合は、依存関係があることをPull Reqeustのメッセージに記載しよう
  • 後から送信したPull Requestを先にマージしないと動作しないというような、順番が前後するPull Reqeustの送信の仕方は避けよう
• 互いにコンフリクトする複数のPull Reqeustを送りたい場合
  • 互いにコンフリクトする複数のPull Reqeustを同時に送信するのは避けよう
    • 注1) 「互いにコンフリクトする」とは、同時にmasterに適用することができない、あるいは同時に適用するとビルドやテストが通らなくなることを意味する
    • 注2) トピックブランチのpushまでは可。むしろ作業状況が他者に見えるように積極的にpushしたほうがよい
  • 互いにコンフリクトするトピックブランチをmasterにマージしたい場合は、ベースとなる側のPull Requestがマージされるまで残りのPull Requestを送信するのは避けよう
  • ベースのPull Requestがマージされたら、残りの変更はrebaseし、コンフリクトを解決してからPull Requestを送信しよう

Pull Request終了後

• 不必要になったブランチの削除
  • マージされたあとは使用したリモートブランチを削除しよう。

議論ポイント

• 「レビューして欲しいレビュアーを選んでAsigneeをセットすること」も追加したいが、現状ではレビュアーを選ぶ明確な基準が無い。
  • レビュアーが2人だったときにはなんとなくセットしていたが、3人になったあたりからセットしなくなってきたというのが背景にあり
  • このままセットしないという運用でもいいと思う
  • モチベーションは「レビュー作業の意図しない重複を割けたい」「ほったらかしをさけたい」なので、レビューを開始した人が自分でセットするのがベストか