Masayan tech blog.

  1. ブログ記事一覧>
  2. Githubを最適化してチーム開発の効率を爆上げする

Githubを最適化してチーム開発の効率を爆上げする

公開日

この記事を読むとできるようになること

Githubを用いたチーム開発において、

  • プルリクエストのテンプレート化
  • マージ制限
  • 自動マージ、自動ソースブランチ削除

などの設定ができるようになる

※全ての設定を紹介するというよりも、私が個人的に有用だと思っているものを中心にピックアップして紹介する

プルリクエストのテンプレート化

.github/PULL_REQUEST_TEMPLATE.mdを作成すると、Create pull requestから新しくプルリクエストを出す際にテンプレートが使用でき、毎回コピペしたり、書く内容を考える手間を省くことが可能

## 1. 実装者向け

### プルリクエストの概要
Ex.) 認証機能の追加

#### チケット
チケットがあれば、urlをここに貼ってください

### 動作検証結果
- 実装者のローカルでの動作検証結果を共有してください
- 共有方法は、・・・

### 環境変数
環境変数の追加を伴う場合はその内容をここに記載する

### 積み残し
仕様検討が必要、時間が不足していて後回しにしているものがあれば、ソースコード上にTODOを残し、その箇所をここに記載して共有する

### 特に重点的にレビューしてほしい点
あればここに記載する

### 次に着手するタスク
レビュー待ちの間に着手するタスクをここに記載する


## 2. レビュアー向け
### 最低限のチェックリスト
#### 実装
- [ ] ディレクトリ設計やファイルの配置場所が適切か
- [ ] 調査用、通知用のログ出力は十分か
- ・・・

#### テスト
- [ ] テスト、テストケースは漏れていないか、カバレッジは十分か
- [ ] データベースへのアクセスを行う処理が含まれる場合、クエリ発行回数は適切か、またテストで確認できているか

## 3. その他
あればここに記載する

デフォルトブランチ

リポジトリを作った直後は、mainがデフォルトブランチになるので、ベースブランチをdevelopなどに変更できる(特にgit-flowで開発する場合)

Settings -> Default branch

プルリクエスト作成後に、ベースブランチが更新されたらソースブランチの更新を提案

Update branchという項目がプルリクエストに表示されるようになり、これを実行すると、リモートのソースブランチにベースブランチの内容を取り込むことが可能。その後、ローカルのブランチにはpullしてくる

Settings -> Pull Requests -> Always suggest updating pull request branches

自動マージ

マージ要件をたしたら、必須としているレビューの承認とステータスチェックを通ったら、自動マージするようにできる

Settings -> Pull Requests -> Allow auto-merge

マージ済みの不要になったソースブランチを自動削除

Settings -> Pull Requests -> Automatically delete head branches

指定ブランチへのマージ要件

マージに承認を必須とすることで、別ブランチをプルリクエストでマージすることを強制する( 指定したブランチには直接pushできなくする)

Settings -> Branches -> Require a pull request before merging にチェックをつけると、保護設定したブランチに直接pushすると以下のメッセージが表示され、キャンセルされる

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: 2 of 2 required status checks are expected.

さらに、Branch name patternに指定したブランチに対して設定可能な、関連する細かい設定がいくつかある

マージに最低限必要な承認数

Require approvalsにチェックをつけると、プルリクエストのマージに最低限必要な承認数を設定できる

新しいコミットが追加されたら承認を却下する

Dismiss stale pull request approvals when new commits are pushed にチェックをつけると、プルリクエストが承認された後に、新しいコミットが追加されたら承認を却下するようになる(一度承認したとしても、その後に何かしらコミットがあれば、そのコミット内容も含めて承認済みとしたい)

コードオーナーの承認を必須とする

Require review from Code Ownersにチェックをつけると、プルリクエストのマージにコードオーナーの承認を必須とすることが可能

コードオーナー(リポジトリ内のコードに責任を持つ人)

プルリクエストが出された場合、自動的にレビュー依頼がコードオーナーに飛ぶようになる

<コードオーナーの設定>
.github/CODEOWNERSを作成し、ユーザー名を指定する。例えば、@Tanaka @satoと記述すれば田中さんと佐藤さんのレビューがマージに必須となり、プルリクエストのReviewersの箇所に鍵マークが表示され、Code owner review required」と表示される

なお、複数のコードオーナーが指定されている場合でも、1人のコードオーナーからの承認があればマージが可能

指定したユーザーに対し、プルリクエストの要求を課さないようにする

指定したユーザーやチームは、この項で説明している指定ブランチへのプルリクエストのマージ要件を適用外とすることができる(緊急の修正などの場合)

Settings -> Branches -> Branch protection rulesからAllow specified actors to bypass required pull requests にチェックをつける

指定ブランチへのマージにステータスチェックを必須とする

Require status checks to pass before merging にチェックをつけるとあらかじめpush時に走るCIの実行を設定しておき、CIの実行が成功したらプルリクエストのボタンを押せるようになる等の制御が可能になる

CIが通る前はマージプルリクエストボタンが押せなくなる。

全てのコメントが resolve (解決)となっていることを必須とする

Require conversation resolution before merging にチェックをつけるとマージに前にプルリクエストの全てのコメントが resolve (解決)となっていることを必須とすることが可能

まとめ

いかがでしたでしょうか。本記事では、Githubで特定のブランチを保護して、直pushや削除を防止する方法について紹介しています。保護ブランチへのマージ前に、特定のステータスチェックを必須とする方法と、レビューを必須とする方法を紹介していますので、ぜひ本記事を参考にし、パターンに応じて設定にしてみてください。