【完全ガイド】git pull / merge conflict の解決方法｜3-way merge の仕組みからoursとtheirsまで徹底解説

Git を使っていて最も緊張する瞬間の一つが、merge conflict の発生:

$ git pull origin main
Auto-merging src/config.js
CONFLICT (content): Merge conflict in src/config.js
Automatic merge failed; fix conflicts and then commit the result.

エディタで開くと、見慣れない記号が…:

const config = {
  appName: 'MyApp',
<<<<<<< HEAD
  timeout: 5000,
  retries: 3,
=======
  timeout: 10000,
  retries: 5,
>>>>>>> feature-branch
  debug: false,
};

「これはどうすればいいんだ…」と手が止まる。

しかし、conflict は バグではなく、Git が「2人が同じ場所を違う方法で変更したから、人間が判断してくれ」と言っているだけです。仕組みを理解すれば、恐れる必要はありません。

現場では:

• <<<<<<< HEAD / ======= / >>>>>>> の意味が分からない
• 「ours」と「theirs」どっちが自分？
• rebase 中に conflict が発生すると、意味が逆転する？
• 全部相手側 or 自分側を採用するには？
• 一度解決したconflict をまた解決する必要ある？（→ rerere）
• VSCode で解決したい
• 途中でやめたい（abort）
• lock ファイル（package-lock.json 等）の conflict どうする？

など、正しく理解しないと間違った解決で本番障害を招くリスクがあります。

本記事では、git conflict の完全な解決方法を、リファレンスとして実用的に整理します。3-way merge の仕組み、conflict marker の完全解読、基本の解決フロー、git checkout --ours/--theirs、-X ours/theirs vs -s ours の重要な違い、diff3 スタイル、rebase 中の ours/theirs 逆転、rerere（自動記憶）、VS Code / vimdiff / meld との連携、実践パターン、予防のベストプラクティス、FAQまで完全網羅。この1本で conflict を恐れずスムーズに解消できるようになります。

結論：conflict 解決の5ステップ

時間がない方向けに、最短の対処手順を示します。

ステップ1：状況確認

git status
# Unmerged paths:
#   both modified: src/config.js

ステップ2：conflict のあるファイルを開く

<<<<<<< HEAD        // ← 自分側（ours）
timeout: 5000,
=======
timeout: 10000,     // ← 相手側（theirs）
>>>>>>> feature-branch

ステップ3：マーカーを消して正しい状態に

timeout: 10000,   // 相手側を採用

ステップ4：解決マークをつける

git add src/config.js

ステップ5：完了

# merge の場合
git commit

# rebase の場合
git rebase --continue

# cherry-pick の場合
git cherry-pick --continue

中止したい場合

git merge --abort         # merge を中止
git rebase --abort        # rebase を中止
git cherry-pick --abort   # cherry-pick を中止

詳細は以下で解説します。

まず理解する：3-way merge の仕組み

なぜ conflict は起きるか

Alice と Bob が同じファイルの同じ行を違う内容に変更した時に発生:

共通の親コミット（BASE）
  ├─ Alice の変更（ours）: timeout: 5000
  └─ Bob の変更（theirs）: timeout: 10000

Git は「どちらを採用すべきか自動判断できない」と判断し、人間に判断を委ねます。

3つのバージョン

Git は3つのバージョンを比較する3-way merge を使います:

図解

       A ─ B ─ C (main / ours)
      /
BASE ─
      \
       X ─ Y ─ Z (feature / theirs)

main にいる時に git merge feature すると:

• ours = C（自分）
• theirs = Z（相手）
• base = 分岐点

両方が同じ行を変更 → conflict。

diff3 の起源

ours / theirs / base の用語は Git 独自ではなく、1979年の Unix diff3 ユーティリティから来ています。IDE や merge tool 全てで同じ用語が使われるため、覚える価値大。

Conflict Marker の完全解読

デフォルトのマーカー

<<<<<<< HEAD
これはあなたの変更
=======
これは相手の変更
>>>>>>> feature-branch

構造:

• <<<<<<< HEAD: 自分側の開始
• =======: 区切り
• >>>>>>> feature-branch: 相手側の終了

HEAD の後は現在のブランチ、>>>>>>> の後は取り込むブランチ名。

diff3 スタイル（強く推奨）

