【永久保存版】初心者向けGit運用マニュアル

Last updated at 2025-11-03Posted at 2025-11-03

Git + GitLab 運用マニュアル

はじめに

Gitの右も左もわからないのに、プロジェクトの管理をGitで行うことになってしまった自分に向けて、備忘録を残しておく。（マニュアル化はすべて生成AIにお願いした。）

対象読者

このマニュアルは、以下のような方を対象としています。

Git/GitLabを使ったチーム開発が初めての方
個人開発からチーム開発に移行する方
ブランチ戦略の統一を図りたいチームリーダー
複数人での並行開発に不安がある開発者
コンフリクトの解決方法を体系的に学びたい方

前提知識

このマニュアルを活用するために、以下の知識があると理解がスムーズです。

必須スキル

基本的なGitコマンドの理解
- git add, git commit, git push, git pull の基本操作
- ブランチの概念（ git branch, git checkout ）
ターミナル/コマンドラインの基本操作
- ディレクトリ移動（ cd ）、ファイル作成（ echo, touch ）など
GitLabアカウントの準備
- プロジェクトへのアクセス権限
- SSHキーまたはHTTPSでの認証設定

1. 初期セットアップ（新規プロジェクトの場合）

1-1. ローカルリポジトリ作成

# 作業フォルダ作成
mkdir my_project
cd my_project

# Git初期化
git init

ブランチ状態:

1-2. リモートリポジトリとの紐付け

※ GitLab上で事前にプロジェクトを作成しておく

# リモートURLの登録(SSH例)
git remote add origin git@gitlab.example.com:username/my_project.git

# HTTPSの場合
# git remote add origin https://gitlab.example.com/username/my_project.git

1-3. 初回コミット & push

# ファイル作成例
echo "# My Project" > README.md

# ステージング
git add README.md

# コミット
git commit -m "chore: initial commit"

# リモートにmainブランチをpush
git branch -M main
git push -u origin main

ブランチ状態:

2. ブランチ運用ルール

ブランチ階層

main(安定版・直接コミット禁止)
└─ dev-<yourname>(個人開発ブランチ)
     ├─ feature-<機能名>(機能追加・修正用)

ブランチ構造図:

3. 開発フロー(feature → dev → main)

図解

[main]───┐
         │ (MR: dev → main)
[dev-cocoa]───┐
                 │ (MR: feature → dev)
[feature-A]─────┘

完全フロー図:

3-1. 個人開発ブランチの作成

# mainを最新化
git checkout main
git pull origin main

# 個人ブランチ作成
git checkout -b dev-cocoa
git push -u origin dev-cocoa

ブランチ作成の様子:

3-2. 機能ブランチ作成

# 個人ブランチを最新化
git checkout dev-cocoa
git pull origin dev-cocoa

# 機能ブランチ作成
git checkout -b feature-A
git push -u origin feature-A

機能ブランチ作成:

3-3. 機能開発

# 編集後
git add .
git commit -m "feat: READMEにDS機能の説明を追記"
git push

機能開発の進捗:

3-4. GitLabでMR(feature → dev)

GitLabにアクセス
Merge Requests → New Merge Request
Source branch: feature-A
Target branch: dev-cocoa
タイトル・説明を記入
Approve → Mergeボタンをクリック

マージ後の状態:

マージの流れ:

feature-A ブランチの変更が dev-cocoa に統合される
GitLab上でコードレビュー・承認プロセスを経てマージ
feature-A の全てのコミットが dev-cocoa に反映される

3-5. テスト後、MR(dev → main)

GitLabで新しいMR作成
Source branch: dev-cocoa
Target branch: main
「テスト済み」と記載
Approve → Merge

本番環境へのマージ:

マージの流れ:

dev-cocoa ブランチで十分なテストを実施
問題がないことを確認後、 main ブランチへマージ
main は常に本番環境にデプロイ可能な安定版を保つ

3-6. ローカル最新化

git checkout main
git pull origin main

ローカルの同期:

4. 運用の注意点

main は直接コミット禁止(必ずMR経由)
機能ごとに feature-〇〇 ブランチを作成
MR作成時は Source / Target branch を必ず確認
使い終わった feature ブランチは削除

git branch -d feature-A
git push origin --delete feature-A

ブランチ削除後:

5. 完全フローまとめ(図)

