1.

git 用語一覧完全リファレンス（Repository / HEAD / Branch / Rebase / Stash 他）

▶
編集
この記事の要点
  • Repository = リポジトリ。Git の管理単位。.git/ ディレクトリにすべて入っている
  • HEAD = 現在チェックアウトしているコミットへのポインタ。通常はブランチ名を指す
  • Index (Staging) = コミット予定の変更を貯める中間領域。git add で入る
  • Origin = clone 元リモートの慣習名。Upstream = フォーク元 or 追跡先
  • Rebase ≠ Merge: rebase は履歴を線形に書き直す、merge はマージコミットを作る

Git 用語を理解する 3 つの軸

Git の用語は (1) 場所（リポジトリ / ワーキングツリー / インデックス）、(2) 状態を指すポインタ（HEAD / ブランチ / タグ）、(3) 操作（merge / rebase / fetch ...）の 3 軸で覚えると整理しやすくなります。

場所に関する用語

用語意味覚え方
Repository (リポジトリ)Git で管理する 1 プロジェクト分のデータ全体。コミット履歴、ブランチ、設定が .git/ 配下に「貯蔵庫」。git init で作る
Working Tree (ワーキングツリー)編集中のファイルが置かれている実際のディレクトリ「机の上」
Index / Staging Areaコミット予定の変更を貯める領域。git add で追加、git commit で確定「コミット直前の控え室」
Bare Repositoryワーキングツリーを持たないリポジトリ。サーバ用GitHub のサーバ側はベアリポジトリ
Remote (リモート)外部に置かれたリポジトリ（GitHub 等）の URL の別名git remote -v で確認

コミットとポインタ

用語意味備考
Commit (コミット)ある時点のスナップショット + 親コミット + 作者 + メッセージSHA-1 ハッシュ（40 文字）で識別。先頭 7 文字で省略可
SHA-1 Hashコミット ID。例: 4f1e2a8b...内容で決まるので改ざん検知になる
HEAD現在チェックアウトしている地点へのポインタ通常はブランチ名を指す（シンボリック参照）
Detached HEADHEAD がブランチではなく特定コミットを直接指す状態そのままコミットすると孤立する
Branch (ブランチ)特定コミットを指す動くポインタ。新コミットで自動前進refs/heads/<name>
Tag (タグ)特定コミットを指す動かないポインタ。リリース版にrefs/tags/<name>
Annotated Tagタグ自体に作者・日時・メッセージを持つタグgit tag -a v1.0 -m "Release 1.0"
Lightweight Tag単なるコミットへのポインタgit tag v1.0

リモート関連

