MENU
  1. ホーム
  2. Development
  3. 【2025年保存版】GitHubコマンド一覧

【2025年保存版】GitHubコマンド一覧

Development
目次

はじめに

プログラミングを始めたばかりの方にとって、GitやGitHubは「よく聞くけど、実際何をするものなのかわからない」という存在かもしれません。

Gitとは、プログラムのファイルの変更履歴を管理するツールです。簡単に言えば、「いつ、誰が、どのファイルを、どのように変更したか」を記録して管理してくれる便利なツールです。

GitHubは、そのGitで管理されたプロジェクトをインターネット上で保存・共有できるサービスです。

本記事では、Git・GitHubを初めて使う方でも理解できるよう、各コマンドの意味や使う場面を丁寧に解説しています。「なぜこのコマンドを使うのか」から「どんな時に使うのか」まで、初心者目線で説明していきます。

この記事を読むことで、Git・GitHubの基本操作ができるようになり、プログラミング学習がより効率的になります。

1. 基本的なリポジトリ操作

リポジトリの初期化・クローン

git init – 新しいプロジェクトを始める

# 新しいGitリポジトリを初期化
git init

これは何をするコマンド？
git initは、現在のフォルダを「Gitで管理するプロジェクト」に変える魔法のコマンドです。

使う場面：

  • 新しいプロジェクトを始める時
  • 既存のフォルダをGitで管理したい時

実行すると：フォルダ内に.gitという隠しフォルダが作られ、そこに変更履歴が保存されるようになります。

git clone – 他の人のプロジェクトをコピーする

# 既存のリポジトリをクローン（コピー）
git clone https://github.com/username/repository.git

# 特定のブランチをクローン
git clone -b branch-name https://github.com/username/repository.git

# 浅いクローン（履歴を制限して軽量化）
git clone --depth 1 https://github.com/username/repository.git

「Clone（クローン）」って何？
Cloneとは「複製」という意味です。つまり、インターネット上にあるプロジェクトを自分のパソコンにコピーすることです。

なぜCloneするの？

  • 他の人が作ったプログラムを勉強したい時
  • チームのプロジェクトに参加する時
  • オープンソースのプロジェクトを改良したい時

実行すると：指定したプロジェクトがフォルダごと自分のパソコンにコピーされます。

実用例：

# 有名なJavaScriptライブラリをクローン
git clone https://github.com/facebook/react.git

このコマンドを実行すると、Reactのソースコードがすべてダウンロードされます。

リモートリポジトリの管理

「リモートリポジトリ」って何？

リモートリポジトリとは、インターネット上（GitHub等）に保存されているプロジェクトのことです。

例えば：

  • 自分のパソコン = ローカルリポジトリ
  • GitHub上 = リモートリポジトリ

この2つを連携させることで、作業内容をバックアップしたり、他の人と共有したりできます。

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

# リモートリポジトリの確認
git remote -v

# リモートリポジトリのURL変更
git remote set-url origin https://github.com/username/new-repository.git

# リモートリポジトリを削除
git remote remove origin

各コマンドの意味：

  • git remote add origin URL – 「origin」という名前でリモートリポジトリを登録
  • git remote -v – 現在登録されているリモートリポジトリを確認
  • git remote set-url – リモートリポジトリのURLを変更
  • git remote remove – リモートリポジトリの登録を削除

「origin」って何？
originは、メインのリモートリポジトリにつける慣習的な名前です。「大元」という意味で、多くの開発者がこの名前を使います。

2. ファイルの変更管理

ステージング・コミット操作

「ステージング」と「コミット」って何？

プログラムの変更を保存するには、2つのステップがあります：

  1. ステージング – 「この変更を保存する準備をする」
  2. コミット – 「実際に変更を保存する」

なぜ2ステップなの？
複数のファイルを変更した時、「このファイルは保存したいけど、こっちはまだ途中だから保存したくない」ということがあります。ステージングで保存したいファイルだけを選んでから、コミットで一括保存できるのです。

ステージング（変更を選ぶ）