[main] ←───────────────┐
 ↑ (MR: dev → main)    │
[dev-cocoa] ←───────┘
 ↑ (MR: feature → dev)
[feature-xxx]

完全な開発サイクル:

フローの手順:

main 最新化 → dev作成

git checkout main
git pull origin main
git checkout -b dev-cocoa

devからfeature作成

git checkout dev-cocoa
git pull origin dev-cocoa
git checkout -b feature-xxx

feature → dev にMR
- GitLab上でMerge Request作成
- レビュー・承認後にマージ
テスト後 dev → main にMR
- 統合テスト実施
- 問題なければmainへマージ
ローカルpullで最新化
```
git checkout main
git pull origin main
```

6. 複数人での並行開発例

複数の機能を同時開発する場合:

これで git init から始まり、GitLabでのMR運用までの完全手順 が揃いました。
各ステップにMermaid図を追加したことで、ブランチの切り方、マージのタイミング、全体の流れが視覚的に理解できます。

7. 複数人での協調開発マニュアル

このセクションでは、 ここあ（dev-cocoa） と サム（dev-sam） が同時に異なる機能を開発する場合の運用方法を説明します。

7-1. 複数開発者のブランチ構造

ブランチ構造の全体像:

ブランチ階層:

main (安定版・直接コミット禁止)
├─ dev-cocoa (ここあの開発ブランチ)
│   ├─ feature-user-auth
│   └─ feature-payment
│
└─ dev-sam (サムの開発ブランチ)
    ├─ feature-dashboard
    └─ feature-analytics

7-2. ここあの作業フロー（認証機能の開発）

ステップ1: 個人開発ブランチの作成

# mainを最新化
git checkout main
git pull origin main

# ここあの個人ブランチ作成
git checkout -b dev-cocoa
git push -u origin dev-cocoa

ブランチ状態:

ステップ2: 機能ブランチの作成（認証機能）

# dev-cocoaを最新化
git checkout dev-cocoa
git pull origin dev-cocoa

# 認証機能のブランチ作成
git checkout -b feature-user-auth
git push -u origin feature-user-auth

ブランチ状態:

ステップ3: 開発作業

# 認証機能の実装
git add .
git commit -m "feat: add user login endpoint"
git push

# バリデーション追加
git add .
git commit -m "feat: add input validation for auth"
git push

# テスト追加
git add .
git commit -m "test: add auth unit tests"
git push

開発の進捗:

ステップ4: MR作成（feature-user-auth → dev-cocoa）

GitLab上での操作:

GitLabにアクセス
Merge Requests → New Merge Request
Source branch:feature-user-auth
Target branch:dev-cocoa
タイトル: feat: ユーザー認証機能の実装
説明に実装内容を記載
Assignee: 自分（ここあ）
Reviewer: サム（任意）
Create Merge Request
レビュー後、 Merge ボタンをクリック

マージ後の状態:

ステップ5: dev-cocoaでテスト

# dev-cocoaに切り替え
git checkout dev-cocoa
git pull origin dev-cocoa

# 統合テスト実施
# テストが成功したら次のステップへ

7-3. サムの作業フロー（ダッシュボード機能の開発）

ステップ1: 個人開発ブランチの作成

# mainを最新化
git checkout main
git pull origin main

# サムの個人ブランチ作成
git checkout -b dev-sam
git push -u origin dev-sam

ブランチ状態:

ステップ2: 機能ブランチの作成（ダッシュボード機能）

# dev-samを最新化
git checkout dev-sam
git pull origin dev-sam

# ダッシュボード機能のブランチ作成
git checkout -b feature-dashboard
git push -u origin feature-dashboard

ブランチ状態:

ステップ3: 開発作業

# ダッシュボードのUI実装
git add .
git commit -m "feat: create dashboard layout"
git push

# データ表示機能追加
git add .
git commit -m "feat: add data visualization components"
git push

# スタイリング
git add .
git commit -m "style: apply responsive design to dashboard"
git push

開発の進捗:

ステップ4: MR作成（feature-dashboard → dev-sam）

GitLab上での操作:

GitLabにアクセス
Merge Requests → New Merge Request
Source branch:feature-dashboard
Target branch:dev-sam
タイトル: feat: ダッシュボード機能の実装
説明に実装内容を記載
Assignee: 自分（サム）
Reviewer: ここあ（任意）
Create Merge Request
レビュー後、 Merge ボタンをクリック

