Content last updated 2026-05-26

マージリクエストの取り扱い

マージリクエストの取り扱いに関するドキュメント

このガイドでは、Customer Support Operations のプロジェクトに対するマージリクエスト（MR）の作成・レビュー・マージ方法を説明します。これらのプラクティスに従うことで、コード品質を保ち、セキュリティ基準を維持し、チーム全体での協調的な開発を実現できます。

マージリクエストについて

マージリクエストを使う理由

マージリクエストには、いくつかの重要な利点があります。

ピアレビュー: コード品質を担保し、デプロイ前に潜在的な問題を捕まえる
コラボレーション: チームメンバー間の議論や知識共有を可能にする
監査証跡: 何が変わったか、なぜか、誰が承認したかについての文書化された履歴を作成する
品質ゲート: 問題のあるコードがプロダクションに到達するのを防ぐ
バージョン管理: 変更が問題を引き起こした場合に簡単にロールバックできる

マージリクエストの作成

前提条件

マージリクエストを作成する前に、次を確認してください。

対応する Issue（機能リクエスト、管理業務、バグなど）があること（軽微なドキュメント修正でない限り）
次のフォーマットに従って正しく命名されたブランチ: USERNAME-PROJECT-IID
- 例: jcolyer-support-ops-project-1963
- 詳細はコーディング規約 - ブランチを参照
説明的なコミットメッセージで変更をコミット済みであること
ローカルで変更をテスト済みであること（該当する場合）

マージリクエストの作成

マージリクエストを作成するには、次の手順に従います。

GitLab.com 上のプロジェクトに移動する
左サイドバーの Merge requests に移動する
New merge request ボタンをクリックする
ソースブランチ（作業ブランチ）とターゲットブランチ（通常は master または main）を選択する
Compare branches and continue をクリックする
マージリクエストの詳細を入力する。
- Title: 変更を要約する明確で説明的なタイトルを使用する
  - Good: “Add new trigger for premium support routing”
  - Bad: “Update triggers” または “Fix stuff”
- Description: 次のコンテキストを提供する。
  - 関連 Issue へのリンク: Relates to ISSUE_URL
  - 何が変わり、なぜかの要約
  - 特別なテストやデプロイの考慮事項
  - 破壊的変更や依存関係（該当する場合）
- Assignee: 自分自身をアサインする
- Reviewer: レビューのためチームメンバーをアサインする（レビューを依頼するを参照）
Create merge request をクリックする

同期リポジトリの場合

同期リポジトリ（トリガー、ビュー、自動化など）でマージリクエストを作成すると、MR は自動的に比較パイプラインを実行し、次を行います。

YAML 構文の検証
必須フィールドのチェック
提案された変更を現在の Zendesk 構成と比較
比較レポートの生成

レビュー依頼前に、変更が正しいことを確認するためパイプラインの結果を確認してください。

レビューを依頼する

誰にレビューを依頼するか

標準的な変更の場合: その領域に詳しい利用可能なチームメンバーにレビューを依頼する
複雑または高リスクの変更の場合: 複数のチームメンバーまたはシニアエンジニアにレビューを依頼する
セキュリティ機微な変更の場合: セキュリティに精通したレビュアーを含める
不明な場合: チームチャンネルでレビュアーの推薦を求める

レビュアーが確認すべき内容

ピアレビューを行う際、レビュアーは次を検証すべきです。

機能性: 変更が宣言された目標を達成しているか
コード品質: コーディング規約に従っているか
セキュリティ: ハードコードされたシークレットがないか、適切な入力検証、安全なプラクティス
テスト: 変更がテストされているか（該当する場合）
ドキュメント: 複雑なロジックにコメントがあるか、必要に応じて README が更新されているか
副作用: 変更が既存の機能を壊していないか
デプロイ影響: デプロイ時に何が起きるかを理解しているか

マージリクエストのレビュー

レビュー方法

レビュアーとしてアサインされたら、次の手順に従います。

関連 Issue を読んでコンテキストを理解する
Changes タブで変更をレビューする
- 各ファイルの差分を見る
- レビュアーが確認すべき内容に挙げられた問題をチェックする
パイプラインの結果を確認する（特に同期リポジトリの場合）
- パイプラインがパスしていることを確認する
- 比較レポートをレビューする
必要に応じて変更をローカルでテストする（コード変更の場合）
次のいずれかの方法でフィードバックを残す。
- Approve: 変更が問題なければ、マージリクエストの Approve をクリックする
- Request changes: 特定の行にコメントを追加するか、懸念事項を説明する一般的なコメントを追加する
- Ask questions: 不明確な点を明確にするためコメントを使う

フィードバックの提供

フィードバックを残す際は、次の点に留意します。