# 特定のファイルをステージング
git add filename.txt

# 全ての変更をステージング
git add .

# 対話的にファイルを選択
git add -i

# ファイルの一部のみステージング（上級者向け）
git add -p filename.txt

各コマンドの使い分け：

  • git add ファイル名 – 特定のファイルだけ選ぶ
  • git add . – 全部のファイルを選ぶ（よく使う）
  • git add -i – 対話的にファイルを選ぶ（メニューが表示される）
  • git add -p – ファイルの一部だけ選ぶ（難しいので最初は使わなくてOK）

コミット（変更を保存する）

# コミットの実行
git commit -m "コミットメッセージ"

# ステージングとコミットを同時実行
git commit -am "変更をコミット"

コミットメッセージって何？
コミットメッセージは、「この変更で何をしたか」を記録するメモです。

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

git commit -m "ログイン機能を追加"
git commit -m "バグ修正: ログインエラーを解決"
git commit -m "デザインを更新: ボタンの色を変更"

悪いコミットメッセージの例：

git commit -m "修正"  # 何を修正したかわからない
git commit -m "asdf"  # 意味不明

変更状況の確認

今何が変更されたのかを確認しよう

プログラムを作っていると、「あれ？さっき何を変更したんだっけ？」となることがあります。そんな時に使うのがこれらのコマンドです。

# 今の状況を確認（これが一番大事！）
git status

# 変更内容を詳しく確認
git diff

# ステージング済みファイルの変更内容を確認
git diff --staged

# 特定ファイルの変更内容を確認
git diff filename.txt

# 統計情報付きの変更概要
git diff --stat

各コマンドでできること：

  • git status – 「何が変更されたか」を一覧表示（まずこれを実行）
  • git diff – 「具体的にどこが変わったか」を詳細表示
  • git diff --staged – ステージングしたファイルの変更内容を確認
  • git diff ファイル名 – 特定のファイルだけの変更を確認
  • git diff --stat – 変更されたファイルの数をサッと確認

初心者の方へ：
最初は git status だけ覚えておけば十分です。このコマンドで今の状況が分かり、「次に何をすればいいか」も教えてくれます。

3. ブランチ管理

「ブランチ」って何？

ブランチとは、「作業用の分身」のようなものです。

例えば、既存のプログラムに新しい機能を追加したい時：

  1. メインのプログラムはそのままにしておく
  2. 別のブランチで新機能を作る
  3. 新機能が完成したらメインに結合する

こうすることで、作業中にメインのプログラムが壊れる心配がありません。

ブランチの作成・切り替え

# 今あるブランチを確認
git branch

# 新しいブランチを作る（しかし、これだけではまだ切り替わらない）
git branch feature-branch

# 新しいブランチを作って、すぐにそのブランチに切り替える（よく使う）
git checkout -b feature-branch

# 新しいコマンド（推奨）
git switch -c feature-branch

# 既存のブランチに切り替える
git checkout main
git switch main

# リモートブランチをローカルにコピー
git checkout -b local-branch origin/remote-branch

各コマンドの意味：

  • git branch – 今あるブランチを一覧表示（現在いるブランチに*が付く）
  • git branch ブランチ名 – ブランチを作るだけ
  • git checkout -b ブランチ名 – ブランチを作ってすぐに切り替える
  • git switch -c ブランチ名 – 上と同じ（新しいコマンド）
  • git checkout ブランチ名 – 既存のブランチに切り替える
  • git switch ブランチ名 – 上と同じ（新しいコマンド）

初心者の方へ：
最初は git checkout -b ブランチ名 でブランチを作って、git checkout ブランチ名 で切り替えることだけ覚えておけば十分です。

ブランチの削除・管理

使わなくなったブランチを片付ける

作業が完了したブランチは、放置しておくとどんどん溜まっていきます。定期的に整理しましょう。

# ローカルブランチの削除（安全な削除）
git branch -d feature-branch

# 強制削除（マージされていないブランチも削除）
git branch -D feature-branch

# リモートブランチの削除
git push origin --delete feature-branch