マージ後の状態:

7-4. 並行開発の全体像

ここあとサムが同時に開発している状態:

7-5. mainへの統合

ここあの機能をmainにマージ

# ここあがdev-cocoaのテストを完了したら
# GitLabでMR作成

GitLab上での操作:

Merge Requests → New Merge Request
Source branch:dev-cocoa
Target branch:main
タイトル: Release: ユーザー認証機能
説明: テスト済み。本番環境へのデプロイ準備完了
Create Merge Request
承認後、 Merge

サムの機能をmainにマージ

# サムがdev-samのテストを完了したら
# 最新のmainを取り込む（ここあの変更を含む）
git checkout dev-sam
git fetch origin
git merge origin/main
# コンフリクトがあれば解決
git push origin dev-sam

# その後、GitLabでMR作成

GitLab上での操作:

Merge Requests → New Merge Request
Source branch:dev-sam
Target branch:main
タイトル: Release: ダッシュボード機能
説明: 最新のmainをマージ済み。テスト完了。
Create Merge Request
承認後、 Merge

mainへの統合完了:

7-6. 複数開発者の作業タイムライン

7-7. コンフリクト解決の例

状況: ここあとサムが同じファイルを編集していた場合

サムの対応手順

# dev-samにmainの最新を取り込む
git checkout dev-sam
git fetch origin
git merge origin/main

# コンフリクトが発生した場合
# <<<<<<< HEAD
# サムの変更
# =======
# ここあの変更
# >>>>>>> origin/main

# 手動でコンフリクトを解決
# エディタで編集後

git add <解決したファイル>
git commit -m "fix: resolve merge conflict with main"
git push origin dev-sam

# その後、mainへのMRを作成

コンフリクト解決の流れ:

7-8. 他の開発者の作業確認

リモートブランチの確認

# 全てのリモートブランチを確認
git branch -r

# 出力例:
# origin/main
# origin/dev-cocoa
# origin/dev-sam
# origin/feature-user-auth
# origin/feature-dashboard

他の開発者の進捗確認

# サムの開発ブランチの履歴を確認
git log origin/dev-sam --oneline

# ここあの機能ブランチを確認
git log origin/feature-user-auth --oneline --graph

他の開発者のブランチをローカルで確認

# サムがここあのブランチを確認したい場合
git fetch origin
git checkout -b local-cocoa-check origin/dev-cocoa

# 確認後、自分のブランチに戻る
git checkout dev-sam

# 不要なローカルブランチは削除
git branch -d local-cocoa-check

7-9. 協調開発のベストプラクティス

1. 定期的なmainの取り込み

# 週に1回程度、mainの最新を個人ブランチに取り込む
git checkout dev-cocoa
git fetch origin
git merge origin/main
git push origin dev-cocoa

2. GitLab上でのコミュニケーション

MRでのメンション:

## 実装内容
- ユーザー認証APIの実装
- JWT トークンによる認証

## レビュー依頼
@sam APIエンドポイントが完成しました。
ダッシュボードから接続テストをお願いします。

## 関連Issue
Closes #123

3. ラベルによる進捗管理

GitLabのMRに以下のラベルを付与:

status::in-progress - 開発中
status::review-needed - レビュー待ち
status::tested - テスト完了
status::ready-to-merge - マージ準備完了
priority::high - 優先度高
type::feature - 新機能
type::bugfix - バグ修正

4. コミットメッセージの統一

推奨フォーマット:

# 新機能
git commit -m "feat: ユーザー認証APIを追加"

# バグ修正
git commit -m "fix: ログインエラー時の処理を修正"

# テスト追加
git commit -m "test: 認証機能のユニットテストを追加"

# ドキュメント
git commit -m "docs: API仕様書を更新"

# スタイル修正
git commit -m "style: コードフォーマットを統一"

# リファクタリング
git commit -m "refactor: 認証ロジックを関数化"

7-10. 複数機能の同時開発例

ここあが2つの機能を、サムが2つの機能を同時開発:

7-11. 開発フローチェックリスト

ここあのチェックリスト