git config --global merge.conflictStyle diff3

または最新版:

git config --global merge.conflictStyle zdiff3

すると 3つ目のセクション（base）が表示されます:

<<<<<<< HEAD
timeout: 5000
||||||| merged common ancestors
timeout: 15
=======
timeout: 60
>>>>>>> feature-branch

base（元の値）が分かるため、「どちらの変更が何をしたか」を判断しやすくなります。

例:

• base: 15
• ours: 5000 （3桁増やした）
• theirs: 60 （4倍にした）

→ 用途によって判断可能。diff3 は絶対に設定しておくべき。

conflict は行単位ではなく hunk（塊）単位

複数行にまたがることも:

const config = {
<<<<<<< HEAD
  appName: 'MyApp v2',
  timeout: 5000,
  retries: 3,
=======
  appName: 'NewApp',
  timeout: 10000,
  retries: 5,
  debug: true,
>>>>>>> feature-branch
};

Git は関連する変更を一つの hunk として扱います。

Conflict が発生するタイミング

1. git pull

git pull origin main
# Auto-merging src/config.js
# CONFLICT (content): Merge conflict in src/config.js

git pull は git fetch + git merge。merge で conflict が発生。

git pull --rebase なら rebase で発生。

詳細はgit push rejected の記事も参照。

2. git merge

git checkout main
git merge feature
# CONFLICT (content): Merge conflict in ...

3. git rebase

git checkout feature
git rebase main
# CONFLICT (content): Merge conflict in ...

⚠️ rebase では ours / theirs の意味が逆転（後述）。

4. git cherry-pick

git cherry-pick abc123
# CONFLICT (content): ...

5. git stash pop / apply

git stash pop
# CONFLICT (content): ...

6. git revert

git revert abc123
# CONFLICT (content): ...

対処法は基本すべて同じですが、--continue するか commit するかの違いがあります。

基本の解決フロー（詳細版）

ステップ1：状況確認

git status

出力:

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified: src/config.js
        both modified: src/utils.js

no changes added to commit

• both modified: 両側で変更（最頻出）
• added by us / them: 片方だけ追加
• deleted by us / them: 片方で削除

ステップ2：詳細確認

# 差分確認
git diff

# 自分の変更内容
git diff --ours src/config.js

# 相手の変更内容
git diff --theirs src/config.js

# base（共通祖先）との差分
git diff --base src/config.js

ステップ3：ファイルを編集

エディタで開き、conflict marker を消して正しい状態にする:

// Before
<<<<<<< HEAD
timeout: 5000,
=======
timeout: 10000,
>>>>>>> feature-branch

// After（相手側を採用した例）
timeout: 10000,

ステップ4：解決マーク

git add src/config.js

すべてのconflict を解決するまで繰り返し。

ステップ5：完了

# merge の場合
git commit
# デフォルトメッセージが用意される（そのまま確定でOK）

# rebase の場合
git rebase --continue

# cherry-pick の場合
git cherry-pick --continue

途中でやめる

git merge --abort         # merge を中止、pull 前の状態へ
git rebase --abort        # rebase を中止、開始前の状態へ
git cherry-pick --abort   # cherry-pick を中止

abort すれば安全に元に戻れる。焦った時の最善策。

一括で片方を採用する方法

git checkout –ours / –theirs

# 自分側を全て採用
git checkout --ours path/to/file

# 相手側を全て採用
git checkout --theirs path/to/file

# 忘れずにadd
git add path/to/file

部分的でなくファイル単位で採用したい時に強力。

例：

# package-lock.json は相手を採用
git checkout --theirs package-lock.json
git add package-lock.json

# 自分の変更コードは残す
# → 手動で src/*.js を解決

全ファイル一括

# 全ての衝突ファイルで相手側を採用
git checkout --theirs .
git add .

⚠️ 影響範囲が大きいため慎重に。

-X ours / -X theirs vs -s ours の重要な違い

多くの人が混同する超重要ポイント。

-X ours（Xは大文字、Strategy Option）

git merge -X ours feature

• 通常の merge を実行（相手の変更も取り込む）
• ただし conflict が発生したら自分側を採用
• 相手の非conflict 変更は反映される

-X theirs

git merge -X theirs feature