# リモートで削除されたブランチのローカル参照を削除
git remote prune origin

# 全ブランチ（リモート含む）の表示
git branch -a

各コマンドの意味：

  • git branch -d ブランチ名 – 安全な削除（マージ済みのブランチのみ削除）
  • git branch -D ブランチ名 – 強制削除（作業中のブランチも削除）
  • git push origin --delete ブランチ名 – GitHub上のブランチを削除
  • git remote prune origin – リモートで削除されたブランチの情報をローカルからも削除
  • git branch -a – ローカルとリモートの全ブランチを表示

初心者の方へ：
最初は git branch -d ブランチ名 だけ覚えておけば十分です。これは安全な削除なので、間違って大事なデータを消す心配がありません。

4. コミット履歴の操作

履歴の確認・検索

「何をしたか」を振り返る

プログラミングをしていると、「あれ？このバグっていつからあったんだっけ？」ということがよくあります。そんな時に過去の変更履歴を確認するのがこれらのコマンドです。

# コミット履歴を表示（詳細版）
git log

# コミット履歴を表示（簡潔版）
git log --oneline

# ブランチの結合状況を図で表示
git log --graph --oneline --all

# 最近2週間の変更だけ表示
git log --since="2 weeks ago"

# 特定の人がした変更だけ表示
git log --author="username"

# 特定ファイルの変更履歴を表示
git log -p filename.txt

# コミットごとの統計情報を表示
git log --stat

各コマンドでできること：

  • git log – コミットの詳細情報を表示（メッセージ、日時、作者など）
  • git log --oneline – コミットを1行で表示（見やすい）
  • git log --graph --oneline --all – ブランチの結合を線で表示
  • git log --since="2 weeks ago" – 最近2週間の変更だけ表示
  • git log --author="名前" – 特定の人がした変更だけ表示
  • git log -p ファイル名 – 特定ファイルの変更内容を表示
  • git log --stat – コミットごとの変更ファイル数を表示

初心者の方へ：
最初は git log --oneline だけ覚えておけば十分です。これで過去のコミットを簡潔に確認できます。

コミットの修正・取り消し

# 直前のコミットメッセージを修正
git commit --amend -m "修正されたメッセージ"

# 直前のコミットにファイルを追加
git add forgotten-file.txt
git commit --amend --no-edit

# 特定のコミットを取り消し（新しいコミットで打ち消し）
git revert commit-hash

# HEADから指定数分のコミットを取り消し
git reset --soft HEAD~3  # コミットのみ取り消し、変更は保持
git reset --mixed HEAD~3 # ステージングも解除
git reset --hard HEAD~3  # 全て取り消し（危険）

注意事項：git reset --hardは変更を完全に失うため、使用前にバックアップを取ることを強く推奨します。

5. マージ・リベース操作

「マージ」って何？

マージとは、別々のブランチで行った作業を「合体」させることです。

例えば：

  • メインのプログラム（mainブランチ）
  • 新機能を追加した作業（feature-branchブランチ）

この2つを合体させて、メインのプログラムに新機能を反映させるのがマージです。

マージの実行

基本的なマージ

# 現在のブランチに他のブランチをマージ
git merge feature-branch

これは何をするコマンド？
現在いるブランチに、feature-branchの変更を取り込みます。

使う場面：

  • 新機能の開発が完了した時
  • バグ修正をメインブランチに反映したい時

より安全なマージ

# Fast-forwardマージを無効化（マージコミットを作成）
git merge --no-ff feature-branch

「Fast-forward」と「No fast-forward」の違いって何？

  • Fast-forward: 変更履歴が一直線になる（シンプル）
  • No fast-forward: 「ここでブランチを合体した」という記録が残る（わかりやすい）

初心者の方へ：
最初は普通の git merge だけ覚えておけば十分です。

マージで問題が起きた時

# マージコンフリクトの確認
git status
git diff

# マージの中止（やり直したい時）
git merge --abort

「マージコンフリクト」って何？
マージコンフリクトとは、同じファイルの同じ場所を、別々のブランチで違うように変更してしまった時に起こる問題です。

