🐙

Git再入門：内部構造からチーム開発の実践まで

に公開
Git
GitHub
初心者
バージョン管理
tech

はじめに

この記事は、Gitの基本的なコマンドは知っているものの、その裏側にある仕組みやチーム開発における効果的な使い方を体系的に学びたいエンジニアを対象としています。

Gitの「なぜそう動くのか？」という内部構造の理解から始め、GitHub Flowに沿った実践的な開発サイクル、そして状況に応じたブランチ戦略の比較まで、豊富な図解と共に一気通貫で解説します。この記事を読み終える頃には、日々の業務で自信を持ってGitを扱えるようになっていることを目指しました。

1. Gitの基本概念と内部構造

Gitを効果的に使うための基礎となる考え方を構築します。本セクションでは、Gitの環境を構成要素に分解し、その設計思想を解説します。これにより、エンジニアが日々の業務でGitを扱う際の地図を提供します。

1.1. Git: 分散バージョン管理システム

Gitは分散バージョン管理システム（DVCS）です。これは、すべてのバージョン履歴を単一の中央サーバーに保存するSubversion（SVN）のような中央集権型バージョン管理システム（CVCS）とは異なります。Gitでは、各開発者がプロジェクトの完全な履歴を含むリポジトリ全体のコピーを、自身のローカルマシン上に保持します。

この分散アーキテクチャには、主に2つの利点があります。

  • オフラインでの作業: コミットやブランチ作成など、ほとんどの操作はローカルで完結するため、ネットワーク接続を必要としません。
  • 高い回復力: 各開発者が完全なバックアップを持つため、中央サーバーに障害が発生しても、いずれかの開発者のローカルリポジトリから復元できます。

以下の図は、中央集権型と分散型のモデルの違いを示します。

モデル 説明
中央集権型 VCS 全ての開発者が単一の中央サーバーに対して直接やり取りするモデル
分散型 VCS 各開発者が自身のローカルリポジトリを持ち、リモートリポジトリを介して変更を同期するモデル

Gitの分散モデルは、現代のソフトウェア開発に不可欠な柔軟性とコラボレーションの基盤です。

1.2. 4つの領域：コードが移動する道のり

Gitを理解する上で最も重要な概念は、コードが存在し移動する4つの主要な領域です。これらの領域は、開発者が変更を管理し、追跡可能なクリーンな履歴を作成するための枠組みを提供します。

領域名 説明
ワーキングツリー ファイルを編集する、ローカルファイルシステム上のディレクトリ。作業台に相当。
インデックス (ステージングエリア) 次のコミットに含める変更のスナップショットを保持する中間領域。変更の準備エリア。
ローカルリポジトリ プロジェクト内の.gitディレクトリ。すべてのコミットとプロジェクトの全履歴をローカルに保存。
リモートリポジトリ サーバー（例: GitHub）上でホストされるプロジェクトのバージョン。チームで共有する信頼できる情報源。

以下の図は、4つの領域間の関係と、領域間で変更を移動させる主要なコマンドを示します。

ワーキングツリー、インデックス、ローカルリポジトリの3つの領域を分離することは、Gitの核となる思想です。これにより、クリーンでアトミックなコミットを作成できます。開発者は、ワーキングツリーで複数のファイルを変更しても、git addコマンドで特定の変更だけをインデックスに登録できます。インデックスを「次のコミットの草稿」として精密に作り上げることで、アトミックなコミット（小さく、自己完結した変更）の作成を促進します。アトミックなコミットは、レビューや取り消しが容易で、保守性の高いソフトウェア履歴の礎となります。

1.3. コミット：特定時点のスナップショット

Gitのコミットは差分ではなく、特定の時点におけるプロジェクト全体のスナップショットです。各コミットは、その内容から計算される一意のSHA-1ハッシュ値を持ち、一つ以上の親コミットを指します。この親子関係が連鎖し、プロジェクトの履歴全体が有向非巡回グラフ（DAG）と呼ばれる構造を形成します。

このスナップショット方式のモデルにより、ブランチの作成やマージといった操作を非常に高速かつ効率的に実行できます。

