git-flowとGitHub Flowを知る
実際のチーム開発でしばしば見られるGitのブランチの扱い方には、git-flowとGitHub Flowの2種類があります。
目次
git-flow
Git-flowは実際に開発を進めるブランチ以外にも多くのブランチがあり、手順が整備されています。
| ブランチ名 | マージ先 | 役割 | 備考 |
|---|---|---|---|
| master | – | リリース済みのコード (要は実際に運用中のコード) があるブランチ | 名前がmainの場合もある |
| hotfix-xx | masterとdevelop | 緊急の修正作業を行う。完了後はマージされ、ブランチは削除される | -xxには、例えば修正名、issue番号などが入る |
| release-xx | masterとdevelop | ドキュメント整備など、リリース前の準備作業用ブランチ。完了したらmasterにマージ (リリース) され、ブランチは削除される。 | -xxには、例えばバージョンなどが入る |
| develop | – | 開発中のソースコードがあり、動作するブランチ。このブランチは削除しない | 要はα版のようなもの |
| feature-xx | develop | 各機能や修正などのの開発作業を進行するブランチ。マージ後は削除される | -xxにはissue番号や機能名などが入る |
これを実際に図にしてみましょう。
流れ
実際に開発する際の流れを考えてみましょう。まずはmainとdevelopブランチを作成します。
特に複雑に見えるのは、featureとreleaseの2つですね。
機能作成やバグ修正
- developからfeature-xxブランチに分岐
- feature-xxで作業
- 完了したら、developにマージ
- developからreleaseに分岐し、リリース準備
- 完了したら、mainとdevelopにマージ
という手順になります。featureからdevelopにマージするときにコードレビューなどが行われます。
リリース
- developブランチからrelease-xxブランチに分岐
- release-xxブランチでリリース前作業 (ドキュメント整備など)
- 完了したらmainとdevelopにマージ
という手順になります。
GitHub Flow
GitHub Flowは、git-flowと比較し、非常にシンプルなフローです。
GitHub Flowに関する公式のドキュメントは下のページにあります。
図の通り、main (master)とfeature系ブランチの2種類しかありません。
また、mainブランチは本番環境で動作するコードと同等のものです。そのため、git-flowより高速なリリースが可能です。
実装の流れ
GitHub Flowには、どのような順で作業を進めていくべきかの6つの手順があります。
機能や修正ごとにブランチを作る
ブランチには、機能名など、そのブランチが何のブランチなのか説明するような名前をつけます。これにより、どのような作業が進行しているかがひと目で分かります。
変更する
作成したブランチ上で作業し、実装していきます。
1つのコミットには1つの独立した完全な変更 (要は部分的な機能が動作する) であることが理想的です。これにより、機能を取り除いたりする際に、簡単に戻せるためです。例えば、変数を追加して新機能を積むコミット、それをテストするコミット、見つかったバグを修正するコミット、といった単位です。1つのバグを修正するのに3つも4つもコミットを分けるのは良くない、あるいはテストと修正を1つのコミットで出すのは良くない、ということです。
コミットしたものはプッシュします。他の人から進捗が見えるようにし、みんなとその実装についての相談や方針の確認などするためです。
Pull Requestを作成
プルリクを作り、実装したもののコードレビューや動作確認などをしてもらいます。
プルリク作成時は、変更点の概要や、何のために実装したものかなどを書きます。また、プルリクとissueを必ず双方向に紐付けます。
もちろん、開発者以外のチームに確認を依頼するような場合もあります。
また、自動テストなどで、プルリク作成時のチェックなども可能です。
レビューへの対応
レビュー者は、質問、コメント、提案などを行います。GitHubであれば、部分的なコードに対してコメントを直接書き込めます。
レビューされたら、また修正し、再度レビューしてもらい、というのを繰り返します。
また、コンフリクトはGitHubが自動検出してくれます。マージに影響が出ないようにその修正も行います。
Pull Requestをマージ
プルリクが承認されたら、GitHub上で開発ブランチをmainブランチにマージします。
GitHubでは、一定人数のレビューを通過しないとマージできない、特定チームのレビューを通過しないとマージできないなどの設定が可能です。
ブランチの削除
プルリクをマージ後は、ブランチを削除します。
削除することで、ブランチ一覧で作業中と誤認されないように、他者が誤って古いブランチを使用しないように、といった対策になります。
削除してもコミット履歴が消えたりすることもなく、削除前に戻すこともできます。
どちらがよいのか
まず、どちらか片方が優れている、というわけではありません。
git-flowは堅実です。releaseブランチがステージング環境として作成される場合もあると思います。
GitHub Flowは素早いリリースが可能で、運用はシンプルです。変化が速いWebアプリなどに向いているかもしれません。
まとめ
git-flowとGitHub Flowはどちらにも良い点があります。進行するプロジェクトは信頼度が高い必要があるのか、素早いリリースをこまめに求められるのかなど、状況によって使い分けるべきです。
