Gitを活用したシステム開発のストーリー

2025年2月11日 最終更新日時 : 2025年2月11日 山崎講師山崎講師

第0章：なぜ、Gitが必要なのか？

1. はじめに

Gitは、ソースコードを管理するためのバージョン管理システム（VCS: Version Control System）です。
EclipseでGitを使う前に、基本的な概念を理解しておくとスムーズに作業できます。

バージョン管理は、プログラムや文書などの変更履歴を記録し、いつでも過去の状態に戻せる仕組みです。

バージョン管理でいつでも元に戻せる

2. Gitとは？

Gitは、「分散型バージョン管理システム」です。
ソースコードの変更履歴を記録し、「誰が・いつ・どこを・どのように変更したか」 を追跡できます。

各開発者がローカル環境で作業し、後で変更を統合できます。

誤った変更の修正や、誰がどの部分を編集したかの追跡が可能となり、共同作業の効率と安全性が大幅に向上します。

2.1 Gitの特徴

1．履歴管理

変更履歴を保持し、過去の状態に戻せる

2．分散型

Gitの最大の特徴は分散型であることです。従来の中央集権型（例: SVN）では、1つのサーバーで履歴を管理しますが、Gitは各開発者のローカル環境にリポジトリ全体の履歴を保持します。英語の【Repository】にはもともと倉庫という意味があります。

そうすることで、ネットワーク不要で過去の履歴を確認・変更でき、サーバー障害時でも作業を継続できます。また、ブランチの作成や統合が高速で、開発チームの効率が向上します。


Gitは分散型バージョン管理システム

3．ブランチ機能

Gitのブランチとは、ソースコードの変更を独立して管理できる仕組みです。【Branch】は英語で枝のことですからイメージしやすいと思います。

本流（main）を維持しつつ、新機能開発やバグ修正を別のブランチで行い、完成後に統合（マージ）できます。そうすることで、本番環境を壊さず並行開発が可能になり、チーム開発の効率が向上します。また、ブランチ作成・切り替えが高速で、実験的な開発も手軽に行えます。

ブランチのイメージ

3. Gitの基本概念

Gitでは、「リポジトリ」 という単位でコードを管理します。

3.1 リポジトリ（Repository）

  • Gitで管理されているプロジェクトのこと
  • ローカルリポジトリ（自分のPC内）と リモートリポジトリ（GitHubなど）がある

3.2 ワークフローの3つの領域

Gitでは、ファイルが以下の3つの領域を移動しながら管理されます。

領域役割
ワーキングディレクトリ（作業ディレクトリ）現在作業しているファイル
ステージングエリア（インデックス）コミット前に確認するための一時保存領域
リポジトリ（ローカル）コミット済みの履歴が保存される

流れ：

  1. ファイルを作成・変更 → ワーキングディレクトリ
  2. コミットするファイルを選択 → ステージングエリア　
  3. コミット（確定） → ローカルリポジトリ

第1章：Gitとの出会い

1-1. 新卒エンジニアの入社と開発チームへの配属

202X年4月、新卒エンジニアの 羽生 義人（はぶ ぎっと） は、IT企業 Tech Innovators に入社した。
学生時代にJavaの基礎を学んでいたが、チームでの開発経験はほぼゼロ。期待と不安を抱えながら、最初の配属先である開発チームの会議室に向かった。

「羽生くん、今日から AutoSales Pro の開発チームに参加してもらうよ。」
チームリーダーの 根本 義翔（ねもと よしと） が迎えてくれた。

AutoSales Pro は、自動車販売会社向けの 新車販売Webサイト であり、ユーザーがオンラインで車種を選び、見積もりや購入予約ができる仕組みを開発するプロジェクトだった。

「よろしくお願いします！」
羽生は緊張しながらも、開発に加わることにわくわくしていた。

「まずは開発環境のセットアップから始めよう。Gitの使い方は知ってる？」
根本の問いかけに、羽生は少し戸惑った。

「基本的なコマンドは学んだことがありますが、チーム開発での使い方はよく分かっていません。」

「じゃあ、Gitの基本から学んでいこう。チーム開発には バージョン管理 が欠かせないんだ。」

1-2. Gitとは？バージョン管理の必要性

「Gitは、ソースコードのバージョン管理を行うツール だよ。」
根本は、ホワイトボードに図を描きながら説明を始めた。

「例えば、コードを間違えて消してしまったり、どのファイルが最新なのかわからなくなった経験はあるか？」

「はい…。大学の課題で FinalVersion.java や FinalVersion2.java みたいなファイルが増えてしまって、どれが正しいのか分からなくなったことがあります。」

「それがGitを使うと解決できる。Gitを使えば、コードの変更履歴を記録できるから、過去の状態に戻したり、誰がどこを変更したかを簡単に確認できるんだ。」