上の図は、コミットがどのように連なっているかを示します。各コミット（円）は親コミットへのポインタを持ち、直線的な履歴を形成します。mainのようなブランチは、特定のコミットを指す軽量なポインタに過ぎません。

2. GitHub Flowによる実践的ワークフロー

GitHub Flowをフレームワークとして、最も一般的な開発サイクルを段階的に解説します。各コマンドと概念を視覚的に理解できる、実践的なチュートリアルです。

2.1. リポジトリのセットアップ

開発の最初のステップは、コードリポジトリをローカルマシンに準備することです。これには主に2つのシナリオがあります。

git init: 新規プロジェクトの開始

ローカルで新しいプロジェクトを開始する場合、git initコマンドを使います。これにより、現在のディレクトリに新しい.gitサブディレクトリが作成され、空のGitリポジトリが初期化されます。

mkdir my-new-project
cd my-new-project
git init

git clone: 既存リポジトリの複製

GitHubなどのリモートサーバーに存在するリポジトリを複製する場合は、git cloneコマンドを使います。このコマンドは、リポジトリをダウンロードするだけでなく、以下の重要な設定を自動的に行います。

  1. プロジェクトの全履歴を含むローカルリポジトリ（.gitディレクトリ）を作成
  2. デフォルトブランチ（通常はmain）のワーキングツリーをチェックアウト
  3. リモートリポジトリをoriginという名前で登録
  4. リモートリポジトリの各ブランチに対応するリモート追跡ブランチ（例: origin/main）を作成

git clone https://github.com/example/repository.git
cd repository

git cloneはリモートリポジトリを複製し、ローカルにmainブランチとリモート追跡ブランチorigin/mainの両方を作成します。

2.2. 機能開発：ブランチの活用

GitHub Flowの核となる原則は、新しい機能開発やバグ修正のたびに新しいブランチを作成することです。これにより、作業をmainブランチから隔離し、本番環境にデプロイ可能なコードベースを常に安定させます。

ブランチ名は、その作業内容を明確に示す、説明的な名前を推奨します（例: feature/user-profile, fix/login-bug）。

  • git branch <branch-name>: 現在のコミットを指す新しいブランチを作成
  • git checkout <branch-name>: HEADポインタを指定ブランチに移動させ、ワーキングツリーを更新して作業ブランチを切り替え
  • git checkout -b <branch-name>: ブランチ作成とチェックアウトを一度に実行

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

# 新しい機能ブランチを作成して切り替え
git checkout -b feature/user-profile

以下の図は、mainブランチからfeature/user-profileブランチが作成され、HEADが新しいブランチに移動した状態を示します。

2.3. ステージングとコミット：進捗の記録

機能ブランチでの作業の変更を記録するプロセスがコミットです。Gitでは、このプロセスを「ステージング」と「コミット」の2段階に分けます。

  • git status: ワーキングツリーとインデックスの状態を確認
  • git diff: ワーキングツリー内のまだステージングされていない変更内容を表示
  • git diff --staged: インデックスにステージングされ、次にコミットされる内容を表示
  • git add <file>: ワーキングツリーの変更をインデックス（ステージングエリア）に移動
  • git commit -m "Your message": インデックスのスナップショットをローカルリポジトリの履歴に永続的に保存

変更からコミットまでの流れ

  1. ファイル変更後
    git statusは変更されたファイル（user.js）をChanges not staged for commitとして表示します。

  2. git add実行後
    git add user.jsを実行すると、変更がインデックスに移動します。git statusはChanges to be committedとして表示します。

  3. git commit実行後
    git commitを実行すると、インデックスのスナップショットが新しいコミットとしてリポジトリに保存されます。

2.4. コラボレーション：リモートとの同期

ローカルでの作業をチームと共有するには、リモートリポジトリとの同期が必要です。この仕組みを理解する鍵は、「リモート追跡ブランチ」をキャッシュとして捉えることです。

