Git の基本操作

Git（ギット）とは、ファイルの変更履歴を記録・管理するバージョン管理システムです。カメラで写真を撮るように、コードの「今この瞬間の状態」をいつでも保存できます。保存した時点（コミット）にはいつでも戻ることができ、複数人で同じプロジェクトを安全に編集できます。

対象読者: バージョン管理を全く使ったことがない方（プログラミング入門者歓迎）

学習時間の目安: 読了 15分 ＋ 実践 20分

前提知識: ターミナルの基本操作（cd、ls など）

なぜ Git が必要なのか

コードを書いていると、以下のような場面に必ず遭遇します。

• 「昨日まで動いていたのに、今日になったら動かなくなった。どこを変えたか分からない」
• 「新機能を追加したら、既存の機能が壊れてしまった」
• 「チームメンバーと同じファイルを編集して、どちらかの変更が消えてしまった」

Git を使うと、これらの問題をすべて解決できます。変更の差分を確認したり、問題が起きる前の状態に戻したり、複数人の変更を安全にひとつにまとめたりすることが可能です。

Git のインストール確認

Mac には Git が標準でインストールされています。ターミナルで以下を実行して確認します。

git --version
# git version 2.46.0 のように表示されれば OK

表示されない場合は Homebrew でインストールします。

brew install git

初期設定

Git を初めて使う前に、自分の名前とメールアドレスを登録します。この情報はコミットの記録に使われ、「誰がいつ変更したか」を追跡できるようにします。

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

設定内容を確認するには以下のコマンドを使います。

git config --list

Git の基本概念：3つのエリア

Git では、ファイルが以下の3つのエリアを移動しながら管理されます。この仕組みを理解することが Git 習得の第一歩です。

作業ディレクトリ          ステージングエリア         リポジトリ
(Working Directory)  →   (Staging Area)    →   (Repository)
  ファイルを編集           git add で追加         git commit で保存

エリア	説明	たとえると
作業ディレクトリ	実際にファイルを編集する場所	机の上で作業中の状態
ステージングエリア	コミットする変更を選んで並べる場所	封筒に入れる前の書類置き場
リポジトリ	コミットされた履歴が保存される場所	保管庫（タイムカプセル）

ステージングエリアを挟むことで「今回のコミットに含める変更」と「まだ含めない変更」を選択できます。これにより、目的に応じた小さな単位でコミットを作れます。

主要コマンド

リポジトリの初期化

git init

プロジェクトフォルダで実行すると、そのフォルダを Git で管理できるようになります。.git という隠しフォルダが作成され、ここにすべての履歴が記録されます。

現在の状態を確認する

git status

どのファイルが変更されているか、ステージングされているかを確認します。作業中は何度でも実行して現在地を確認する習慣をつけましょう。

変更後の出力例:
On branch main
Changes not staged for commit:
  modified:   index.html

Untracked files:
  style.css

変更をステージングする

git add .             # すべての変更をステージング
git add index.html    # 特定のファイルだけステージング

「このファイルの変更を次のコミットに含める」という宣言です。git add . はすべての変更を一括でステージングしますが、不要なファイルまで含めることがあるため注意が必要です。

コミットする

git commit -m "メッセージ"

ステージングされた変更を記録します。メッセージには「何をしたか」を端的に書きます。良いコミットメッセージは、後から履歴を読んだときに変更の意図が分かるものです。

# コミットメッセージの例（具体的に書く）
git commit -m "ログイン画面のデザインを修正"
git commit -m "README にセットアップ手順を追加"
git commit -m "ユーザー一覧の検索機能を追加"

履歴を確認する

git log            # 詳細な履歴
git log --oneline  # 1行で簡潔に表示

git log --oneline の出力例:
a3f8c21 ユーザー一覧の検索機能を追加
8b2d1e4 ログイン画面のデザインを修正
1c9a7f0 README にセットアップ手順を追加

変更差分を確認する

git diff           # ステージング前の変更を確認
git diff --staged  # ステージング後の変更を確認

