GitLabで複数バージョンを管理する方法｜ブランチ・タグ・リリースの実践手順
株式会社 SunSunTech
GitLabで複数バージョンを並行管理していると、「どのブランチに修正を入れるべきか分からない」「本番向けの修正が次期版に反映されていない」「タグはあるのに再現できない」といった問題が起こりがちです。特に、現行版の保守と次期版の開発が同時に進むチームでは、個人の注意力だけに頼る運用は長続きしません。
この記事は、GitLabを使う開発者、リーダー、構成管理担当者に向けて、ブランチ・タグ・マージリクエスト・リリースを組み合わせた版数管理の設計方法を解説します。読み終えると、自分のチームに必要なルールを決め、リリース手順と緊急修正の流れを具体化できるようになります。
目次
複数バージョン管理で最初に決めること
最初に整理したいのは、GitLabの機能ではなく「何を同時に保守するか」です。たとえば、本番稼働中の1.4系、障害修正のみ受け付ける1.3系、次期リリース予定の2.0系があるなら、それぞれの終了条件、変更可能な範囲、リリース責任者を明確にします。対象が曖昧なままブランチだけ増やすと、どの版が正しいか判断できません。
運用開始前に、次の項目を1枚のルール表にまとめましょう。
- 同時に保守するバージョンとサポート終了日
- 機能追加、通常修正、緊急修正を受け付けるブランチ
- バージョン番号の付け方と更新するタイミング
- マージリクエストの承認人数と必須レビュー担当
- リリースの実行者、検証者、切り戻し判断者
- 成果物、変更履歴、タグを保存する場所
バージョン番号は「メジャー・マイナー・パッチ」の意味をチーム内で統一します。互換性を壊す変更はメジャー、後方互換の機能追加はマイナー、不具合修正はパッチという考え方が基本です。ただし、業務システムでは顧客ごとの版や法令対応日を含める場合もあります。大切なのは、番号を見ただけで変更の大きさと適用先を判断できることです。
GitLabのブランチ構成をシンプルに設計する
複数バージョン管理では、役割が重複しない最小限のブランチ構成が扱いやすいです。基本形として、常にリリース可能なmain、次期版を統合するdevelop、作業単位のfeature、リリース準備用のrelease、緊急修正用のhotfixを使います。小規模チームや短いリリース周期ではdevelopを置かず、mainから短命な作業ブランチを切る構成でも構いません。
長期保守版が複数ある場合だけ、release/1.4、release/1.3のような保守ブランチを残します。すべての過去版に恒久ブランチを作ると管理対象が増えるため、サポート中の版に限定してください。作業ブランチ名にはissue番号と目的を含め、feature/123-login-timeout、hotfix/456-tax-roundingのようにすると、GitLab上で変更理由を追跡しやすくなります。
mainと保守ブランチは保護し、直接pushを禁止します。マージは必ずマージリクエスト経由とし、パイプライン成功、レビュー承認、未解決コメントなしを必須条件にします。さらにCODEOWNERSを設定すれば、決済、認証、インフラなど変更リスクの高い領域に適切なレビュアーを自動で割り当てられます。
安全なリリース手順と修正の横展開
通常リリースは、対象issueの確定、releaseブランチ作成、受け入れテスト、バージョン更新、変更履歴の確認、タグ作成、成果物生成の順に進めます。タグ名はv1.4.2のように統一し、原則として後から付け替えません。GitLab Releaseには対象タグ、主な変更、既知の制約、移行手順、切り戻し方法、成果物へのリンクを残します。これにより「ソースはあるが、何をどう配布したか分からない」状態を防げます。
緊急修正では、本番版に対応するタグまたは保守ブランチからhotfixを作成します。修正を本番向けブランチにマージして終わりにせず、次期版にも同じ変更が必要か判断してください。必要ならcherry-pick用のマージリクエストを別に作り、元のissueと相互リンクします。競合が発生した場合は機械的に解消せず、版ごとの仕様差を確認してテストします。
リリース前チェックリストには、対象コミット、パイプライン結果、DB変更、設定値、依存ライブラリ、バックアップ、監視項目、切り戻し手順を含めます。承認した人と実行した人も記録すると、障害時の調査が速くなります。可能であればタグを起点にCI/CDで成果物を生成し、同じコミットから同じ成果物を再作成できる状態を目指しましょう。
よくある失敗と防止策
失敗1：ブランチを長期間放置する。 差分が大きくなり、マージ時に競合と確認漏れが増えます。作業単位を小さくし、定期的に統合先の変更を取り込みます。不要になったブランチはマージ後に削除し、保守対象だけを残してください。
失敗2：緊急修正を次期版へ反映し忘れる。 hotfix用テンプレートに「他バージョンへの適用要否」を必須項目として追加します。GitLab issueに対象バージョンのラベルを付け、反映先ごとにマージリクエストを作ると進捗を見失いません。
失敗3：タグと実際の配布物が一致しない。 開発者のPCで手作業ビルドせず、保護されたタグからCI/CDで生成します。成果物にはバージョン番号やコミットIDを表示できるようにし、稼働中の版を現場で確認できるようにします。
失敗4：ルールが複雑すぎて守られない。 例外を増やす前に、mainの保護、マージリクエスト、タグ、変更履歴という最小構成から始めます。月に一度、滞留ブランチ、失敗したパイプライン、反映漏れを振り返り、問題が実際に起きた箇所だけルールを改善します。
GitLabの複数バージョン管理でよくある質問
Git Flowを必ず採用する必要はありますか？
必須ではありません。複数の保守版や明確なリリース期間があるチームには適しますが、継続的デリバリーではmainと短命な作業ブランチだけの方が運用しやすい場合があります。リリース周期、保守版の数、承認プロセスに合わせて選びましょう。
タグとリリースブランチはどう使い分けますか？
タグは特定時点を固定して再現するための印、リリースブランチはサポート中の版へ修正を加えるための作業線です。修正予定がない過去版はタグだけを残し、保守対象の版だけブランチを維持すると管理しやすくなります。
cherry-pickとmergeはどちらを使うべきですか？
特定の修正だけを別バージョンへ適用する場合はcherry-pickが便利です。一方、継続的に同じ変更群を取り込むならmergeが履歴を追いやすくなります。どちらでも、適用先ごとにマージリクエストを作り、テストとレビューを省略しないことが重要です。
まとめ
GitLabで複数バージョンを安全に管理するには、ブランチを増やすことより、保守対象、変更の入口、承認条件、リリースの証跡をそろえることが重要です。保護ブランチとマージリクエストで変更経路を統一し、タグとGitLab Releaseで配布時点を固定しましょう。緊急修正は次期版への横展開までを一つの作業として扱うと、反映漏れを防げます。
まずは現在の保守バージョンを一覧化し、各版の統合先、責任者、終了日を書き出してください。そのうえでmainの直接push禁止とリリース前チェックリストを設定するところから始めると、無理なく再現性の高い版数管理へ移行できます。
投稿者プロフィール
-
はじめまして。
株式会社SunSunTech代表取締役の鈴木と申します。
SunSunTechは、エンジニアが納得できるキャリアと報酬を得られるSES企業を目指して設立しました。
私は元々、エンジニアとして複数のSES現場で経験を積んできました。
その中で、「スキルに見合った評価が得られない」「給与の仕組みが不透明」といった業界特有の課題に何度も直面してきました。
こうした状況を変えるために、SunSunTechでは、透明性のある評価制度の導入、エンジニアファーストな案件選定など、"エンジニアが報われる仕組み"を徹底しています。
SES企業様とのパートナー連携においても、スピード・誠実・精度を大切にし、長期的に信頼される関係構築を目指しております。
エンジニアの未来を、本気で変えていく。
その想いに共感してくださる方、ぜひ一度お気軽にお声がけください。