• 通常の merge
• conflict は相手側を採用
• 自分の非conflict 変更は残る

-s ours（sは小文字、Merge Strategy）

git merge -s ours feature

⚠️ 相手の変更を一切見ない、破棄する:

• 相手のブランチが「存在した」ことだけ記録
• 相手の内容は0行も取り込まれない

用途:

• 特定機能の履歴を残しつつ、内容は捨てたい時
• 極めて稀

比較表

実務での使い分け

# 相手のコードを取り込むが、conflict は自分側で解決
git merge -X ours upstream/main

# 相手を優先（相手のブランチの方が新しい）
git merge -X theirs upstream/main

# ⚠️ 通常は使わない
git merge -s ours abandoned-feature

rebase 中の ours / theirs 逆転（要注意）

rebase 中は ours と theirs の意味が反対になります。

rebase の仕組み

Before:
main:    A ─ B ─ C
              \
feature:       X ─ Y

After (git rebase main):
main:    A ─ B ─ C
                  \
feature:           X' ─ Y'

rebase は「自分のコミット X, Y を、main の先端 C の上に再生」します。

なぜ逆転するか

• rebase では「受け入れる側」= main のC（ours）
• 「取り込まれる側」= 自分の X, Y（theirs）

つまり自分のコミットが theirs、相手のブランチが ours。

例

git checkout feature
git rebase main
# CONFLICT in src/config.js

# 自分の feature の変更を残したい
git checkout --theirs src/config.js  # ← 自分！
git add src/config.js
git rebase --continue

多くの人が –ours と勘違いする。要注意。

覚え方

• 常に「受け入れる側」が ours
• merge: 現在のブランチが受け入れ → 現在が ours
• rebase: 対象ブランチの上にコミットを乗せる → 対象が ours

メッセージを読む

CONFLICT (content): Merge conflict in src/config.js

Git が「Merge」と言うか「rebase」と言うかで、内容も違います。メッセージを毎回読むのが安全。

rerere（Reuse Recorded Resolution）

Git の隠れた神機能。同じ conflict を何度も解決する手間を省きます。

有効化

git config --global rerere.enabled true

動作の仕組み

1. conflict を手動で解決
2. Git が「conflict の内容」と「あなたの解決内容」を記録
3. 次に同じ conflict が発生 → 自動的に解決を適用

効果的なシーン

• 同じ rebase を何度も試す（abort → 再開）
• 長期間 feature ブランチを main に追随
• チームで似た conflict を繰り返す

実際の例

git rebase main
# CONFLICT in src/config.js
# 手動で解決...
git add src/config.js
git rebase --continue

# その後、main が更新されて再rebase
git rebase --abort
git rebase main
# → 同じconflict が発生
# → rerere が「前に解決した内容を再適用しました」と表示
# → git add して continue するだけ

確認

# 記録された解決を確認
ls .git/rr-cache/

# 特定ファイルの記録を忘れる
git rerere forget src/config.js

効果は絶大

一度有効化すれば体感的に「conflict が減った」ように感じるほど。必ず設定しておくべき。

VS Code での解決

VS Code は 3-way merge editor を標準搭載（1.70+）。

使い方

1. conflict のあるファイルを開く
2. 上部の “Resolve in Merge Editor” をクリック
3. 3ペイン表示: Current (ours) / Incoming (theirs) / Result

操作

• 各 hunk で Accept Current / Accept Incoming / Accept Both ボタン
• 手動編集も可能
• “Complete Merge” で完了

インライン解決

Merge editor を使わずインライン解決も可能:

<<<<<<< HEAD
[Accept Current Change] [Accept Incoming Change] [Accept Both Changes] [Compare Changes]
timeout: 5000
=======
timeout: 10000
>>>>>>> feature-branch

各リンクをクリックで選択。

コマンドパレット

• Git: Merge
• Git: Rebase
• Git: Abort Merge

settings.json

{
  "git.mergeEditor": true,      // Merge editor を有効
  "diffEditor.experimental.showMoves": true,
  "git.openDiffOnClick": true
}

vimdiff / vim での解決

git mergetool の設定

git config --global merge.tool vimdiff
git config --global mergetool.prompt false

起動

git mergetool

vim が4ペイン（LOCAL / BASE / REMOTE / MERGED）で開きます:

