Git入門｜基本コマンドの使い方を体系的にマスターするチュートリアル

ソフトウェア開発の現場で、バージョン管理システム（VCS）は酸素のような存在だ。Stack Overflow Developer Survey 2025によれば、開発者の97.1%がGitを使用しており、事実上の業界標準となっている。GitHub上のリポジトリ数は4億2,000万を超え、毎日300万以上のプルリクエストが作成される。にもかかわらず、Gitの基本操作を「なんとなく」で使い続けている開発者は少なくない。init、add、commit、push──4つのコマンドの意味と流れを正確に理解しているかどうかで、開発効率には大きな差が生まれる。本記事では、Gitの基本コマンドをワークフローに沿って体系的に解説し、よくあるミスとそのリカバリー方法まで網羅する。

Gitの採用状況──なぜGitが圧倒的に選ばれるのか

バージョン管理システムの歴史は長いが、2005年にLinus Torvaldsが開発したGitの登場で勢力図は一変した。現在、主要なVCSの利用率は以下のとおりだ。

VCS	利用率（2025年）	開発元	分散型/集中型	主な特徴
Git	97.1%	Linus Torvalds	分散型	高速、分散型、ブランチが軽量
Subversion（SVN）	4.2%	Apache	集中型	歴史が長い、大規模バイナリに対応
Mercurial	1.1%	Matt Mackall	分散型	Gitに似た設計、シンプルなUI
Perforce	2.8%	Perforce Software	集中型	ゲーム・映像など大容量ファイル向け
TFS/Azure DevOps	3.5%	Microsoft	両対応	Microsoft製品との統合

Gitが選ばれる最大の理由は「分散型」であることだ。各開発者がリポジトリの完全なコピーを持つため、ネットワーク接続がなくてもコミットや履歴閲覧ができる。加えて、ブランチの作成・切り替えが高速であり、並行開発のコストが極めて低い。

インストール方法──OS別セットアップ手順

Gitは主要なOSすべてで利用できる。インストール後に実行すべき初期設定もあわせて確認する。

OS	インストール方法	推奨手順	バージョン確認
Windows	Git for Windows公式サイトからインストーラーをダウンロード	Git Bash同梱版を選択。改行コード設定はCheckout as-is, commit Unix-style	git --version で確認
macOS	Xcode Command Line Toolsに同梱。Homebrewでも導入可	brew install git で最新版を維持	git --version で確認
Linux（Ubuntu/Debian）	aptパッケージマネージャーで導入	sudo apt update && sudo apt install git	git --version で確認
Linux（Fedora/RHEL）	dnfパッケージマネージャーで導入	sudo dnf install git	git --version で確認

初期設定で必ず行うべき3項目

インストール直後に設定すべき項目は以下の3つだ。これらを設定しないと、コミット時にエラーが発生する。

設定項目	設定コマンドの概要	目的
ユーザー名	git config --global user.name に名前を指定	コミット履歴に記録される名前
メールアドレス	git config --global user.email にアドレスを指定	GitHubアカウントとの紐付け
デフォルトブランチ名	git config --global init.defaultBranch に「main」を指定	新規リポジトリのブランチ名をmainに統一

Gitの4つの領域──データの流れを理解する

Gitを正しく使うには、データが通過する4つの領域を理解する必要がある。多くの初心者がつまずくのは、この領域間の関係を把握していないからだ。

領域	英語名	役割	状態
作業ディレクトリ	Working Directory	ファイルを実際に編集する場所	Modified（変更済み）
ステージングエリア	Staging Area / Index	次のコミットに含める変更を登録する場所	Staged（ステージ済み）
ローカルリポジトリ	Local Repository	コミット履歴が保存される場所（.gitディレクトリ内）	Committed（コミット済み）
リモートリポジトリ	Remote Repository	GitHub等のサーバー上のリポジトリ	Pushed（プッシュ済み）

データの流れは「作業ディレクトリ → ステージングエリア → ローカルリポジトリ → リモートリポジトリ」の一方向が基本だ。逆方向の操作（pullやfetch）も存在するが、まずはこの順方向の流れを完全に理解することが重要になる。

基本ワークフロー──init から push までの5ステップ

Gitの最も基本的なワークフローを、5つのステップに分解して解説する。

