Git
簡介
Linus Torvalds 在 2005 年為了管理 Linux kernel 開發而設計的分散式版本控制系統（distributed version control system，DVCS）。每個 clone 出來的本地倉庫都是完整副本（含全部歷史），不依賴中央伺服器即可 commit / branch / merge——這個性質讓 GitHub 等中央化託管平台能在 Git 之上架設社交化協作層，但仍保留每個開發者的離線自主性。Git 已是當代軟體工程的事實標準 VCS，本 vault 視角下也是 AI輔助開發 駐留 agent（如 Claude-Code）能對程式碼安全反覆修改的前置基礎設施。
重要事實
- 誕生背景：2005 年 BitKeeper 與 Linux kernel 社群授權糾紛後，Linus Torvalds 在數週內寫出 Git，宗旨是速度 / 簡單設計 / 對非線性開發的強支援 / 完全分散式。
- 三層心智模型（2026-05-01-十分鐘GitHub工作流 教程版本）：給新手最容易上手的拆法是 Remote（遠端共享倉庫，如 GitHub）/ Local Git（本地
.git/目錄，保存「你告訴 Git 的所有資訊」）/ Disk（編輯器看到的工作目錄狀態）三層；理解三層分離才能解釋「我改了檔案但 Git 不知道」「我 commit 了但 GitHub 沒變」「checkout 後 disk 自動變樣」這些日常困惑。正規版本還有 staging area（暫存區）作為 Local Git 與 Disk 之間的緩衝層——是git add的目的地。 - 核心命令家族（教程級別）：
- 取得 / 同步：
clone、fetch、pull - 檢視 / 切換：
status、diff、log、checkout、switch - 記錄修改：
add、commit、reset、restore - 分支 / 合併：
branch、merge、rebase、cherry-pick - 發佈：
push、push -f（rebase 後必要的 force push）
- 取得 / 同步：
- Branch 是廉價的：與舊式 VCS（CVS / SVN）相反，Git 的 branch 只是一個指向 commit 的指標，建立 / 刪除 / 切換成本極低——這是 GitHub工作流 為什麼能以 feature branch 為單位組織所有改動的根因。
- Rebase vs Merge 的選擇：rebase 把你的 commit「嫁接」到新基底之上、保持線性歷史，但會改寫 commit hash（故 push 時必須
-f）；merge 保留分叉並建立 merge commit。一般慣例：個人 feature branch 用 rebase 同步 main / 多人合作的長壽分支用 merge。 - Distributed 的核心意涵：每個 clone 都是完整倉庫——可以離線 commit、離線切 branch、離線看 log；網路恢復後再 push / pull 同步。對位 SVN「中央伺服器是真理唯一來源」的思維。
- 與 GitHub 的關係：Git 是底層協議與工具（命令列 + 物件模型）；GitHub 是 Git 之上最大的中央化託管平台 + 社交協作層（PR / Issues / Actions / wiki / 探索）。可以只用 Git 不用 GitHub（自架 / GitLab / Bitbucket / Gitea），但用 GitHub 必然在用 Git。
相關概念
- GitHub工作流 — Git 在開源 / 成熟團隊場景下的標準操作流程：feature branch + PR + squash-merge + 清理；本 vault 中 Git 命令的具體應用案例。
- Pull-Request — 不是 Git 原生功能，而是託管平台（GitHub / GitLab / Gitea）在 Git 之上加的 code review + 合併介面層；本質仍是請求把 branch A 的 commits merge 進 branch B。
- AI輔助開發 — Git 的 branch 隔離 + diff 檢視 + commit 歷史是 AI agent 大量產出代碼時的安全網：可以放手讓 agent 改、不滿意再 reset / checkout 回去；對位 Claude-Code 教程「Hooks 自動清技術債」與「自動 PR review」企業級用例的執行底層。
- 程式碼風格指南 — Git 的 PR / commit hooks（pre-commit / pre-push）是 style guide 自動化執行的基礎設施：能交給 formatter / linter 的就在 hook 層阻擋，符合 程式碼風格指南 「自動化原則」。
相關來源
- 2026-05-01-十分鐘GitHub工作流 — vault 中第一份系統處理 Git 命令層 + GitHub 工作流的來源；以「Remote / Local Git / Disk」三層心智模型介紹 clone → checkout -b → diff → add → commit → push → PR → squash-merge → 清理的完整 happy path
備註
建頁理由：作為 GitHub工作流 與 AI輔助開發 的共同前置工具，Git 在 vault 累積到第一個系統來源時即建獨立 entity 而非併入概念頁。理由：(1) 是具體 product，有版本演進、設計決策、許可證等實體屬性；(2) 與 GitHub 概念上必須分開（Git ≠ GitHub）；(3) 累積方向多元（command 細節 / 物件模型 / Git LFS / submodule / 替代 VCS 對位 / 與 AI agent 的整合範式）。
未來累積方向：(a) Git 物件模型（blob / tree / commit / tag）的概念深入；(b) 進階工作流（git-flow / trunk-based development / monorepo 策略）對位 GitHub工作流；(c) Git LFS / submodule / worktree 等較進階場景；(d) 與 Mercurial / Fossil / Pijul 等替代 VCS 的對位；(e) Git 在 AI agent 工作流中的具體用例累積（如 Claude Code worktree、自動 commit message 生成等）。