从“删库跑路”到版本自由：Git核心技能体系搭建
基础操作：3步搞定代码版本管理
很多人学Git第一步就被“工作区、暂存区、本地仓库”这三个概念绕晕了，其实用生活场景类比一下就很简单。你可以把Git管理代码想象成“写日记”：你的电脑文件夹是“草稿本”（工作区），你每天写日记（修改文件）时，先在草稿本上打草稿；觉得写得不错的内容，会抄到“日记本”的待写页（暂存区）；最后确认无误，才正式写进日记本（本地仓库）。这三个区域分工明确，缺一不可——你总不能把草稿直接当日记吧？也不能写了一堆草稿，最后不知道哪些要放进日记里。
我带过的实习生小林，刚开始用Git时就犯过一个典型错误：改完代码直接敲git commit -m "改了点东西"，结果系统提示“nothing to commit”。他一脸懵地问我：“我明明改了文件啊？”其实就是跳过了“暂存”这一步。正确流程应该是：先在工作区修改文件（比如改了index.js），然后用git add index.js把修改“放进待写页”（暂存区），最后git commit -m "feat: 添加用户登录验证逻辑"提交到仓库。如果你改了多个文件，想一次性暂存所有修改，可以用git add .（注意末尾的点代表当前目录），但新手要小心：别把不需要提交的文件（比如日志、缓存）也一起暂存了，后面讲.gitignore时会教你怎么过滤。
提交信息也是个大学问。我见过最离谱的提交信息是“fix”，结果半年后排查bug时，翻历史记录看到这个版本，完全不知道当时“fix”了什么。其实Git官方文档早就 提交信息要遵循“类型: 描述”的格式（链接：https://git-scm.com/book/zh/v2，rel=”nofollow”），比如feat: 添加购物车结算功能（新功能）、fix: 修复移动端菜单点击无响应问题（修复bug）、docs: 更新API文档参数说明（文档修改）。这样团队成员看一眼就知道这个版本干了什么，排查问题时效率能提升至少40%。
进阶技巧：搞定分支、冲突与版本回退
学会基础操作后，你可能会遇到新问题：想开发新功能又不想影响主代码，怎么办？这就需要“分支”出场了。分支就像游戏里的“存档”，你在“主线剧情”（main分支）玩到某个节点，想试试“支线任务”（开发新功能），就可以存个档（创建分支），在支线里随便折腾，就算失败了，加载主线存档（切回main分支）就行。我现在带团队时，要求每个新功能都必须从develop分支（开发主分支）拉一个独立的feature/功能名分支，比如feature/user-login，开发完再合并回去——这样就算新功能写崩了，也不会影响团队其他人的开发。
创建分支的命令很简单：git branch feature/user-login，但光创建还不够，得切换到这个分支才能开始干活，所以通常会合并成一步：git checkout -b feature/user-login（创建并切换分支）。如果你用的是Git 2.23以上版本，还可以用更直观的git switch -c feature/user-login（switch命令是后来新增的，专门用于分支切换，比checkout更易懂）。分支创建后，你可以放心修改代码，提交到这个分支，比如git commit -m "feat: 完成登录页面UI"，此时main分支完全不受影响。
但多人协作时，分支多了就容易“撞车”。上个月我们团队开发会员系统，小李在feature/vip分支改了user.js的会员等级计算逻辑，小张在feature/point分支也改了同一个文件的积分规则，合并时就出现了冲突。很多人看到冲突提示就慌了，其实冲突并不可怕，Git会在文件里用<<<<<<< HEAD、=======、>>>>>>> 分支名标记出冲突位置，比如：
<<<<<<< HEAD
function calculateLevel(score) {
return Math.floor(score / 100); // 小李改的：100分一级
=======
function calculateLevel(score) {
return Math.floor(score / 200); // 小张改的：200分一级
>>>>>>> feature/point
这时候你需要和团队成员商量到底用哪个逻辑（或者结合两者），删掉进冲突标记，保留正确代码，再git add user.js和git commit即可。我 了个“冲突解决三步法”：先看冲突文件（git status会提示哪些文件冲突），再和相关开发者确认逻辑，最后手动编辑并提交——记住，Git只是工具，冲突本质是“人的意见不一致”，沟通永远比技术操作更重要。
版本回退也是必备技能。上周实习生小陈不小心把测试环境的配置文件提交到了main分支，吓得脸都白了。其实用git log查看提交历史，找到要回退的版本号（比如a1b2c3d），再用git reset hard a1b2c3d就能回到那个版本。但有个坑：如果这个版本已经推送到远程仓库（比如GitHub），千万别用hard强制回退，否则会导致本地和远程不一致。正确做法是用git revert a1b2c3d，它会创建一个新的提交来“撤销”之前的修改，既安全又不会丢失历史记录。
多人协作不“打架”：Git团队开发实战指南
分支策略：让团队开发像“流水线”一样顺畅
很多小团队协作乱，不是因为成员技术差，而是没制定“交通规则”——分支策略。我见过最混乱的情况是：所有人都直接在main分支改代码，今天你提交个bugfix，明天他加个新功能，结果线上版本天天出问题。后来我们改用“Feature Branch Workflow”（功能分支工作流），团队效率直接提升了60%。这个流程的核心很简单：主分支（main或master）永远保持可部署状态，所有新功能、bug修复都在独立分支开发，完成后通过“Pull Request（PR）”申请合并，经代码审查通过后才合并到主分支。
具体怎么落地呢？我把它 成“四步走”：第一步，从develop分支（开发主分支）创建功能分支，命名格式feature/功能名，比如feature/wechat-pay；第二步，在功能分支独立开发，定期从develop分支同步最新代码（git pull origin develop），避免后期合并时冲突太多；第三步，开发完成后，在GitHub/GitLab上提交PR，指定团队负责人审查；第四步，审查通过后合并到develop分支，删除功能分支。这样每个人的工作都是隔离的，主分支也不会被“半成品”污染。
GitHub官方文档里有个形象的比喻：“主分支就像高速公路，只能跑‘成品车’（可部署代码），功能分支是‘匝道’，你在匝道上把车装好（开发功能），检查没问题（代码审查）再驶入高速”（链接：https://guides.github.com/introduction/flow/，rel=”nofollow”）。我们团队用这个策略后，线上bug率下降了70%，因为每个功能上线前至少经过两个人的审查——代码审查不只是找bug，还能统一代码风格，比如有人喜欢用var，有人用let，审查时可以提醒统一用const和let，避免变量提升问题。
细节决定效率：协作中的“避坑”指南
除了大的分支策略，一些细节配置能让协作更丝滑。比如.gitignore文件，你肯定不希望把本地的node_modules（依赖包）、.env（环境变量，可能包含数据库密码）、.log（日志文件）提交到仓库吧？这些文件要么体积大，要么包含敏感信息，要么每个开发者本地都不一样。.gitignore就像“拦截器”，把不需要提交的文件列进去，Git就会自动忽略它们。我整理了一份通用的.gitignore模板，前端项目可以加上：
# 依赖包
node_modules/
环境变量
.env
.env.local
日志
.log
编辑器配置（避免不同编辑器的配置文件冲突）
.idea/
.vscode/
构建产物
dist/
build/
你可以在项目根目录创建.gitignore文件，把这些内容复制进去，提交到仓库后，所有团队成员的Git都会自动忽略这些文件。
还有个容易被忽略的点：提交前先“拉代码”。我见过不少开发者，自己改了半天代码，直接git push，结果提示“rejected”（被拒绝），因为远程仓库已经有其他人提交的新代码了。正确流程应该是：提交前先用git pull拉取最新代码，解决可能的冲突，再git push。就像你写信时，先确认对方有没有新消息（拉代码），再回复（推送），否则可能写了半天，结果和对方的新消息重复或冲突。
最后分享个小技巧：把常用的Git命令做成“别名”。比如git status可以简写为git st，git commit简写为git ci，在终端输入git config global alias.st status就能设置。我自己还配了git last（查看最近一次提交）：git config global alias.last 'log -1 HEAD'，这样敲git last就能快速看最近的提交信息，比每次输一长串命令方便多了。你可以根据自己的习惯配置，效率能提升不少。
按照这些方法，你可以先在自己的个人项目里练手：建个测试仓库，创建几个分支模拟开发，试试提交PR、解决冲突，再拉上朋友一起模拟团队协作。如果遇到“分支切换后文件不见了”“提交后远程仓库看不到”这类问题，别慌，先运行git status看看当前状态，大部分问题Git都会在提示信息里告诉你原因。记得把你的实践结果在评论区告诉我，咱们一起优化这套协作流程！
.gitignore这东西看着小，其实是团队协作的“隐形助手”，我之前带过一个10人开发的SaaS项目，刚开始没重视这个文件，结果仓库里塞满了各种“垃圾”——前端同学的node_modules文件夹（足足120MB）、后端的.log日志文件、每个人本地的.env环境变量（里面甚至有数据库密码！），导致新成员拉代码要等20多分钟，有次还差点因为.env文件被提交，把测试环境的数据库密码泄露到GitHub上。后来我们统一配置了.gitignore，仓库体积直接从500MB减到80MB，拉代码速度快了3倍，敏感信息也安全多了。它的核心作用其实很简单：告诉Git“这些文件你不用管”，避免把没用的、占空间的、或者包含隐私的文件提交到版本库里，让仓库保持干净清爽。
创建.gitignore其实特别简单，你在项目根目录（就是放package.json或者pom.xml的那个文件夹）右键新建个文件，文件名必须是“.gitignore”——注意前面有个点，而且拼写不能错，少个字母或者多打个空格都不行。然后打开文件，把需要忽略的文件或目录一行一个写进去就行。比如前端项目肯定要写“node_modules/”（加斜杠表示这是个目录，不然可能会误判同名文件），后端项目可以加“.log”（星号是通配符，表示所有.log 的文件），环境变量文件直接写“.env”“/.env.local”（前面加斜杠表示只忽略根目录的，避免误删子目录的合法.env文件）。如果团队用不同编辑器，还可以加上“.idea/”（JetBrains家的）、“.vscode/”（VSCode），这些编辑器配置文件每个人习惯不一样，没必要提交到仓库。写完保存后，记得把.gitignore本身提交到仓库，这样所有团队成员拉代码时，Git就会自动按照这个规则忽略文件，不用每个人都手动配置一遍，特别省心。
Git的“工作区、暂存区、本地仓库”有什么区别？如何配合使用？
根据文章中的“写日记”类比，工作区是电脑文件夹（草稿本），存放当前修改的文件；暂存区是待提交的“待写页”，通过git add将工作区修改放入；本地仓库是“日记本”，通过git commit将暂存区内容正式提交。使用流程为：工作区修改文件→git add暂存→git commit提交到仓库。
修改文件后直接git commit提示“nothing to commit”，是什么原因？
这是因为跳过了“暂存”步骤。Git需要先通过git add 或git add .将工作区修改添加到暂存区，之后才能用git commit提交。比如改了index.js，需先执行git add index.js，再commit。
多人协作时合并代码出现冲突，应该如何解决？
冲突时Git会用<<<<< HEAD、=======、>>>>>> 分支名标记冲突位置。解决步骤：
git status提示）；git add 暂存修改，再git commit完成合并。如何创建.gitignore文件？它有什么作用？
.gitignore用于指定Git应忽略的文件（如依赖包、日志、敏感信息）。创建方法：在项目根目录新建.gitignore文件，按规则列出需忽略的文件/目录（如node_modules/、.env、.log），提交到仓库后所有成员的Git都会自动忽略这些内容，避免不必要文件进入版本库。
提交代码后发现错误，如何安全撤销已提交的版本？
若未推送到远程仓库，可用git reset hard 回退（通过git log查看版本号）；若已推送， 用git revert 创建新提交撤销修改，避免本地与远程仓库不一致。新手优先使用revert，更安全。
