gfls入門 - gitflowっぽいアレ-
TRANSCRIPT
GFLS 入門 GFLS means GitFlow Like Style
© 2015 Takahashi Fumiki
いつ使うの？• 商用環境でミスをすることが許されない怖い環境
• 計画的・定時リリースが行われる環境
• 複数の開発者が存在する環境
• 課題がたくさん存在し、それが必ずしも採用されるとは限らない環境
• 「あの広告表示機能、やっぱいらないわ」という環境
• Githubじゃないので、GithubFlowできない環境
基本ワークフローmaster
develop
feature
release
ロゴの差し替え
タブの追加
2015/03/12公開分
開発デプロイ
商用デプロイ
基本原則• masterブランチはどのコミットを商用環境にリリースしても問題のないブランチである。
• developブランチは開発の起点となるブランチであり、ステージング環境相当である。
• すべての開発はdevelopブランチから枝分かれしたfeatureブランチで行う。
• 1つのfeatureブランチは課題管理システムにおける1つの課題に相当する。
• masterおよびdevelopへのデプロイはreleaseブランチを作成することで行う。
• masterブランチに対してのみ、例外的にhotfixブランチを作成することが許される。
• すべてのブランチをpushする。
手順• 課題に紐付いたfeatureブランチを作成する。名前はfeature/課題IDとする。各コミットには課題への言及（およそのITSにはそういう機能がある）を含める。
• 必ず最新のdevelopブランチからfeatureブランチを作成する。
• リリースが決まったら、releaseブランチを最新のdevelopブランチから作成する。名前はrelease/whatever-you-likeとする。
• releaseブランチに必要なfeatureブランチをマージしていく。競合が発生した場合は、releaseブランチ上で解決する。
• マージする際は常にマージコミットを作成する。fast-forwardは行わない（他者から見て分かりづらいため）
• releaseブランチが完了したらdevelopブランチからマージする。競合が発生した場合はdevelopブランチ上で解決する。
• developブランチはステージング環境相当であるため、この時点で確認は行われている。確認して問題なければ、商用環境にリリースする。
• masterブランチにreleaseタグをつける。
よくある質問
Q.やっぱりいらない
develop
feature
release
ロゴの差し替え
タブの追加
2015/03/12公開分
このマージはいらない
A. コミット取り消し
git reset - -hard でブランチを戻してマージしなおすか……
REVERT
git revert commit_id で取り消し用コミットを作成する
Q. 商用が真っ白にmaster
develop
feature
release
ここで問題！ヤベエｪｪ！
A. hotfixで治すmaster
develop
hotfix developへのマージを忘れると、masterとの差分が発生してしまう。
商用環境自体はmasterブランチを
一個戻せば治る。
Q.一部だけ必要に
develop
feature/hoge
BのJSがないと開発が…
feature/fuga
A B C
A. Cherry Pickdevelop
feature/hoge
feature/fuga
ただし、適切な粒度で開発され、細かくコミットされていることが条件。多くの場合、こんなに上手くいかない。
Aのコミットの差分は来ない
A B C
Q. 放置したfeature
develop
release
feature
ずっと前に作ったのだが、たくさんの新機能がすでにリリースされてしまった……
A. developをマージ
develop
release
feature
追いついた！
Q. テストサーバは？master
develop
test
A. testブランチ作る
試したいfeatureブランチを集めたtestブランチを
都度作成する。いらなくなったら消す。
テストサーバにデプロイ
Q. GithubFlowがよくね？
A. Github使うならYes
• Githubを業務に使ってない会社もあり、プルリクができない。
• コードレビューの体制がない場合もある。
• テストコード？ なにそれ？ という場所も多い。
終わりすてきなGitライフを！