🔔 あなたへのおすすめ記事「For you（β）」をリリースしました
Zenn
Open4

Gitの運用ルールについて考える

Git
GitHub
GitLab
git-flow
Hiroki_blogHiroki_blog

背景

  • 金融システムの保守開発案件に参画することになった
  • 今までSubversionでバージョン管理していたがGitを導入することになった
  • Git周りの管理をすることになった(リポジトリ・ブランチなど)

やりたいこと

  • Gitのチームでの運用ルールを考える
  • Gitを使っているITエンジニアの共通理解をルールとしてまとめたい

やらないこと

  • Gitのコマンド・操作についてはスコープ外

ルールにしたいこと

  1. ブランチ設計
  2. コミットルール
  3. コードレビュー
  4. 役割分担

参考書籍

エンジニアのためのGitの教科書

Hiroki_blogHiroki_blog

1.ブランチ設計

方針

  • Git Flow準拠で進める
    • 使用ブランチ
      • mainブランチ
      • developブランチ
      • featureブランチ
      • releaseブランチ
      • hotfixブランチ

ブランチ概要

ブランチ名 命名規則 派生元ブランチ マージ先ブランチ 他ブランチからのマージ
main main - - ・release
・hotfix
develop develop main - ・feature
・release
・hotfix
feature feature-* develop ・develop -
release release-* develop ・main
・develop		 -
hotfix hotfix-* main ・main
・develop		 -

ブランチごとのルール

mainブランチ

  1. リリース可能な状態を常に維持すること
    • リリース可能な状態とは、アプリが安定して動作できる状態を指す
  2. 作りかけのコードを含めないこと
    • レビュー未実施のコード、開発途中のコードはmainブランチに含めてはいけない
  3. mainブランチに対して直接コミットしないこと
    • ほかブランチからのマージによって機能追加・修正すること

developブランチ

  1. 最新の開発状態を常に反映すること
    • このブランチに機能の追加、修正を加えていくこと
  2. mainブランチに直接マージしないこと
    • releaseブランチを切り出し、リリース・テスト後にmainブランチにマージすること
  3. 動作の安定性が必要であること
    • 以下の条件を満たしているfeatureブランチのみマージすること
      • ビルドに成功すること
      • 単体テストをクリアしたこと
      • 最新のdevelopブランチを取り込んでいること
      • ソースコードレビューを受けていること
  4. developブランチに対して直接コミットしないこと
    • ほかブランチからのマージによって機能追加・修正すること

featureブランチ

  1. タスク単位でブランチを作ること
    • 機能の追加実装や修正など、タスクごとに切り出すこと
  2. タスクに関連したファイルのみ修正すること
    • タスクに無関係のファイルを修正したい場合は別ブランチを切り出すこと
      • 理由①：各ブランチにおける変更内容を明確にするため
      • 理由②：コンフリクトのリストを軽減するため
  3. 共通設定ファイルの修正時は周知すること
    • 修正ファイル・修正内容を周知すること
    • 同時に共通設定ファイルを修正する場合は、修正前に打合せすること
  4. タスクが完了したらレビューをうけること
    • タスク完了後、以下の条件を満たしていることを確認してPRを作成しレビューを受けること
      • ビルドに成功すること
      • 単体テストをクリアしたこと
      • 最新のdevelopブランチを取り込んでいること

releaseブランチ

  1. 本番環境リリース前に作成すること
    • リリースの準備が整ったタイミングで切り出すこと
  2. 変更内容はリリースに必要な範囲に限定すること
    • バグ修正やリリース準備に関連する修正のみに限定すること
    • 機能追加や大規模な変更はfeatureブランチで行うこと
  3. リリース後に修正内容を他ブランチに反映すること
    • リリース後、main・developブランチにマージすること

hotfixブランチ

  1. 緊急の修正場合のみ使用すること
    • リリース済みのバージョンのアプリに対して緊急で対応が必要なバグ修正のために使用すること
  2. 変更内容はリリースに必要な範囲に限定すること
    • 修正内容は緊急対応に必要な範囲のみに限定すること
    • 機能追加や大規模な変更はfeatureブランチから行うこと
  3. 修正完了後に修正内容を付加ブランチに反映すること
    • 修正対応完了後に変更内容をmain・developブランチにマージすること