例：

  • Aさんが「こんにちは」と書いた
  • Bさんが同じ場所に「Hello」と書いた
  • Gitは「どっちが正しいの？」と迷ってしまう

解決方法：

  1. 問題のあるファイルを開く
  2. どちらの変更を採用するか決める
  3. git add でファイルを追加
  4. git commit でマージを完了

リベースって何？

リベースは、「履歴をきれいに整理する」機能です。

マージとリベースの違い：

  • マージ: 「2つのブランチを合体した」という記録が残る
  • リベース: あたかも最初から1つのブランチで作業していたかのように見える

リベースの活用

基本的なリベース

# 現在のブランチを他のブランチにリベース
git rebase main

これは何をするコマンド？
現在のブランチの変更を、mainブランチの最新状態の上に「乗せ直し」ます。

使う場面：

  • メインブランチが更新された後、自分の作業を最新の状態に合わせたい時
  • 履歴をきれいに保ちたい時

対話的リベース（上級者向け）

# 対話的リベース（コミット履歴の整理）
git rebase -i HEAD~5

これは何をするコマンド？
過去5つのコミットを編集・整理できるメニューが表示されます。

できること：

  • コミットメッセージの修正
  • 複数のコミットを1つにまとめる
  • コミットの順番を変更
  • 不要なコミットを削除

初心者の方へ：
このコマンドは慣れてから使いましょう。最初は無理に使う必要はありません。

リベースで問題が起きた時

# リベースの継続（問題を解決した後）
git rebase --continue

# リベースの中止（やり直したい時）
git rebase --abort

# 競合解決後のリベース続行
git add resolved-file.txt
git rebase --continue

リベース中にコンフリクトが起きたら：

  1. コンフリクトを解決する
  2. git add で解決したファイルを追加
  3. git rebase --continue でリベースを続行

リベースのメリット：

  • 履歴がまっすぐで見やすい
  • 「誰がいつ何をしたか」がわかりやすい
  • チーム開発で混乱が少ない

リベースの注意点：

  • 他の人と共有しているブランチではリベースを使わない
  • 迷ったら git rebase --abort で中止してやり直し

6. リモートリポジトリとの同期

「プッシュ」と「プル」って何？

リモートリポジトリとの同期とは、自分のパソコン（ローカル）とGitHub（リモート）の間でファイルを同期することです。

  • プッシュ: 自分のパソコンの変更をGitHubに送る
  • プル: GitHubの変更を自分のパソコンに取り込む

プッシュ・プル操作

基本的なプッシュ

# 変更をリモートにプッシュ
git push origin main

これは何をするコマンド？
自分のパソコンで行った変更を、GitHub上のmainブランチに送信します。

使う場面：

  • コミットした変更をGitHubに保存したい時
  • 他の人に自分の変更を共有したい時

新しいブランチをプッシュ

# 新しいブランチをリモートにプッシュ
git push -u origin feature-branch

「-u」って何？
-uは「upstream」の略で、「今後このブランチは自動的にリモートのこのブランチと連携する」という設定です。

なぜ便利？
一度 -u を使うと、次回からは git push だけでプッシュできるようになります。

強制プッシュ（注意が必要）

# 強制プッシュ（注意が必要）
git push --force-with-lease origin main

いつ使うの？
通常のプッシュが拒否された時に使います。ただし、他の人の変更を消してしまう可能性があるので注意が必要です。

セキュリティ考慮：
--force-with-leaseは--forceより安全で、他の開発者の変更を誤って上書きするリスクを減らします。

初心者の方へ：
最初のうちは強制プッシュは使わず、問題が起きたら先輩や同僚に相談しましょう。

基本的なプル

# リモートの変更を取得してマージ
git pull origin main

これは何をするコマンド？
GitHub上のmainブランチの最新変更を、自分のパソコンに取り込みます。

使う場面：

  • 他の人が変更した内容を自分のパソコンに反映したい時
  • 作業を始める前に最新の状態にしたい時

フェッチ（取得のみ）

