【入門】Git の基本操作を完全マスター!初心者が最初に覚えるべき 10 コマンド

プログラミングを始めたばかりの皆さんは、「Git って何?」「なんだか難しそう...」と感じていませんか。でも安心してください。この記事では、Git の基本操作を初心者の方でも確実にマスターできるよう、必要最小限の10コマンドに絞ってわかりやすく解説いたします。
Git は現代のソフトウェア開発では欠かせないツールです。最初は複雑に感じるかもしれませんが、今回ご紹介する10のコマンドを覚えるだけで、日常的な開発作業の大部分をこなせるようになります。一歩ずつ確実に進んでいきましょう。
背景
なぜ Git が必要なのか
プログラミングを学び始めると、必ずといっていいほど「Git を使いましょう」という話を耳にしますね。では、なぜ Git がそれほど重要なのでしょうか。
現代のソフトウェア開発では、コードの変更履歴を管理することが必須です。例えば、新しい機能を追加している最中にバグが発生した場合、以前の動いていた状態に戻したくなることがあります。また、複数人でプロジェクトに取り組む際には、誰がいつ何を変更したかを把握する必要があります。
mermaidflowchart LR
dev1[開発者A] -->|コード変更| git[Git リポジトリ]
dev2[開発者B] -->|コード変更| git
dev3[開発者C] -->|コード変更| git
git -->|履歴管理| history[変更履歴]
git -->|同期| sync[チーム同期]
上図のように、Git は複数の開発者が同じプロジェクトで作業する際の中央管理システムとして機能します。個人開発であっても、バックアップや実験的な変更の管理に威力を発揮するのです。
バージョン管理の重要性
バージョン管理がない開発環境を想像してみてください。ファイル名が「index.html」「index_backup.html」「index_final.html」「index_final_final.html」のようになってしまい、どれが最新かわからなくなってしまいます。
Git を使用すると、以下のようなメリットがあります。
機能 | 従来の方法 | Git を使用 |
---|---|---|
バックアップ | 手動でコピー | 自動的に履歴保存 |
変更の追跡 | ファイル名で管理 | コミットメッセージで管理 |
実験的変更 | 別フォルダを作成 | ブランチ機能で分岐 |
チーム作業 | メールやUSBで共有 | リモートリポジトリで同期 |
問題発生時の対応 | 手動で以前のファイルを復元 | コマンド一つで任意の状態に復元 |
Git の特徴と利点
Git には他のバージョン管理システムと比較して、以下のような特徴があります。
分散型アーキテクチャ:各開発者のマシンに完全な履歴が保存されるため、インターネット接続がなくても作業を続けられます。また、中央サーバーに問題が発生しても、各開発者のローカルリポジトリから復旧できます。
高速な動作:Git はローカルで動作するため、履歴の確認やブランチの切り替えが非常に高速に行えます。これにより、開発者の作業効率が大幅に向上します。
柔軟なワークフロー:プロジェクトの規模やチームの特性に応じて、様々な開発フローを選択できます。一人開発から大規模なオープンソースプロジェクトまで、幅広く対応可能です。
課題
初心者が直面する Git の壁
Git を学び始めた多くの初心者が、同じような壁にぶつかります。まず、Git には独特の概念が多く存在することです。「リポジトリ」「コミット」「ブランチ」「マージ」といった用語が次々と登場し、それぞれの関係性を理解するのに時間がかかります。
さらに、Git はコマンドライン(ターミナル)での操作が基本となるため、GUI に慣れ親しんだ初心者にとっては敷居が高く感じられがちです。「黒い画面」に対する心理的な抵抗感も、学習の妨げとなることがあります。
mermaidstateDiagram-v2
[*] --> 興味
興味 --> 混乱: コマンドの多さ
混乱 --> 挫折: エラーメッセージ
混乱 --> 理解: 段階的学習
理解 --> 習得: 実践練習
習得 --> [*]
挫折 --> [*]
上の図が示すように、多くの初心者は混乱から挫折へと向かってしまいがちです。しかし、適切な学習方法を選択することで、確実に理解から習得へと進むことができます。
コマンドの多さによる混乱
Git には100を超えるコマンドが存在します。公式ドキュメントを見ると、膨大な数のオプションや機能が紹介されており、「一体何から覚えればいいの?」と途方に暮れてしまうのも無理はありません。
多くの学習リソースでは、Git の全機能を体系的に説明しようとするため、初心者にとって本当に必要な情報が埋もれてしまいがちです。また、上級者向けの機能まで一度に学ぼうとすることで、基本的な操作すら身につかないという悪循環に陥ることもあります。
概念理解の難しさ
Git の概念は、日常生活では馴染みのないものが多くあります。例えば「ステージング」という概念は、Git 特有のワークフローであり、なぜそのような仕組みになっているのかを理解するのに時間がかかります。
また、「ブランチ」や「マージ」といった概念も、実際に使ってみるまではピンときません。理論的な説明だけでは理解が難しく、実際に手を動かして体験することが重要になります。
解決策
10 の基本コマンドに絞った学習法
この記事では、日常的な開発作業で本当に必要な10のコマンドに絞って解説します。これらのコマンドをマスターするだけで、個人開発からチーム開発まで、幅広いシーンで Git を活用できるようになります。
選定基準は以下の通りです。
選定基準 | 説明 |
---|---|
使用頻度 | 日常的な開発で頻繁に使用する |
重要度 | Git の基本概念を理解するのに必須 |
安全性 | 初心者が使っても大きな問題が起きにくい |
汎用性 | 様々なプロジェクトで共通して使える |
mermaidflowchart TD
basic[基本操作] --> init[git init]
basic --> add[git add]
basic --> commit[git commit]
basic --> status[git status]
check[確認操作] --> log[git log]
check --> diff[git diff]
branch[ブランチ操作] --> branch_cmd[git branch]
branch --> checkout[git checkout]
branch --> merge[git merge]
remote[リモート操作] --> clone[git clone]
このような段階的なアプローチにより、各コマンドの役割と関係性を明確に理解できます。
段階的な習得アプローチ
10のコマンドを一度に覚えようとするのではなく、以下の4つのステップに分けて段階的に習得していきます。
ステップ1:基本操作をマスター(1-4週目) まずは Git の基本的な仕組みを理解するために、最も重要な4つのコマンドから始めます。この段階では、一人でローカル環境での作業に集中します。
ステップ2:履歴管理を理解(5-6週目) 次に、変更履歴の確認方法を学びます。これにより、自分の作業の振り返りや問題の特定ができるようになります。
ステップ3:ブランチ機能を活用(7-10週目) 複数の機能を並行して開発できるブランチ機能を習得します。これができるようになると、実際の開発現場で通用するスキルが身につきます。
ステップ4:リモート連携をマスター(11-12週目) 最後に、GitHub などのリモートリポジトリとの連携方法を学びます。これにより、チーム開発やオープンソース貢献への道が開けます。
実践的な使い方重視
各コマンドの説明では、理論的な解説よりも実際の使用場面を重視します。「こんな時にこのコマンドを使う」という具体的なシチュエーションを提示することで、実際の開発現場ですぐに活用できる知識を身につけられます。
また、よくあるエラーやその対処法も併せて紹介することで、初心者が安心して Git を使えるようサポートします。机上の理論ではなく、現場で本当に役立つスキルの習得を目指しましょう。
具体例
1. git init - リポジトリの初期化
Git での作業を始める際に最初に実行するコマンドが git init
です。このコマンドは、現在のフォルダを Git リポジトリとして初期化し、バージョン管理を開始できる状態にします。
新しいプロジェクトを始める際の手順を見てみましょう。
bash# 新しいプロジェクトフォルダを作成
mkdir my-first-project
cd my-first-project
bash# Git リポジトリとして初期化
git init
このコマンドを実行すると、以下のような出力が表示されます。
sqlInitialized empty Git repository in /Users/username/my-first-project/.git/
実行後、プロジェクトフォルダ内に .git
という隠しフォルダが作成されます。このフォルダには Git が管理するすべての情報(履歴、設定など)が保存されるため、削除しないよう注意が必要です。
使用シーン:
- 新しいプロジェクトを開始する時
- 既存のプロジェクトに Git を導入する時
- 練習用のリポジトリを作成する時
よくあるエラーと対処法:
arduinofatal: not a git repository (or any of the parent directories): .git
このエラーが表示される場合は、Git リポジトリではないフォルダで Git コマンドを実行しようとしています。git init
を実行してリポジトリを初期化するか、既存のリポジトリフォルダに移動してください。
2. git add - ファイルをステージング
git add
は、変更したファイルを「ステージングエリア」に追加するコマンドです。ステージングエリアとは、次回のコミットに含める変更を一時的に保管する場所のことです。
まずは簡単なファイルを作成してみましょう。
bash# テキストファイルを作成
echo "Hello, Git!" > readme.txt
bash# 特定のファイルをステージング
git add readme.txt
bash# すべての変更をステージング
git add .
bash# 特定の拡張子のファイルをまとめてステージング
git add "*.js"
ステージングの概念を図で理解してみましょう。
mermaidflowchart LR
working[作業ディレクトリ] -->|git add| staging[ステージングエリア]
staging -->|git commit| repo[リポジトリ]
working -.->|git add で選択| file1[readme.txt]
working -.->|まだ追加していない| file2[index.html]
この仕組みにより、変更したファイルの中から、コミットに含めたいものだけを選択できます。例えば、複数のファイルを編集しているが、そのうち一部だけをコミットしたい場合に便利です。
使用シーン:
- 新しいファイルを作成した時
- 既存のファイルを編集した時
- 複数の変更の中から一部だけをコミットしたい時
便利なオプション:
bash# 削除されたファイルも含めてすべての変更をステージング
git add -A
# 対話的にファイルを選択してステージング
git add -i
3. git commit - 変更をコミット
git commit
は、ステージングエリアにある変更を正式にリポジトリに記録するコマンドです。各コミットには、変更内容を説明するメッセージを付けることができます。
基本的なコミットの方法を見てみましょう。
bash# コミットメッセージを含めてコミット
git commit -m "最初のコミット: readme.txt を追加"
bash# より詳細なメッセージを書きたい場合(エディタが開きます)
git commit
bash# ステージングとコミットを同時に行う(追跡済みファイルのみ)
git commit -am "既存ファイルの修正をコミット"
良いコミットメッセージの書き方は重要です。以下のような形式を推奨します。
diffタイプ: 簡潔な変更内容の要約(50文字以内)
詳細な説明(必要に応じて)
- 変更の理由
- 影響範囲
- 注意点など
コミットメッセージの例:
bashgit commit -m "feat: ユーザー登録機能を追加"
git commit -m "fix: ログイン時のバリデーションエラーを修正"
git commit -m "docs: README にセットアップ手順を追加"
使用シーン:
- 機能の実装が完了した時
- バグ修正が完了した時
- ドキュメントを更新した時
- 定期的な進捗保存として
4. git status - 状態確認
git status
は、現在のリポジトリの状態を確認するためのコマンドです。どのファイルが変更されているか、どのファイルがステージングされているかなど、重要な情報を表示します。
bash# リポジトリの現在の状態を確認
git status
出力例を見てみましょう。
vbnetOn branch main
Your branch is up to date with 'origin/main'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: index.html
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
style.css
この出力から以下のことがわかります。
状態 | 説明 |
---|---|
Changes to be committed | ステージング済みで、次のコミットに含まれるファイル |
Changes not staged for commit | 変更されているが、まだステージングされていないファイル |
Untracked files | Git が管理していない新しいファイル |
bash# より簡潔な出力
git status --short
# または
git status -s
簡潔な出力例:
cssA index.html
M readme.txt
?? style.css
使用シーン:
- 作業を開始する前の状態確認
- git add や git commit の前の確認
- 何を変更したか忘れた時
- エラーの原因を調べる時
5. git log - 履歴確認
git log
は、コミット履歴を確認するためのコマンドです。過去の変更内容や作業の進捗を把握するのに重要な役割を果たします。
bash# 基本的なログ表示
git log
bash# 各コミットを一行で表示
git log --oneline
bash# グラフ表示でブランチの関係を可視化
git log --graph --oneline
bash# 最新の3つのコミットのみ表示
git log -3
出力例を見てみましょう。
yamlcommit 1a2b3c4d5e6f7g8h9i0j (HEAD -> main)
Author: Taro Yamada <taro@example.com>
Date: Mon Aug 21 10:30:00 2023 +0900
feat: ユーザー登録機能を追加
commit 9z8y7x6w5v4u3t2s1r0q
Author: Taro Yamada <taro@example.com>
Date: Sun Aug 20 15:45:00 2023 +0900
fix: ログイン時のバリデーションエラーを修正
便利なオプション:
bash# 変更されたファイル名も表示
git log --name-only
# 変更の統計情報を表示
git log --stat
# 特定の作者のコミットのみ表示
git log --author="Taro Yamada"
# 特定期間のコミットを表示
git log --since="2023-08-01" --until="2023-08-31"
使用シーン:
- プロジェクトの進捗を確認したい時
- 特定の変更がいつ行われたかを調べる時
- バグの原因となったコミットを探す時
- 作業レポートを作成する時
6. git diff - 差分確認
git diff
は、ファイルの変更内容を詳細に確認するためのコマンドです。何が変更されたかを正確に把握することで、意図しない変更を防ぎ、コードレビューの品質向上にも役立ちます。
bash# 作業ディレクトリとステージングエリアの差分
git diff
bash# ステージングエリアと最新コミットの差分
git diff --staged
# または
git diff --cached
bash# 特定のファイルの差分のみ表示
git diff readme.txt
bash# 2つのコミット間の差分
git diff HEAD~1 HEAD
diff の出力例を見てみましょう。
diffdiff --git a/readme.txt b/readme.txt
index 1234567..abcdefg 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,3 +1,4 @@
# My Project
このプロジェクトについて説明します。
+新しい機能を追加しました。
この出力の読み方:
記号 | 意味 |
---|---|
- | 削除された行 |
+ | 追加された行 |
@@ -1,3 +1,4 @@ | 変更箇所の行番号情報 |
mermaidflowchart TD
working[作業ディレクトリ] -->|git diff| staging[ステージングエリア]
staging -->|git diff --staged| commit[最新コミット]
commit -->|git diff HEAD~1| previous[前のコミット]
便利なオプション:
bash# 変更されたファイル名のみ表示
git diff --name-only
# 単語単位での差分表示
git diff --word-diff
# 行数の統計情報も表示
git diff --stat
使用シーン:
- コミット前に変更内容を確認したい時
- 意図しない変更が含まれていないかチェックする時
- 他の人の変更内容を理解したい時
- デバッグ時に変更箇所を特定したい時
7. git branch - ブランチ操作
git branch
は、ブランチの作成、確認、削除を行うコマンドです。ブランチとは、メインの開発ラインから分岐して、独立した作業環境を作る機能です。
bash# 現在のブランチ一覧を表示
git branch
bash# 新しいブランチを作成
git branch feature/user-registration
bash# ブランチを削除
git branch -d feature/completed-task
bash# 強制的にブランチを削除(未マージでも削除)
git branch -D feature/experimental
ブランチの概念を図で理解してみましょう。
mermaidgitGraph
commit id: "Initial"
commit id: "基本機能"
branch feature/login
checkout feature/login
commit id: "ログイン画面"
commit id: "認証処理"
checkout main
commit id: "バグ修正"
merge feature/login
commit id: "リリース準備"
この図が示すように、main ブランチから feature/login ブランチを分岐させ、ログイン機能を開発した後、main ブランチに統合(マージ)しています。
ブランチ命名のベストプラクティス:
bash# 機能開発
git branch feature/user-profile
git branch feature/payment-system
# バグ修正
git branch fix/login-error
git branch fix/responsive-layout
# ホットフィックス
git branch hotfix/security-patch
使用シーン:
- 新しい機能の開発を始める時
- バグ修正を独立して行いたい時
- 実験的な変更を試したい時
- 複数の機能を並行して開発する時
ブランチ一覧の出力例:
bash* main
feature/user-registration
fix/login-bug
アスタリスク(*)が付いているのが現在のブランチです。
8. git checkout/switch - ブランチ切り替え
ブランチ間を移動するためのコマンドです。Git 2.23 以降では git switch
が推奨されていますが、git checkout
も広く使われています。
bash# ブランチを切り替え(checkout)
git checkout feature/user-registration
bash# ブランチを切り替え(switch - 新しい方法)
git switch feature/user-registration
bash# ブランチを作成して同時に切り替え
git checkout -b feature/new-feature
# または
git switch -c feature/new-feature
bash# 前のブランチに戻る
git checkout -
# または
git switch -
ブランチ切り替え時の注意点を確認しましょう。
未コミットの変更がある場合:
vbneterror: Your local changes to the following files would be overwritten by checkout:
readme.txt
Please commit your changes or stash them before you switch branches.
Aborting
このエラーが発生した場合の対処法:
bash# 方法1: 変更をコミットしてから切り替え
git add .
git commit -m "作業中の変更を保存"
git checkout feature/other-branch
bash# 方法2: 変更を一時的に退避してから切り替え
git stash
git checkout feature/other-branch
# 後で変更を復元: git stash pop
使用シーン:
- 別の機能の開発に切り替える時
- main ブランチに戻って最新の状態を確認する時
- 複数のブランチを行き来しながら作業する時
- 他の人のブランチを確認する時
9. git merge - ブランチマージ
git merge
は、異なるブランチの変更を統合するコマンドです。機能開発が完了した際に、main ブランチに変更を取り込む際によく使用されます。
基本的なマージの手順を見てみましょう。
bash# main ブランチに切り替え
git checkout main
bash# feature ブランチの変更を main にマージ
git merge feature/user-registration
マージには主に3つのパターンがあります。
1. Fast-forward マージ main ブランチに新しいコミットがない場合、単純にポインタを移動するだけでマージが完了します。
mermaidgitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature
2. Three-way マージ main ブランチにも新しいコミットがある場合、新しいマージコミットが作成されます。
bash# マージコミットメッセージを指定
git merge feature/payment-system -m "決済システム機能をマージ"
3. コンフリクト(競合)が発生した場合 同じファイルの同じ箇所を異なるブランチで変更した場合、手動での解決が必要です。
sqlAuto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
コンフリクト解決の手順:
bash# コンフリクトが発生したファイルを確認
git status
ファイルを開くと、以下のような表示があります:
markdown<<<<<<< HEAD
メインブランチでの変更
=======
フィーチャーブランチでの変更
>>>>>>> feature/user-registration
手動で編集してコンフリクトを解決した後:
bash# 解決したファイルをステージング
git add readme.txt
# マージを完了
git commit
使用シーン:
- 機能開発が完了して main ブランチに統合する時
- 複数の開発者の変更を統合する時
- 実験的なブランチの成功した変更を取り込む時
10. git clone - リポジトリ複製
git clone
は、リモートリポジトリ(GitHub、GitLab など)をローカルにコピーするコマンドです。他の人のプロジェクトに参加したり、自分のプロジェクトを新しい環境で作業したりする際に使用します。
bash# GitHub からリポジトリをクローン
git clone https://github.com/username/repository-name.git
bash# SSH を使用してクローン(事前にSSHキーの設定が必要)
git clone git@github.com:username/repository-name.git
bash# 特定のディレクトリ名でクローン
git clone https://github.com/username/project.git my-project
bash# 特定のブランチのみクローン
git clone -b develop https://github.com/username/project.git
クローンプロセスを図で理解してみましょう。
mermaidflowchart LR
remote[リモートリポジトリ<br/>GitHub/GitLab] -->|git clone| local[ローカルリポジトリ]
local -.->|完全な履歴| history[コミット履歴]
local -.->|すべてのブランチ| branches[ブランチ情報]
local -.->|設定情報| config[リモート設定]
クローン後、以下の情報が自動的に設定されます。
設定項目 | 内容 |
---|---|
リモートURL | origin として元のリポジトリが設定される |
ブランチ | すべてのリモートブランチ情報が取得される |
履歴 | 完全なコミット履歴がローカルにコピーされる |
クローン後の確認:
bash# リモートリポジトリの確認
git remote -v
# ブランチ一覧の確認
git branch -a
# 最新のコミット履歴を確認
git log --oneline -5
使用シーン:
- オープンソースプロジェクトに貢献したい時
- 新しい開発環境をセットアップする時
- 他の開発者のコードを参考にしたい時
- プロジェクトのバックアップを作成したい時
よくあるエラーと対処法:
rustfatal: repository 'https://github.com/username/repo.git/' not found
このエラーは、リポジトリが存在しないか、アクセス権限がない場合に発生します。URL を確認し、プライベートリポジトリの場合は認証情報が正しく設定されているか確認してください。
まとめ
10 コマンドで始める Git ライフ
おめでとうございます!これで Git の基本操作を支える重要な10のコマンドをすべて学習いたしました。これらのコマンドをマスターすることで、以下のことができるようになります。
個人開発での活用:
- プロジェクトの履歴管理
- 実験的な変更の安全な実装
- バックアップとしての活用
- 作業の振り返りと分析
チーム開発での活用:
- 複数人での並行開発
- コードレビューのスムーズな実施
- 変更履歴の共有と追跡
- 競合の解決とマージ
各コマンドの関係性を改めて整理してみましょう。
段階 | コマンド | 主な用途 |
---|---|---|
基本操作 | git init, git add, git commit, git status | リポジトリ管理の基礎 |
履歴確認 | git log, git diff | 変更内容の把握と分析 |
ブランチ操作 | git branch, git checkout, git merge | 並行開発とコード統合 |
リモート連携 | git clone | チーム開発とコード共有 |
次のステップへの道筋
基本の10コマンドをマスターした皆さんには、以下のような学習の道筋をおすすめします。
短期目標(1-2ヶ月):
- GitHub の基本操作(プルリクエスト、イシュー管理)
git push
とgit pull
によるリモート同期.gitignore
ファイルの作成と管理- コミットメッセージの品質向上
中期目標(3-6ヶ月):
git rebase
による履歴の整理git stash
による作業の一時退避- タグ機能による版数管理
- Git フローやGitHub フローの理解
長期目標(6ヶ月以上):
- 高度なマージ戦略の習得
- Git hooks による自動化
- 大規模プロジェクトでの運用ノウハウ
- オープンソースプロジェクトへの貢献
Git は奥が深いツールですが、今回学習した10のコマンドがあれば、ほとんどの開発作業を問題なく進められます。最初は完璧を目指さず、日々の開発で少しずつ使いながら慣れていくことが重要です。
エラーが発生しても慌てず、git status
で状況を確認し、適切なコマンドで対処する習慣を身につけてください。Git を使いこなせるようになると、開発効率が大幅に向上し、より安心してコードを書けるようになります。
皆さんの Git ライフが充実したものになることを心よりお祈りしております。一歩ずつ、確実にスキルアップしていきましょう!
関連リンク
公式ドキュメント
学習リソース
ツールとサービス
- GitHub - 最も人気のある Git ホスティングサービス
- GitLab - DevOps プラットフォーム統合型 Git サービス
- Sourcetree - 無料の Git GUI クライアント
- GitKraken - 高機能な Git GUI クライアント
コミュニティと質問サイト
追加の学習トピック
- Git Flow ワークフロー
- GitHub Flow ガイド
- Semantic Versioning - バージョン管理のベストプラクティス
- Conventional Commits - コミットメッセージの規約
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来