#ブランチモデル
ブランチモデルは
Git Flow,
Git Hub Flow,
の二つが有名です。
それぞれのブランチ構成を見ていきます。
#Git Flow
A successful Git branching modelで提唱されたブランチモデルです。
それぞれのブランチを役割ごとに切り分けており、ブランチは5種類存在します。
(引用:https://nvie.com/posts/a-successful-git-branching-model/)
全ての開発者が参照するリポジトリ(origin)と開発者のリポジトリによって構成されます。
(以下origin/masterの表記はoriginリポジトリのmasterブランチ)
5種類の内訳はoriginに永続的に存在している２種類のメインブランチと必要に応じて作成され破棄される３種類のブランチからなります。
5種類の内訳）
1,origin/master:ソースコードのHEADが常に出荷可能な状態を反映するメインブランチ
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
2,origin/develop:ソースコードのHEADが常に時期リリースのための最新の変更を反映するメインブランチ。統合ブランチと呼ばれることもあります。
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
3,feature:今度のリリースに入る、または遠い将来のリリースに入るような新しい機能を開発するのに使われるブランチで基本的には開発者のリポジトリにあり、originにはありません。
developから切り、developにマージします。
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release.
Feature branches typically exist in developer repos only, not in origin.
4,release:次のプロダクションリリースに向けた準備をするブランチです。
新しいリリースをする段階で切り、マイナーバグフィックスやバージョン番号などの準備もここで行います。
developから切り、developとmasterにマージします。
Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.
5,hotfixes:ホットフィックスブランチです。
製品にバグが見つかった場合など緊急の修正を行うための切られます。
developから切り、developとmasterにマージします。
Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.
#GitHub Flow
大元はおそらくGitHub共同創業者のScott Chacon氏のGitHub Flow(リンク付き)です。
GitFlowがリリースを中心に設計されているのに対して、デプロイを中心にした考え方になっています。
定期的なデプロイと修正を行うことでバグがたくさん混入することがなくなります。
プルリクを作るタイプのフローで、以下の６つの特徴をもちます。
1,masterブランチのものは全てデプロイできる。
Anything in the master branch is deployable
2,新しい作業をするときはそれをよく説明するネーミングがされたブランチを作成する。
To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
3,ローカルでコミットをして、サーバー上に存在する同じ名前のブランチにも定期的にそれをpushする。
Commit to that branch locally and regularly push your work to the same named branch on the server
4,フィードバックやヘルプが欲しいとき、もしくはマージの準備が出来たらプルリクエストを作成する。
When you need feedback or help, or you think the branch is ready for merging, open a pull request
5,誰かがレビューして、認めてくれたらそれをmasterにマージして良い。
After someone else has reviewed and signed off on the feature, you can merge it into master
6,masterにマージしたら直ちにデプロイする。
Once it is merged and pushed to ‘master’, you can and should deploy immediately
##GitHub Flowの使い所
コンスタントにテストしデプロイするような出荷の文化が存在するチームにとってはGitHubFlowが好ましいとされています。
For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.
#GitLab Flow
上にあげた二つがメジャーな形式ですがそれ以外にもGitLab Flow(リンク付き)などが存在します。
よかったら見てみてください。