Content last updated 2026-07-14

マージリクエストを扱う

マージリクエストを扱うためのドキュメント

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

マージリクエストを理解する

マージリクエストを使用する理由

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

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

マージリクエストを作成する

前提条件

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

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

マージリクエストを作成する

マージリクエストを作成するには:

GitLab.com でプロジェクトに移動します
左側のサイドバーでマージリクエストに移動します
新しいマージリクエストボタンをクリックします
ソースブランチ（作業ブランチ）とターゲットブランチ（通常は master または main）を選択します
ブランチを比較して続行をクリックします
マージリクエストの詳細を入力します:
- タイトル: 変更内容を要約した明確で説明的なタイトルを使用します
  - 良い例: “プレミアムサポートルーティング用の新しいトリガーを追加”
  - 悪い例: “トリガーを更新” または “いろいろ修正”
- 説明: 次を含むコンテキストを提供します:
  - 関連する Issue へのリンク: Relates to ISSUE_URL
  - 何を、なぜ変更したかの要約
  - 特別なテストまたはデプロイに関する考慮事項
  - 破壊的変更または依存関係（該当する場合）
- 担当者: 自分を割り当てます
- レビュアー: レビューのためにチームメンバーを割り当てます（レビューを依頼するを参照）
マージリクエストを作成をクリックします

同期リポジトリの場合

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

YAML 構文を検証する
必須フィールドを確認する
提案された変更を現在の Zendesk 設定と比較する
比較レポートを生成する

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

レビューを依頼する

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

標準的な変更の場合: 領域の知識がある、対応可能なチームメンバーにレビューを依頼します
複雑またはリスクの高い変更の場合: 複数のチームメンバーまたはシニアエンジニアにレビューを依頼します
セキュリティに配慮が必要な変更の場合: セキュリティを意識したレビュアーを含めます
不明な場合: レビュアーの推奨についてチームチャンネルで尋ねます

レビュアーが確認すべきこと

ピアレビューを行う際、レビュアーは次を確認する必要があります:

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

マージリクエストをレビューする

レビュー方法

レビュアーとして割り当てられた場合:

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

フィードバックを提供する

フィードバックを残すときは:

具体的にする: 正確な行を指し、問題を説明します
建設的にする: 批判するだけでなく、改善を提案します
迅速に対応する: 可能な場合は 1 〜 2 営業日以内にレビューします
質問する: 不明な場合は、推測せずに質問します
良い仕事を認める: 巧妙な解決策や改善を取り上げます

マージリクエストを承認する

マージリクエストを承認するには:

すべての懸念事項に対処されていることを確認します
右側のサイドバーで承認をクリックします
必要に応じてコメントを追加します: “Looks good! ✅” または確認した内容を記載します

マージリクエストをマージする

マージするタイミング

マージリクエストは、次の条件を満たすとマージできます:

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

マージ方法

承認されたマージリクエストをマージするには:

すべてのマージ基準を満たしていることを確認します
マージをクリックします

マージ後

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 下部のマージリクエストを閉じるをクリックします
必要に応じてソースブランチを削除します

ベストプラクティス

MR を焦点化する: 1 つの MR では 1 つの Issue または機能を扱う必要があります。無関係な変更を混在させないでください。
MR を小さく保つ: 小さい MR はレビューしやすく、マージ時のリスクも低くなります。可能な場合は変更行数を 500 行未満にすることを目指してください。
明確な説明を書く: 変更した理由に関するコンテキストは、将来の自分（およびチームメイト）に役立ちます。
レビューに迅速に対応する: 作業を進め続けるため、フィードバックには 1 〜 2 日以内に対応します。
レビューを依頼する前にテストする: レビュアーを QA として使用しないでください。最初に自分で変更をテストします。
ドキュメントを更新する: 変更がプロセスまたは使用方法に影響する場合は、関連するドキュメントを更新します。
関連する Issue にリンクする: 追跡可能性のため、MR は必ず対応する Issue に接続します。

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

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

比較パイプラインが失敗した場合:

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