ステップ	コマンド	操作内容	何が起きるか
1. 初期化	git init	カレントディレクトリにリポジトリを作成	.git ディレクトリが生成される
2. 状態確認	git status	変更されたファイルの一覧を確認	未追跡・変更・ステージ済みファイルが表示される
3. ステージ	git add ファイル名	指定したファイルをステージングエリアに登録	次のコミット対象としてマークされる
4. コミット	git commit -m "メッセージ"	ステージ済みの変更をローカルリポジトリに記録	スナップショットがハッシュ値付きで保存される
5. プッシュ	git push origin main	ローカルのコミットをリモートに送信	GitHub等のサーバーに反映される

既存リポジトリから始める場合

新規作成ではなく、既存のリモートリポジトリから作業を始める場合は git clone を使う。cloneを実行すると、リモートリポジトリの全履歴がローカルにコピーされ、origin という名前でリモートが自動登録される。

必須コマンド一覧──日常的に使う12のコマンド

日常業務で頻繁に使用するGitコマンドを、目的別に分類して整理する。

カテゴリ	コマンド	用途	使用頻度
開始	git init	新規リポジトリの作成	低（プロジェクト開始時のみ）
開始	git clone	リモートリポジトリの複製	低（最初の1回）
記録	git add	ステージングエリアへの追加	高（毎回）
記録	git commit	変更の確定	高（毎回）
同期	git push	リモートへの送信	高（コミット後）
同期	git pull	リモートからの取得と統合	高（作業開始時）
同期	git fetch	リモートの情報取得（統合なし）	中
確認	git status	作業状態の確認	高（常時）
確認	git log	コミット履歴の閲覧	中
確認	git diff	変更差分の確認	中
分岐	git branch	ブランチの一覧・作成	中
分岐	git switch	ブランチの切り替え	中

ブランチ戦略──並行開発の基盤を作る

ブランチはGitの最大の武器だ。メインの開発ラインから分岐して作業し、完了後にマージするという流れにより、複数人での並行開発が可能になる。

ブランチ操作	コマンド概要	説明
ブランチ一覧表示	git branch	ローカルブランチの一覧を表示。-a でリモートも含む
ブランチ作成	git branch ブランチ名	新しいブランチを作成（切り替えはしない）
ブランチ切り替え	git switch ブランチ名	指定ブランチに切り替え。-c オプションで作成と同時に切り替え
ブランチマージ	git merge ブランチ名	指定ブランチの変更を現在のブランチに統合
ブランチ削除	git branch -d ブランチ名	マージ済みブランチを削除。-D で強制削除

チーム開発でよく使われるブランチモデル

モデル名	概要	適したチーム規模
GitHub Flow	mainブランチ＋featureブランチのシンプル構成	小〜中規模
Git Flow	main、develop、feature、release、hotfixの5種類	中〜大規模
Trunk-Based Development	mainに直接短いブランチをマージ。CI/CD前提	CI/CDが整備されたチーム

マージコンフリクト──避けられない衝突への対処法

複数の開発者が同じファイルの同じ箇所を変更した場合、マージコンフリクト（衝突）が発生する。慌てる必要はない。Gitはコンフリクトの箇所を明確にマークするため、手動で解決できる。

段階	作業内容	詳細
1. 検知	マージ実行時にCONFLICTメッセージが表示される	どのファイルで衝突が起きたかが一覧表示される
2. 確認	対象ファイルを開き、コンフリクトマーカーを確認	HEAD側と相手ブランチ側の変更が区切り線で表示される
3. 解決	コンフリクトマーカーを削除し、正しい内容に編集	両方の変更を取り込む、片方を選ぶ、新たに書き直すなど
4. 完了	解決したファイルをaddしてcommit	マージコミットが作成される

コンフリクトを減らすためのベストプラクティスとして、こまめにpullして最新の変更を取り込むこと、小さな単位で頻繁にコミットすること、そして同じファイルを複数人が同時に編集しないようタスクを分割することが挙げられる。

よくあるミスとリカバリー──焦らず対処する方法

Gitの操作で失敗しても、ほとんどの場合はリカバリーが可能だ。以下に頻出するミスと復旧方法をまとめる。