mainから個人ブランチ dev-cocoa を作成
dev-cocoa から機能ブランチ feature-xxx を作成
機能を実装しcommit & push
GitLabでMR作成: feature-xxx → dev-cocoa
コードレビュー対応
MRをマージ
dev-cocoa で統合テスト
定期的に main の最新を dev-cocoa に取り込む
テスト完了後、GitLabでMR作成: dev-cocoa → main
MRをマージ
使い終わった feature-xxx ブランチを削除
ローカルの main を最新化

サムのチェックリスト

mainから個人ブランチ dev-sam を作成
dev-sam から機能ブランチ feature-yyy を作成
機能を実装しcommit & push
GitLabでMR作成: feature-yyy → dev-sam
コードレビュー対応
MRをマージ
dev-sam で統合テスト
定期的に main の最新を dev-sam に取り込む
テスト完了後、GitLabでMR作成: dev-sam → main
MRをマージ
使い終わった feature-yyy ブランチを削除
ローカルの main を最新化

7-12. トラブルシューティング

ケース1: 間違ったブランチにコミットしてしまった

状況: dev-cocoa にコミットすべきところを main にコミットしてしまった

# まだpushしていない場合 
git log  # 最新のコミットIDを確認 

# ブランチを切り替え 
git checkout dev-cocoa 

# コミットを持ってくる
git cherry-pick <コミットID> 

# mainブランチに戻って、間違ったコミットを取り消す 
git checkout main 
git reset --hard HEAD~1

ケース2: pushした後に間違いに気づいた

状況: 間違ったコミットをリモートにpushしてしまった

# 最新のコミットを取り消す 
git revert HEAD 

# 取り消しのコミットをpush 
git push origin main 

# 正しいブランチで作業をやり直す 
git checkout dev-cocoa 

# 作業を再度実施...`

ケース3: コンフリクトが複雑で解決できない

状況: マージ時のコンフリクトが複雑すぎる

# マージを一旦中止 
git merge --abort 

# 別の方法: rebaseを使う 
git checkout dev-sam 
git rebase origin/main 

# コンフリクトを1つずつ解決 
# ファイルを編集後 
git add <解決したファイル> 
git rebase --continue 

# 解決できない場合はrebaseも中止 
git rebase --abort

ケース4: 誤って機能ブランチを削除してしまった

状況: feature-dashboard を間違って削除した

# reflogで削除前のコミットIDを探す 
git reflog 

# 出力例: 
# abc1234 HEAD@{0}: branch: deleted feature-dashboard 
# def5678 HEAD@{1}: commit: dashboard: complete 

# ブランチを復元 
git checkout -b feature-dashboard def5678 
git push -u origin feature-dashboard

ケース5: リモートとローカルが大きくずれてしまった

状況: ローカルが古すぎてマージできない

# 現在の作業を一時退避 
git stash 

# リモートの最新を強制取得 
git fetch origin 
git reset --hard origin/dev-cocoa 

# 退避した作業を戻す 
git stash pop 

# コンフリクトがあれば解決

7-13. よくある質問（FAQ）

Q1: dev-cocoaとdev-samはいつまで保持すべきですか?

A: プロジェクトが続く限り保持します。個人の開発ブランチは常に最新のmainから分岐し続けます。削除するのは feature-xxx ブランチのみです。

Q2: 複数の機能を同時に開発してもいいですか?

A: はい、問題ありません。dev-cocoa から複数の feature-xxx ブランチを作成できます。ただし、マージの順序に注意してください。

# 同時に複数の機能を開発 
git checkout dev-cocoa 
git checkout -b feature-auth 

# ... 開発 ... 
git checkout dev-cocoa 
git checkout -b feature-payment 
# ... 開発 ...`

Q3: 緊急のバグ修正はどうすればいいですか?

A: hotfixブランチを使います。

# mainから直接hotfixブランチを作成 
git checkout main 
git pull origin main 
git checkout -b hotfix-critical-bug 

# 修正後 
git add . 
git commit -m "fix: critical bug in authentication" 
git push -u origin hotfix-critical-bug 

# GitLabでMR作成: hotfix-critical-bug → main 
# マージ後、各開発者はmainを取り込む 
git checkout dev-cocoa 
git merge origin/main

Q4: 他の人のコードレビューはどうすればいいですか?

A: GitLab上でMRのコメント機能を使います。

GitLabで対象のMRを開く
Changes タブで差分を確認
気になる行にコメントを追加
Approve または Request changes
必要に応じてディスカッション

