こんにちは、2年目の加藤です！
私は現在、データエンジニアとして、Google Cloudを活用したデータの取得や加工、整形などを担当しています。データ取得をCloud Run上でPythonを動かしたり、リソースをTerraformで管理する上で、GitHubを利用しています。前回の記事では、GitHubを利用する上でのGitの概念やGitコマンドを書きましたが、本記事では、共同で開発を行う上でのGitHubの運用方法のお勧めを共有したいと思います。
おさらい
本記事では、ブランチという考えが多くでてきます。ブランチとは、1つのメインのプロジェクトとは異なる分岐を作り、プロジェクト本体に影響を与えずに開発を行える機能のことをいいます。端的に述べると、本番環境やテスト環境、ローカル環境などが一般にありますが、その「環境」のことをブランチと述べているという認識で問題ありません。
ブランチの実際の操作コマンドやGitのコマンド、概念などは前回の記事からご覧ください。
共同開発のベストプラクティス
GitHubを使用する際に、何でこんなにブランチがあるんだろう？ブランチの運用ルールとかたくさんあって面倒くさい…などと思ったことはないでしょうか？私は思いました。なので、自分なりにブランチについて調べてみました。
ブランチにはブランチ戦略なるものがたくさんあるらしく、開発規模や開発環境によって適切なブランチ運用方法があるそうです。その中でも代表的なブランチ戦略として、下記3つを紹介したいと思います。
- GitHub-Flow
- Git-Flow
- GitLab-Flow
GitHub-Flow
GitHub-Flowとは、GitHub社が開発を進める際に用いているワークフローです。登場ブランチとしては、2種類だけでとてもシンプルで分かりやすいものとなっています。具体的なブランチイメージ図は下記の通りです。
- mainブランチ
本番環境にリリースするためのブランチ 常にリリースできる状態を保っているブランチ - featureブランチ
各ユーザがそれぞれ開発を行うためのブランチ mainブランチからブランチを切り出し、開発が終わったらmainブランチへマージする mainブランチへの直接のプッシュは禁止で、mainブランチへマージする際にプルリクエストを送り、コードレビューが通るとマージすることができる
GitHub-Flowの特徴は以下のものが挙げられます。
| メリット | デメリット |
|---|---|
|
|
GitHub-Flowの開発サイクル例は下記のようになっています。
- mainブランチから、各ユーザの開発用作業ブランチ（feature）を作成する
- featureブランチで開発をする
- 作業が完了したら、コミット＆プッシュをし、プルリクエストを作成、開発チームメンバーにコードレビューを依頼する
- レビューが承認されたらfeatureブランチをmainブランチへマージする
- mainブランチへマージ後ただちにデプロイをする
Git-Flow
Git-Flowとは、2010年にVincent Driessen 氏が提唱したワークフローです。GitHub-Flowとは異なり、主に5種類のブランチが登場します。具体的なブランチイメージ図は下記の通りです。
- mainブランチ
本番環境にリリースするためのブランチ 常にリリースできる状態を保っているブランチ - hotfixesブランチ
本番環境の緊急のバグ修正用ブランチ mainブランチから作成されるブランチ mainブランチと同時にdevelopブランチへマージさせる - releaseブランチ
本番環境へリリースする前の最終確認を行うブランチ developブランチから作成されるブランチ 軽微なバグ修正、ドキュメントの更新などを行い、新機能は開発しない mainブランチと同時にdevelopブランチへマージさせる - developブランチ
開発用のブランチ mainブランチから作成されるブランチ featureブランチのマージ先となる - featureブランチ
各ユーザがそれぞれ開発を行うためのブランチ developブランチから作成されるブランチ developブランチにマージする
Git-Flowの特徴は以下のものが挙げられます。
| メリット | デメリット |
|---|---|
|
|
Git-Flowの開発サイクル例は下記のようになっています。
【新機能開発から本番環境へのリリース】
- developブランチから、各ユーザの開発用作業ブランチ（feature）を作成する
- featureブランチで開発作業を行う
- 作業が完了したら、コミット＆プッシュをし、プルリクエストを作成、開発チームメンバーにコードレビューを依頼する
- レビューが承認されたらfeatureブランチをdevelopブランチへマージする
- 不要になったfeatureブランチを削除する
- developブランチからreleaseブランチを作成
- releaseブランチでリリース準備作業を行う
- リリース準備完了後、mainとdevelopにマージ
- 不要になったreleaseブランチを削除する
GitLab-Flow
GitLab-Flowとは、GitLab社が提唱しているワークフローです。Git-FlowとGitHub-Flowの中間的な位置づけのワークフローで、Git-Flowを少しシンプルにしたものです。GitLab-Flowに登場するブランチは主に4種類です。具体的なブランチイメージ図は下記の通りです。
- mainブランチ
常にリリースできる状態を保っているブランチ - productionブランチ
本番環境にリリースするためのブランチ 一度ブランチを作成したら削除しない - pre-production/stagingブランチ
リリース前の最終確認を行うブランチ mainブランチから作成されるブランチ 動作確認やテストを行う 一度ブランチを作成したら削除しない - feature/hotfixesブランチ
mainブランチからブランチを切り出し、開発が終わったらmainブランチへマージする 緊急のバグ修正もこのブランチで行う
GitLab-Flowの特徴は以下のものが挙げられます。
| メリット | デメリット |
|---|---|
|
|
GitLab-Flowの開発サイクル例は下記のようになっています。
【新機能開発から本番環境へのリリース】
- mainブランチから、各ユーザの開発用作業ブランチ（feature）を作成する
- featureブランチで開発作業を行う
- 作業が完了したら、コミット＆プッシュをし、プルリクエストを作成、開発チームメンバーにコードレビューを依頼する
- レビューが承認されたらfeatureブランチをmainブランチへマージする
- 不要になったfeatureブランチを削除する
- （pre-productionブランチが未作成の場合）mainブランチからpre-productionブランチを作成
- （pre-productionブランチが作成済の場合）mainブランチからpre-productionブランチへのプルリクエストを作成
- レビューが承認されたらmainブランチをpre-productionブランチへマージする
- pre-productionブランチで最終確認を行う
- （pre-productionブランチが未作成の場合）最終確認完了後、mainブランチからproductionブランチを作成
- （pre-productionブランチが作成済の場合）最終確認完了後、mainブランチからproductionブランチへのプルリクエストを作成
結局どれがいいの？
各ブランチ戦略とその特徴、ユースケースを下記に示します。
| ブランチ戦略 | 特徴 | ユースケース |
|---|---|---|
| GitHub-Flow | シンプルなワークフロー 複数リリースの並行管理ができない |
チーム規模が小さく、頻繁にリリースを行うプロジェクトの場合 |
| Git-Flow | 複雑なワークフロー リリースを厳格に管理することができる |
チーム規模が大きく、計画的に長期リリースするプロジェクトの場合 |
| GitLab-Flow | Git-FlowとGitHub-Flowの中間的な位置づけのワークフロー | デプロイやテストをやりやすくしつつ、本番環境コードの品質をある程度担保したい場合 |
どれを使えばいいかは基本的にチームの規模やリリースサイクル、品質管理の厳密さなどによって変わってきますので、どれがいいとは言えず、ケースバイケースです。しかし、私個人の意見としては、GitLab-Flowをお勧めします。その理由としては、ある程度の品質保証を行いながらも、シンプルなワークフローで運用できるため、導入もそんなに大変ではないと考えるためです。GitHub-Flowはわかりやすいですが、私見に基づくに、本番環境へのバグ混入が多々見られたり、Git-Flowでは運用フローが複雑すぎて、学習コストが高く使いにくい印象を受けました。
まとめ
今回は、GitHubを共同開発で使用する際のブランチ戦略について紹介させていただきました。
本記事では、ブランチ戦略として3種類紹介いたしましたが、他にもあるのでご興味のある方は調べてみてください。
自分たちのプロジェクトに合うブランチ戦略を見つけ、効率的な開発を実現しましょう。