A successful Git branching model を途中から導入する
Gitのブランチの良い切り方はないかと探していたところ、A successful Git branching model(翻訳)なるものを見つけたので、これを参考にすることにした。
（別の流派）
僕たちが行き着いた、シンプルで簡潔なGitの運用方法 - テクノロジーと広義のデザイン！
こんなのもある。
- リリースブランチにmerge --squash(圧縮コミット)でコミット
- 細かい開発の経緯はフィーチャーブランチにしか残らない
- フィーチャーブランチの終端は履歴の上でリリースブランチに合流することなく、文字通り枝のように残り続ける
- リリースブランチの先頭はリリースできる状態ではない
- どの状態をリリースしたの（すべき）かはタグで管理
- 図を見るとリリースブランチが2本あるが、masterが開発用ブランチでv0.1releaseが実際のリリース用のブランチなのだと思われる
・リリースブランチがコミットで埋もれることがないので後で見やすいと思える。
・フィーチャーブランチを開発する機能名にするとよさげ。
・masterをリリース用ブランチにしようと思うなら、devブランチを作成してフィーチャーブランチはそこから分岐させていけばいいと思われる。
GitHub Flow (Japanese translation) — Gist
GitHub社で行われてるflow
A successful Git branching model とは
- masterはリリース用のブランチで、リリースしたらタグ付けする
- developは開発用ブランチ。リリース準備ができたらmasterへマージする。リリース前はこのブランチが最新
- サブブランチ
- feature branchesは機能追加のためのブランチで、developから分岐/マージする
- release-*はリリースの準備のためのブランチ(主にバージョン番号を挙げる作業のためだけに使われる) ※*はバージョン番号を進めたもの
- hotfix-*(緊急性高)／fix-*(緊急性低)はバグ修正のためのブランチ ※*はバージョン番号を小数点で進めたもの
- サブブランチをマージするときは「git merge --no-ff」で痕跡を残す
- no-fast-forwardとはなんぞやという方は→図で分かるgit-mergeの--ff, --no-ff, --squashの違い - アジャイルSEを目指すブログ
参考：
Gitコマンドの復習
実践
0.リモートにoriginリポジトリを用意する
git remote add origin git@github.com:LeafCage/sample.git
1.developブランチを作りそれに切り替える
√a.今までのmasterをdevelopブランチに書き換える
git branch -m master develop
√b.新しくdevelopブランチを作成する
git checkout -b develop master
2.developブランチからサブブランチを作る
git checkout -b feature-test develop
※今現在ワークツリーで行った修正を別のブランチにコミットしたくなった場合はstashを使う
git stash save git checkout -b feature-test develop git stash pop git commit -a
3.サブブランチをdevelopブランチにマージしてサブブランチを削除する
git checkout develop git merge --no-ff feature-test git branch -d feature-test git push origin develop #originリポジトリにdevelopブランチも一応作るらしい
4.新バージョンをリリースする（リリースブランチとmasterのタグ付け）
git checkout -b release-1.2 develop 〜諸変更〜 git commit -a -m "Bumped version number to 1.2" git checkout master git merge --no-ff release-1.2 git tag -a 1.2 #masterにタグを打つ git push origin master git checkout develop git merge --no-ff release-1.2 git branch -d release-1.2
