几乎每个程序员都经历过「final_v2_真的最后版.docx」式的崩溃。文件改着改着，自己都分不清哪个是最新的、哪次改坏了。Git 就是为终结这种混乱而生的——它给文件的每一次修改拍一张「快照」，你想回到哪次都行。

一、仓库、工作区、暂存区

Git 管理的目录叫「仓库（repository）」。你平时编辑文件的地方叫「工作区」，改完之后，Git 并不会自动记录，而是让你先挑要记录哪些改动，放进「暂存区（stage）」，再一次性提交。

这套「工作区 → 暂存区 → 仓库」的三段式，初学觉得多余，用熟了才发现灵活：你可以把一次大的改动拆成几个逻辑清晰的提交，而不是把所有乱七八糟的修改混在一起。

二、commit：一次有说明的快照

commit 就是把暂存区的内容存成仓库里的一个版本，附带一段你写的描述（"修复登录崩溃""新增导出功能"）。这些描述日后比代码本身还重要——它记录了「当时为什么这么改」。

好的提交习惯是「小而专一」：一个提交只做一件事。这样将来某次改动出问题，你能精准定位到是哪次提交引入的，而不是面对一个塞了十项改动的大杂烩。

三、分支：平行宇宙

分支（branch）是 Git 最被低估的能力。默认你在 main 主线上工作；想试一个新功能又怕搞乱主线，就开一条分支，在分支上随便折腾，成功了再合并回主线，失败了直接丢弃，主线毫发无损。

多人协作时，每个人一条分支，互不干扰，最后合并。这就是「feature 分支」工作流的基础。理解分支，才算真正理解 Git 为什么适合团队。

四、远程仓库与 push/pull

本地仓库存在你电脑上，远程仓库（如 GitHub、GitLab）是放在服务器上的同一份。你本地的提交通过 push 上传，pull 把别人的改动拉下来。clone 则是第一次把整个远程仓库复制到本地。

冲突就发生在合并时：两个人都改了同一行，Git 不知道听谁的，就把冲突标记出来让你人工裁决。初看吓人，其实就是「选 A 的、选 B 的、还是各取一半」，解决后标记已处理再提交即可。

五、.gitignore：别什么都提交

仓库里有些东西不该进版本控制：依赖目录（node_modules）、编译产物、本地配置、日志、密钥文件。它们要么体积巨大，要么每台机器不同，要么涉密。.gitignore 文件就是一张「黑名单」，告诉 Git 这些路径直接忽略。

手写容易漏规则，用 .gitignore 生成器 勾选你的技术栈（Node、Python、前端框架等），自动生成一份靠谱的忽略清单，比凭记忆写稳得多。

六、README：仓库的门面

别人（或几个月后的你）打开仓库，第一眼看的是 README。它该说清楚：这个项目干嘛的、怎么装、怎么跑、基本用法。一个没有 README 的仓库，别人接入成本高，你自己过段时间也看不懂。

起项目时顺手用 README 生成器 搭个骨架（标题、简介、安装、用法、许可证），再填具体内容，比面对空白文档容易开工。

七、版本号：语义化版本

项目对外发布时，版本号不是随便写的。1.2.3 通常对应「主版本.次版本.修订号」：主版本变了代表不兼容的大改，次版本代表向后兼容的新功能，修订号代表修 bug。这套规则叫 SemVer。

依赖别人的库时，版本号决定你能不能安全升级。用 SemVer 比较器 比对两个版本号的大小关系，能快速判断「从 2.3.0 升到 2.4.1 会不会有破坏性改动」。

八、心态：先会用，再求精通

新手不必一上来啃透 rebase、cherry-pick、git 内部对象模型。先把「改完 add、commit、push，要回退就 checkout 老版本」这套日常跑顺，遇到特殊需求再查。Git 的本质就一句话：给改动留痕，让过去可回溯，让协作不打架。

小结：仓库三段式（工作区/暂存/仓库）、commit 留说明、分支平行实验、远程 push/pull、.gitignore 挡垃圾、README 当门面、SemVer 管版本。概念通了，命令自然就记住了。