Zenn
🐲

【第1回】Gitブランチ戦略について調べた（前編）

2024/01/02に公開
Git
idea

最初に

社内発信するネタ作りで、ブランチ戦略について年末年始で少し調べたのでいくつかの記事に分けてメモ書き程度にまとめる。Gitの理解はterraformやhelmなどの学習を進める上で第一歩になるのかなというところで、Gitの理解の過程として学習した。

今回のテーマはブランチ戦略。一人でGitを使う分にはGitの使い方の学習だけで十分かもしれないが、チーム利用を想定する場合はGitの使い方の他にもブランチ戦略やコードレビュー、CI/CDなどの知識も必要と思われたので、まずはブランチ戦略をテーマにしてみた。

今回はブランチ戦略を理解する上で必要な最低限の基本知識を最初に紹介し、ブランチ戦略を活用する必要性を紹介した後に、ブランチ戦略の1つのGit Flowについて紹介する。（追記：Git Flowの説明で力尽きたので比較先のGitHub FlowやGitLab Flowについては記事を分けることにした。）

各章はWeb調査をもとに要約、整理した内容を記載している。参考にした記事は参考情報としてリンクも載せるので興味ある方はご参照ください。続編記事は以下です。
【第2回】Gitブランチ戦略について調べた（後編）

基本知識

Git

ファイルの変更履歴を記録・追跡するための分散型バージョン管理システム。他バージョン管理システムとの違いは、他のバージョン管理システムの多くは差分ベースでファイルをバージョン管理するが、Gitは追跡しているファイルのデータのバージョンをファイルシステムの一連のスナップショットのように管理する。
参考情報：Getting Started - What is Git?

Gitの特徴：ブランチが軽量

ブランチとは、開発のメインラインから分岐し、そのメインラインをいじらずに作業を続けるための機能。他バージョン管理システムにもブランチ機能はあるが、特徴的な違いはブランチ作成・変更の軽量さ。他のバージョン管理システムの多くはブランチ作成の際に管理対象のファイルをコピーしてメインラインから分岐するが、Gitはブランチが指すコミット番号を記録したファイルを作成するだけのため、軽量で誰でも気軽にブランチを作成することができる。
参考情報：Git Branching - Branches in a Nutshell

ブランチ戦略

管理されたソフトウェア開発プロセスを実現するための開発モデル。気軽にブランチを作成できるため、チームでソフトウェア開発を行う場合には開発者全員が一定のルールを守りながら開発を進めることが大切になり、開発モデルとして体系化された。

（例）

  • Git Flow
  • GitHub Flow
  • GitLab Flow

一般的なブランチ戦略を取り入れるメリット

一般的にブランチ戦略を取り入れることで以下のメリットがある。

  • 新機能の開発
    • 本番用のコードに影響を与えず、新機能の開発ができる。
  • バグ修正
    • 本番用のコードに影響を与えず、バグ修正の開発ができる。
  • リリース管理
    • バージョン管理ができ、特定のバージョンでの試験ができる。
  • コードレビュー
    • メインブランチに取り込む前に、品質やコードスタイルの一貫性の確認ができる。
  • CI/CDの統合
    • CI/CDの導入がしやすくなる。

Git Flow

ブランチ戦略の1つ。古参。以下のブログで2010年に紹介された。今ではGit Flowを紹介した本人も他のもっとシンプルなブランチ戦略（例としてGitHub Flow）の利用をお勧めしている。
参考情報：A successful Git branching model

Git Flowの概要

5つのブランチにそれぞれの役割を持たせて、リリース管理する開発モデル。主にmainブランチとdevelopブランチが中心的なブランチとして役割を果たす。
参考情報：（再掲）A successful Git branching model

  • main（またはmaster）
    • リリース可能な状態（本番環境向け）のブランチ
    • リリースバージョンはタグで管理
  • hotfixes
    • mainブランチから分岐する
    • mainブランチ（developブランチ）にマージされる
    • 即時性の高いバグの修正を行うブランチ
    • developブランチと分けることで次期リリース向けの開発と並行して進められる
  • release
    • developブランチから分岐する
    • mainブランチ（場合によってはdevelopブランチ）にマージされる
    • 機能統合後のレベルで試験を行うブランチ
    • developブランチに次期リリースで追加されるすべての機能がfeatureブランチから統合された後（またはスプリント完了後）に作成される
  • develop
    • mainブランチから分岐する
    • 開発時のメインブランチ
    • 各featureブランチの統合先
    • releaseブランチを作ったりマージされた後はリリースを待たずに次期リリース向けのメインブランチとなる（円滑に開発を進められる。）
  • feature
    • developブランチから分岐する
    • 機能単位で新しい機能開発や機能単位でテストするためのブランチ
    • ライフサイクルとしてはdevelopブランチに統合されるか、破棄されるかの二択

Git Flowの特徴

1.新機能の開発

  • featureブランチにより独立した新機能開発が可能で機能単位で進捗確認ができる。

2.バグ修正

  • hotfixesブランチにより独立したバグ修正が可能で迅速に対処することができる。

3.リリース管理

  • 本番環境、ステージング環境、開発環境へはそれぞれmainブランチ、releaseブランチ、developブランチからリリースされる。
  • releaseブランチによりリリース前の状態で試験や修正をすることができる。

4.CI/CDの統合

  • Git Flowはリリースサイクルが他ブランチ戦略より比較的長いためCI/CDの統合には不向き。

5.その他

  • ブランチ数の多さと各ブランチの生存期間が長いため、マージが増え、履歴の複雑化やコンフリクト多発の可能性が高い。これはCI/CDの統合の妨げになる。
  • ブランチの数が多いため、ブランチ管理が複雑になる。一般的に小規模プロジェクトには過剰で不向き。

Tips

使い捨てブランチ

  • Git Flowはそれぞれ役割を持たせた複数のブランチを持つブランチ戦略ですが、主要なブランチはmainブランチとdevelopブランチ。
  • そのため、この2つのブランチは安定した状態を維持したいが、featureブランチをdevelopブランチにマージしたときに安定性を損なう可能性がある。
  • developブランチの安定性を担保する方法としてfeatureブランチからdevelopブランチに直接マージせずに使い捨てのブランチを間に挟むことでdevelopブランチの安定性を担保することが可能になる。
    参考情報：Throw-away integration

まとめ

Git Flowを取り入れることはブランチ戦略上いくつかのメリットがあるが、構造が複雑でリリースサイクルが長いため、CI/CDの統合では不向きであること、小規模プロジェクトについても不向きであることが分かった。
他のブランチ戦略を書く前に力尽きたので、じゃあどうすれば、っていう話は次の記事で書こうと思います・・・。

免責事項

内容の正確性、安全性等を保証するものでなく、何らの責任を負うものではありません。本記事内容のご利用により、万一、ご利用者様に何らかの不都合や損害が発生したとしても、何らの責任を負うものではありません。

Discussion