refirio.org

gitflowだと、案件によっては 「本番環境に反映できないものがdevelopにあるので運用しづらい」 が多く発生するため、ブランチモデルについて考察 独自のブランチ名やルールは極力避けたい 通常のgitflowに戻して運用できるのが理想 「日々の更新が頻繁に発生するWebシステムだが、大きな機能追加も並行して進める必要がある」 という案件に導入して、スムーズに運用できたと思うのでメモ ■master 本番環境と同一 このブランチで直接作業は行わない releaseとhotfixからのみマージされる releaseからマージした場合、1.0.0 → 1.1.0 とする（バージョンタグを付ける場合） hotfixからマージした場合、1.0.0 → 1.0.1 とする（バージョンタグを付ける場合） hotfixのreleaseへのマージ忘れ対策に、定期的にmasterからreleaseにマージする ■release ステージング環境と同一（最終確認用のステージング環境がある場合） 原則としてこのブランチで直接作業は行わないが、すぐに（「本日中に」くらいの目安）本番反映してもいい軽微な調整なら直接作業も可 masterから作成し、リリースのタイミングでmasterへマージする 日々の更新を開発版に反映するため、定期的にreleaseからdevelopとtestにマージする ■topic/1-xxx 大きな機能開発とは別に、すぐに（「数日中に」くらいの目安）本番反映してもいい日々の更新を行う releaseから作成し、完了したらreleaseへマージする 先方に確認してもらう場合、testにマージする 他の作業との差異が大きくなりすぎないように、ときどきreleaseから自身のtopicにマージする ■develop 機能開発を行う このブランチで直接作業は行わない releaseから作成し、開発が一段落したらreleaseにマージする ■feature/1-xxx 日々の更新とは別に、大きな機能開発を行う developから作成し、完了したらdevelopへマージする 先方に確認してもらう場合、testにマージする 他の作業との差異が大きくなりすぎないように、ときどきdevelopから自身のfeatureにマージする ■hotfix/1-xxx 即座に本番反映が必要な緊急対応を行う masterから作成し、完了したらmasterにマージする 問題なければreleaseとtestにもマージする ■test（必要に応じて） テスト環境と同一（先方確認用のテスト環境がある場合。社内案件の場合など、先方確認用環境が不要ならtestは無しでreleaseで確認する） このブランチで直接作業は行わない releaseから作成する ■support/1.0.1（必要に応じて） 過去バージョンのサポートを行う 必要になったときに、masterから作る バージョンタグを付けている場合、そのバージョンをブランチ名に使う - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ■デザイナーの簡易対応 topicで作業してreleaseにマージ。testにマージしたものをテスト環境に反映 gitに慣れていなければreleaseで直接作業して、testにマージしたものをテスト環境に反映 ■開発者の対応 featureで作業してdevelopにマージ。testにマージしたものをテスト環境に反映 topicで作業してreleaseにマージ。testにマージしたものをテスト環境に反映 ■その他メモ 独自のブランチ名やルールは極力避けたい 通常のgitflowに戻して運用できるのが理想 プルリクエストを活用するか否か featureからdevelopにマージするときと、topicからreleaseにマージするときに使用するか masterブランチは原則として保護しておくか 開発初期にプルリクエスト必須にしたりすると手間がかかるので、途中から変更すべきか 定期的にmasterブランチのバックアップを取っておくか backup/master_20180911 最悪無くてもGitで戻せるので、2〜3世代程度あれば十分 大きな仕様変更による競合が問題になりそうなら、場合によっては ・マイグレーションや共通関数の調整は、できるだけ早い段階で本番反映する ・その後、隠し機能として実装を進める という手順を検討する ただし早い段階で本番反映することにより、作業の取り消しが難しくなるのは注意 topicの内容を他のtopicに取り込みたいが、本番反映はもう少し先なのでreleaseには取り込みづらい という場合はどうするか testを経由するのは可能だが、本来の目的とは違うしtestが無い場合もある チェリーピックを使ったり、topic同士でマージするくらいか ■以下、考察メモ 主に http://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama これを元にするか Aの作業が完了した上にBとCの機能を追加する…という場合にどうするかは要検討 stagingからmasterにマージしないので、作業の差が残り続ける懸念があるのは要検討 https://postd.cc/gitlab-flow/ GitLabFlowというのもあるらしい - - - - - master work/1-aaa work/2-bbb work/3-ccc staging masterからworkブランチを作成 作業が完了したらworkをstagingにマージし、ステージング環境に反映して動作確認 確認が完了したらworkをmasterにマージし、本番環境に反映 - - - - - 「うっかりmasterにマージした」を防ぐために、作業者はローカルにmasterを持たなくていいようにすべきか。つまりmasterからいったんブランチを作るべきか それならうっかりstagingにマージする可能性もあるので、masterからbackup/20180903 のようなブランチをときどき作る方がいいか masterからいったんdevelopを作成し、そこから作業ブランチを作るほうがいいか。それならworkとか独自の名前を付けないほうがいいか （でもgitflowと違って、気軽にfeatureからdevelopにマージしてはいけないので、独自の名前のほうがいいか。要検討） - - - - - master develop feature/1-aaa feature/2-bbb feature/3-ccc staging masterからdevelopブランチを作成 developからfeatureブランチを作成 作業が完了したらfeatureをstagingにマージし、ステージング環境（先方確認用など）に反映して動作確認 確認が完了したらfeatureをdevelopにマージし、developをmasterにマージして本番環境に反映 作業者の環境に、原則としてmasterブランチは置かない - - - - - とすればいいか そのうえで、 ・マイグレーションや共通関数の調整は、できるだけ早い段階で本番反映する ・その後、隠し機能として実装を進める とすればいいか ただし早い段階で本番反映することにより、作業の取り消しが難しくなるのは注意 masterから作業ブランチを作ると、masterに色々マージして動作確認しているときの緊急対応がやりづらい masterからリリースブランチを作って、そこからworkブランチを作るか 緊急対応はmasterからhotfixを作る 作業のマージはリリースブランチにマージしてからworkブランチへ …なら、普段どおりdevelopという名前でいいか featureからdevelopとreleaseに戻せればいい？それに加えて、デーベース定義の変更などは、早い段階でリリースを目指して隠し機能扱いにする？ developからではなくmasterから作業したいfeatureがある場合はどうするか 本来はhotfixが妥当だが、開発系は常にreleaseからfeatureブランチを作るか。その後必要に応じてdevelopからfeatureにマージ。ただし慎重に - - - - - - - - - - master ... 本番環境と同一 releaseとhotfixからのみマージされる releaseからマージした場合、1.0.0 → 1.1.0 とする hotfixからマージした場合、1.0.0 → 1.0.1 とする release ... ステージング環境と同一（環境自体は無くていいかも。test ブランチの確認用環境のみでいいかも） featureはここから作る（？） developからマージされるが、featureから直接マージもあり得る（？） develop ... 開発版 featureからマージされる。開発が一段落したらreleaseにマージする feature/1-xxx ... 作業用 releaseから作り、必要に応じてdevelopからマージする（？） 大きな改修はdevelopから作っても問題はない 完了したらdevelopへマージ。先方連携するものはtestへマージ。すぐにリリースするものはreleaseへマージ（？） 他の作業との差異が大きくなりすぎないように、ときどきreleaseからマージ。developの内容を取り込んでいる場合はdevelopからマージ（？） hotfix/1-xxx ... 緊急対応用 masterから作る 完了したらmasterとreleaseとtestとdevelopにマージする。競合が心配だし面倒か（？） test ... テスト環境（先方確認用など）と同一 featureとhotfixからマージされる support ... 過去バージョンのサポート用（必要になったときのみ） masterから作る 通常のgitflowとしても運用できるのが理想 ときどき develop → release → master のマージを行わないと、コンフリクトが発生したときに差異が残り続けそうなのは懸念 featureブランチに、developの内容が混ざっているものと混ざっていないものがあるのは混乱するかも develop に対する feature のように、release から派生する作業ブランチに特別な名前を設けて区別するか fix/1-xxx とするか。修正ではなく追加もあるので topic/1-xxx とするか。完了したら release と develop と test にマージするか このブランチを設けるなら、feature は通常どおり develop から作ればいい - - - - - - - - - - Git-flowって何？ - Qiita https://qiita.com/KosukeSone/items/514dd24828b485c69a05 GitFlowをやめて本番リリースが楽になった話 - Qiita https://qiita.com/koyopro/items/b4569285efc22c6397c6 Gitブランチについての基本まとめ - Qiita https://qiita.com/katsunory/items/252c5fd2f70480af9bbb