羽生は、コードの歴史を記録し、変更を管理できるというGitの重要性を理解し始めた。

「それに、チームで開発していると、誰かが間違ってコードを上書きしてしまうこともある。でもGitを使えば、変更を管理して問題が起きても元に戻せるんだ。」
そう補足したのは、フロントエンド担当の 枝野 美枝（えだの みえ） だった。

「これからは Gitを使ってコードを管理しながら開発する のが基本になるよ。」

1-3. リポジトリのクローンと初めてのコミット

「じゃあ、実際にGitを使ってみよう。」
根本の指示のもと、羽生は AutoSales Pro のリポジトリを GitHub からクローン（コピー）することになった。

GitHubとは？
GitHubは、クラウド上でGitリポジトリを管理できるサービス で、チーム開発ではコードを共有しながら共同作業を行う。

羽生は、ターミナルを開いて以下のコマンドを実行した。

# GitHubリポジトリをクローン（コピー）
git clone git@github.com:tech-innovators/autosales-pro.git

# クローンしたディレクトリに移動
cd autosales-pro

「これで、プロジェクトの最新のコードが自分のPCにコピーされたよ。」

「次に、新しいファイルを作って、Gitで管理する流れを覚えよう。」
羽生は、新しいJavaファイル Test.java を作成し、シンプルなコードを書いた。

public class Test {
    public static void main(String[] args) {
        System.out.println("Hello, Git!");
    }
}

「このファイルをGitに記録するには、まず ステージング（git add） して、コミット（git commit） する必要があるんだ。」

Gitの基本操作

  1. ステージング（git add）
    → 変更を記録対象にする
  2. コミット（git commit）
    → 変更履歴を保存する
  3. プッシュ（git push）
    → GitHubにアップロードする（リモートリポジトリへ）

羽生は、以下のコマンドを実行してGitに変更を記録した。

# 新しいファイルをステージング（変更を記録対象に）
git add Test.java

# 変更をコミット（履歴に保存）
git commit -m "初めてのGitコミット"

git addのオプション

git add は変更をステージングするコマンドです。以下によく使うオプションを紹介します。

主なオプション
  • git add . → すべての変更（新規・変更・削除）を追加
  • git add -A または --all → 削除を含む全変更を追加

「よし、これでGitに記録された。試しに git log を実行してみよう。」

# コミット履歴を確認
git log --oneline

ターミナルに以下のようなログが表示された。

a1b2c3d4 初めてのGitコミット

ハッシュ値について

Gitのログに表示される ハッシュ値（コミットID） は、各コミットを一意に識別する SHA-1 による40桁の16進数です。git log --oneline では先頭7～10桁のみが表示されます。

活用例
  • 特定のコミットに戻る: git checkout <コミットID>
  • 過去の状態にリセット: git reset --hard <コミットID>

ハッシュ値はGitの履歴管理の核心 であり、変更追跡や復元に役立ちます！

「これが、羽生くんの最初のGitの記録だよ。Gitは、すべての変更履歴を記録するので、過去の状態に戻すこともできるんだ。」

羽生は、Gitがコードの変更をしっかり記録していることに感動した。

「過去の状態に戻すって、どういうことですか？」羽生は興味深そうに尋ねた。

「例えば、間違えてコードを変更してしまったとしよう。でも、Gitを使えば、過去の状態に簡単に戻すことができるんだ。試しに変更を加えて、元に戻してみよう。」先輩の春田はそう言って、羽生に次の操作を促した。

「まず、ファイルを編集して変更を加えてみよう。」

羽生は `Test.java` を開き、以下のようにコードを修正した。

public class Test {
    public static void main(String[] args) {
        System.out.println("Hello, Git!!!");
    }
}

「この状態で変更を確認してみよう。」

変更内容を確認

git status

ターミナルには次のようなメッセージが表示された。

変更が検出されました:
(変更あり) Test.java


「この状態で、元のコミットに戻すには git checkout を使う方法があるよ。」

ファイルを元のコミットの状態に戻す

git checkout -- Test.java

「これで Test.java の変更が取り消されたはずだ。確認してみよう。」

羽生がエディタで Test.java を開くと、変更前の状態に戻っていた。

「すごい！本当に元に戻ってる！」

春田は頷きながら続けた。「でも、git checkout は単に作業ディレクトリの変更を元に戻すだけだから、もしすでに git add してしまっていたら、git reset を使う必要がある。」

ステージングした変更を取り消す

git reset HEAD Test.java

「さらに、もしコミットしてしまった場合でも、git reset --hard を使えば、過去の状態に完全に戻せる。」

直前のコミットを取り消して、変更も破棄

git reset --hard HEAD~1

