Git の基本：init・add・commit でバージョン管理を始める

ファイルを編集していて「あの時点の状態に戻したい」と思ったことはないでしょうか。 Git は、そうした変更履歴を記録し、いつでも過去の状態に戻せる分散バージョン管理システムです。「分散」とは、リポジトリ（履歴データベース）が中央サーバーだけでなく各開発者のマシンにも丸ごとコピーされることを指します。ネットワークが切れていても履歴を参照でき、バックアップにもなる点が大きな強みです。

ソフトウェア開発での利用が中心ですが、設定ファイル・ドキュメント・スクリプトなど、テキストベースのファイルであれば何でも管理できます。本記事では、Git を初めて使う人を対象に、インストール確認から最初のコミットまでを順番に解説します。

インストール確認と初期設定

Git がインストールされているか確認するには、バージョン確認コマンドを実行します。

git --version
# git version 2.x.x

インストールされていなければ、OS のパッケージマネージャーで導入します（Ubuntu なら sudo apt install git、macOS なら brew install git など）。

次に、コミットに記録されるユーザー名とメールアドレスを設定します。この情報はコミット履歴に残るため、最初に必ず設定しておきましょう。

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

--global オプションをつけると、ホームディレクトリの ~/.gitconfig に書き込まれ、全リポジトリで共通の設定として使われます。特定のリポジトリだけ別の設定にしたい場合は --global を外してリポジトリ内で実行します。

設定内容を確認したいときは次のコマンドを使います。

git config --list

リポジトリを作る（git init）

管理したいプロジェクトのディレクトリへ移動し、git init を実行するとリポジトリが作られます。

mkdir myproject
cd myproject
git init
# Initialized empty Git repository in /home/user/myproject/.git/

実行後、カレントディレクトリに .git という隠しディレクトリが作成されます。 Git が管理するすべての情報（コミット履歴・ブランチ情報・設定など）はここに格納されています。 .git を削除するとリポジトリごと消えるので注意してください（プロジェクトのファイルは残ります）。

ls -a
# .  ..  .git

3つの領域を理解する

Git では、ファイルが「どの段階にあるか」を3つの領域で管理します。この概念を掴んでおくと、add や commit の意味がぐっと理解しやすくなります。

領域	別名	説明
作業ツリー	Working Tree	実際に編集しているファイルがある場所
ステージングエリア	Index	コミットに含める変更を積んでおく一時置き場
リポジトリ	.git directory	コミット済みの履歴が永続的に保存される場所

ファイルを編集しただけでは作業ツリーにのみ変更が存在します。 git add でステージングエリアに積み、git commit でリポジトリに記録する、というのが基本の流れです。

基本サイクル：status → add → commit

git status で現状を確認する

作業中は git status で現在の状態を確認する習慣をつけましょう。

git status
# On branch main
# No commits yet
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#         README.md

Untracked files は Git がまだ追跡していないファイルです。

git add でステージングする

コミットに含めたいファイルを git add でステージングします。

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

# カレントディレクトリ以下のすべての変更をステージング
git add .

git add . は便利ですが、意図しないファイルまで含めてしまう場合があります。最初のうちはファイルを個別に指定するか、git status で確認しながら使うのが無難です。

git commit でリポジトリに記録する

ステージングした内容を -m オプションでメッセージを添えてコミットします。

git commit -m "Add README"

コミットが成功すると、一意のハッシュ値（SHA-1）が割り振られ、変更が永続的に記録されます。

履歴を確認する（git log）

コミット履歴は git log で確認できます。

git log
# commit a1b2c3d4... (HEAD -> main)
# Author: Your Name <you@example.com>
# Date:   Thu Jun 19 ...
#
#     Add README

ハッシュ・著者・日時・メッセージが表示されます。変更がたまってきたら --oneline で一行表示にすると見やすくなります。

git log --oneline
# a1b2c3d Add README
# e5f6a7b Initial commit

過去のコミット時点のファイル内容を参照したい場合は、ハッシュを使います。

git show a1b2c3d

.gitignore でトラッキング対象を絞る

すべてのファイルを Git 管理下に置く必要はありません。ビルド成果物・ログ・環境設定ファイル（.env など）・依存ライブラリ（node_modules など）は、リポジトリに含めないほうが賢明です。

プロジェクトルートに .gitignore ファイルを作り、除外パターンを記述します。

# コメント行は # で始める
node_modules/
*.log
.env
dist/
__pycache__/

.gitignore に記載されたパターンに一致するファイルは git add の対象から外れ、git status でも Untracked files に表示されなくなります。

.gitignore ファイル自体はリポジトリに含めて共有するのが一般的です。 GitHub には言語・フレームワーク別のテンプレートが多数用意されており、gitignore.io でも生成できます。

実践的なコツ

1コミット1論理変更を意識する

複数の無関係な変更を1つのコミットにまとめると、後からどの変更が何の目的で行われたか追いにくくなります。「バグ修正」と「機能追加」は別コミットにするのが基本です。

コミットメッセージは変更の「なぜ」を書く

「何を変えたか」はコードを見ればわかります。コミットメッセージには「なぜその変更を行ったか」を書くと、後から見返したときの情報量が格段に上がります。 Fix typo より Fix typo in error message that caused user confusion のほうが有益です。

こまめにコミットする

「完璧になったら1回コミット」より、「動くマイルストーンごとにこまめにコミット」するほうが戻りやすく、変更の追跡も容易です。ワークインプログレスのコミットは、後で git rebase -i でまとめることもできます（これは後の連載で扱います）。

git diff で差分を確認してからステージングする

git add の前に git diff を実行すると、作業ツリーの変更内容を確認できます。意図しない変更が含まれていないかチェックする習慣をつけましょう。

git diff          # 未ステージの差分
git diff --staged # ステージ済みの差分（コミット前の最終確認）

まとめ

Git は変更履歴を記録・管理する分散バージョン管理システム。git init でリポジトリを作成する
git config でユーザー名・メールを設定するのが最初のステップ
「作業ツリー → ステージング → リポジトリ」の3段階でファイルの状態が管理される
git add → git commit -m が基本の記録サイクル
git log --oneline で履歴を素早く確認できる
.gitignore で管理対象外のファイルを明示しておく
1コミット1論理変更・変更の「なぜ」をメッセージに書く習慣が後から役立つ

次回は Git の強力な機能の一つ、ブランチを取り上げます。本流に影響を与えずに作業を分岐させ、完成したら合流させる運用を学びます。