コミット前に「何を変えたのか」を確認する習慣を持つと、ミスのあるコミットを防げます。

.gitignore の作成

.gitignore（ドットギットイグノア）とは、Git の管理対象から除外するファイルやフォルダを指定するファイルです。パスワードを含む設定ファイルや、自動生成されるファイルは Git に含めないのが鉄則です。

プロジェクトのルートに .gitignore という名前でファイルを作成し、以下のように記述します。

node_modules/
.env
.DS_Store
dist/

除外するもの	理由
node_modules/	npm パッケージは npm install で再生成できる
.env	API キーやパスワードが含まれる可能性がある
.DS_Store	Mac が自動生成するファイル（不要）
dist/	ビルド成果物は再生成できる

.env ファイルをコミットすると、パスワードや API キーが公開されてしまいます。必ず .gitignore に追加してください。一度コミットしてしまうと、履歴から完全に消すのは非常に手間がかかります。

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

日常の開発では、以下のサイクルを繰り返します。

# 1. プロジェクトフォルダで Git を初期化（初回のみ）
git init

# 2. ファイルを編集する（エディタで作業）

# 3. 現在の状態を確認
git status

# 4. 変更をステージング
git add .

# 5. コミット（変更を記録）
git commit -m "最初のコミット"

# 6. 履歴を確認
git log --oneline

実際のユースケース

個人開発：セーフティネットとしての Git

個人でウェブサイトやアプリを開発するとき、Git はセーフティネットとして機能します。「新しい機能を試したら動かなくなった」というときに、コミット済みの安全な状態にすぐ戻せます。

# 直前のコミットまで戻す（コミットは保持する）
git revert HEAD

# 特定のファイルを最後のコミット状態に戻す
git restore index.html

チーム開発：変更の追跡と責任の明確化

チームで開発する場合、誰がいつ何を変更したかを git log で確認できます。バグが混入したとき、「どのコミットで問題が発生したか」を絞り込む際に役立ちます。

# 誰がどの行を変更したかを確認
git blame index.html

オープンソース貢献：差分レビューの基盤

GitHub でオープンソースプロジェクトに貢献する際、Pull Request の差分（Diff）は Git の仕組みで生成されます。変更内容を可視化することで、レビュアーが変更の意図を正確に把握できます。

よくある初心者ミスと対処法

コミットメッセージを忘れた

git commit   # -m オプションなし → エディタが開く
# エディタを終了できない場合は Ctrl + C で中断し、-m オプションを使う
git commit -m "メッセージ"

間違えてステージングした

git restore --staged index.html  # 特定ファイルを取り消し
git restore --staged .           # すべて取り消し

直前のコミットメッセージを修正したい

git commit --amend -m "修正後のメッセージ"

--amend は GitHub にプッシュ済みのコミットには使わないでください。履歴の書き換えが発生します。

コミット前の変更を元に戻したい

git restore index.html  # 特定ファイルを最後のコミット状態に戻す

FAQ

Q. git init と git clone の違いは何ですか？

git init は新しいリポジトリをゼロから作成します。git clone は既存のリポジトリ（GitHub など）をダウンロードして複製します。既存のプロジェクトを手元で作業したい場合は git clone を使います。

Q. コミットはどのくらいの頻度でするべきですか？

「ひとつの意味のある変更」をひとつのコミットにするのが基本です。機能の追加、バグ修正、リファクタリングなど、目的が異なる変更は別々のコミットに分けましょう。こまめにコミットするほど、問題が発生したときに戻りやすくなります。

Q. コミットメッセージは日本語でも良いですか？

個人プロジェクトや日本語チームでは日本語で構いません。英語の方が国際的なプロジェクトでは一般的です。チームのルールに合わせましょう。

Q. ステージングエリアはなぜ必要ですか？

複数のファイルを変更したとき、「今回のコミットにはAとBの変更を含め、Cは次のコミットにする」という選択ができます。1回のコミットに目的が異なる変更を混在させないための仕組みです。