Hiroki_blogHiroki_blog

2.コミットルール

ルール

  • Convertional Commits準拠で記述すること
    • 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様
  • なぜ使うのか
    • CHENGELOG(変更履歴)を自動生成するため

フォーマット

<type>: <description>

<type>：コミットの種別を表す
<description>：コミット内容について記述する

type一覧

type名 意味
fix バグやロジックの修正
add ファイルの追加
feat 新機能の追加
refactor コードのリファクタリング
test テストの追加・修正
build ビルドシステムの変更・依存関係のアップデート
ci CI/CDの設定の追加・変更
chore その他の変更(雑用)

コミットの粒度について

commitは意味のある単位で細かく分ける

理由

  1. コミット履歴を見る人が変更の意味を理解できるようにするため
  2. コミット単位でロールバック(git reset)できるため

具体的なコミットの例

  • 例①：エラーがなく動く単位で1コミット
    • 理由：障害対応でコミットを1つずつ遡って検証する際にエラーがおこると検証できなくなるため
  • 例②：rename・ファイル移動・typo修正でそれぞれ1コミット
    • 理由：レビュー内容を明確にするため
      • ロジックの修正に加えてrename、ファイル移動をまとめるとわかりづらくなるため
Hiroki_blogHiroki_blog

DeepReserchから

ありがとうございます。いただいた情報をもとに、Git Flowをベースとしたチーム開発の運用ルールをより詳細に精緻化します。

  • コードレビューのルール：GitLabを使用し、最低1名のレビューが必要である点をベースに、レビュー基準をより詳細に整理します。
  • 役割分担：現時点で特にルールはないとのことですが、よりスムーズな運用のための推奨ルールを提案します。
  • 運用上の補足ルール：CI/CDの設定は未定ですが、バージョン管理ルールやブランチ保護設定を含めたベストプラクティスをまとめます。

完成次第、内容をご確認いただけるようにします。

Git Flowベースのチーム開発運用ルール

背景

当プロジェクトでは、既存のバージョン管理を Subversion から Git へ移行し、GitLab を利用した開発フローに変更します。Git の強力なブランチ機能を活用し、Git Flowに基づいた運用ルールを策定することで、チーム開発を効率化しつつ、新規参画者にもわかりやすいガイドラインとします。以下に、ブランチ戦略からコミット方法、コードレビュー基準、役割分担、補足ルールに至るまで、詳細なチーム開発ルールを定義します。

1. ブランチ設計

(git-flow 図解) 図: Git Flowにおけるブランチモデルの概略図。main（紺）, develop（緑）を基軸に、feature（青）, release（紫）, hotfix（オレンジ）の各ブランチで機能開発・リリース準備・緊急修正を行う。矢印はマージの方向を示す。

ブランチの種類と役割