ミスの内容	リカバリー方法	コマンド概要
直前のコミットメッセージを間違えた	直前のコミットを修正	git commit --amend でメッセージを書き換え
addしたファイルをステージから外したい	ステージの取り消し	git restore --staged ファイル名
ファイルの変更を元に戻したい	作業ディレクトリの変更破棄	git restore ファイル名
直前のコミットを取り消したい（変更は残す）	ソフトリセット	git reset --soft HEAD~1
直前のコミットを完全に取り消したい	ハードリセット	git reset --hard HEAD~1（変更も消える）
プッシュ済みのコミットを取り消したい	打ち消しコミット作成	git revert コミットハッシュ
一時的に作業を退避したい	スタッシュ	git stash で退避、git stash pop で復元
消したブランチやコミットを復元したい	操作履歴の確認	git reflog で履歴を確認し、該当ハッシュにリセット

resetとrevertの使い分け

resetとrevertは混同されやすいが、用途が明確に異なる。ローカルで作業中であればresetで履歴を書き換えても問題ないが、すでにリモートにプッシュ済みの場合はrevertで新しいコミットとして取り消す。リモートの履歴を書き換えると、他の開発者の環境に影響を与えるためだ。

.gitignore設定──追跡すべきでないファイルを除外する

リポジトリに含めるべきでないファイル（環境変数、依存パッケージ、ビルド成果物など）は、.gitignoreファイルで除外する。

プロジェクト種別	除外すべき主要パターン	理由
Node.js	node_modules/、.env、dist/、.next/	依存パッケージ、環境変数、ビルド成果物
Python	pycache/、*.pyc、venv/、.env	バイトコード、仮想環境
Java	target/、.class、.jar	コンパイル成果物
共通	.DS_Store、Thumbs.db、*.log	OS固有ファイル、ログ
IDE	.vscode/、.idea/、*.swp	エディタ設定、一時ファイル

.gitignoreはリポジトリのルートに配置する。すでにgit addで追跡対象になっているファイルは、.gitignoreに追加しただけでは除外されない。追跡を解除してからignoreに追記する必要がある。

GUIツール比較──コマンドラインが苦手な場合の選択肢

Gitはコマンドラインでの操作が基本だが、GUIツールを活用することで視覚的に操作できる。

ツール名	価格	対応OS	特徴	推奨ユーザー
Sourcetree	無料	Windows / macOS	Atlassian製、直感的なUI	Git初心者
GitKraken	有料（無料プランあり）	全OS	美しいグラフ表示、統合機能が豊富	中級者以上
VS Code内蔵Git	無料	全OS	エディタと統合、拡張機能で強化可能	全レベル
GitHub Desktop	無料	Windows / macOS	GitHub特化、シンプル	GitHub中心の開発者
Fork	有料（評価版あり）	Windows / macOS	高速、差分表示が優秀	日常的にGitを使う開発者

GUIツールとコマンドラインは排他的な選択ではない。通常の操作はGUIで行い、複雑な操作やスクリプト化にはコマンドラインを使うというハイブリッドな運用が実務では効果的だ。

学習ロードマップ──入門から実践までの道筋

Gitの学習は段階的に進めるのが効果的だ。以下のロードマップを目安に、自分の現在地を確認してほしい。

段階	目標	習得すべき項目	目安期間
Level 1: 基礎	一人でリポジトリを管理できる	init、add、commit、push、pull、status	1〜2週間
Level 2: 分岐	ブランチを使った開発ができる	branch、switch、merge、コンフリクト解決	2〜3週間
Level 3: 復旧	問題が起きても自力で対処できる	reset、revert、stash、reflog	1〜2週間
Level 4: 協働	チーム開発にスムーズに参加できる	Pull Request、コードレビュー、ブランチ戦略	2〜4週間
Level 5: 応用	複雑なリポジトリ管理ができる	rebase、cherry-pick、submodule、hook	継続的に

最も効果的な学習方法は、個人プロジェクトでGitを日常的に使うことだ。学習用のテストリポジトリを作り、意図的にコンフリクトを起こしたり、resetとrevertを試したりすることで、コマンドの挙動を体で覚えることができる。

Gitの基本を学んだ今、次に問うべきことがある。あなたのチームでは、ブランチ戦略やコミットメッセージのルールは明文化されているだろうか。ツールを正しく使えることと、チームとして効率的に使いこなすことの間には、もうひとつの壁がある。個人の技術力をチームの開発力に変えるために、あなたが最初に取り組むべきルール作りは何だろうか。