刚入职的新手，大概都有过这样的至暗时刻：
你小心翼翼地敲下git push，结果屏幕弹出一大堆红色的CONFLICT；
你试图用git pull解决冲突，却不小心把同事写了一下午的代码给覆盖了；
最后，你只能红着脸去找老同事求助。
老同事叹了口气，用命令行敲了几个你看不懂的指令，三下五除二解决了问题，顺便留下一句：“Git 基础还得补补啊。”
其实，很多新手在 Git 上栽跟头，并不是因为不够聪明，而是因为一开始就陷入了“死记硬背命令”的误区。Git 并不是一门玄学，它只是一套有规矩的“交通规则”。
今天，我们不讲复杂的底层原理，只聊最实用的“保命指南”。掌握这套心法，你也能在团队协作中如丝般顺滑。
搞懂“三区模型”：代码的打包发货之旅
很多新手最容易犯的错，就是改完代码直接commit，然后纳闷为什么远程仓库没更新。要解决这个问题，你只需要把 Git 想象成一个“打包发货”的流程。你的代码在提交前，必须经历三个区域：
- 工作区（你的办公桌）：你正在疯狂敲击键盘、修改文件的地方。这里的改动是零散的、未整理的。
- 暂存区（你的打包箱）：当你执行
git add时，你其实是在挑选这次要发走哪些文件。放进暂存区，意味着你确认了这些修改。 - 本地仓库（已贴单的快递）：当你执行
git commit时，代码正式被封箱，成为一条不可篡改的历史记录。
记住这个口诀：改完代码先add，确认无误再commit。千万不要把还在桌面上乱放的草稿，直接当成正式文件发出去。
团队协作模式：从单兵作战到流水线
在团队里，代码不能随便往主干上堆。根据项目的不同，我们通常有两种协作模式（以使用 VS Code 为例）：
简单模式（适合快速迭代的小项目）
在这种模式下，团队只有一条主线（比如main分支）。你的日常工作流非常简单：
- 开始工作前，先
pull一下最新代码。 - 切出你自己的个人分支（比如
feature/login）进行开发。 - 在个人分支上完成“工作区 → 暂存区 → 仓库区”的循环。
- 开发完成后，推送到远程，并在 VS Code 中发起一个 Pull Request（PR），请同事审核后再合并。
复杂模式（适合有严格发布周期的正规军）
大团队通常会设立beta（测试分支）和main（生产分支）。你的标准流水线是这样的：
- 在本地
beta分支拉取最新代码，然后切出你的个人分支。 - 在个人分支上安心写代码、做提交。
- 测试通过后，将个人分支合并回本地的
beta分支。 - 将本地的
beta推送到远程，等待测试通过后再由专人合并到main。
如果你使用的是 VS Code，这些操作完全不需要离开编辑器。点击左下角的分支图标，你就可以轻松创建、切换和删除分支；在左侧的源代码管理面板里，勾选文件、输入提交信息、推送代码，一切都有直观的图形化引导。
绝对不可逾越的红线
在团队协作中，有几条红线是无数前辈用“血泪”换来的，新手必须刻在脑子里：
红线一：永远只在“个人分支”上写代码
哪怕你只是修改了一个字母、一个标点符号，也绝对不要直接在beta或main上动刀。所有的改动，必须在你的个人分支上完成后再合并。
红线二：永远不要强行推送（Force Push）
当你遇到冲突或拉取失败时，绝对不要使用git push -f命令！该命令会覆盖掉别人已经推送到远程的代码，导致灾难性的数据丢失。遇到问题，请立刻向团队老手求助。
红线三：不要提交无关文件或敏感信息
不要盲目信任 IDE 的“全部提交”按钮。提交前务必看一眼变更列表，千万别把本地的编译产物、IDE 配置文件（如.idea、.vscode）甚至密码密钥推送到远程。这样的情况一般不会发生，因为项目管理员会为项目配置合理的.gitignore文件，但是新手往往会提交一些出乎管理员意料之外的、没有被.gitignore忽略的文件。
常见问题与自救指南
Q：不小心把不该提交的文件推上去了怎么办？
如果还没推送到远程，可以用git reset撤销提交；如果已经推送，千万不要用reset抹除历史，而是应该补充一个提交来删除该文件，并立刻把它加入.gitignore。
Q：合并时出现满屏的冲突标记（<<<<<<）怎么办？
不要慌，冲突不是错误，只是 Git 在问你“听谁的”。打开文件，找到冲突标记，和同事沟通后保留正确的代码，删掉标记，然后重新add和commit。
Q：操作失误，代码好像丢了？
Git 几乎不会丢数据。只要你commit过，哪怕分支被删了，也能通过git reflog找回你的“后悔药”。
其实，老同事之所以能行云流水地解决 Git 问题，只是因为他们踩过足够多的坑，形成了肌肉记忆。别怕犯错，带着这份指南，大胆地去提交你的第一个 PR 吧！