Q5: mainへのマージは誰が承認しますか?

A: プロジェクトのルールによりますが、一般的には:

小規模チーム: 開発者同士でレビュー
中規模チーム: テックリード/シニア開発者が承認
大規模チーム: CI/CDでの自動テスト合格 + 2名以上の承認

GitLabの設定で承認ルールを定義できます:

Settings → Repository → Merge request approvals

Q6: コミットメッセージを間違えた場合は?

A: まだpushしていなければ修正可能です。

# 最新のコミットメッセージを修正 
git commit --amend -m "fix: 正しいコミットメッセージ" 

# pushしていない場合は通常通りpush 
git push 

# 既にpushしている場合は強制push（注意！） 
git push --force

⚠️ 警告: --force は他の人の作業に影響するため、個人ブランチでのみ使用してください。

まとめ

このマニュアルでは、 ここあ（dev-cocoa） と サム（dev-sam） が独立して作業し、安全にmainブランチに統合する方法を説明しました。

重要なポイント:

各開発者は自分の dev-<name> ブランチを持つ
機能ごとに feature-<機能名> ブランチを作成
feature → dev-<name> → main の順でマージ
定期的に main の最新を取り込んでコンフリクトを最小化
GitLab上でコミュニケーションを取りながら開発

備忘録にしては長すぎた...

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【永久保存版】初心者向けGit運用マニュアル

Git + GitLab 運用マニュアル

はじめに

対象読者

前提知識

必須スキル

1. 初期セットアップ（新規プロジェクトの場合）

1-1. ローカルリポジトリ作成

1-2. リモートリポジトリとの紐付け

1-3. 初回コミット & push

2. ブランチ運用ルール

ブランチ階層

3. 開発フロー(feature → dev → main)

図解

3-1. 個人開発ブランチの作成

3-2. 機能ブランチ作成

3-3. 機能開発

3-4. GitLabでMR(feature → dev)

3-5. テスト後、MR(dev → main)

3-6. ローカル最新化

4. 運用の注意点

5. 完全フローまとめ(図)

フローの手順:

6. 複数人での並行開発例

7. 複数人での協調開発マニュアル

7-1. 複数開発者のブランチ構造

7-2. ここあの作業フロー（認証機能の開発）

ステップ1: 個人開発ブランチの作成

ステップ2: 機能ブランチの作成（認証機能）

ステップ3: 開発作業

ステップ4: MR作成（feature-user-auth → dev-cocoa）

ステップ5: dev-cocoaでテスト

7-3. サムの作業フロー（ダッシュボード機能の開発）

ステップ1: 個人開発ブランチの作成

ステップ2: 機能ブランチの作成（ダッシュボード機能）

ステップ3: 開発作業

ステップ4: MR作成（feature-dashboard → dev-sam）

7-4. 並行開発の全体像

7-5. mainへの統合

ここあの機能をmainにマージ

サムの機能をmainにマージ

7-6. 複数開発者の作業タイムライン

7-7. コンフリクト解決の例

サムの対応手順

7-8. 他の開発者の作業確認

リモートブランチの確認

他の開発者の進捗確認

他の開発者のブランチをローカルで確認

7-9. 協調開発のベストプラクティス

1. 定期的なmainの取り込み

2. GitLab上でのコミュニケーション

3. ラベルによる進捗管理

4. コミットメッセージの統一

7-10. 複数機能の同時開発例

7-11. 開発フロー チェックリスト

ここあのチェックリスト

サムのチェックリスト

7-12. トラブルシューティング

ケース1: 間違ったブランチにコミットしてしまった

ケース2: pushした後に間違いに気づいた

ケース3: コンフリクトが複雑で解決できない

ケース4: 誤って機能ブランチを削除してしまった

ケース5: リモートとローカルが大きくずれてしまった

7-13. よくある質問（FAQ）

Q1: dev-cocoaとdev-samはいつまで保持すべきですか?

Q2: 複数の機能を同時に開発してもいいですか?

Q3: 緊急のバグ修正はどうすればいいですか?

Q4: 他の人のコードレビューはどうすればいいですか?

Q5: mainへのマージは誰が承認しますか?

Q6: コミットメッセージを間違えた場合は?

まとめ

7-11. 開発フローチェックリスト