コマンド / 要素 説明
リモート追跡ブランチ リモートリポジトリの状態をローカルに反映する読み取り専用の参照 (origin/main など)。リモートの状態の「キャッシュ」と考えることができます。
git push ローカルブランチのコミットをリモートリポジトリにアップロードします。
git fetch リモートから新しいデータをダウンロードし、リモート追跡ブランチを更新します。ローカルの作業ブランチには影響を与えません。
git pull git fetchとgit mergeを連続して実行するコマンド。リモートの最新状態を取得し、現在のローカルブランチに統合（マージ）します。

リモート操作の図解

  1. git push
    ローカルのfeatureブランチでの作業が進み、リモートにはまだ存在しないコミット(c4, c5)があるとします。下の図は、まさにそのpush直前の状態を示しています。ローカルのfeatureはc5を、リモート追跡ブランチorigin/featureはc3を指しています。

    ここで git push origin feature を実行すると、c4とc5のコミットがリモートリポジトリにアップロードされ、リモート追跡ブランチorigin/featureのポインタもc5に移動します。

  2. git fetch
    チームの他のメンバーがmainブランチに新しいコミットをプッシュした状況を考えます。fetch前のローカルではorigin/mainは古いコミットを指しています。

    • ローカルリポジトリ

    • リモートリポジトリ

    git fetchを実行すると、リモートリポジトリの最新情報がダウンロードされ、リモート追跡ブランチ（origin/main）だけが更新されます。

    • ローカルリポジトリ

    リモートの変更（c3, c4, c5）がダウンロードされ、origin/mainのポインタがc5に移動しました。重要なのは、ローカルのmainブランチはc2を指したままで、一切変更されていない点です。これにより、ローカルの作業に影響を与えることなく、安全にリモートの進捗を確認できます。

  3. git pull
    git pullは、git fetch（リモート内容の取得）とgit merge（ローカルブランチへの統合）を連続して行うコマンドです。
    fetchによってorigin/mainが更新された後、その変更が現在のローカルブランチ（main）にマージされます。これにより、新しいマージコミットが作成される場合があります。

2.5. 統合：プルリクエストとマージ

機能開発が完了したら、GitHubの場合Pull Request（PR）を、GitLabの場合Merge Request（MR）を作成します。これは、あるブランチを別のブランチ（通常はmain）にマージすることを依頼するもので、コードレビューの場となります。

PRが承認されると、GitHub内で機能ブランチをmainブランチにマージします。内部的には以下のコマンドと同等のことが行われます。

  1. mainブランチに切り替える
    git checkout main
  2. リモートの最新の状態に更新する
    git pull origin main
# ※PRマージの内部処理では、自身がリモートリポジトリなので、pullしない。
  3. 機能ブランチをマージする
    git merge feature/user-profile
  4. マージ結果をリモートにプッシュする
    git push origin main
# ※PRマージの内部処理では、自身がリモートリポジトリなので、pushしない。
  5. 不要になった機能ブランチを削除する
    git branch -d feature/user-profile
git push origin --delete feature/user-profile
# ※PRマージの内部処理では、自身がリモートリポジトリなので、pushしない。

以下の図は、feature/user-profileブランチがmainブランチにマージされ、新しいマージコミットが作成される様子を示します。

2.6. 4つの領域とブランチのつながり

Gitでは、リモートリポジトリ／ローカルリポジトリ／インデックス／ワーキングツリーの4つの領域の中を、ブランチごとに連携して開発が進みます。各領域がどの状態にあるかを把握できれば、 「今、どのブランチがどこまで進んでいるのか」 を正確に理解でき、チームのブランチ戦略に沿った適切なアクションが取れるようになります。

3. 発展的なブランチ戦略の比較

GitHub Flowは多くのプロジェクトで有効ですが、要件によってはより構造化されたワークフローが必要になる場合があります。ここでは主要な3つのブランチ戦略を比較し、それぞれの長所、短所、最適なシナリオを分析します。

リリース戦略をまず定義し、次にそれをサポートするブランチモデルを選択することが、適切なワークフローを導入する鍵となります。