Git Flowモデルでは、永続的なメインブランチ2本（mainとdevelop）と、必要に応じて作成・削除されるサポートブランチ3種（feature、release、hotfix）を使用します。それぞれのブランチの目的と運用ルールは以下の通りです。

  • mainブランチ（本番ブランチ）: 本番リリース用のブランチです。常に本番リリース可能な安定したコードのみを含みます。基本的に直接コミットせず、リリース用の変更はすべてreleaseブランチやhotfixブランチからのマージによって反映します。リリース時には、main上の該当コミットにバージョンタグ（例: v1.2.0）を付与します。

  • developブランチ（開発ブランチ）: 次回リリースに向けた開発中の最新ソースコードを集約するブランチです。日々の開発者の作業はこのブランチ上では行わず、featureブランチで行った作業をマージすることで更新されます（いわゆる「インテグレーションブランチ」）。developブランチも直接のコミットは行わず、常に最新の開発成果物を反映させるため、チームメンバーは定期的にdevelopから派生ブランチを作成・更新します。

  • featureブランチ（機能ブランチ）: 新機能開発や特定のタスク実装用のブランチです。通常、developブランチから派生し、開発対象ごと（機能単位や不具合修正単位）に新しく作成します。 (A successful Git branching model » nvie.com)開発が完了したらdevelopブランチへマージし、不要になったfeatureブランチは削除します。一つのfeatureブランチでは一つの課題や機能に集中し、他の変更と混在させないようにします。注意: 開発中のfeatureブランチは原則短期間で完了させ、長期間developから乖離させないようにしてください。

  • releaseブランチ（リリース準備ブランチ）: リリース直前の調整を行うブランチです。次のリリース用に十分な変更がdevelopに取り込まれ安定した段階で、developからreleaseブランチを切ります。 (git-flow 図解) (git-flow 図解)このブランチ上でバージョン番号の更新や、本番リリースのための微調整・軽微なバグ修正を行います。準備が整ったらreleaseブランチをmainブランチにマージし、本番リリースを確定します。また同じ変更をdevelopブランチにもマージして、開発ブランチに取り込まれていない修正があれば反映します（mainとdevelopの差異をなくします）。リリースが完了したらreleaseブランチは削除します。

  • hotfixブランチ（緊急修正ブランチ）: 本番環境で発生した重大なバグ修正など、緊急対応が必要な場合に使用するブランチです。mainブランチから直接派生し、問題の修正を行います。 (git-flow 図解) (git-flow 図解)修正が完了したら、hotfixブランチをmainブランチにマージして速やかに本番リリースを行い、同じ修正をdevelopブランチにもマージして今後のリリースにも組み込みます。hotfixブランチも作業完了後は削除します。リリース時にはパッチバージョンなどバージョン番号を更新し、タグを付けます。hotfixはdevelopを経由せずmainへ直接マージできる点でreleaseに似ていますが、これにより開発中の機能に影響を与えず緊急修正を適用できる利点があります。

ブランチ命名規則

各ブランチは上記の種類に応じて命名し、わかりやすさと一貫性を保ちます。ブランチ名には必要に応じて課題IDや機能名を含め、内容が推測できるようにします。具体的な命名ルールは以下の通りです。

  • main / develop: メインブランチはリポジトリ作成時に作成されるmainおよびdevelopを使用します（名前は固定）。特別な接頭辞やIDは付けません。
  • featureブランチ: "feature-<課題IDまたは機能名>"の形式で命名します（ハイフン区切り。例: feature-12345-user-login や feature-login-api）。課題管理ツールのIDがある場合は含めることでトラッキングが容易になります。命名時は他のブランチ名と重複しない簡潔な名前にしてください。
  • releaseブランチ: "release-<バージョン番号>"の形式で命名します（例: release-1.2.0）。リリース対象のバージョンをブランチ名に含めることで、目的が明確になります。原則としてreleaseブランチは一つのリリースにつき一時的に存在し、リリース完了後に削除されます。
  • hotfixブランチ: "hotfix-<バージョン番号や課題ID>"の形式で命名します（例: hotfix-1.2.1 や hotfix-6789-payment-bug）。修正内容が分かるようにバージョンやIDを含めます。緊急度が高いため、命名は簡潔かつ一意にしてください。

※ブランチ名には半角英数字とハイフン（-）などを使用し、スペースや日本語は避けます。feature/〇〇のように「カテゴリ/名前」のスラッシュ区切りも可能ですが、GitLabのブランチ保護設定との兼ね合いも考慮し、上記のように接頭辞として扱う形式に統一します。

