Gitの基本操作をマスターしよう | 実践講座

このチュートリアルで学ぶこと

Gitリポジトリの初期化（init）
変更のステージング（add）
コミットの作成（commit）
リモートへのプッシュ（push）

前提条件: Gitがインストールされていること。git --versionでバージョンが表示されればOKです。

Gitとは何か？なぜ生まれたのか

Gitの誕生背景

Gitは2005年にLinus Torvalds（Linuxカーネルの生みの親）によって開発されました。

当時、Linuxカーネルの開発には「BitKeeper」という商用のバージョン管理システムが使われていました。しかし、ライセンスの問題でBitKeeperが使えなくなり、Linusはわずか2週間で新しいバージョン管理システムを作り上げました。それがGitです。

「Gitという名前は、イギリスのスラングで”嫌なやつ”という意味。Linusは自分のプロジェクトに自虐的な名前をつける傾向があります」

Gitが解決した課題

分散型バージョン管理: 中央サーバーに依存せず、各開発者が完全な履歴を持てる
高速な操作: ほとんどの操作がローカルで完結するため非常に高速
ブランチの軽量化: ブランチの作成・切り替えが一瞬でできる
データの整合性: SHA-1ハッシュにより、すべての変更が暗号学的に保護される

現在のGit

現在、Gitは世界で最も使われているバージョン管理システムです。Stack Overflowの2022年調査によると、開発者の93%以上がGitを使用しています。

Gitの内部構造を理解する

Gitを効果的に使うには、内部の仕組みを理解することが重要です。

3つのエリア

Gitには3つの主要なエリアがあります：

flowchart LR
    WD["作業ディレクトリ<br/>(Working Dir)"] -->|git add| SA["ステージングエリア<br/>(Staging Area)"]
    SA -->|git commit| Repo["リポジトリ<br/>(.git)"]

作業ディレクトリ（Working Directory）: 実際にファイルを編集する場所
ステージングエリア（Staging Area / Index）: 次のコミットに含める変更を準備する場所
リポジトリ（.git）: コミットされた履歴が保存される場所

Gitオブジェクトモデル

Gitは4種類のオブジェクトでデータを管理します：

blob: ファイルの内容
tree: ディレクトリ構造
commit: スナップショット + メタデータ
tag: 特定のコミットへの参照

すべてのオブジェクトはSHA-1ハッシュ（40文字の16進数）で識別されます。

Step 1: リポジトリの初期化

まず、プロジェクト用のディレクトリを作成し、Gitリポジトリとして初期化します。

# プロジェクトディレクトリを作成
mkdir my-first-repo
cd my-first-repo

# Gitリポジトリとして初期化
git init

git initを実行すると、.gitという隠しフォルダが作成されます。これがGitの管理情報を保存する場所です。

.gitディレクトリの中身

$ ls -la .git/
├── HEAD          # 現在のブランチへの参照
├── config        # リポジトリ固有の設定
├── hooks/        # Git hookスクリプト
├── objects/      # すべてのGitオブジェクト
└── refs/         # ブランチとタグへの参照

公式ドキュメント: git-init

Step 2: ファイルの作成とステージング

新しいファイルを作成し、Gitの管理下に追加しましょう。

# READMEファイルを作成
echo "# My First Repository" > README.md

# 状態を確認
git status

# ファイルをステージング
git add README.md

# 再度状態を確認
git status

git addは、変更をステージングエリアに追加します。これは「次のコミットに含める変更」を選択する操作です。

なぜステージングエリアが必要なのか？

「ステージングエリアは、コミットを論理的な単位に整理するためのバッファ。一度にすべてをコミットする必要はない」— Pro Git Book

ステージングエリアがあることで：

部分的なコミット: 複数の変更から一部だけを選んでコミットできる
レビュー: コミット前に何を含めるか確認できる
原子的なコミット: 関連する変更だけをまとめられる

よく使うaddのパターン

# 特定のファイルを追加
git add filename.txt

# すべての変更を追加
git add .

# 特定の拡張子を追加
git add *.js

# 対話的に追加（部分的な変更を選択）
git add -p

公式ドキュメント: git-add

Step 3: コミットの作成

ステージングした変更を、コミットとして記録します。

# コミットを作成
git commit -m "Initial commit: Add README"

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

良いコミットメッセージの書き方

Conventional Commitsという規約が広く採用されています：

<type>(<scope>): <subject>

<body>

<footer>

typeの例:

