Git 不只是“提交代码”的工具。它更像开发过程的黑匣子：你改过什么、为什么改、谁看过、怎么上线、出了问题怎么退回来，最后都会落到 Git 里。这篇不是 Git 教材，而是一份能放在手边的参考手册。目标很简单：你看完后，知道日常开发该用哪些命令，团队协作还要补哪些动作，遇到 AI 生成代码时怎么让 Git 保护你。看文章配图找原文阅读体验更好。Git 到底解决什么问题从版本备份到分布式协作早期写代码，最朴素的版本管理是复制目录：project-final、project-final2、project-final-really-final。它能保留一点历史，但不能回答三个关键问题：这一行是谁改的？为什么这样改？两个人同时改同一个文件，怎么合起来？集中式版本控制把代码放在服务器上，开发者从服务器检出、提交。它解决了多人协作，但服务器是中心。网络断了，很多操作就受限；中心挂了，团队就停。Git 的核心变化是分布式。每个开发者本地都有完整历史，不只是当前文件。你可以离线提交、查看历史、切分分支、回滚实验，等网络恢复再同步到远端。Git 诞生于 2005 年，由 Linus Torvalds 为 Linux 内核开发创建。当时 Linux 内核社区需要一个速度快、能支撑大量分支和补丁协作、同时不依赖单一中心的版本控制系统。这个背景决定了 Git 的性格：快、强、偏底层，也有一点不迁就新手。Git 的优势Git 的优势可以压成四句话：本地完整历史：大多数查询、分支、提交都不需要联网。分支很轻：开分支几乎没有心理负担，适合实验。内容可追溯：提交、作者、时间、差异、关联 issue 都能留下证据。协作可自动化：PR、CI、部署、代码审查、Release 都能围绕 Git 事件运行。它也有代价：概念多，命令多，错误操作看起来吓人。解决办法不是背完所有命令，而是建立正确心智模型。Git 心智模型：四个区域先记住四个区域，Git 的大部分命令都是在它们之间移动内容。区域含义典型动作工作区你正在编辑的文件修改、删除、创建文件暂存区下一次提交要包含的内容git add本地仓库已经形成历史的提交git commit、git log远端仓库团队共享的仓库git push、git pull工作区：你正在编辑的地方工作区就是项目目录里当前能看到的文件。你新建、修改、删除文件，最先都发生在这里。判断工作区状态，主要看两件事：git status：哪些文件被修改、删除或新增。git diff：这些修改具体是什么。工作区的内容还不是历史，也不会自动进入下一次提交。它只是你的当前现场。暂存区：下一次提交的清单暂存区可以理解为“本次提交购物车”。你通过git add把工作区里的一部分改动放进去，下一次git commit只会提交暂存区里的内容。它的价值是让你拆分提交：一个文件里有两类改动，可以用git add -p只提交其中一类。一次开发里既改逻辑又改文档，可以拆成两个提交。AI 一次改了很多文件，可以先挑最确定的一部分入库。有一个容易让新人迷惑的点：Git 也允许你不显式经过git add，直接提交某个已经被 Git 跟踪的文件。git commit src/auth/login.py -m "fix(auth): handle expired token"这条命令的意思是：把src/auth/login.py当前工作区里的改动直接放进本次提交。它确实“绕过了你手动 add 的步骤”，但不是绕过了 Git 的提交模型，Git 内部仍然会为这次提交准备一份快照。这个写法适合非常确定只提交一个已跟踪文件的场景。它有两个限制：对新文件无效。新文件还没被 Git 跟踪，仍然要先git add new_file.py。容易漏看 diff。新人最好先用git add、git diff --staged建立习惯，再考虑这种快捷写法。本地仓库：已经形成历史的提交本地仓库存放你机器上的完整提交历史。git commit之后，改动才真正变成一条可追溯记录。本地仓库能做很多离线操作：git log看历史。git switch切分支。git revert或git restore恢复问题。git rebase -i整理尚未共享的提交。只要还没 push，本地提交通常仍是你的个人工作区，可以适度整理。远端仓库：团队共享的历史远端仓库是团队协作的公共位置，例如 GitHub、GitLab、Gitea 上的仓库。git push后别人才能看到你的提交，git fetch或git pull后你才能看到别人的提交。一旦进入远端，历史就不再只属于你。公共分支上要更谨慎：不随意强推。不改写别人依赖的提交。通过 PR、CI、review 让改动可检查。很多 Git 问题都来自没分清这四层。比如文件还在工作区，就不能指望别人看到；文件只 add 了，还没 commit，就还不是历史；本地 commit 了但没 push，别人也拿不到。基本命令：够你独立完成开发这组命令不花哨，但够你从拉代码、建分支、改文件、提交、同步到恢复误改，独立完成绝大多数开发工作。初始化和获取代码场景命令示例第一次拿到远端项目git clone urlgit clone git@github.com:example/shop-api.git把本地目录变成仓库git initmkdir notes cd notes git init查看远端地址git remote -vgit remote -v日常开发里，clone用得更多。init通常用于新项目。看状态和差异场景命令示例看哪些文件改了、哪些已暂存git statusgit status看工作区还没暂存的差异git diffgit diff src/auth/login.py看已经暂存、准备提交的差异git diff --stagedgit diff --staged用一行图形看提交历史git log --oneline --graph --decorategit log --oneline --graph --decorate -10好习惯是：提交前一定看status和diff。不要把“我以为改了这些文件”当成事实。提交一组完整改动场景命令示例把文件放进暂存区git add filegit add src/auth/login.py tests/test_login.py
Git 不只是“提交代码”的工具。它更像开发过程的黑匣子：你改过什么、为什么改、谁看过、怎么上线、出了问题怎么退回来，最后都会落到 Git 里。这篇不是 Git 教材，而是一份能放在手边的参考手册。目标很简单：你看完后，知道日常开发该用哪些命令，团队协作还要补哪些动作，遇到 AI 生成代码时怎么让 Git 保护你。看文章配图找原文阅读体验更好。Git 到底解决什么问题从版本备份到分布式协作早期写代码，最朴素的版本管理是复制目录：project-final、project-final2、project-final-really-final。它能保留一点历史，但不能回答三个关键问题：这一行是谁改的？为什么这样改？两个人同时改同一个文件，怎么合起来？集中式版本控制把代码放在服务器上，开发者从服务器检出、提交。它解决了多人协作，但服务器是中心。网络断了，很多操作就受限；中心挂了，团队就停。Git 的核心变化是分布式。每个开发者本地都有完整历史，不只是当前文件。你可以离线提交、查看历史、切分分支、回滚实验，等网络恢复再同步到远端。Git 诞生于 2005 年，由 Linus Torvalds 为 Linux 内核开发创建。当时 Linux 内核社区需要一个速度快、能支撑大量分支和补丁协作、同时不依赖单一中心的版本控制系统。这个背景决定了 Git 的性格：快、强、偏底层，也有一点不迁就新手。Git 的优势Git 的优势可以压成四句话：本地完整历史：大多数查询、分支、提交都不需要联网。分支很轻：开分支几乎没有心理负担，适合实验。内容可追溯：提交、作者、时间、差异、关联 issue 都能留下证据。协作可自动化：PR、CI、部署、代码审查、Release 都能围绕 Git 事件运行。它也有代价：概念多，命令多，错误操作看起来吓人。解决办法不是背完所有命令，而是建立正确心智模型。Git 心智模型：四个区域先记住四个区域，Git 的大部分命令都是在它们之间移动内容。区域含义典型动作工作区你正在编辑的文件修改、删除、创建文件暂存区下一次提交要包含的内容git add本地仓库已经形成历史的提交git commit、git log远端仓库团队共享的仓库git push、git pull工作区：你正在编辑的地方工作区就是项目目录里当前能看到的文件。你新建、修改、删除文件，最先都发生在这里。判断工作区状态，主要看两件事：git status：哪些文件被修改、删除或新增。git diff：这些修改具体是什么。工作区的内容还不是历史，也不会自动进入下一次提交。它只是你的当前现场。暂存区：下一次提交的清单暂存区可以理解为“本次提交购物车”。你通过git add把工作区里的一部分改动放进去，下一次git commit只会提交暂存区里的内容。它的价值是让你拆分提交：一个文件里有两类改动，可以用git add -p只提交其中一类。一次开发里既改逻辑又改文档，可以拆成两个提交。AI 一次改了很多文件，可以先挑最确定的一部分入库。有一个容易让新人迷惑的点：Git 也允许你不显式经过git add，直接提交某个已经被 Git 跟踪的文件。git commit src/auth/login.py -m "fix(auth): handle expired token"这条命令的意思是：把src/auth/login.py当前工作区里的改动直接放进本次提交。它确实“绕过了你手动 add 的步骤”，但不是绕过了 Git 的提交模型，Git 内部仍然会为这次提交准备一份快照。这个写法适合非常确定只提交一个已跟踪文件的场景。它有两个限制：对新文件无效。新文件还没被 Git 跟踪，仍然要先git add new_file.py。容易漏看 diff。新人最好先用git add、git diff --staged建立习惯，再考虑这种快捷写法。本地仓库：已经形成历史的提交本地仓库存放你机器上的完整提交历史。git commit之后，改动才真正变成一条可追溯记录。本地仓库能做很多离线操作：git log看历史。git switch切分支。git revert或git restore恢复问题。git rebase -i整理尚未共享的提交。只要还没 push，本地提交通常仍是你的个人工作区，可以适度整理。远端仓库：团队共享的历史远端仓库是团队协作的公共位置，例如 GitHub、GitLab、Gitea 上的仓库。git push后别人才能看到你的提交，git fetch或git pull后你才能看到别人的提交。一旦进入远端，历史就不再只属于你。公共分支上要更谨慎：不随意强推。不改写别人依赖的提交。通过 PR、CI、review 让改动可检查。很多 Git 问题都来自没分清这四层。比如文件还在工作区，就不能指望别人看到；文件只 add 了，还没 commit，就还不是历史；本地 commit 了但没 push，别人也拿不到。基本命令：够你独立完成开发这组命令不花哨，但够你从拉代码、建分支、改文件、提交、同步到恢复误改，独立完成绝大多数开发工作。初始化和获取代码场景命令示例第一次拿到远端项目git clone urlgit clone git@github.com:example/shop-api.git把本地目录变成仓库git initmkdir notes cd notes git init查看远端地址git remote -vgit remote -v日常开发里，clone用得更多。init通常用于新项目。看状态和差异场景命令示例看哪些文件改了、哪些已暂存git statusgit status看工作区还没暂存的差异git diffgit diff src/auth/login.py看已经暂存、准备提交的差异git diff --stagedgit diff --staged用一行图形看提交历史git log --oneline --graph --decorategit log --oneline --graph --decorate -10好习惯是：提交前一定看status和diff。不要把“我以为改了这些文件”当成事实。提交一组完整改动场景命令示例把文件放进暂存区git add filegit add src/auth/login.py tests/test_login.py