# リモートの変更を取得（マージはしない）
git fetch origin

プルとフェッチの違いって何？

  • プル: 取得 + 自動的にマージ
  • フェッチ: 取得のみ（マージは手動）

フェッチが便利な場面：

  • 他の人の変更を確認してからマージしたい時
  • まず何が変更されたかを見たい時

プルリベース

# プルリベース（マージコミットを作らない）
git pull --rebase origin main

通常のプルとプルリベースの違い：

  • 通常のプル: マージコミットが作られる
  • プルリベース: 履歴がまっすぐになる

初心者の方へ：
最初は通常の git pull だけ覚えておけば十分です。

タグ管理

「タグ」って何？

タグとは、特定のコミットに「目印」を付ける機能です。主に「このバージョンをリリースしました」という記録に使います。

例えば：

  • v1.0.0 = 最初のリリース
  • v1.1.0 = 機能追加
  • v1.1.1 = バグ修正

タグの作成・管理

# シンプルなタグの作成
git tag v1.0.0

# 注釈付きタグの作成（推奨）
git tag -a v1.0.0 -m "バージョン1.0.0リリース"

# タグ一覧の表示
git tag

# タグをリモートにプッシュ
git push origin v1.0.0

# 全てのタグをプッシュ
git push origin --tags

# タグの削除
git tag -d v1.0.0
git push origin --delete v1.0.0

各コマンドの意味：

  • git tag v1.0.0 – シンプルなタグを作成
  • git tag -a v1.0.0 -m "メッセージ" – 説明付きタグを作成（推奨）
  • git tag – 現在あるタグを一覧表示
  • git push origin v1.0.0 – 特定のタグをGitHubに送信
  • git push origin --tags – 全てのタグをGitHubに送信
  • git tag -d v1.0.0 – ローカルのタグを削除
  • git push origin --delete v1.0.0 – GitHub上のタグを削除

バージョン管理への活用：
セマンティックバージョニング（v1.2.3形式）を使用することで、リリース管理が効率化されます。

バージョン番号の意味：

  • v1.2.3 – メジャーバージョン（大きな変更）
  • v1.2.3 – マイナーバージョン（機能追加）
  • v1.2.3 – パッチバージョン（バグ修正）

7. 高度なコマンド・トラブルシューティング

作業の一時保存（Stash）

「Stash（スタッシュ）」って何？

Stashとは、「今の作業を一時的にしまっておく」機能です。まるで「作業用の引き出し」のようなものです。

こんな時に便利：

  • 作業途中で急に別のブランチに移る必要がある
  • 「あ、間違えた！一旦元に戻したい」という時
  • 作業を途中で保存して、後で再開したい時

Stashの基本操作

# 現在の作業を一時保存
git stash

# メッセージ付きで保存（何を保存したかわかりやすい）
git stash save "作業中の機能実装"

# Stash一覧の表示
git stash list

# 最新のStashを復元（取り出して削除）
git stash pop

# 特定のStashを復元（取り出すだけ、削除しない）
git stash apply stash@{2}

# Stashの削除
git stash drop stash@{0}

# 全てのStashを削除
git stash clear

各コマンドの意味：

  • git stash – 今の変更を「引き出し」にしまう
  • git stash save "メッセージ" – 何をしまったかメモ付きで保存
  • git stash list – 引き出しに何がしまってあるか確認
  • git stash pop – 一番新しいものを取り出して使う
  • git stash apply stash@{2} – 3番目のものを取り出す（番号は0から始まる）
  • git stash drop stash@{0} – 一番新しいものを削除
  • git stash clear – 引き出しの中身を全部捨てる

実用例：

# 1. 機能Aを作業中...
git add .
git stash save "機能Aの実装途中"

# 2. 緊急でブランチを切り替え
git checkout main
git checkout -b bugfix

# 3. バグ修正完了後、元の作業に戻る
git checkout feature-A
git stash pop  # 作業を復元

ファイル追跡の管理

「追跡」って何？

