Centralized Workflow

Subversionの使い方を踏襲する。
中央リポジトリを使用して、プロジェクトへの変更の単一エントリーポイントとして使用する戦略。小規模プロジェクト向け。

  • 開発者は中央リポジトリのメインブランチ（たとえばorigin/master）のみ使う

Feature Branch Workflow

すべての機能開発をメインブランチではなく専用のブランチで行う戦略。
このカプセル化により、複数の開発者がメインのコードベースに影響を与えることなく特定の機能開発を行うことができる。
これはプルリクエストの活用にもつながっている。

  • 開発者は機能ブランチ（たとえばorigin/issue-xxxxx）をつかう
  • 機能（feature）ブランチをメインブランチ（たとえばorigin/master）へpushする

Gitflow Workflow

Feature Branch Workflowを基に厳密なプロジェクトリリースを中心に設計された厳密な分岐モデルを定義したもの。大規模プロジェクト向け。
メインブランチ（master）と開発（develop）を中心にサポートブランチとして機能（feature/topic）ブランチ、リリース（release）ブランチ、メンテナンス（hotfix）ブランチを使う。

  • 公式リリース用のmasterブランチ（公式リリース履歴を格納）
  • 開発用のdevelopブランチを（機能の統合ブランチ）
  • 機能（feature）ブランチはdevelopを親ブランチとして分岐する
  • developブランチを公開する場合releaseブランチを作成する（リリース履歴としてmasterにバージョン番号タグで記録）
  • リリースが完了したらreleaseブランチはmasterブランチとdevelopブランチにマージさせる
  • releaseブランチは機能追加を行わずメンテナンスのみを行うブランチになる
  • バグ修正はhotfixブランチとしてmasterから分岐して行い、masterとdevelopにマージする

Forking Workflow

開発者が独自のリポジトリを持つ戦略。パブリックオープンソースプロジェクト向け。
開発者は独自のリポジトリにpushし、プロジェクトの公式リポジトリはメンテナーのみがpushできる。
公式リポジトリへのマージはプルリクエストを使う。

GitHub flow

定期的なデプロイが必要なプロジェクト向けの軽量のブランチベースのワークフロー。
Feature Branch Workflowと基本的には変わらないが、メインブランチへのマージはプルリクエストを使う。

  • 開発者は機能ブランチ（たとえばorigin/issue-xxxxx）をつかう
  • 機能（feature）ブランチをメインブランチ（たとえばorigin/master）へpushするためにプルリクエスト

GitLab flow

Issue Tracking Systemを統合した仕組み。
GitLab flowは機能（feature）ブランチをマージするたびに本番環境へデプロイすることを想定しているが、環境によってはリリース時間はコントロールできない。
そこで、デプロイしたコードを反映させたproductionブランチを使用する。

  • コード変更は必ずIssueとして登録して機能ブランチとリンクする
  • GitHub flowのように機能ブランチをつかい開発する
  • メインブランチ（master）は開発環境（srtage）へデプロイする
  • プリプロダクション環境へのデプロイはメインブランチからpreproductionブランチへのプルリクエストで行う
  • プロダクション環境へのデプロイはpreproductionブランチからproductionブランチへのプルリクエストで行う

gitworkflows

Git本家推奨のワークフロー。

  • 変更は小さな論理的ステップに分割する（git-blameやgit-bisectで調査・解析を容易にする）
  • メンテナンスリリース用のmaintブランチ
  • 機能リリース用のmasterブランチ
  • 機能リリースに向けたトピック安定化のためのテスト用のnextブランチ
  • 含めるには時期尚早なコミット用の統合用のpu（proposed updates）ブランチ
  • maint -> master -> next -> puの親子関係
  • 機能リリースはmasterブランチからトピックブランチを作成する（pu -> next -> masterでマージ）
  • メンテナンスリリースはmaintブランチからトピックブランチを作成する（next -> maintでマージ）
  • masterブランチはmaintブランチのスーパーセットでなければならない（maint -> masterでマージ）
  • 機能リリース統合後、統合用のnextブランチやpuブランチはmasterの先端へと巻き戻し（reset）もとのnext上に生き残っていたトピックブランチを使って再構成（historyがきれいになる）
  • 巻き戻しと再構成はnextブランチに関しては関する公式アナウンスをすべき（puブランチは使い捨て）

Trunk Based Development (TBD)

各機能を個別のブランチで開発し、安定した後にのみマージするFeature Branchingとは異なりトランクで開発し、リリースごとに分岐を保持するRelease Branchingの戦略。
小規模で頻繁なマージを行うことで、マージの複雑さを軽減し、コードを最新の状態に保つ。

  • 各開発者は自分の作業を数時間で終わる程度の小さなバッチに分割
  • メインブランチであるトランク（メインライン）にマージは少なくとも1日に1回（場合によっては数回）の頻度で行う
  • リリースブランチで行われたバグ修正などはできるだけ早くトランクへマージする
  • 小規模で頻繁なマージを行うことで、イベントのマージの複雑さを軽減し、コードを最新の状態に保つ