「つまり、Gitでは作業内容を簡単に元に戻せるんだ。だから、安心してコードを書き進められるってわけさ。」

「すごい！これなら、ミスしても怖くないですね！」羽生はGitの便利さに感動した。

1章のまとめ

□ Gitは、コードの変更履歴を管理するツール であり、チーム開発には不可欠

□ GitHubはリモートリポジトリを管理するクラウドサービス で、チームでコードを共有できる

□ 変更をステージング（git add）し、コミット（git commit）して履歴に記録する ことで、安全に開発が進められる

次の章：Gitブランチ戦略を学ぶ

羽生はGitの基本を理解し、次に学ぶのは「ブランチ（branch）」の概念だった。
チームで同じコードをどうやって安全に編集するのか？
羽生のGit学習の旅は、まだ始まったばかりだ！

第2章：Gitブランチ戦略を学ぶ（シンプルなブランチ戦略）

2-1. ブランチとは何か？

羽生 義人（はぶ ぎっと）は、Gitの基本的な操作を学び、プロジェクトのリポジトリをクローンし、初めてのコミットを行った。
次のステップは、ブランチ（branch）を使いこなすこと だった。

「羽生くん、もしチームで同じファイルを同時に編集したら、どうなると思う？」
根本 義翔（ねもと よしと）が問いかける。

「えっと…修正が上書きされて、どちらかの変更が消えてしまうとか？」

「そう、それが起こると困るよね。だから、チーム開発では ブランチ を使うんだ。」

ブランチとは？
「ブランチは、プロジェクトの独立した作業スペースのようなものさ。新しい機能を開発するときに、メインのコードを壊さずに作業するために使う。」

根本はホワイトボードに図を描いた。

main  ---- A ---- B ---- C  ← 安定版（本番）
                 \
                  D ---- E   ← 新機能開発中（ブランチ）

「この D と E が、ブランチで作業した部分だ。こうすることで、メインのコードに影響を与えずに開発が進められる。」

2-2. AutoSales Pro のシンプルなブランチ戦略

「羽生くん、新人エンジニアにはシンプルなブランチ戦略がいいだろう。」
根本は、簡単なルールを説明した。

シンプルなブランチ戦略

  • main（または master）：本番環境の安定したコード。直接変更しない。
  • feature-○○：新機能を開発するためのブランチ（例：feature-search-cars）。
  • fix-○○：バグを修正するためのブランチ（例：fix-bug-123）。

「要は、main を安全に保ちながら、新機能や修正ごとにブランチを作るだけだよ。」

「この方法ならシンプルですね！」
羽生は納得した。

2-3. ブランチの作成と作業の流れ

羽生は feature-search-cars ブランチを作成し、車種検索機能を開発した。

# main ブランチを最新に更新
git checkout main
git pull origin main

# 新しい機能開発用ブランチを作成
git checkout -b feature-search-cars

「この feature-search-cars ブランチの中で、車種検索の機能を開発するんだ。」

羽生は CarSearchService.java に以下のコードを追加した。

public class CarSearchService {
    public void searchCar(String model) {
        System.out.println("🔍 検索結果: " + model);
    }
}

「開発が終わったら、変更を main に統合（マージ）するよ。」

# 変更をGitに記録
git add CarSearchService.java
git commit -m "車種検索機能の追加"

# main ブランチに戻る
git checkout main

# 開発ブランチをマージ
git merge feature-search-cars

# リモートリポジトリに反映
git push origin main

「これで、新機能が main に統合されたよ。」

2-4. マージ時のコンフリクトと解決方法

「でも、ブランチをマージするときに コンフリクト（競合） が発生することがあるんだ。」
根本が説明する。

「コンフリクト？」

「例えば、枝野さんが CarSearchService のデザインを変更して、羽生くんが検索機能を追加したとする。二人の変更を同じファイルに適用しようとすると、Gitは 'どっちを採用すればいいの？' って困るんだ。」

羽生が git merge feature-search-cars を実行すると、ターミナルに "CONFLICT (content): Merge conflict in CarSearchService.java" というメッセージが表示された。

「これがコンフリクトよ。」
枝野 美枝がエディタを開いて見せた。

<<<<<<< HEAD
    public void searchCar(String model) {
        System.out.println("🔍 " + model + " の検索結果を表示します。");
    }
=======
    public void searchCar(String model) {
        System.out.println("検索結果: " + model);
    }
>>>>>>> feature-design-update

「HEAD の部分が羽生くんのコード、feature-design-update の部分が枝野さんのコードね。」

「どうすればいいんですか？」

「開発者が手動で編集して、どちらの変更を採用するか決めるんだ。」

羽生は、最終的に以下のように修正した。

public class CarSearchService {
    public void searchCar(String model) {
        System.out.println("🔍 " + model + " の検索結果を表示します。");
    }
}