3.1. GitHub Flow: 継続的デリバリー

  • 概要: シンプルでアジャイルなワークフロー

  • ブランチ戦略:

    • mainブランチは常にデプロイ可能な状態を維持
    • 機能ブランチはmainから作成し、レビュー後にmainへマージ
    • 長期的なdevelopやreleaseブランチは存在しない

  • 長所:

    • シンプルで習得が容易
    • 高速なイテレーションを促進
    • CI/CD（継続的インテグレーション/継続的デリバリー）との親和性が高い

  • 短所:

    • 複数のバージョンサポートや、厳格なリリースサイクルを持つプロジェクトには不向きな場合がある

  • 図解:

3.2. Git Flow: 構造化されたリリースモデル

  • 概要: Vincent Driessenによって提唱された、構造化されたワークフロー

  • ブランチ戦略: 複数の長期ブランチが特定の役割を担う

    • main: 安定した本番リリースの履歴のみを保持
    • develop: すべての機能開発を統合する主要ブランチ
    • feature/*: developから分岐し、developにマージ
    • release/*: developから分岐し、mainとdevelopにマージ
    • hotfix/*: mainから分岐し、mainとdevelopにマージ

  • 長所:

    • 定期的なバージョンリリースの管理に優れる
    • 本番ブランチの安定性を最大限に確保
    • 役割分担が明確

  • 短所:

    • 複雑で、開発サイクルを遅らせる可能性がある
    • 継続的デリバリーには過剰装備
    • 複数のreleaseブランチを運用すると、マージの運用がかなり複雑

  • 図解:

3.3. GitLab Flow: 柔軟な中間案

  • 概要: GitHub FlowのシンプルさとGit Flowの構造性を組み合わせた実用的な折衷案

  • ブランチ戦略: プロジェクトのニーズに応じた2つのバリエーション

    1. 環境ブランチ: stagingやproductionなど、デプロイ環境に対応する長期ブランチを使用
    2. バージョンブランチ: 1-5-stableや2-0-stableなど、複数のバージョンをサポートするため長期ブランチを使用

  • 長所:

    • Git Flowより柔軟で、GitHub Flowにはない明確なデプロイステージを提供
    • 課題追跡システムとの統合が強力

  • 短所:

    • 多くの環境ブランチを使用すると複雑になる可能性がある

  • 図解 (環境ブランチ):

3.4. 戦略の比較

特徴 GitHub Flow Git Flow GitLab Flow
複雑さ 低 高 中
主な用途 継続的デリバリー、Webアプリ 定期的なバージョンリリース ステージング環境でのデプロイ、バージョン保守
主要ブランチ main, feature main, develop, feature, release, hotfix main, feature, + 環境 or バージョンブランチ
CI/CD適合性 非常に高い 難しい 高い
最適なチーム 強力な自動化を持つチーム 厳格なリリースサイクルを持つ大規模チーム アジリティと統制のバランスが必要なチーム

4. 日常業務で役立つGitコマンドリファレンス

日常業務で役立つ強力なGitコマンドを、具体的なシナリオ、コマンド構文、そして効果を視覚化する図と共に解説します。

4.1. コミット履歴の整理

git pull --rebase

  • シナリオ: リモートの変更を取り込む際に、不要なマージコミットを作成せず、ローカルの変更をリモートの変更の先端に再配置して、直線的な履歴を保ちたい場合。
  • コマンド: git pull --rebase
  • 解説: この操作後、ローカルのコミットは新しいコミットとして再作成されるため、コミットハッシュが変わります。
  • 図解:

    • 通常の git pull (マージコミットが作成される)

    • git pull --rebase (直線的な履歴を維持)

git merge --squash

  • シナリオ: 機能ブランチの細かな「作業中」コミットを一つにまとめ、mainブランチに意味のある単一のコミットとして統合したい場合。
  • コマンド: git merge --squash <feature-branch>
  • 図解:

    • Squash前:

    • Squash後: (mainブランチでコマンド実行後、コミットする)

4.2. 特定の変更の適用

git cherry-pick

  • シナリオ: あるブランチの特定のコミット（例: 重要なバグ修正）だけを、別のブランチにも適用したい場合。

  • コマンド: git cherry-pick <commit-hash>

  • 図解: release-1.0ブランチのコミットCをmainブランチに適用します。

4.3. 作業の書き換えと取り消し

git reset

  • シナリオ: まだリモートにプッシュしていないローカルのコミットを取り消したい場合 (注意: チームで共有しているブランチでは絶対に使用しないでください)。
  • コマンド:
    • git reset --soft HEAD~1: コミットのみを取り消し、変更はステージングされたまま残す。
    • git reset --mixed HEAD~1 (デフォルト): コミットとステージングを取り消し、変更はワーキングツリーに残す。
    • git reset --hard HEAD~1: コミット、ステージング、ワーキングツリーの変更をすべて破棄する。
  • 図解 (--hardの例): git reset --hard HEAD~1 を実行すると、mainブランチの先端がコミットCからBへ移動します。

    • Reset前:

    • Reset後:

git revert

  • シナリオ: 既にリモートにプッシュした共有ブランチ上のコミットを、安全に取り消したい場合。

  • コマンド: git revert <commit-hash>

  • 解説: resetが履歴を書き換えるのに対し、revertは指定したコミットの変更を打ち消す新しいコミットを作成します。これにより、共有履歴を安全に修正できます。

  • 図解: コミットBを打ち消す新しいコミットRevert Bが作成されます。

4.4. 作業の一時退避

git stash

  • シナリオ: 現在の作業が中途半端だが、緊急の修正のために別のブランチに切り替える必要がある場合。コミットしたくない変更を一時的に退避させたい時に使用します。

  • コマンド:

    • git stash push -m "message": 変更をスタックに退避。
    • git stash list: 退避した作業の一覧を表示。
    • git stash pop: 最新の退避作業を復元し、スタックから削除。

  • 図解:

4.5. 履歴の調査

git reflog

  • シナリオ: git reset --hardで誤ってコミットを消した場合など、「失われた」作業を回復したい場合。reflogはHEADのすべての動きを記録したローカル専用の安全網です。

  • コマンド: git reflog

  • 図解: resetでDとCを消してしまっても、reflogでDのコミットハッシュ（例：a3c21b0）を見つけ、git reset --hard a3c21b0で復元できます。

4.6. マイルストーンの記録

git tag

  • シナリオ: プロジェクトの特定の時点に、v1.0.0のような永続的な名前を付けたい場合。主にリリースバージョンをマークするために使用します。

  • コマンド:

    • git tag v1.0.0 (軽量タグ)
    • git tag -a v1.0.0 -m "Release version 1.0.0" (注釈付きタグ)

  • 図解:

4.7. コミット履歴のインタラクティブな編集

git rebase -i

  • シナリオ: プルリクエストを提出する前に、複数の「作業中」コミットを一つにまとめたり、コミットメッセージを修正したり、不要なコミットを削除して、履歴をきれいに整えたい場合。
  • コマンド: git rebase -i <base> (例: git rebase -i HEAD~3 は直近3つのコミットを対象とします)
  • インタラクティブな操作: コマンド実行後、エディタが開き、各コミットに対して以下のアクションを指定できます。
    • pick (p): コミットをそのまま使用します。
    • reword (r): コミットを使用しますが、コミットメッセージを編集します。
    • edit (e): コミットを使用しますが、内容を修正するために一時停止します。
    • squash (s): コミットを直前のコミットに統合し、新しいコミットメッセージを編集します。
    • fixup (f): squashと同様ですが、このコミットのメッセージは破棄されます。
    • drop (d): コミットを完全に削除します。
  • 図解: 3つのwipコミットをgit rebase -i HEAD~3を使って1つにsquashします。

    • Rebase前:

    • Rebase後:

4.8. 安全なブランチ切り替え

git switch

  • シナリオ: ブランチの切り替え操作を、ファイル復元機能も持つgit checkoutから分離し、より明確で安全に行いたい場合（Git v2.23以降で推奨）。

  • コマンド:

    • git switch <branch-name>: 既存のブランチに切り替えます。
    • git switch -c <new-branch-name>: 新しいブランチを作成して切り替えます。
    • git switch -: 直前にいたブランチに切り替えます。

  • 図解:

4.9. 変更の安全な復元

git restore

  • シナリオ: ワーキングツリーの変更を破棄したり、ステージングした変更を取り消したりする操作を、より安全かつ明確に行いたい場合（Git v2.23以降で推奨）。

  • コマンド:

    • git restore <file>: ワーキングツリーのファイルの変更を破棄します。
    • git restore --staged <file>: ステージングされたファイルの変更を取り消します（アンステージ）。
    • git restore --source <commit> <file>: ファイルを特定のコミットの状態に戻します。

  • 図解:

5. トラブルシューティング：マージコンフリクトの解決

マージコンフリクトはGitの一般的な課題ですが、これはエラーではなく分散開発における正常なプロセスの一部です。ここでは、コンフリクトの原因を理解し、解決するための実践的なガイドを提供します。

5.1. コンフリクトの原因

マージコンフリクトは、2つの異なるブランチが同じファイルの同じ行を編集した場合など、Gitがどちらの変更を優先すべきか自動的に判断できない時に発生します。Gitはマージプロセスを中断し、開発者に手動での解決を促します。

5.2. 段階的解決ガイド

コンフリクトは、以下の手順で体系的に解決できます。

  1. マージの開始とコンフリクトの発生
    git merge <branch-name>を実行すると、コンフリクト発生時にGitが通知します。

    $ git merge fix/typo
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

  2. コンフリクトの確認
    git statusを実行すると、コンフリクトしているファイルがUnmerged pathsとして表示されます。

    $ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
Unmerged paths:
    both modified:   README.md

  3. コンフリクトマーカーの解釈
    コンフリクトしたファイルを開くと、以下のようなマーカーが表示されます。

    <<<<<<< HEAD
# My Awesome Project
=======
# My Awesom Project
>>>>>>> fix/typo
    • <<<<<<< HEAD: 現在のブランチ（この例ではmain）の変更内容
    • =======: 2つのブランチの変更内容の区切り
    • >>>>>>> fix/typo: マージしようとしているブランチの変更内容

  4. 手動での解決
    エディタでファイルを開き、マーカーをすべて削除し、最終的に残したいコードの状態に手動で編集します。

    # My Awesome Project

  5. 解決のマーク
    ファイルを保存した後、git addコマンドでコンフリクトが解決されたことをGitに伝えます。

    git add README.md

  6. マージの完了
    git commitを実行してマージを完了させます。Gitが自動でコミットメッセージの雛形を用意してくれます。

    git commit

これでマージコンフリクトは解決され、2つのブランチの履歴が統合されます。

おわりに

Gitは単なるツールではなく、チームの生産性を向上させ、クリーンな開発履歴という資産を築くための強力なフレームワークです。この記事ではその基礎から実践までを解説しましたが、現場でのチーム開発ではさらに考慮すべき点があります。

  • .gitattributes: OS間の改行コードの違いなど、環境差異をリポジトリレベルで吸収します。
  • Git Hooks: コミット前やプッシュ前に特定のスクリプト（リンターやテストなど）を自動実行させ、コードの品質を保ちます。
  • Conventional Commits: feat:やfix:といった接頭辞をコミットメッセージに付けるルールで、履歴の可読性を高め、リリースノートの自動生成を可能にします。

これらの概念も探求することで、あなたのGitスキルはさらに向上するでしょう。この記事が、あなたのGitに対する理解を深め、日々の開発業務に自信をもたらす一助となれば幸いです。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

1. Git全般・公式ドキュメント

Gitの基本的な概念やコマンドについて学べる公式リファレンスやチュートリアルです。

2. ブランチ戦略 (Git Flow, GitHub Flow, GitLab Flow)

この記事で紹介した主要なブランチ戦略の提唱者による原文や、各ワークフローを詳しく解説・比較している記事です。

Discussion