目次
はじめに
Gitを使った有名な開発フローに、GitFlowとGitHub Flowがあります。
- GitFlow
- 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の本質とも言えて、ブランチ間の移動に取り決めがあります。
- スタート
- 開発ブランチ作成
- 開発
- 開発ブランチマージ
- リリースブランチ
- ホットフィックス
- リリースブランチマージ
- リリース
ざっくり上記の流れになります。
それに対して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の本質とも言えて、ブランチ間の移動に取り決めがあります。
- スタート
- 開発ブランチ作成
- 開発
- 開発ブランチマージ
- リリースブランチ
- ホットフィックス
- リリースブランチマージ
- リリース
ざっくり上記の流れになります。
それに対して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