その後、以下のコマンドを実行して、コンフリクトを解決した。

git add CarSearchService.java
git commit -m "コンフリクト解決：検索結果のデザインを統一"

「これで解決したね。」
枝野が微笑んだ。

2章のまとめ

□ ブランチは、メインのコードを壊さずに開発を進めるための仕組み

□ シンプルなブランチ戦略では、main feature-○○ fix-○○ の3種類だけを使う

□ マージの際にコンフリクトが発生することがあり、手動で解決する必要がある

次の章：コードレビューとプルリクエスト

羽生は、Gitのブランチ操作に慣れた。次に学ぶのは プルリクエスト（PR）。
チーム開発では、変更をどのようにレビューし、品質を確保するのか？
羽生のGit学習の旅は、さらに続く！

第3章：コードレビューとプルリクエスト（PR）

3-1. プルリクエストとは？

羽生 義人（はぶ ぎっと）は、ブランチを作成し、新機能を main に統合する方法を学んだ。
しかし、チーム開発では、すぐにmain にマージするのではなく、コードレビューを受けるのが一般的 だ。

「羽生くん、開発したコードは必ず プルリクエスト（PR：Pull Request） を作って、他のメンバーに確認してもらおう。」
根本 義翔（ねもと よしと）が説明する。

プルリクエストとは？
「プルリクエストは、'このコードをマージしたいので、確認してください！' というリクエスト なんだ。」
「レビューアーがコードをチェックして、問題がなければマージできる。」

「つまり、誤ったコードが main に入るのを防ぐための仕組みですね。」
羽生は理解を深めた。

3-2. プルリクエストの作成

羽生は feature-search-cars ブランチで作業を終えた。
そこで、GitHub上でプルリクエストを作成する。

# 開発ブランチを最新のリモートリポジトリにプッシュ
git push origin feature-search-cars

GitHubで Pull Request を作成し、以下の内容を記入した。

  • タイトル：「車種検索機能の追加」
  • 説明：「検索機能を追加しました。レビューをお願いします。」
  • レビュアー：枝野 美枝（えだの みえ）、根本 義翔（ねもと よしと）

「この状態で、枝野さんや根本さんがコードをチェックするわけですね。」

3-3. コードレビューの流れ

「じゃあ、レビューを始めようか。」
枝野が Pull Request のページを開く。

コードレビューでは、次の点をチェックする

  1. コードの品質：変数名や関数名が適切か
  2. バグがないか：意図した動作になっているか
  3. 不要なコードがないか：デバッグ用のコードが残っていないか
  4. セキュリティ的に問題がないか

枝野は、CarSearchService.java にコメントを入れた。

「羽生さん、 searchCar() メソッドですが、引数のチェックを入れたほうがいい ですね。
例えば、空の文字列が渡された場合、エラーになりませんか？」

羽生は指摘されたコードを確認した。

public class CarSearchService {
    public void searchCar(String model) {
        System.out.println("🔍 検索結果: " + model);
    }
}

「確かに… null や空文字が渡された場合、何も表示されないですね。」

羽生はコードを修正した。

public class CarSearchService {
    public void searchCar(String model) {
        if (model == null || model.trim().isEmpty()) {
            System.out.println("⚠️ 車種を入力してください。");
            return;
        }
        System.out.println("🔍 " + model + " の検索結果を表示します。");
    }
}

3-4. レビュー後の修正と再プッシュ

修正が終わったら、以下のコマンドで変更を反映する。

git add CarSearchService.java
git commit -m "検索機能のバリデーション追加"
git push origin feature-search-cars

GitHubのプルリクエスト画面では、「修正済みです！」とコメントを残し、再レビューを依頼した。

3-5. プルリクエストの承認とマージ

「いいね。動作確認も問題なし。マージしよう！」
根本が最終確認を終え、プルリクエストを承認した。

羽生はGitHub上で Merge pull request をクリックし、変更が main に統合された。

# mainブランチを最新の状態にする
git checkout main
git pull origin main

「これで main に統合されたよ！」
羽生は、コードがチームの一員として正式にプロジェクトに加わったことを実感した。

3章のまとめ

□ プルリクエストは、コードをマージする前にレビューを依頼する仕組み

□ コードレビューでは、品質やバグ、セキュリティをチェック

□ 指摘を受けたら修正し、再プッシュして確認を受ける

□ 承認後にマージし、main のコードを最新の状態に更新する

次の章：Gitの履歴を活用する

羽生は、プルリクエストの流れを理解した。次に学ぶのは、Gitの履歴を活用する方法。
「過去のコードを確認したり、間違えた変更を元に戻したりできるのか？」
Gitの便利な機能を学び、さらにスキルアップしていく！

第4章：Gitの履歴を活用する