+-------+-------+-------+
| LOCAL | BASE  |REMOTE |
+-------+-------+-------+
|         MERGED        |
+-----------------------+

• LOCAL: ours
• REMOTE: theirs
• BASE: 共通祖先
• MERGED: 編集する対象

主要コマンド

詳細はLinuxでファイル差分を確認する方法（diff/colordiff/vimdiff）の記事も参照。

他のマージツール

# meld (GUI)
git config --global merge.tool meld

# kdiff3 (GUI)
git config --global merge.tool kdiff3

# opendiff (macOS)
git config --global merge.tool opendiff

# VS Code
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

実践シナリオ

シナリオ1：シンプルな pull conflict

git pull origin main
# CONFLICT in src/config.js

# 1. 確認
git status
git diff

# 2. エディタで解決
code src/config.js
# marker を消して正しい状態に

# 3. マーク
git add src/config.js

# 4. コミット
git commit
# デフォルトメッセージで OK

シナリオ2：rebase 中の conflict

git checkout feature
git rebase main
# CONFLICT in src/utils.js

# ⚠️ rebase中は ours/theirs が反対
# 自分の変更を残したい → --theirs
git checkout --theirs src/utils.js
git add src/utils.js
git rebase --continue

# 複数コミットで conflict が発生する場合、繰り返し

シナリオ3：全部相手を採用（緊急対応）

git pull origin main
# 大量の conflict

# 全部相手を取り込む
git checkout --theirs .
git add .
git commit

⚠️ 自分の変更が消える。バックアップ必須。

シナリオ4：package-lock.json / yarn.lock

lock ファイルの conflict は再生成が正解:

git pull origin main
# CONFLICT in package-lock.json

# 相手を採用してから再インストール
git checkout --theirs package-lock.json
npm install
git add package-lock.json
git commit

または yarn:

git checkout --theirs yarn.lock
yarn install
git add yarn.lock

シナリオ5：db/schema.rb (Rails)

Rails の schema.rb は同様に再生成:

git checkout --theirs db/schema.rb
bin/rails db:migrate:status
bin/rails db:migrate
git add db/schema.rb
git commit

詳細はrails db:migrate 使い方の記事も参照。

シナリオ6：Gemfile.lock

git checkout --theirs Gemfile.lock
bundle install
git add Gemfile.lock
git commit

シナリオ7：cherry-pick の conflict

git cherry-pick abc123
# CONFLICT

# 解決
vim src/config.js
git add src/config.js
git cherry-pick --continue

# 中止する場合
git cherry-pick --abort

シナリオ8：stash pop の conflict

git stash pop
# CONFLICT

# 解決
vim src/config.js
git add src/config.js
# stash は自動でdrop されるが、上のcase では残る場合あり
git stash list   # 残っていれば
git stash drop   # 手動でクリア

シナリオ9：巨大な PR での conflict 大量発生

# feature が長期間 main から離れて develop の変更が大量
git checkout feature

# こまめに main を rebase して conflict を減らす
git rebase main
# conflicts 解決...

# または merge で
git merge main

「長期間放置しない」が最大の予防。

シナリオ10：Kamal デプロイでの conflict

# デプロイ前に main を最新化
git checkout main
git pull

# feature を rebase して conflict 解決
git checkout feature
git rebase main
# 解決...

# push
git push --force-with-lease origin feature

# PR merge 後、デプロイ
kamal deploy

詳細はgit push rejected の記事、Kamal 2 デプロイの記事も参照。

conflict の予防

1. こまめな同期

# 朝一で
git fetch origin
git rebase origin/main

# または
git pull --rebase origin main

放置するほど conflict は増える。

2. 小さい PR

大きい変更を一度にmerge するより、小さいPR を頻繁にマージ。

3. コードフォーマットは別 PR

# ❌ 大きい機能追加 + prettier 整形
# → 他PRとの conflict 多発

# ✅ 機能追加PR → merge → 整形PR

prettier / rubocop などの整形専用 PR を分離。

4. .gitattributes でマージ戦略を指定

# .gitattributes
package-lock.json merge=theirs
yarn.lock merge=theirs
db/schema.rb merge=theirs

これで自動的に theirs 採用。

5. rerere 有効化

git config --global rerere.enabled true

絶対にやるべき。

