Gitを使った有名な開発フロー、GitFlowとGitHub Flowについて

はじめに

Gitを使った有名な開発フローに、GitFlowとGitHub Flowがあります。

  1. GitFlow
  2. GitHub Flow

この2つの開発フローについて主観的にまとめてみました。

GitFlow


http://keijinsonyaban.blogspot.jp/2010/10/a-successful-git-branching-model.html

GitHub Flow
https://gist.github.com/Gab-km/3705015

それぞれの特徴

まずはそれぞれの主観的な特徴です。

特徴 GitFlow GitHub Flow
ブランチ 定型 自由
難しさ ちょっと難しい 難しい
マージ Gitのマージ機能 プルリクエスト
コードレビュー 取り決めなし PR時にレビュー
CUIヘルパ git-flow hub
リリース 堅い ガンガン

ブランチの切り方について、GitFlowは(ほぼ)決められています。

ブランチの運用について

GitFlowではブランチの運用方針について取り決めがあります。

ブランチ デフォルト値
マスターブランチ master
開発ブランチ develop
機能追加用ブランチ future/
リリース用ブランチ release/
ホットフィックス用ブランチ hotfix/

それぞれのブランチ名は、基本的にデフォルトの名前を付けます。

このブランチ運用こそがGitFlowの本質とも言えて、ブランチ間の移動に取り決めがあります。

  1. スタート
  2. 開発ブランチ作成
  3. 開発
  4. 開発ブランチマージ
  5. リリースブランチ
  6. ホットフィックス
  7. リリースブランチマージ
  8. リリース

ざっくり上記の流れになります。

それに対してGitHub Flowでは、masterブランチのみ決められています。
ただしmasterブランチは「常にデプロイ可能」という強い制約があります。
GitHub Flowのブランチ運用で最も重要な箇所ですね。

難しさ

特徴 GitFlow GitHub Flow
難しさ ちょっと難しい 難しい

そもそも「難しさ」の定義について色々あると思いますが、実際に運用してみた感想です。
開発フローとしてGitFlowを採用した場合、GitHub Flowを採用した場合にチームメンバーから不明な点などの問い合わせが相次ぎました。

「Gitを使いましょう!」と始めて、プル、コミット、プッシュができるようになって、その次のフェーズに進みました。

Gitレベル できること
レベル1 pull(fetch), commit, push
レベル2 branch, stash, merge, resolve
レベル3 プルリクエスト, レビュー、採用

GitFlowの名称について

GitFlowは同名のgitflowという名前のツールがあります。
作者は

このリポジトリのfirst commitは2010年1月となっていました。

https://github.com/petervanderdoes/gitflow-avh/commit/a9575ca331c6f1855dcd78ff5c8838b92d9bea67
この最初のコミットを行っているのが nvie(Vincent Driessen)という方です。

またGitFlowの開設について、原典は下記の記事のようです。
この記事を書いたのも nvie です。
ちなみにこの記事では「GitFlow」という名称は出てきておらず、
「A Successful Git Branching Model」(素晴らしいGitのブランチ運用について)
というタイトルが付いています。
この記事では「GitFlow」という名称は登場していません。

恐らく先ほどのgitflowというツール名から、
nvieの提唱する「A Successful Git Branching Model」の方法論のことを「GitFlow」と呼ぶようになったのではないか、と思われます。
ちなみにGitのリポジトリ名は全て小文字で表記しますので、gitflowのツール名は小文字です。
ですが開発フローとしての表記はGitFlowが自然に見えます。そのあたりもあり、表記については揺れがあるようです。
1. GitFlow
1. gitflow
1. git-flow

GitFlow

運用して発生した問題点

ブランチ操作

プルリクエスト

コードレビュー

http://qiita.com/mint__/items/bfc58589b5b1e0a1856a
https://b.pyar.bz/20140122/github-flow

GitHub Flow

それぞれの特徴

まずはそれぞれの主観的な特徴です。

特徴 GitFlow GitHub Flow
ブランチ 定型 自由
難しさ ちょっと難しい 難しい
マージ Gitのマージ機能 プルリクエスト
コードレビュー 取り決めなし PR時にレビュー
CUIヘルパ git-flow hub
リリース 堅い ガンガン

ブランチの切り方について、GitFlowは(ほぼ)決められています。

ブランチの運用について

GitFlowではブランチの運用方針について取り決めがあります。

ブランチ デフォルト値
マスターブランチ master
開発ブランチ develop
機能追加用ブランチ future/
リリース用ブランチ release/
ホットフィックス用ブランチ hotfix/

それぞれのブランチ名は、基本的にデフォルトの名前を付けます。

このブランチ運用こそがGitFlowの本質とも言えて、ブランチ間の移動に取り決めがあります。

  1. スタート
  2. 開発ブランチ作成
  3. 開発
  4. 開発ブランチマージ
  5. リリースブランチ
  6. ホットフィックス
  7. リリースブランチマージ
  8. リリース

ざっくり上記の流れになります。

それに対してGitHub Flowでは、masterブランチのみ決められています。
ただしmasterブランチは「常にデプロイ可能」という強い制約があります。
GitHub Flowのブランチ運用で最も重要な箇所ですね。

難しさ

特徴 GitFlow GitHub Flow
難しさ ちょっと難しい 難しい

そもそも「難しさ」の定義について色々あると思いますが、実際に運用してみた感想です。
開発フローとしてGitFlowを採用した場合、GitHub Flowを採用した場合にチームメンバーから不明な点などの問い合わせが相次ぎました。

「Gitを使いましょう!」と始めて、プル、コミット、プッシュができるようになって、その次のフェーズに進みました。

Gitレベル できること
レベル1 pull(fetch), commit, push
レベル2 branch, stash, merge, resolve
レベル3 プルリクエスト, レビュー、採用

GitFlowの名称について

GitFlowは同名のgitflowという名前のツールがあります。
作者は

このリポジトリのfirst commitは2010年1月となっていました。

https://github.com/petervanderdoes/gitflow-avh/commit/a9575ca331c6f1855dcd78ff5c8838b92d9bea67
この最初のコミットを行っているのが nvie(Vincent Driessen)という方です。

またGitFlowの開設について、原典は下記の記事のようです。
この記事を書いたのも nvie です。
ちなみにこの記事では「GitFlow」という名称は出てきておらず、
「A Successful Git Branching Model」(素晴らしいGitのブランチ運用について)
というタイトルが付いています。
この記事では「GitFlow」という名称は登場していません。

恐らく先ほどのgitflowというツール名から、
nvieの提唱する「A Successful Git Branching Model」の方法論のことを「GitFlow」と呼ぶようになったのではないか、と思われます。
ちなみにGitのリポジトリ名は全て小文字で表記しますので、gitflowのツール名は小文字です。
ですが開発フローとしての表記はGitFlowが自然に見えます。そのあたりもあり、表記については揺れがあるようです。
1. GitFlow
1. gitflow
1. git-flow

GitFlow

運用して発生した問題点

ブランチ操作

プルリクエスト

コードレビュー

http://qiita.com/mint__/items/bfc58589b5b1e0a1856a
https://b.pyar.bz/20140122/github-flow

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

%d人のブロガーが「いいね」をつけました。