ブランチ運用上の注意点

  • メインブランチへの直接Push禁止: mainブランチおよびdevelopブランチへは開発者が直接コミットやプッシュすることを禁止します。必ず上記の運用に従い、feature／hotfixブランチからのマージ（Merge Request経由）によってのみ更新されるようにします。これにより、レビューやテストを経ずに本番／開発ブランチが変更されることを防ぎます。
  • マージ方法: ブランチをマージする際は、原則としてMerge Request（プルリクエスト）を経由したマージを行います。developにfeatureをマージする際など、GitLab上でMRを作成し、レビューと承認を経てからdevelopへ取り込みます。マージ時には履歴を明確に残すために**マージコミットあり（--no-ff）**で実行し、ブランチの統合単位が履歴上わかるようにします。
    （※自動マージ設定やプロジェクトのポリシーによっては、全てSquashしてからマージする運用も考えられますが、本ルールでは基本的にマージコミットを残す方法とします。）
  • ブランチの定期同期: チームメンバーは各自の作業ブランチ（featureやhotfix）が長期間developから分岐したまま乖離しないよう、適宜developの最新変更を取り込む（リベースまたはマージする）よう心がけます。特にマージリクエストを出す前に最新のdevelopをマージ/リベースしてコンフリクトを事前解消してください。
  • ブランチの削除: マージが完了し不要になったfeature、release、hotfixブランチは、リポジトリ上から削除します。GitLabのMerge Request完了時に「ブランチを削除」オプションを利用するか、手動で削除してください。古いブランチを残さないことでリポジトリの混乱を防ぎます。
  • その他: ブランチ名やコミットメッセージには機密情報（パスワード等）を含めない、強制プッシュ（force push）は基本禁止（特に共有ブランチでは厳禁）など、一般的なGit運用上の注意も遵守してください。

2. コミットルール

コミットメッセージには一貫した形式とわかりやすい内容を求めます。メッセージのフォーマットはConventional Commits（コンベンショナルコミット）の規約に準拠し、変更内容の種類がひと目で分かるようにします。また、コミットは適切な粒度で行い、履歴を追いやすく管理しやすい状態を保ちます。具体的なルールは以下の通りです。

  • Conventional Commits規約の採用: コミットメッセージの先頭に変更の種類を表すタイプを記述します。タイプには決められたキーワードを用い、以下は主な例です。

    • feat: 新機能の追加
    • fix: バグ修正
    • docs: ドキュメントのみの変更（コード変更なし）
    • style: フォーマットの変更（機能に影響しないコードスタイル修正など）
    • refactor: リファクタリング（機能追加やバグ修正を含まないコードの構造改善）
    • perf: パフォーマンス改善
    • test: テストコードやCI周りの変更
    • chore: ビルドプロセスやツールの変更（ソースやテストに影響しない更新）
      （必要に応じてプロジェクト固有のタイプを追加定義しても構いません。）

  • コミットメッセージの書式: メッセージは原則英語表記で簡潔に記述します（ただし内容によって日本語併記も許容します）。基本フォーマットは：

    <type>(<scope>): <subject>

    <scope>は変更箇所やモジュールを表す任意のスコープ名（省略可）、<subject>は変更内容の概要を述べる短い説明です。<subject>は句点を付けずに書き、50文字程度以内に収めます。必要であれば空行を挟んで本文を追記し、変更理由や詳細、影響範囲を記述します。また関連する課題IDやチケットがある場合はフッターにCloses #課題番号のように記載して、コミットと課題追跡を紐付けます。
    例:

    • feat(payment): 新規支払い処理のAPIを実装
    • fix: 会員登録時のバグ修正 (スコープ省略、シンプルなケース)

  • コミットの粒度とベストプラクティス: 1コミットには一つの論理的変更または課題対応を含めるように心がけます。複数の異なる修正や機能追加を一度にまとめてコミットしないでください。変更が大きくなる場合は機能ごと、モジュールごとにコミットを分割し、「いつ」「何を」「なぜ」変更したかが履歴から追いやすい状態を保ちます。また、コミット時点でコードがビルド可能でテストが通る状態を維持してください（問題のある中間状態をコミットすると、後でgit bisectなどで原因追跡する際に障害となります）。必要ならローカルで細かくコミットし、最終的に整理してからプッシュすることも検討してください。

  • コミットメッセージの質: メッセージは後から読んでも意図が伝わるよう具体的かつ簡潔に書きます。「修正」「変更」など曖昧な表現は避け、何をどうしたのかを書いてください。例えば不具合修正であれば、何が原因でどう直したのかを書き、機能追加であれば目的や挙動を記述します。レビューや将来の保守者が履歴を見たときに内容を理解できることを意識しましょう。

3. コードレビューのルール