追跡とは、Gitがファイルの変更を「監視」することです。

  • 追跡中: ファイルの変更がGitに記録される
  • 追跡停止: ファイルがあってもGitは無視する

ファイル追跡の操作

# ファイルを追跡対象から除外（.gitignoreに追加後）
git rm --cached filename.txt

# ディレクトリを追跡対象から除外
git rm -r --cached directory/

# ファイル名の変更を追跡
git mv old-name.txt new-name.txt

# 削除されたファイルの追跡を停止
git rm filename.txt

各コマンドの使い分け：

  • git rm --cached ファイル名 – ファイルは残すけど、Gitには無視してもらう
  • git rm -r --cached ディレクトリ名 – フォルダごと無視してもらう
  • git mv 古い名前 新しい名前 – ファイル名変更をGitに教える
  • git rm ファイル名 – ファイルを削除して、Gitからも除外

注意点：
git rm --cachedは追跡を停止するだけで、ローカルファイルは削除されません。ファイルは残ったまま、Gitが監視をやめるだけです。

実用例：

# パスワードファイルを間違ってコミットしてしまった場合
echo "passwords.txt" >> .gitignore  # .gitignoreに追加
git rm --cached passwords.txt       # 追跡を停止
git commit -m "パスワードファイルを追跡対象から除外"

問題解決・デバッグ

バグの原因を特定する

プログラムにバグがあった時、「いつからこのバグがあったのか」を調べるためのコマンドです。

# 特定の変更を導入したコミットを特定
git bisect start
git bisect bad          # 問題のあるコミット
git bisect good HEAD~10 # 問題のないコミット

git bisectって何？
git bisectは「二分探索」という方法で、バグが混入したコミットを効率的に見つける機能です。

使い方：

  1. git bisect start – 調査開始
  2. git bisect bad – 「今のバージョンはバグがある」と報告
  3. git bisect good HEAD~10 – 「10個前のコミットは正常だった」と報告
  4. Gitが自動的にその間のコミットをチェック
  5. 各コミットでテストして git bisect good または git bisect bad を続ける

ファイルの変更履歴を調べる

# ファイルの各行の最終変更者を表示
git blame filename.txt

git blameって何？
ファイルの各行について「いつ、誰が、どのコミットで変更したか」を表示します。

使う場面：

  • バグのある行を書いた人を特定したい時
  • 特定のコードがいつ追加されたかを知りたい時

Git の設定確認・変更

# 設定の確認・変更
git config --list
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

設定でできること：

  • git config --list – 現在の設定を全て表示
  • git config --global user.name "名前" – コミット時の名前を設定
  • git config --global user.email "メール" – コミット時のメールアドレスを設定

「–global」って何？
--globalを付けると、そのパソコン全体での設定になります。付けないと、そのプロジェクトだけの設定になります。

リポジトリの健康診断

# リポジトリの整合性チェック
git fsck

git fsckって何？
リポジトリに問題がないかチェックする「健康診断」コマンドです。

いつ使う？：

  • リポジトリが壊れていないか心配な時
  • 何か変な動作をしている時

デバッグ効率化：
git bisectは二分探索でバグの原因となったコミットを効率的に特定できる強力なツールです。大きなプロジェクトでバグの原因を探すときに威力を発揮します。

まとめ

GitHubコマンドの習得は、現代のWeb開発において必須のスキルです。

今回紹介した厳選コマンドを段階的に習得することで、開発効率が大幅に向上し、チーム開発でのコラボレーション能力も高まります。

特に以下のコマンドは、日常的な開発作業で頻繁に使用されるため、優先的に覚えることをおすすめします：

最優先で覚えるべきコマンド：

  • git add、git commit、git push（基本的なワークフロー）
  • git branch、git checkout/switch（ブランチ操作）
  • git pull、git merge（リモートとの同期）

効率化に役立つコマンド：

  • git stash（作業の一時保存）
  • git log --oneline --graph（履歴の可視化）
  • git rebase -i（コミット履歴の整理）

Git・GitHubを使いこなして、より効率的で品質の高い開発を実現しましょう！

Development
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
目次