6. diff3 スタイル

git config --global merge.conflictStyle diff3

base 表示で判断が楽に。

7. マージ関連の設定

git config --global pull.rebase true       # pull はrebase デフォルト
git config --global fetch.prune true       # 削除ブランチも同期
git config --global rerere.enabled true    # 自動記憶
git config --global merge.conflictStyle diff3  # base表示
git config --global rebase.autoStash true  # rebase 前に自動stash

推奨設定を一括で。

8. Feature Toggle の活用

長期間 branch を分岐する代わりに、main にfeature flag でマージ。conflict の温床を回避。

トラブルシューティング

git status で「unmerged paths」が消えない

# 解決マーク忘れ
git add resolved_file.js

# 状況確認
git status

commit しようとしたら「fatal: cannot do a partial commit during a merge」

conflict 解決中は -a や特定ファイルの commit ができない:

# ❌
git commit -a -m "..."
git commit resolved_file.js -m "..."

# ✅ 全部add してから
git add -A
git commit

全ての conflict を解決したのにコミットできない

git status で確認。tab や空白の違いで解決したつもりの箇所が残っているかも:

grep -rn '<<<<<<< ' .
grep -rn '=======' .
grep -rn '>>>>>>> ' .
# marker が残っていないか

詳細はLinux grep オプション一覧の記事も参照。

マージ中に混乱した、リセットしたい

# merge を中止
git merge --abort

# rebase を中止
git rebase --abort

# もっと強力にリセット（開発中の変更も破棄）
git reset --hard HEAD

⚠️ --hard は未commit の変更を消す。

rerere が想定通り動かない

# 記録を確認
ls .git/rr-cache/

# 記録を消す
git rerere forget path/to/file

# 全記録を消す
rm -rf .git/rr-cache/

バイナリファイルの conflict

# バイナリはマージ不可
git checkout --ours image.png
git add image.png

# または相手側
git checkout --theirs image.png
git add image.png

rename / delete conflict

片方がリネームし、片方が変更した場合:

CONFLICT (rename/modify): utils.js renamed to helpers.js in feature, modified in main

→ 両方見て、意図を判断。通常は新しい場所に修正を移す:

mv utils.js helpers.js  # or 手動でマージ
git add helpers.js
git rm utils.js

誰の変更か分からない

# ファイルの変更履歴
git log --oneline path/to/file

# 行ごとの変更者
git blame path/to/file

# ブランチ間の commit 比較
git log HEAD..origin/main --oneline
git log origin/main..HEAD --oneline

詳細はLinuxでファイル差分を確認する方法（diff/colordiff/vimdiff）の記事、Linuxでシンボリックリンクを作成・確認・削除する方法（ln/readlink/unlink）の記事も参照。

よくある質問（FAQ）

Q1. ours と theirs、どっちが自分？

現在いるブランチ（受け入れる側）が ours。

• git merge 時: 現在ブランチが ours
• git rebase 時: 対象ブランチが ours（自分のコミットは theirs）

Q2. conflict marker を消すのを忘れて commit した

大惨事。すぐ修正:

# 直前の commit を修正
vim path/to/file  # marker を消す
git add path/to/file
git commit --amend --no-edit

# push 済みなら
git push --force-with-lease origin BRANCH

詳細はgit push rejected の記事も参照。

Q3. 何度も同じ conflict が発生する

rerere を有効化。または、根本的にブランチ戦略の見直し。

git config --global rerere.enabled true

Q4. VS Code の merge editor が起動しない

// settings.json
{
  "git.mergeEditor": true
}

または VS Code を最新にアップデート（1.70+ 必要）。

Q5. GitHub 上で解決したい

PR ページで “Resolve conflicts” ボタンが表示される（軽微な conflict のみ）。複雑な場合はローカルで解決。

Q6. GitLab 上で解決

PR (Merge Request) の “Resolve conflicts” から Web エディタで解決可能。

Q7. conflict の予防に最も効くもの

1. こまめな pull / rebase（放置しない）
2. rerere 有効化
3. PR を小さく
4. 整形専用の commit を分離
5. チーム内で分業を明確に

Q8. git merge -X theirs は危険？

危険ではないが、注意深く使う必要あり:

• 自分の変更が意図せず消える可能性
• CI/CD の自動 merge には向く
• 手動 merge では手動確認推奨

