Git バージョン管理の用語集（46語）

ビルド生成物・ログ・秘密情報などを記述して履歴から除外する。1行1パターンで、ワイルドカードやフォルダ指定が使える。すでにコミット済みのファイルには効かない点に注意。

Gitでの変更は、編集しただけの「作業ツリー」、git addでステージングした「インデックス（ステージ）」、コミット済みの「HEAD」という3段階を経て記録される。git diffはこの3つのうちどの2つを比べるかによって、素のdiff・--staged・HEAD付きの3通りの見え方に分かれる。

git blameコマンドを使うと、ファイルの各行の左に、その行を最後に変更したコミットのハッシュ・作成者・日付が表示される。単語の意味は「非難」だが、実務での目的は責任追及ではなく、値や実装の背景にある理由をコミットメッセージから読み解くことにある。

タグや過去のコミットハッシュを直接checkoutしたときに入る状態。この状態で新しくコミットを作っても、どのブランチにも属さないため見失いやすい。作業を続けたい場合は git switch -c で新しいブランチを作ってからコミットするのが安全。

マージ先に新しいコミットがなければ、ブランチのポインタを先へ動かすだけで統合が完了し、マージコミットは作られない。履歴が一直線に保たれるのが特徴で、記録を残すため--no-ffであえて無効にする流儀もある。

git add ファイル名で個別に、git add .でまとめて登録できる。addしただけでは履歴に残らず、commitして初めて記録される点を混同しやすい。新規作成したファイルはaddするまでGitの管理外のまま。

履歴・ブランチを含む全体をコピーし、複製元をoriginとして自動登録する。既存プロジェクトへ参加するときの最初の一歩になる。ZIPダウンロードと違い履歴ごと手に入るので、そのまま開発を続けられる。

-mオプションでメッセージを添えて実行するのが基本形。記録されるのはステージ済みの変更だけで、addし忘れた変更は含まれない。-aオプションで変更済みファイルのaddを兼ねる省略形もある。

引数なしでは作業ツリーとステージの差、--stagedでステージと直前コミットの差を表示する。コミット前の見直しや、コミット同士の比較に使う。削除行は-、追加行は+の記号付きで示される。

取ってきた内容はorigin/mainのようなリモート追跡ブランチに置かれ、内容を確認してから自分でマージできる。いきなり統合まで行うpullと違い、他人の変更を吟味してから取り込みたいときの安全な選択肢になる。

実体はgit fetchとgit mergeを続けて行う合わせ技。共同作業では作業開始前にpullして最新化するのが習慣になる。取得だけで統合しないfetchとの違いを押さえておくと、履歴のトラブルを避けやすい。

コミットは手元に貯まるだけなので、pushして初めて他のメンバーやGitHub上に反映される。リモート側が先に進んでいると拒否されるため、先にpullで取り込んでから押し直すのが定石。

--softは履歴だけ、--hardは作業ツリーごと戻すなど、モードによって影響範囲が変わる。履歴そのものを書き換えるため、push済みのコミットに使うと他人の履歴と食い違う。公開後の取り消しにはrevertを選ぶのが安全。

履歴を消すのではなく「逆の変更」を上に積むため、push済みの変更も安全に取り消せる。履歴自体を巻き戻すresetとの違いが重要で、共有ブランチではrevert、手元だけの履歴ならresetと使い分ける。

急な割り込み作業やブランチ切り替えの前に、未コミットの変更を棚に仮置きできる。git stash popで退避した変更を呼び戻す。コミットするほどではない中途半端な状態を扱うときに重宝する。

ビルド生成物・ログ・秘密情報など履歴に入れたくないものを.gitignoreに書いておくと、git statusやgit addの対象から外れる。ただし一度コミット済みのファイルは書いても無視されない点がつまずきやすい。

通常は現在のブランチの最新コミットを指す。ブランチを切り替えると HEAD の指す先も移動する。

次のコミットの親になる位置を示し、ブランチを切り替えるとHEADも一緒に移動する。HEAD~1のように相対指定して「1つ前のコミット」を参照でき、git resetやgit diffの引数として頻繁に登場する。

GitHubなどのホスティングサービス上で作成する、コード変更の取り込み依頼。差分の確認・コメントによるレビュー・追加コミットでの修正・承認・mergeという一連の流れをひとつの画面上で管理できる。pushしただけでは自動でmainに反映されず、レビューという人の確認工程を挟むのが特徴。

git stash push を実行するたびにスタック状の一覧へ積まれる、退避済みの変更セット。新しいものほど番号が0に近くなる。中身は git stash show -p で差分として確認でき、git stash pop・apply で作業ツリーへ戻せる。

git clone を実行すると、リモートの全履歴がダウンロードされ、複製元が origin として自動登録される。

Pull Request上でコメントを付け合いながら、コードの正しさ・読みやすさ・既存実装との整合性などを確認する作業。指摘は個人攻撃ではなく品質向上のための対話であり、チーム開発では欠かせない工程として定着している。

コミットには変更内容のほか、作成者・日時・メッセージが含まれる。各コミットには固有のハッシュ値（識別子）が付き、あとから参照できる。