チーム開発の品質を保つため、Merge Request（MR）を用いたコードレビューを徹底します。GitLab上で各featureやhotfixブランチからdevelop/mainブランチへのMRを作成し、最低1名以上のレビュワーによる承認を経てからマージする運用とします。自己のコードに対する思い込みや見落としを防ぐため、作者以外のメンバーによるチェックを必須とします。レビューの際には以下の点を基準に確認・承認を行います。

  • ビルドが通ること: 提出されたMRのコードがビルドエラーなくコンパイル/実行可能であることを確認します。可能であれば自動ビルド（CI）が成功していることをチェックし、CIがない場合でもレビュワーはローカル環境でビルドするか、最低限コード上明らかな間違いがないことを見ます。ビルドエラーがある状態のコードはレビュー以前の問題となるため、開発者はMRを出す前にビルド確認を徹底してください。

  • 動作確認・テストのクリア: 単体テストや結合テストなど、関連するテストがすべてパスしていることを確認します。CI環境で自動テストが動いている場合はその結果を確認し、カバレッジやテストケースの追加もチェックポイントです。手動確認が必要な変更（画面の変更や大きな機能追加）については、開発者が事前にローカルで十分に動作検証していることを前提に、レビュワーも必要に応じて手元で動作を確認します。

  • 最新のdevelopブランチを取り込んでいること: MR作成時点でdevelopブランチに他の変更が入っている場合、対象のfeature/hotfixブランチに最新developをマージまたはリベースしてコンフリクトが解消済みであることを確認します。古いブランチのままだと将来マージ時に競合が発生したり、最新の変更と整合が取れない可能性があります。レビュワーは必要に応じて「最新のdevelopをマージしてください」と差し戻し、開発者側で対応してもらいます。

  • コーディング規約を満たしていること: プロジェクトで定められたコーディングスタイルや規約に違反していないか確認します。変数名やインデント、コメントの書き方などがチームの基準に沿っているか、静的解析ツールやLintの警告が出ていないかもポイントです。些細なスタイルの指摘もコード品質維持のため重要ですが、自動整形ツールを導入している場合はそれを活用し、指摘事項を減らすよう努めます。

  • 変更内容が適切に分割されていること: 提出されたMRの変更範囲が妥当か確認します。一つのMRにあまりにも多くのファイル変更や複数の課題が混在していないか、レビュワーは注視します。 (git-flow 図解) (git-flow 図解)機能ごとにブランチを分ける原則通り、変更が大きすぎる場合は「この部分は別ブランチで対応してほしい」等フィードバックします。逆に細かすぎる分割で全体像が見えない場合もありますが、その場合はMRの説明に経緯を書くなどのフォローをします。

  • パフォーマンスやセキュリティの問題がないか: 変更によってシステムの性能に悪影響が出ないか、セキュリティ上の脆弱性や懸念が新たに生じていないかを確認します。特に金融システムの保守開発という性質上、入力値の検証漏れや機密データの扱いなどセキュリティ面のレビューは重要です。パフォーマンスについても、アルゴリズムの計算量やDBクエリの負荷が問題ないかチェックし、必要であれば負荷テストの実施や実装方法の改善を提案します。

レビュワーは上記の点を踏まえてコードを精査し、必要に応じてコメントや修正リクエストを行います。全てのチェックをクリアしたらMerge Requestを承認し、マージを行います（もしくは承認後、作成者にマージしてもらいます）。自己承認によるマージは禁止とし、少なくとも1人他のメンバーの目を通すようにします。可能であれば2名以上の承認が望ましいですが、チームの人数や状況に応じて調整してください。コードレビューを単なる形式にせず、チーム内の知識共有や品質向上の機会と捉えて積極的に活用しましょう。

4. 役割分担