4-1. Gitの履歴を確認する方法

羽生 義人（はぶ ぎっと）は、プルリクエストの流れを理解し、チーム開発でのコード管理に慣れてきた。
しかし、開発を進めていく中で、「過去のコードに戻したい」「誰がどんな変更を加えたのか確認したい」 という場面が増えてきた。

「羽生くん、Gitは すべての変更履歴を記録している んだ。」
根本 義翔（ねもと よしと）が説明する。

「間違えてコードを変更してしまったり、誰かの修正を確認したいときに履歴を活用すると便利だよ。」

4-2. git log で履歴を確認する

「まずは、これまでの履歴を確認してみよう。」
羽生は git log を実行した。

git log

ターミナルには、過去のコミット履歴が表示された。

commit 3a5f9e2d83f3 (HEAD -> main)
Author: Habu Gitto <habu@example.com>
Date: 202X-04-15 10:30:00

車種検索機能の追加

commit 2b7e3f8a1c9d
Author: Edano Mie <edano@example.com>
Date: 202X-04-14 16:20:00

UIデザインの修正

commit 1a4d5c7b9e2f
Author: Nemoto Yoshito <nemoto@example.com>
Date: 202X-04-10 09:10:00

初回コミット

「この git log を使うと、過去にどんな変更が行われたのか を確認できるんだ。」

「でも、これだと情報が多すぎて見づらいですね。」
羽生は、git log のオプションを試すことにした。

git log --oneline --graph --all

すると、以下のようにコンパクトで見やすいログが表示された。

* 3a5f9e2 (HEAD -> main) 車種検索機能の追加
* 2b7e3f8 UIデザインの修正
* 1a4d5c7 初回コミット

「--oneline をつけると、1行で簡潔に表示できるよ。」

「--graph をつけると、ブランチの分岐も確認しやすくなる。」

4-3. git blame で変更の責任者を確認する

「羽生くん、もし CarSearchService.java の searchCar() メソッドを誰が修正したのか確認したい 場合はどうする？」
根本が尋ねる。

「…履歴を一つずつ確認するんですか？」

「そんなことしなくても、git blame を使えば、各行の変更者と日時がすぐに分かる よ。」

羽生は、以下のコマンドを実行してみた。

git blame src/main/java/com/autosales/CarSearchService.java

すると、各行の左側に、変更した人の名前と日時が表示された。