git commitで実行し、変更内容・日時・作者・メッセージがひとまとまりで保存される。各コミットにはハッシュと呼ばれるIDが付き、後から差分の確認や巻き戻しの目印になる。「小さく意味のある単位で刻む」のが上達の基本。

発生するとファイル内に<<<<<<<などの目印が挿入され、どちらの変更を残すか人間が編集して決める。解決後にgit addとcommitで完了する。怖がられがちだが、目印を消して望む形に直すだけで、リポジトリが壊れるわけではない。

mergeやrebaseで自動統合できない箇所に挿入される目印。<<<<<<< HEADから=======までが自分側、そこから>>>>>>>ブランチ名までが取り込む側の内容を表す。人間がどちらを残すか判断し、マーカー行ごと削除してから add・commitすることで解消する。

git addで変更をステージに載せ、載せた分だけがgit commitで記録される。編集した変更のうち一部だけをコミットに含めるといった調整ができる。インデックスとも呼ばれ、作業ツリーとコミットの間に挟まる緩衝地帯にあたる。

git add で変更をステージに載せ、git commit でステージ上の内容だけを記録する。これにより、関係する変更だけを選んでまとめられる。

互換性のない大きな変更でメジャーを、互換性を保った機能追加でマイナーを、バグ修正などの小さな直しでパッチを、それぞれ増やすという広く使われるルール。semverと略される。厳密な運用はプロジェクトによって差があるが、形式自体は共通言語として通じやすい。

コミットハッシュの代わりに人間が読める名前で特定の地点を参照できるようにする仕組み。ブランチと違い、新しいコミットが増えても自動では動かない。名前・日付・メッセージを持つ注釈付きタグと、名前だけの軽量タグがある。

いつ誰が何を変更したかを履歴として残し、必要なら任意の時点へ復元できる。Gitはその代表的なツールで、複数人での共同開発や、壊れる前の状態への巻き戻しに欠かせない。「最終版_v2」のような手動コピー保存の混乱を根本から解消する。

diffやlog -pで表示される、-（削除）と+（追加）の記号で変更内容を表現した形式。この形式のまま保存すれば他の環境に変更を適用することもできるため、パッチと呼ばれる。Gitのコミット・マージ処理の内部でも、この差分の考え方が基礎になっている。

本流（多くは main）に影響を与えずに新機能や修正を進められる。仕上がったら元のブランチにマージして取り込む。

mainなどの本流から分岐を作り、新機能や実験を隔離して開発できる。完成したらマージで本流へ取り込む。実体はコミットを指す軽いポインタなので、作成や切り替えは一瞬で済み、気軽に作って消してよい。

履歴が一直線につながる場合はそのまま進む（fast-forward）。両方で変更があると衝突（コンフリクト）が起き、手作業での解決が必要になることがある。

git mergeで実行し、双方の変更が自動的に合成される。ただし同じ箇所を双方で変更しているとコンフリクトが起きて手動解決が必要になる。取り込み先のブランチへ移動してから実行するのが基本手順。

実体は隠しフォルダ .git で、コミット・ブランチなどの履歴がすべてここに記録される。手元の作業フォルダとリモート（サーバー側）の両方にリポジトリが存在しうる。

git initで作られる.gitディレクトリを核とし、コミット履歴・ブランチ・設定を丸ごと抱える。手元の「ローカルリポジトリ」とGitHubなどの「リモートリポジトリ」があり、両者を同期しながら開発を進めるのが基本の形。

手元のリポジトリと push / pull でやり取りして変更を共有する。既定のリモートは慣習的に origin という名前が使われる。

手元のローカルリポジトリと対になる存在で、pushで送り、pull/fetchで取り込む。originという別名で登録されるのが慣例。共同開発のハブであると同時に、個人開発でもバックアップ先として重要な役割を果たす。

アプリやライブラリを配布・公開した時点のコード状態を指す。あとから同じ状態を再現できるよう、リリースのたびにコミットへ注釈付きタグを打ち、バージョン番号とあわせて記録するのが一般的な運用。

通常の --force は、リモート側に自分の知らない新しいコミットがあってもそのまま上書きしてしまう。--force-with-lease は、自分が最後に取得した時点からリモートが変わっていないことを確認したうえでのみpushを実行し、他者の変更を誤って消す事故を防ぐ。

リポジトリの履歴から取り出された「いま見えているファイル群」を指す。ここでの編集はまだ履歴に残っておらず、git addでステージ、git commitで記録という段階を踏んで初めて保存される。ワーキングツリーとも呼ぶ。

working tree clean とも呼ばれる。この状態であれば、ブランチの切り替えやpull・rebaseなどの操作を変更の巻き込みを気にせず安全に行える。stashやcommitはこの状態を作るための代表的な手段。

git add で一度もステージングされていないファイルを指す。git status では Untracked files として表示される。git stash push は既定でこれを退避対象に含めないため、含めたい場合は -u オプションが必要になる。

コミットの内容を直接編集すると、そのコミットを識別するハッシュ値も変わる。手元だけの未共有コミットなら安全だが、すでにpushして他者が取り込んだコミットを書き換えると、リモートとローカルで履歴が食い違い、混乱や上書き事故につながる。