用語意味
Origingit clone したリモートの慣習名。リモート 1 個目のデフォルト名
Upstream追跡対象のリモートブランチ、または OSS でフォーク元リポジトリ
Tracking Branchリモートブランチを追跡するローカルブランチ（git branch -vv）
Remote-tracking Branchリモートの状態を反映する読み取り専用ローカル参照（origin/main）
Refspecローカルとリモートの参照のマッピング指定。+refs/heads/*:refs/remotes/origin/*

同期系の操作

用語動作
Cloneリモートを丸ごとローカルに複製
Fetchリモート最新を取得（ローカルブランチは未変更、origin/main 等が更新）
Pullfetch + merge（または fetch + rebase）の合成コマンド
Pushローカルのコミットをリモートへ送信
Force Push履歴を上書きする push。--force-with-lease を推奨

履歴を統合する操作

用語動作履歴形
Merge2 系列のブランチを統合。3-way マージ。マージコミットを作る分岐が残る
Fast-forward Merge分岐がなければ単にポインタを進めるだけ直線
Rebaseブランチのコミットを別の基点の上に積み直す直線化
Interactive Rebase (-i)コミットを編集 / 順序入替 / squash整形済
Cherry-pick特定のコミットだけ取ってきて適用新コミット作成
Squash複数コミットを 1 つに統合（rebase の -i 内で操作）1 コミット化

履歴を巻き戻す系

用語動作用途
ResetHEAD と（必要なら）インデックス・ワーキングツリーを過去のコミットに戻す「無かったことに」
Revert指定コミットを打ち消す新しいコミットを作る履歴を残しつつ取り消し
ReflogHEAD の動きを記録するログ。reset で失った変更も取り戻せるgit reflog
Checkoutブランチ切替 or ファイル復元（Git 2.23+ は switch / restore 推奨）切替・復元
Restorecheckout の「ファイル復元」専用版（Git 2.23+）明確な意図
Switchcheckout の「ブランチ切替」専用版（Git 2.23+）明確な意図

差分系

用語意味
Diff差分。git diff でワーキングツリーとインデックスの差、--cached でインデックスと HEAD
Conflict (コンフリクト)マージ時、同じ部分を両方が変更していたため自動統合できない状態
Conflict Marker<<<<<<< HEAD ... ======= ... >>>>>>> branch
Blame各行を誰がいつ変更したか表示（git blame <file>）

退避・複数チェックアウト系

用語意味
Stash作業中の変更を一時退避（git stash で push、pop で復元）
Submodule別の Git リポジトリを自リポジトリに埋め込む。バージョンを固定追跡
Worktree1 つのリポジトリから複数のワーキングツリーを切り出す（git worktree add）
Sparse Checkout巨大リポジトリで一部のディレクトリだけチェックアウト

その他重要用語

用語意味
.gitignore追跡対象から除外するファイル / フォルダ
Hook特定タイミングで自動実行されるスクリプト（.git/hooks/）
Pull Request (PR) / Merge Request (MR)GitHub / GitLab 上のレビュー & マージ依頼。Git 本体の機能ではない
ForkGitHub 上で他人のリポジトリを自アカウントにコピーする操作。Git 本体の機能ではない
Pack File複数のオブジェクトを圧縮した .git/objects/pack/ のファイル
ObjectGit の内部単位（blob / tree / commit / tag の 4 種）
Blobファイル内容のスナップショット
Treeディレクトリ構造を表現するオブジェクト

コマンドと用語のマッピング

# Working Tree → Index に「ステージング」
git add file.txt

# Index → Repository に「コミット」
git commit -m "msg"

# Repository → Remote に「プッシュ」
git push origin main

# Remote → Repository に「フェッチ」
git fetch origin

# Remote → Repository → Working Tree に「プル」（fetch + merge）
git pull origin main

# 現在の状態を全部見る
git status      # Working / Index / HEAD の差
git log         # コミット履歴
git reflog      # HEAD の動き履歴
git branch -vv  # ブランチと追跡関係

覚えにくい用語のミニまとめ

  • Origin と Upstream の違い: 単独リポジトリなら同じことが多い。フォーク開発では origin = 自分のフォーク、upstream = 本家。
  • Fetch vs Pull: fetch は取得だけで安全、pull は取得 + 統合。
  • Reset vs Revert: reset は履歴を消す、revert は打ち消しコミットを足す（履歴を残す）。
  • Merge vs Rebase: merge は履歴が分岐、rebase は履歴を直線化（プッシュ済を rebase してはいけない）。
  • Tag vs Branch: branch は動く、tag は動かない（特定リリースの目印）。

FAQ

Q: Detached HEAD でコミットしてしまった、どう救う？
A: その場で git branch rescue でブランチを生やす。または git reflog でコミット SHA を確認し、新しいブランチを生やす。

Q: SHA-1 は衝突しない？
A: 理論上は衝突しうるが、Git は内容アドレスとして 160 ビット使うので実用的には衝突は無視可能。Linux Kernel / 大規模 OSS でも問題なく稼働。新規プロジェクトは SHA-256 サポートも始まっている。

Q: タグとブランチ、どちらでリリースを管理？
A: リリース版はタグ（動かない）、開発中はブランチ（動く）。v1.0.0 のような Semantic Versioning のタグが定石。

編集
Post Share
子ページ

子ページはありません

同階層のページ
  1. 用語一覧
  2. エラー一覧
  3. git本体のインストール(Linux)
  4. Linuxサーバーへのgit導入とクライアントのセットアップ
  5. リモートリポジトリをローカルリポジトリとしてクローンする方法
  6. リモートとローカルのリポジトリを同期(pull)する方法
  7. 設定の確認
  8. gitユーザー名とemailの設定
  9. リモートリポジトリの作成
  10. ローカルリポジトリの作成
  11. 新規ファイル/ディレクトリをインデックスに登録
  12. インデックスの登録状態を確認
  13. ローカルリポジトリの変更をコミット
  14. コミット履歴の確認
  15. クライアントからリモートリポジトリの接続設定、確認、削除
  16. リポジトリへのプッシュ
  17. リモートリポジトリからクライアントへのSSHクローン
  18. リモートとローカルの差分表示
  19. バージョンの確認
  20. プロキシの設定
  21. ローカルをリモートリポジトリの状態に戻す
  22. ブランチの作成, 一覧表示, 切り替え
  23. ブランチのマージと削除
  24. リベース
  25. .gitignoreの書き方
  26. .gitignoreの設定が反映されない場合
  27. 特定のファイルをgitの管理から外す方法
  28. 参照(ORIG_HEAD, HEAD, FETCH_HEAD)
  29. git rm [-r --cached] の取り消し
  30. 一部のディレクトリ/ファイルのみをリポジトリから復元する方法
  31. ローカルとリモートリポジトリの有無を同期
  32. pushの取消し方法
  33. マージツールの起動方法
  34. Gitで「MERGING」の状態
2026-06-11 07:12:00 guest 274

人気ページ

最近更新/作成されたページ