質問: ### 開発時の運用について gitを利用して開発を行ってっており今の現場での運用での疑問になります。 リリース時にリリース対象日でまとめたテスト用のブランチ(リリースブランチに該当するもの)を作り、 それをdevelopブランチにマージした後developブランチ自体をリリースしているのですが、 このやり方だと次のリリース向けに作業している人達は、対象課題のdevブランチ(開発用)を作成し、 まとめブランチにマージする前にdevelopブランチを開発用のdevブランチにマージしています。 これって一般的なことなんでしょうか。 この運用だとmasterブランチが意味を成していないことや、何かあったときの切り戻しのしづらさ、 履歴肥大化など心配事が出てきます。 以前の現場だとgit-flow的な運用をしていたことやプルリクやブランチ俯瞰、だけでなくお互いに気を使っていたため大味なコンフリクトは起きていなかったことや、releaseブランチを切ることによって、全体に「リリース準備に入ったので機能追加はSTOP」という意思表明をある程度行えると思っています。 正直今の管理は特定の人間の俺俺運用だと思っており疑問が生じているのですが本来どのように開発を進めていくのが良いのでしょうか。
回答: > > developブランチにマージした後developブランチ自体をリリースしている > > > 中々のマイノリティぶりだと思います。 eugenioさんもアラートを出しているように客観的に見て酷い状況で、 もう暫くすると大火事になるでしょう。 > > 履歴肥大化 > > > これ単体はあまり目くじらたてる必要はないと思います。 プルリク直前に自分のコミットを纏めて綺麗にするのは良い習慣かもしれませんが、マストではありません。 > > releaseブランチを切る > > > 質問文にタグというワードが出てきませんでしたが、タグは利用していますか? タグを上手く利用すればmasterとdevelopmentの2ブランチでなんとかなると思います。 リリースしたタイミングでバージョン番号を1個増やしたモノを登録しておくと捗りますね。 releaseブランチを切るという習慣自体は良い習慣ですが、タグを含めた場合冗長な気がします。 チームによっては多少の冗長性を持たせるのもありだと思います。 とりあえずリリース完了後、masterに向けてプルリクを投げてタグを打つという習慣も入れてみてはどうでしょうか? ちなみにうちのチームではこんな感じで動かしています。 master: 本番環境で動いている最新のソースコードと同一 development: 各メンバーのプルリクのマージ向き先 各開発メンバーは好きなブランチを切ってpushし、developmentに向けてプルリクを出す。 プルリクは常時承認→マージの過程を経てdevelopmentにマージされる。 リリース時はプルリク状態のままぶら下がってる中から、リリースされるもの全てを承認→developmentへのマージを行う development→masterへのプルリクを出し承認→マージする。 最新のmasterをステージング環境に反映させ、テストが通ったらタグを打ち、本番環境へリリースする。 テストが通るまではmasterへ向けてプルリクが飛ぶ状態になる。 緊急対応時はmasterへ向けて直接プルリク→承認→リリース。 タグを打ちつつdevelopmentへマージしてdevelopmentを更新する。 ちょっとこの辺が弱く、緊急対応とステージング環境へのリリース準備が衝突した場合に少し困りますが、半日待ってみたいな交渉を上司としてます。