目次
はじめに
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