チーム開発を円滑に進めるため、各メンバーの役割と責任範囲を明確にします。ただし本プロジェクトでは厳密な権限管理者（ブランチ管理者や特定メンバーのみマージ可能といった制限）は現時点で設けない方針のため、以下は推奨される役割分担と行動指針になります。各自が主体的にこれらの役割を果たし、相互に補完し合うことで高品質なソフトウェア開発を目指します。

  • 開発者（Implementer）: 機能開発やバグ修正を担当するメンバーです。与えられたタスクに対しfeatureブランチを作成して実装を行い、コミットルールを順守して履歴を積み上げます。自身の作業が完了したらMerge Requestを起票し、レビュワーへコードを提出します。開発者はコードの動作確認・テストを十分に行い、レビューに出す前に品質を担保する責任があります。また、他者のレビューにも協力し、チーム全員でコード品質を高める姿勢を持ちます。

  • レビュワー（Reviewer）: 他メンバーの提出したMerge Requestをレビューする役割です。原則として実装者とは別の人が担当し、上記コードレビュー基準に従ってコードをチェックします。指摘事項があればコメントで伝え、必要に応じてディスカッションを行います。レビュワーは単に動作を追認するだけでなく、より良い実装方法の提案や潜在バグの指摘など、建設的なフィードバックを提供します。最低1名のレビュワー承認が必要ですが、余裕がある場合は複数人でレビューし、知見を集めることも有効です。レビュー完了後、必要条件を満たしていればMRを承認し、マージ（またはマージの許可）を行います。

  • リリース担当者（Release Manager）: リリース作業を統括する役割です。各リリースサイクルの終わりにdevelopからreleaseブランチを作成し、バージョン番号の更新やリリースノートの作成、リリースブランチ上での最終確認を行います。リリース担当者は該当リリースの変更内容を把握し、本番環境へのデプロイ手順を調整します。releaseブランチのレビューやテスト結果を確認し、問題がなければmainへのマージとタグ付けを実施します。また、緊急時にはhotfixブランチからのリリース対応にも協力します。リリース担当者は固定せず、スプリントやリリースごとに持ち回りで担当することで、メンバー全員がリリース手順に習熟することを推奨します。

  • プロジェクトリーダー / メンテナー (必要に応じて): 小規模チームであれば全員が上記役割を兼務しますが、プロジェクトリーダーやリポジトリのメンテナーが存在する場合、その人はルールの運用状況を監視し、必要なら改善提案を行います。例えば、ブランチ運用が乱れていないか、コミットメッセージ規約が守られているか、レビューが適切に機能しているかをチェックします。権限的には他の開発者と同等ですが、万一緊急でルールを逸脱する操作（直接mainに修正をあてる等）が必要になった場合の判断や、CI/CDの設定管理などプロジェクト運営上の責任を負います。ただし通常時においても、本ドキュメントで定義したプロセスに従うことを原則とします。

※現状では特定ブランチへのマージ権限を限定する運用は敷かない予定ですが、将来的にコミット数やプロジェクト規模が増大した場合、mainブランチへのマージはリーダーのみ実施するといった運用に切り替える可能性もあります。その際はチーム内合意の上でルールを改定します。

5. 運用上の補足ルール

CI/CDとの連携

現在CI/CDパイプラインの整備はありませんが、今後の品質保証と開発効率向上のため継続的インテグレーション（CI）/ 継続的デリバリー（CD）の導入を推奨します。GitLab CIを利用すれば、Merge Requestの作成時やブランチへのプッシュ時に自動でビルドとテストを実行し、コードレビュー前に問題を検出できます。具体的には、developブランチやrelease/hotfixブランチへのMRに対して以下を自動化することが望ましいです。

  • ユニットテストや静的解析の実行
  • ビルドの成功確認（コンパイルエラーの有無）
  • 必要に応じたデプロイ処理（例えばmainブランチへのマージ時に本番環境へデプロイ、developブランチへのマージ時にステージング環境へデプロイなど）

これらをCIで行うことで、人手による見落としを減らし、「ビルドが通ること」「テストがクリア」のレビュー基準を自動で担保できます。また、将来的にCDを構築すれば、タグ付けと同時にリリースパッケージを作成したり、本番環境へのデプロイをワンクリックで行うことも可能になります。まずはCIによる自動テストから着手し、段階的に整備していきます。

バージョン管理ポリシー（セマンティックバージョニング）