Q9. rebase 中に abort したら、変更が消える？

git rebase --abort は開始前の状態に戻します。作業中の変更は失われないが、rebase 中に手動で編集した内容は破棄されます。

Q10. conflict がある状態で checkout できない

# 未解決の場合
git checkout other-branch
# error: Your local changes to the following files would be overwritten

# 解決方法1: stash
git stash
git checkout other-branch

# 解決方法2: merge/rebase を中止してから
git merge --abort
git checkout other-branch

Q11. conflict のあったコミットを後で確認

git log --merges --oneline
# マージコミット一覧

git show <merge-commit-hash>
# 詳細

Q12. GitHub Actions の PR で conflict が起きた

# .github/workflows/pr.yml
- name: Check for conflicts
  run: |
    git fetch origin ${{ github.base_ref }}
    git merge --no-commit --no-ff origin/${{ github.base_ref }}
    if [ $? -ne 0 ]; then
      echo "Conflicts detected"
      exit 1
    fi

CI で自動検知して通知。

参考リンク・関連資料

Git 公式

• git-merge Documentation – merge 公式
• git-rerere Documentation – rerere 公式
• Pro Git Book: Advanced Merging – 詳細ガイド

関連ツール

• meld – GUI マージツール
• kdiff3 – GUI マージツール
• VS Code Merge Editor – 3-way merge editor

関連記事（本サイト）

• git push rejected – push 関連エラー
• Linuxでファイル差分を確認する方法（diff/colordiff/vimdiff） – vimdiff での解決
• Linux find オプション一覧 – conflict marker 検索
• Linux grep オプション一覧 – 検索と抽出
• rails db:migrate 使い方 – db/schema.rb 対応
• Rails 8 アップグレードガイド – デプロイフロー
• Kamal 2 デプロイ – 本番デプロイ
• Solid Queue 使い方 – Rails ジョブ
• SSH host key verification failed – リモート操作
• scp vs rsync – デプロイ関連
• docker daemon 接続エラー – Docker 開発
• find vs find_by vs where 違い – Rails クエリ

まとめ

git conflict 解決、要点を再整理します。

5ステップ解決フロー

1. git status                     # 状況確認
2. エディタで開いてマーカーを消す   # 解決
3. git add <file>                 # マーク
4. git commit                     # 完了（merge の場合）
   or git rebase --continue       # rebase の場合
   or git cherry-pick --continue  # cherry-pick の場合
5. 中止したい時は --abort

Conflict Marker 早見表

<<<<<<< HEAD           自分側の開始
timeout: 5000          自分の変更
||||||| ancestors      base (diff3 スタイル時)
timeout: 15            共通祖先
=======                区切り
timeout: 10000         相手の変更
>>>>>>> feature-branch 相手側の終了

一括採用

git checkout --ours <file>    # 自分側全部
git checkout --theirs <file>  # 相手側全部
git add <file>

merge オプションの違い

rebase 中の逆転

rebase では:
自分のコミット = theirs
対象ブランチ = ours

絶対にやる設定

git config --global rerere.enabled true               # 自動記憶
git config --global merge.conflictStyle diff3          # base 表示
git config --global pull.rebase true                   # pull は rebase
git config --global rebase.autoStash true              # rebase 前 stash

conflict の予防

• こまめな pull / rebase（放置しない）
• PR を小さく
• 整形専用 PR を分離
• rerere 有効化
• feature flag 活用（長期分岐回避）

特殊ファイルの扱い

エディタ/ツール推奨

• VS Code: 3-way merge editor（1.70+）
• vimdiff: git mergetool で起動
• meld: GUI で見やすい
• rerere: 自動化

これらの知識は、日々の Git 操作・チーム開発・デプロイフロー・トラブル対応など、あらゆる場面で活用できます。本記事をブックマークしておけば、conflict に出会っても慌てず確実に解決できるようになります。

本記事は2026年6月時点の情報をもとに、Git 2.40+ での動作確認・公式ドキュメント・GitHub/GitLab のドキュメントに基づき作成しています。Git のバージョンや使用するホスティングサービスによって挙動が異なる場合があるため、最新の情報はGit公式ドキュメント、GitHub Docs、GitLab Docs もあわせてご確認ください。