feat: 新機能
fix: バグ修正
docs: ドキュメント
style: フォーマット変更
refactor: リファクタリング
test: テスト追加・修正
chore: ビルド設定など

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

# 良い例
git commit -m "feat: Add user authentication"
git commit -m "fix: Resolve login button not working on mobile"
git commit -m "docs: Update API documentation"

# 悪い例
git commit -m "fix"
git commit -m "Update"
git commit -m "変更"

ベストプラクティス: 「このコミットを適用すると〇〇する」という形式で書く。命令形を使い、現在形で記述する。

公式ドキュメント: git-commit

Step 4: リモートリポジトリへのプッシュ

GitHub等でリモートリポジトリを作成し、ローカルの変更をプッシュします。

# リモートリポジトリを追加
git remote add origin https://github.com/username/my-first-repo.git

# メインブランチをプッシュ
git push -u origin main

-uオプションは、次回からgit pushだけでプッシュできるように上流ブランチ（upstream）を設定します。

リモートの確認

# 設定されているリモートを確認
git remote -v

# 出力例:
# origin  https://github.com/username/my-first-repo.git (fetch)
# origin  https://github.com/username/my-first-repo.git (push)

公式ドキュメント: git-push

基本ワークフローのまとめ

# 日常的な作業フロー
git status              # 現在の状態を確認
git add .               # 変更をステージング
git commit -m "message" # コミットを作成
git push                # リモートにプッシュ

Git操作の可視化

flowchart LR
    subgraph WD["Working Directory"]
    end
    subgraph SA["Staging Area"]
    end
    subgraph Repo["Repository"]
    end
    WD -->|git add| SA
    SA -->|git commit| Repo
    Repo -->|git checkout| WD
    Repo -->|git reset --soft| SA

よくある間違いとアンチパターン

1. 巨大なコミット

# 悪い例: すべてを一度にコミット
git add .
git commit -m "Add all features"

# 良い例: 論理的な単位で分割
git add src/auth/
git commit -m "feat: Add authentication module"

git add src/api/
git commit -m "feat: Add API endpoints"

2. 機密情報のコミット

# .gitignoreに追加すべきファイル
.env
*.pem
config/secrets.yml
node_modules/

3. コミットメッセージの省略

コミットメッセージは未来の自分や他の開発者へのドキュメントです。意味のあるメッセージを書きましょう。

よくあるトラブルと解決法

コミットメッセージを間違えた

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

注意: すでにpushしたコミットの修正は避けてください。履歴の書き換えは他の開発者に影響を与えます。

addを取り消したい

# ステージングを取り消し（ファイルの変更は維持）
git reset HEAD filename.txt

# Git 2.23以降の新しいコマンド
git restore --staged filename.txt

直前のコミットを取り消したい

# コミットを取り消し、変更をステージングに戻す
git reset --soft HEAD~1

# コミットを取り消し、変更を作業ディレクトリに戻す
git reset HEAD~1

# コミットと変更を完全に削除（危険）
git reset --hard HEAD~1

特定のファイルを以前の状態に戻したい

# 特定のコミットからファイルを復元
git checkout <commit-hash> -- filename.txt

# Git 2.23以降
git restore --source=<commit-hash> filename.txt

設定のベストプラクティス

初めてGitを使う場合は、以下の設定を行いましょう：

# ユーザー名とメールアドレスの設定（必須）
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# デフォルトブランチ名をmainに
git config --global init.defaultBranch main

# 改行コードの自動変換（macOS/Linux）
git config --global core.autocrlf input

# エディタの設定
git config --global core.editor "code --wait"

# カラー出力を有効化
git config --global color.ui auto

次のステップ

基本操作をマスターしたら、次はブランチの使い方を学びましょう。チーム開発では必須のスキルです。

学習を続けるためのリソース：

ブランチ戦略を学ぶ → Gitブランチ戦略を実践
インタラクティブに学ぶ → Learn Git Branching

参考リンク

公式ドキュメント

Git公式ドキュメント - 公式リファレンス
Pro Git Book（日本語） - 無料で読める包括的なGit解説書

推奨記事・チュートリアル

Conventional Commits - コミットメッセージの規約
GitHub Git Cheat Sheet - よく使うコマンド一覧
Atlassian Git Tutorial - ビジュアルで学ぶGit

ツール

GitHub Desktop - GUIでGitを操作
GitLens (VS Code拡張) - VS CodeでGit履歴を可視化
Learn Git Branching - インタラクティブなGit学習サイト

← 一覧に戻る