本プロジェクトではセマンティックバージョニング（Semantic Versioning; SemVer）に準拠したバージョン番号管理を行います。バージョン番号はMAJOR.MINOR.PATCHの形式で付与し、リリースの内容に応じて以下の方針で更新します。

  • MAJOR（メジャー番号）: 後方互換性のない大規模な変更や仕様変更が行われる場合に更新します。既存APIの破壊的変更や大幅な仕様変更時のみ発生し、保守開発フェーズでは通常変更しません。現在の金融システムが1系であれば、将来2系に上げるタイミングがこれに該当します。
  • MINOR（マイナー番号）: 後方互換性のある機能追加や改善が行われた場合に更新します。新規の画面や機能拡張、大きめの変更だけど既存の利用者影響がない場合はこちらをインクリメントします。例えばバージョン1.2.0から新機能追加のリリースでは1.3.0のように上げます。
  • PATCH（パッチ番号）: バグ修正や小規模な変更で、後方互換性に影響しない場合に更新します。緊急の不具合修正リリース（hotfix）や軽微な改善のみのリリースではこの番号を増やします。例: 1.2.0からバグフィックスのみ行う場合は1.2.1に上げます。

リリース時の運用: 新たにreleaseブランチを切った際、そのリリースで適用するバージョン番号を決定します。基本的には上記規則に従い、developに含まれる変更内容を見て適切なバージョンに繰り上げます。決定したバージョン番号は、ソースコード内のバージョン定義箇所（例: package.jsonやアプリケーションの定数）を更新し、releaseブランチ上でコミットします。また、リリースノートや変更履歴（Changelog）を更新する運用があればこの時点で行います。mainブランチへreleaseブランチをマージしたら、そのコミットに対応するバージョンのタグ（例えばv1.3.0）を作成します。GitLabではタグ付けによりリリース情報を管理できます。

自動採番の検討: プロジェクトによってはCIでバージョン番号を自動更新・タグ付けする仕組みもありますが、本運用では人間がリリース時にバージョンを判断して付与します（自動化する場合もセマンティックバージョニングの原則に従うことが前提です）。将来的にリリース作業をさらに効率化するため、releaseブランチ作成時にスクリプトでバージョンを自動インクリメントすることも検討してください。

ブランチの保護設定

重大なブランチへの誤操作を防ぐため、GitLabのブランチ保護機能を活用します。具体的には、mainブランチとdevelopブランチに対して以下の保護設定を有効にします。

  • 直接プッシュ禁止: 誤ってローカルから直接プッシュすることを防ぐため、GitLab上でmainおよびdevelopブランチをProtected設定にし、Developerロール以下のユーザーによるプッシュを禁止します。これにより、これらのブランチへはMerge Request経由でしか変更を反映できなくなります。
  • マージ条件の設定: Protectedブランチに対し、「Merge Requestに一定の承認が必要」というルールを設定します。少なくとも1人の承認者がいないとmain/developにマージできないようにすることで、コードレビューを強制します。また、可能であれば「パイプラインが成功していることをマージの必須条件」に設定し、CIが失敗しているコードは取り込めないようにします。
  • 強制プッシュ（Force push）禁止: Protectedブランチでは強制プッシュも自動的に禁止されます。履歴を書き換える操作はリポジトリを混乱させる恐れがあるため、保護設定により安全性を担保します。万一mainやdevelopの状態を修正する必要がある場合は、管理者権限者のみが慎重に行います。
  • ブランチ削除保護: 誤ってmainやdevelopを削除することがないよう、削除も保護します（通常Protectedにすると削除不可になります）。また、releaseブランチについてもリリース作業中は保護を有効にし、作業完了後に削除する運用とします。

以上の設定によって、GitLab上で本運用ルールが技術的にも enforce（強制）される形になります。保護設定はリポジトリの「Settings > Repository > Protected Branches」でプロジェクトリーダーまたはメンテナーが管理します。必要に応じて例外的な操作ができるユーザーをメンテナー権限で指定しつつも、通常業務では原則として全員がこのルール内で作業するよう徹底します。

以上が、金融システム保守開発案件におけるGit Flowベースのチーム開発運用ルールの詳細です。初めて参加するメンバーでも理解しやすいよう平易なルールとしましたが、不明点や疑問があれば都度チーム内で共有・議論し、本ドキュメントをアップデートしてください。Gitへの移行当初は戸惑う点もあるかもしれませんが、本ルールに沿って運用することで安定した開発プロセスと高品質な成果物の両立を目指しましょう。

作成者以外のコメントは許可されていません