Gitを理解する第一歩は、ファイルが今「どこ」にあり、「どこ」へ向かおうとしているのかを把握することです。Gitには大きく分けて4つの領域が存在します。
Gitのコミット履歴は、単なる一本の線ではありません。 DAG (Directed Acyclic Graph: 有向非巡回グラフ) と呼ばれるデータ構造です。
各コミットは「親」へのポインタを持っており、ブランチ（mainやdevelop）は特定のコミットを指し示す単なる ポインタ（動くラベル） に過ぎません。
checkout から switch/restore へ2026年現在、多くの現場では従来の git checkout は使われなくなっています。なぜなら、checkout は「ブランチの切り替え」と「ファイルの復元」という全く異なる2つの役割を持っていたため、誤操作のリスクが高かったからです。
Git v2.23以降、これらは明示的に分割されました。
| 役割 | 旧コマンド (Deprecating) | 新コマンド (Modern) |
|---|---|---|
| ブランチ切り替え | git checkout <branch> | git switch <branch> |
| 新ブランチ作成 | git checkout -b <new> | git switch -c <new> |
| ファイル変更破棄 | git checkout -- <file> | git restore <file> |
| ステージから降ろす | git reset HEAD <file> | git restore --staged <file> |
# 安全に新しいブランチを作成して切り替え
$ git switch -c feature/new-logic
# 前のブランチに即座に戻る
$ git switch -
標準的な開発サイクルを StepRoadmap で確認しましょう。
git pull origin main --rebase
git switch -c create-feature
git add .
git commit -m "feat: add new visualization"
git push origin create-feature
Tip : git pull --rebase を使うことで、マージコミットを抑え、綺麗な一本の履歴を保つことができます。
モノリポジトリ（巨大なリポジトリ）で作業する場合、リポジトリ全体をローカルに落とすのは非効率です。2026年では git sparse-checkout が標準的に利用されます。
# 必要なディレクトリだけをチェックアウト対象にする
$ git sparse-checkout set src/components docs/これにより、数ギガバイトあるリポジトリでも、必要な数メガバイト分だけで作業を開始できます。
Gitで迷ったら、「今、グラフのどの点（コミット）にいて、ブランチというポインタがどこを指しているのか」を図解して考える癖をつけましょう。
この記事が、あなたのGitライフをより円滑にすることを願っています。