具体的に: 正確な行を指し、問題を説明する
建設的に: 改善案を示し、批判だけにとどめない
タイムリーに: 可能なら 1〜2 営業日以内にレビューする
質問する: 不明な点があれば、推測せずに質問する
良い仕事を称える: 巧みな解法や改善を取り上げる

マージリクエストの承認

マージリクエストを承認するには、次の手順に従います。

自分の懸念事項がすべて対応されていることを確認する
右サイドバーの Approve をクリックする
任意でコメントを追加: 「Looks good! ✅」や検証した内容を記載する

マージリクエストのマージ

いつマージするか

マージリクエストは、次の条件を満たした場合にマージできます。

✅ 少なくとも 1 名のピアレビュアーに承認されている
✅ すべてのパイプラインチェックがパス（緑色のチェック）
✅ すべてのディスカッションが解決済み（または明示的にブロックしないとマークされている）
✅ 関連 Issue でデプロイ準備完了が確認されている
✅ Standard デプロイの場合: 次回のデプロイ日にデプロイされる準備ができている

マージ方法

承認されたマージリクエストをマージするには、次の手順に従います。

すべてのマージ条件が満たされていることを確認する
Merge をクリックする

マージ後

MR がマージされた後は、次のことを行います。

Ad-hoc デプロイの場合: 変更は即座にデプロイされるか、次回のスクリプト実行時にデプロイされる
Standard デプロイの場合: 変更は次のスケジュール済みデプロイ（毎月 1 日）にデプロイされる
関連 Issue にコメントを追加: MR がマージされたことを記載する
問題を監視する: デプロイ後の予期しない挙動を監視する
緊急の場合は例外デプロイを実施: 例外デプロイ手順については個別のドキュメントページを参照する

よくあるマージリクエストのシナリオ

レビュー後の変更

レビュアーが変更を依頼した場合は、次の手順に従います。

ローカルブランチで依頼された変更を行う
変更をコミットしてプッシュする
MR は新しいコミットで自動的に更新される
レビュアーのコメントに対し、何を変更したかを返信する
必要に応じて再レビューを依頼する

マージコンフリクトへの対応

MR にマージコンフリクトが表示された場合、CLI で次の方法で解決できます。

プロジェクトリポジトリに自分のコンピュータ上で移動する
ソースブランチをチェックアウトする（例として jcolyer-source-branch を使用）
```
git checkout jcolyer-source-branch
```
ターゲットブランチからリベースする（例として jcolyer-target-branch を使用）。
```
git rebase origin/jcolyer-target-branch
```
コンフリクトを含むファイルを見つけるため出力を確認する
該当ファイルを編集してコンフリクトを解決する
修正したファイルを追加する（例として public/index.html を使用）。
```
git add public/index.html
```
リベースを続行する。
```
git rebase --continue
```
出力にリベースが完了したと表示されるまで、手順 4 から繰り返す
--force-with-lease フラグを使ってソースブランチに変更をプッシュする。
```
git push origin jcolyer-source-branch --force-with-lease
```
MR は自動的に更新される

マージせずにマージリクエストをクローズする

変更を進めないと判断した場合は、次の手順に従います。

MR をクローズする理由を説明するコメントを追加する
関連 Issue をクローズする（適切な場合）
MR の下部にある Close merge request をクリックする
必要に応じてソースブランチを削除する

ベストプラクティス

MR を絞り込む: 1 つの MR は 1 つの Issue または機能に対応すべきです。無関係な変更を混ぜないでください。
MR を小さく保つ: 小さい MR ほどレビューが容易で、マージのリスクも低くなります。可能であれば 500 行以下の変更を目指してください。
明確な説明を書く: 後の自分（とチームメイト）が、なぜ変更したかのコンテキストを知れることに感謝するでしょう。
レビューには素早く対応する: 作業を進めるため、フィードバックには 1〜2 日以内に対応してください。
レビュー依頼前にテストする: レビュアーを QA として使わないでください。まず自分で変更をテストしてください。
ドキュメントを更新する: 変更がプロセスや使い方に影響する場合、関連ドキュメントを更新してください。
関連 Issue へリンクする: トレーサビリティのため、MR は対応する Issue に必ずリンクしてください。

よくある問題とトラブルシューティング

同期リポジトリでのパイプライン失敗

比較パイプラインが失敗した場合は、次のことを行います。

パイプラインのログをレビューして問題を特定する
一般的な原因:
- YAML の構文エラー（インデント、コロン、引用符を確認）
- 必須フィールドの欠落（title、position など）
- 同期リポジトリ内の重複タイトル
- マネージドコンテンツファイルの欠落（contains_managed_content: true のトリガー/ビューの場合）
問題を修正して新しいコミットをプッシュする