3a5f9e2d (Habu Gitto 202X-04-15 10:30:00) public class CarSearchService {
3a5f9e2d (Habu Gitto 202X-04-15 10:30:00) public void searchCar(String model) {
2b7e3f8a (Edano Mie 202X-04-14 16:20:00) System.out.println("🔍 " + model + " の検索結果を表示します。");
3a5f9e2d (Habu Gitto 202X-04-15 10:30:00) }

「なるほど！ git blame を使えば、どのコードを誰がいつ変更したのか が一目で分かりますね。」

「うん、コードレビューやデバッグで便利だから、ぜひ覚えておいて。」

4-4. git checkout で過去のバージョンに戻す

「でも、もし最新の変更でバグが発生したらどうします？」
羽生が疑問を投げかけた。

「その場合は、過去のバージョンに戻して確認するといいよ。」

例えば、一つ前のコミットに戻るには、以下のコマンドを使う。

git checkout 2b7e3f8a1c9d

「すると、2b7e3f8a1c9d の状態にファイルが戻る。」

「ただし、このままだと detached HEAD という状態になってしまうから、戻したい場合は新しいブランチを作るのがいい。」

git checkout -b debug-version 2b7e3f8a1c9d

「これで debug-version というブランチが作成され、過去の状態で作業を続けられるよ。」

4-5. git revert でコミットを取り消す

「じゃあ、間違えて main にマージしてしまった場合は？」

「その場合は、git revert を使うと安全に元に戻せる。」

例えば、最新のコミット 3a5f9e2d を取り消したい場合は、次のコマンドを実行する。

git revert 3a5f9e2d

すると、新たなコミットが作成され、変更が取り消された。

「git revert は、過去のコミットを完全に削除するのではなく、新たな変更として取り消しを記録するから、安全に使えるんだ。」

4-6. git reset で履歴を巻き戻す（注意！）

「git reset を使えば、もっと強力に履歴を戻すこともできるけど、使い方を間違えると危険 だから慎重にね。」

例えば、最新のコミット 3a5f9e2d を 完全に消したい 場合は、以下のコマンドを使う。

git reset --hard 2b7e3f8a1c9d

「これを実行すると、3a5f9e2d 以降のコミットが完全に削除されてしまう から注意が必要だよ。」

4章のまとめ

□ git log で過去の履歴を確認できる（--oneline --graph で見やすく）

□ git blame で、各行の変更者を確認できる

□ git checkout で過去のバージョンに戻せる（ブランチ作成推奨）

□ git revert で安全にコミットを取り消せる

□ git reset は強力な巻き戻し機能だが、慎重に使用する

次の章：チーム開発におけるGitの運用

羽生は、Gitの履歴を活用する方法を学んだ。
次に学ぶのは、実際のチーム開発でGitをどのように運用していくか。
運用ルールを学び、プロジェクトをスムーズに進めていこう！

第5章：チーム開発におけるGitの運用

5-1. Gitをスムーズに運用するためのルール

羽生 義人（はぶ ぎっと）は、Gitの基本操作や履歴管理を学び、実際にプロジェクトで活用し始めていた。
しかし、チーム開発では 「個人が自由にGitを使えばいい」というわけではない。

「羽生くん、チーム開発では 統一されたルールを決める ことが大事なんだ。」
根本 義翔（ねもと よしと）がホワイトボードにいくつかのルールを書いた。

Git運用の基本ルール

  1. main に直接コミットしない
  2. 必ずブランチを作成して開発する（feature-○○ や fix-○○）
  3. コミットメッセージを分かりやすく書く
  4. プルリクエスト（PR）を作成し、レビューを受けてからマージする
  5. 定期的にmainの最新状態を取得する
  6. チーム内でのコンフリクトを防ぐために、小さな単位でコミットする

「なるほど…。個人で好きにGitを使うのではなく、チームで統一した使い方をする のが大事なんですね。」

5-2. main に直接コミットしない理由

「例えば、羽生くんが main に直接コミットしたらどうなると思う？」
根本が質問する。

「うーん…すぐに反映されてしまうので、もしバグがあったら、プロジェクト全体に影響が出るかも…？」

「その通り！だから、必ず 新しいブランチを作って作業する んだ。」

# main の最新状態を取得
git checkout main
git pull origin main

# 新しい機能のためのブランチを作成
git checkout -b feature-new-function

「このように feature-new-function のようなブランチで作業を進め、完成したらPRを出してレビューを受ける のがルールだ。」

5-3. コミットメッセージのルール

「次に、コミットメッセージ について説明しよう。」
枝野 美枝（えだの みえ）が補足する。

「適当に 修正 とか 変更 みたいなメッセージを入れるのはダメですよ。」

「えっ？でも、つい適当に書いてしまいそうです…。」
羽生が苦笑する。

「チームで開発していると、過去の変更を調べることがある。
そのときに、分かりやすいコミットメッセージ を書いておくと役立つの。」

良いコミットメッセージの例

git commit -m "検索機能にバリデーションを追加（空入力を防止）"
git commit -m "購入履歴画面のUIを修正（ボタンの配置変更）"

悪いコミットメッセージの例

git commit -m "修正"
git commit -m "変更した"

「なるほど…。何を変更したのか、すぐ分かるように書くんですね！」

5-4. main の最新状態を定期的に取得する

「次に、定期的にmain の最新状態を取得すること も重要だよ。」

「例えば、羽生くんが feature-search-cars で作業を進めている間に、別の人が main に変更を加えていたらどうなる？」

「えっと…僕の作業が main の最新の変更を含んでいないことになりますね。」

「その通り！だから、作業中でも定期的に main の変更を取り込むんだ。」

# main ブランチに移動
git checkout main

# 最新の状態を取得
git pull origin main

# 作業中のブランチに戻る
git checkout feature-search-cars

# main の変更を取り込む
git merge main

「こうすれば、常に最新の状態で作業を続けられる。」

5-5. チーム内でのコンフリクトを防ぐための運用ルール

「最後に、コンフリクトを防ぐためのルール について説明しよう。」
根本が話を続ける。

「羽生くん、ブランチをマージするときにコンフリクトが発生したことがあるよね？」

「はい… CarSearchService.java で競合が起きました。」

「コンフリクトを防ぐためには、次のルールを守るといいよ。」

コンフリクトを防ぐルール

  1. 定期的に main の最新状態を取り込む（git merge main）
  2. 1つのファイルを同時に複数人で編集しない（担当を分ける）
  3. こまめにコミットし、変更を小さくする

「例えば、羽生くんと枝野さんが 同じファイルの同じ部分 を同時に編集したら、コンフリクトが起こりやすくなる。」

「だから、機能ごとに担当を分ける ことも大事なんだ。」

「なるほど…。無計画に変更すると、後で大変になるんですね。」

5章のまとめ

□main に直接コミットせず、必ずブランチを作成して作業する

□ 分かりやすいコミットメッセージを心がける

□ 定期的に main の最新状態を取得し、作業ブランチに取り込む

□ コンフリクトを防ぐために、変更を小さく、担当を分ける

次の章：Gitを活用した効率的な開発フロー

羽生は、チーム開発でのGitの運用ルールを理解した。
次に学ぶのは、効率的な開発フローの実践。
Gitを活用して、どのように開発をスムーズに進めるのか？
羽生の学習は続く！

第6章：Gitを活用した効率的な開発フロー

6-1. 効率的な開発フローとは？

羽生 義人（はぶ ぎっと）は、Gitの基本操作やチーム開発での運用ルールを学び、少しずつ実践できるようになってきた。
しかし、実際の開発現場では、効率的にGitを使いながら、スムーズに開発を進めることが求められる。

「羽生くん、Gitの操作に慣れてきたところで、実際の開発フロー を学んでみよう。」
根本 義翔（ねもと よしと）が話を切り出した。

「開発フローとは、チームがどのような流れでコードを管理し、開発を進めるかの手順 のことだよ。」

「なるほど…。チーム全体で統一された流れがあるんですね。」

「そう！適切な開発フローを作ることで、作業の重複やコンフリクトを減らし、効率的に開発を進めることができる んだ。」

6-2. シンプルな開発フローの流れ

「初心者でも理解しやすい シンプルな開発フロー を説明しよう。」

① main ブランチを最新の状態にする

git checkout main
git pull origin main

② 作業用のブランチを作成

git checkout -b feature-新機能名

③ コードを編集し、変更をコミット

git add .
git commit -m "新機能の追加"

④ 変更をGitHubにプッシュ

git push origin feature-新機能名

⑤ プルリクエスト（PR）を作成し、レビューを依頼
GitHub上でプルリクエストを作成し、他のメンバーにレビューを依頼。

⑥ レビュー後、修正が必要なら修正し、再プッシュ

git add .
git commit -m "レビューの指摘を反映"
git push origin feature-新機能名

⑦ 問題がなければ main にマージ

git checkout main
git merge feature-新機能名
git push origin main

「この流れを守れば、開発がスムーズに進むはずだよ。」

6-3. 1日の作業の流れ（具体例）

羽生は、「車の価格フィルター機能」 を開発することになった。

【午前】作業開始

1．main の最新状態を取得

git checkout main
git pull origin main

2．新しいブランチを作成

git checkout -b feature-filter-price

3．CarSearchService.java に価格フィルター機能を追加

public class CarSearchService {
    public void searchCar(String model, int maxPrice) {
        System.out.println("🔍 " + model + " の検索結果（最大価格: " + maxPrice + " 円）");
    }
}

【午後】コミット＆プッシュ

4．変更をコミット

git add CarSearchService.java
git commit -m "価格フィルター機能の追加"

5．GitHubにプッシュ

git push origin feature-filter-price

【夕方】レビュー＆修正

6．GitHubでプルリクエストを作成し、根本と枝野にレビューを依頼

7．枝野から「価格のバリデーションが必要では？」と指摘

8．修正を行い、再コミット＆プッシュ

public class CarSearchService {
    public void searchCar(String model, int maxPrice) {
        if (maxPrice <= 0) {
            System.out.println("⚠️ 価格は正の値を指定してください。");
            return;
        }
        System.out.println("🔍 " + model + " の検索結果（最大価格: " + maxPrice + " 円）");
    }
}

git add CarSearchService.java
git commit -m "価格のバリデーションを追加"
git push origin feature-filter-price

【夜】マージ

9．再レビューで問題なし→ main にマージ

git checkout main
git merge feature-filter-price
git push origin main

10．feature-filter-price ブランチを削除

git branch -d feature-filter-price
git push origin --delete feature-filter-price

6-4. 開発フローを円滑に進めるポイント

「羽生くん、ここまでの流れを実践すれば、スムーズに開発できるよ。」
根本が、開発フローをスムーズにするためのポイント を教えてくれた。

開発フローをスムーズに進めるポイント

✅ 1つのブランチでは、1つの機能だけを実装する（ブランチを小さく保つ）
✅ こまめに main の最新状態を取り込み、コンフリクトを防ぐ
✅ コミットはできるだけ小さく、分かりやすいメッセージをつける
✅ プルリクエストでは、簡潔に「何を変更したか」を記載する
✅ レビューの指摘には迅速に対応し、チームと協力する

「このルールを意識すれば、Gitの運用がもっとスムーズになるよ！」

6章のまとめ

□ シンプルな開発フローを確立すると、開発が効率的に進む

□ 1日の作業の流れとして、「ブランチ作成→開発→プルリクエスト→マージ」の手順を守る

□ 開発フローを円滑にするポイントを意識することで、Gitの管理が楽になる

次の章：トラブルシューティング（Gitで困ったときの対処法）

羽生は、開発フローを理解し、スムーズにGitを活用できるようになった。
しかし、実際の開発では 「間違えてファイルを削除してしまった」「コミットをやり直したい」 など、トラブルが発生することもある。
次の章では、Gitでよくある問題の対処法 を学び、より実践的なスキルを身につけていく！

第7章：Gitで困ったときのトラブルシューティング

7-1. Gitでよくあるトラブルとは？

羽生 義人（はぶ ぎっと）は、Gitの基本操作や開発フローを学び、少しずつ実践できるようになってきた。
しかし、開発を進める中で 「間違えてファイルを削除してしまった！」「コミットをやり直したい！」 という場面に直面することも増えてきた。

「羽生くん、Gitを使っていると、トラブルに遭遇することもある。でも、Gitには トラブルを解決するためのコマンド が用意されているんだ。」
根本 義翔（ねもと よしと）が説明する。

「よくあるトラブルと、その対処法を覚えておこう。」

7-2. 間違えて変更をリセットしたい (git checkout / git restore)

📌 ケース1：編集途中のファイルを元に戻したい

誤ってコードを変更してしまい、最初の状態に戻したいとき

git restore ファイル名

例：

git restore src/main/java/com/autosales/CarSearchService.java

git restore は、ステージングされていない変更を元に戻すときに使う。

7-3. 間違えてコミットした (git reset / git revert)

📌 ケース2：直前のコミットをやり直したい

間違えてコミットしてしまった場合

git reset --soft HEAD~1

--soft をつけると、コミットは取り消されるが、変更はそのまま残る。
すぐに修正して、再コミットできる。

📌 ケース3：コミットを取り消して、履歴にも残さない

git reset --hard HEAD~1

⚠️ このコマンドは危険！ 履歴が完全に消えるため、慎重に使うこと。

📌 ケース4：過去のコミットを取り消す（安全な方法）

git revert コミットID

例：

git revert 3a5f9e2d

git revert は、新たな「取り消しコミット」を作るため、履歴が安全に残る。

7-4. マージでコンフリクトが発生 (git merge の解決方法)

📌 ケース5：マージ時のコンフリクトを解決

マージしたとき、以下のようなエラーが出ることがある。

CONFLICT (content): Merge conflict in CarSearchService.java

この場合、エディタを開いてコンフリクトを解決し、以下のコマンドを実行。

git add ファイル名
git commit -m "コンフリクトを解決"

7-5. うっかりファイルを削除した (git restore で復元)

📌 ケース6：誤って削除したファイルを元に戻す

git restore --staged ファイル名

例：

git restore --staged src/main/java/com/autosales/CarSearchService.java

もし git restore で戻らない場合は、 git checkout を試す。

git checkout HEAD -- ファイル名

7-6. 他のブランチの最新の状態を取得 (git pull の注意点)

📌 ケース7：git pull で競合が発生した場合

error: Your local changes to the following files would be overwritten by merge:

このエラーが出た場合、変更を一時的に退避（stash）する。

git stash
git pull origin main
git stash pop

7-7. 変更を一時的に退避 (git stash)

📌 ケース8：作業途中で、別のブランチに切り替えたい

未コミットの変更がある状態で、別の作業をする必要が出た場合、git stash で変更を一時保存 できる。

git stash
git checkout main
git pull origin main

作業を再開するときは git stash pop を実行。

git stash pop

7-8. 間違えてリモートリポジトリにプッシュした (git push --force の危険性)

📌 ケース9：間違えてプッシュしたコミットを取り消す

誤ってリモートにプッシュしてしまった場合、git reset で戻してから git push --force する。

git reset --hard HEAD~1
git push --force

⚠️ --force は注意して使う！ 他の人の作業が消えてしまう可能性があるため、基本的には使用しない。

7章のまとめ

7章のまとめ

□ 変更をリセットする場合は git restore を使う

□ 間違えてコミットしたら git reset --soft HEAD~1

□ 安全に過去のコミットを取り消すには git revert

□ マージのコンフリクトが発生したら、手動で修正して git add

□ 削除したファイルは git restore で復元できる

□ 未コミットの変更を一時的に退避するには git stash

□ リモートリポジトリの変更を上書きする git push --force は慎重に使う

セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク

投稿者プロフィール

山崎講師
山崎講師代表取締役
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
海外放浪の末、2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。

学生時代は趣味と実益を兼ねてリゾートバイトにいそしむ。長野県白馬村に始まり、志賀高原でのスキーインストラクター、沖縄石垣島、北海道トマム。高じてオーストラリアのゴールドコーストでツアーガイドなど。現在は野菜作りにはまっている。
対象読者
新入社員
前の記事
IT導入補助金をフリーランスの講師向けに解説
2025年2月10日
次の記事
Webページを公開しながらGitコマンドとGitHubを学ぶ
2025年2月12日