从“文件堆”到“版本树”：Git帮你搞定代码管理
先搞懂3个“区”：像整理房间一样管理代码
很多人觉得Git难，是被“工作区”“暂存区”“本地仓库”这些词吓住了。其实你把它想象成整理房间就明白了：
git add命令），暂时不归档，但已经和“废纸”（没改的代码）分开了。 git commit -m "备注"命令），以后想找就能直接按标签翻。 我刚开始用Git时，总搞不清“暂存区”有啥用，觉得直接commit不就行了？后来有次开发用户注册功能，写了登录验证和密码加密两部分逻辑。结果登录验证没问题，但密码加密还没写完，这时候突然要紧急修复另一个bug。如果直接commit，没写完的加密代码就会被存进去；如果不存，修复bug时可能会误删登录验证代码。这时候暂存区就派上用场了——我先用git add login.py把写好的登录验证放进暂存区，再commit这部分，没写完的加密代码留在工作区，等修复完bug再回来接着写。你看，暂存区就像“半成品收纳盒”，让你能灵活控制“存什么、什么时候存”。
3步上手核心操作：从安装到第一次“存档”
其实Git的基础操作就像“注册账号-发朋友圈”一样简单，跟着这几步走，5分钟就能完成第一次版本记录：
第一步：安装Git并“告诉它你是谁”
先去Git官网（https://git-scm.com/downloadsnofollow）下载对应系统的安装包，一路“下一步”就行。安装完后打开终端（Windows用Git Bash，Mac/Linux用终端），输入两行命令“自我介绍”：
git config global user.name "你的名字" git config global user.email "你的邮箱"
为什么要填名字和邮箱？因为Git会记录每次修改是谁做的，就像发朋友圈要显示昵称一样。我之前帮一个外包项目做代码审计，发现有个commit没写用户信息，查了半天不知道是谁改的，最后只能拉着团队所有人核对代码，白白浪费时间。所以这一步千万别跳过，名字和邮箱最好和你公司的开发账号一致，方便团队追溯。
第二步：初始化仓库——给代码“建个档案库”
打开你的项目文件夹（比如user_system），在终端里进入这个文件夹，输入git init。这时候文件夹里会多一个隐藏的.git文件夹（别删！这就是Git的“档案库”）。我第一次用的时候，还以为这是垃圾文件，差点删掉，结果所有版本记录全没了，只能哭着重新写代码。记住：.git文件夹就是Git的“大脑”，删了就等于把“档案库”烧了，千万别动！
第三步：存档——用commit记录你的每一次进步
假设你写好了用户登录接口的代码（login.py），现在要存档。先输入git status看看当前状态，终端会显示“未跟踪的文件：login.py”，意思是“书桌”上有新东西没整理。接着输入git add login.py，把文件放进“暂存区”；再输入git commit -m "完成用户登录接口：实现手机号+验证码登录逻辑"，完成存档。
这里有个关键技巧：commit备注一定要写清楚！我见过最离谱的备注是“改了点东西”，结果后来出了bug想回滚，翻了30多个commit记录都不知道哪个版本是关键修改，最后只能一个个试，浪费了一下午。好的备注应该包含“做了什么+为什么做”，比如“修复登录接口超时问题（用户反馈网络差时请求失败）”，这样不管是自己还是同事，以后回看都能秒懂。
团队协作不“打架”：Git进阶技巧让合作更顺畅
分支管理：像“平行宇宙”一样隔离开发
后端开发很少单打独斗，当你和团队一起开发时，总不能所有人都在同一个文件里改代码吧？这时候“分支”就派上用场了。分支就像“平行宇宙”——主宇宙（main分支）是稳定的“现实世界”，你可以在“平行宇宙”（功能分支）里随便折腾，等搞定了再把“平行宇宙”合并回“现实世界”。
我一般会建这3类分支，足够应对90%的后端开发场景：
feature/pay-api，“优化用户注册”就建feature/register-optimize，每个人在自己的feature分支开发，互不影响。 举个我参与过的电商项目例子：当时要同时开发“商品详情页缓存优化”和“购物车结算接口”两个功能。我建了feature/cart-checkout分支，另一个同事建了feature/detail-cache分支，我们各改各的代码，完全不冲突。等我写完结算接口，就把我的feature分支合并到dev分支，测试没问题后，再等同事的缓存优化也合并过来，最后一起合并到main分支上线。整个过程就像“各拼各的乐高零件，最后一起拼成完整模型”，效率超高。
创建分支的命令也很简单：git checkout -b 分支名，比如git checkout -b feature/pay-api，这个命令会帮你新建并直接切换到这个分支。开发完后，用git checkout dev切回dev分支，再git merge feature/pay-api就能把功能合并过去。
远程仓库：让代码“住”在云端，团队协作更丝滑
自己本地的Git只能管理自己的代码，团队协作还需要“远程仓库”——相当于大家共用的“云端档案库”，比如GitHub、Gitee或者公司内部的GitLab。你把本地代码“推”到云端，同事再从云端“拉”下来，就能看到彼此的修改了。
我常用的远程仓库操作就3个，记牢这3步，合作时基本不会“掉链子”：
第一步：克隆仓库——把云端代码“搬”到本地
如果项目已经在远程仓库（比如GitHub上有个user-system仓库），你第一次参与开发时，先在终端输入git clone 仓库地址，比如git clone https://github.com/yourname/user-system.git，远程仓库的代码就会完整复制到你本地，包括所有分支和版本记录。
第二步：拉取最新代码——合作前先“同步进度”
每天开始写代码前，一定要先git pull！这步能帮你把同事刚提交的代码拉到本地，避免“你改你的，他改他的，最后合并时代码打架”。我之前有个同事，早上来了没pull，直接改了user.py文件，结果另一个同事凌晨刚优化了这个文件的逻辑，最后合并时冲突了20多行代码，排查了好久才解决。所以养成“先pull后开发”的习惯，能省很多事。
第三步：推送代码——把你的成果“分享”给团队
写完代码、commit到本地仓库后，用git push origin 分支名推到远程仓库，比如git push origin feature/pay-api，同事就能在远程仓库看到你的分支，一起review代码了。
如果推送时提示“冲突”，别慌！Git会告诉你哪个文件有冲突，打开文件后，你会看到类似这样的标记：
<<<<<<< HEAD def login(phone, code):
# 旧的登录逻辑
=======
def login(phone, code, token):
# 你写的新登录逻辑（增加了token参数）
>>>>>>> feature/pay-api
这时候你需要和改了同一部分代码的同事商量：保留旧逻辑还是新逻辑？或者结合两者修改？改完后删掉冲突标记，再git add、git commit、git push就行。我和前端同事合作时经常遇到这种情况，一般5分钟就能商量好——毕竟大家的目标都是让代码跑通，没必要为“谁的写法更好”争论，能解决问题的代码就是好代码。
最后给你一个“Git命令速查表”，平时开发时存手机里，忘了就翻一翻：
| 命令 | 作用 | 使用场景 |
|---|---|---|
| git status | 查看工作区状态 | 不确定改了哪些文件时 |
| git log | 查看提交历史 | 想知道之前改了什么内容时 |
| git checkout 版本号 | 回到指定版本 | 改崩了想回滚时（版本号用git log查） |
| git branch | 查看所有分支 | 忘记自己在哪个分支时 |
根据Git官方文档（https://git-scm.com/docnofollow）的统计，全球有超过90%的开发团队用Git管理代码，后端开发更是离不开它。其实你用熟了会发现，Git就像“代码时光机”——既能帮你留住每一个重要瞬间，又能让团队协作从“抢遥控器”变成“分工拼乐高”。
你之前开发时有没有遇到过代码管理的坑？或者用Git时踩过什么有趣的bug？欢迎在评论区分享，我可以帮你看看怎么用Git解决！
我上周就遇到这事儿，刚写完用户注册接口的校验逻辑，commit的时候脑子一抽，备注随手写了句“改了点东西”。按下回车的瞬间就后悔了——这要是过俩月线上出问题，翻版本记录看到“点东西”，谁知道是啥“东西”？当时还好没push到远程仓库，赶紧在终端输了git commit amend，屏幕上直接弹开之前用的编辑器（我用的VS Code），原来那句敷衍的备注就在光标那儿闪着，我赶紧改成“完善用户注册接口：增加手机号格式校验和密码强度检测”，顺手加了个关联的需求单号，保存退出，再git log一看，之前的commit记录直接被更新了，就像从没写错过备注一样，这招简直是“备注后悔药”。
不过要是已经把写错备注的commit推到远程仓库，比如公司的GitLab或者GitHub上，那可千万别随便用amend改了。我同事小李上个月就踩过坑，他改了支付接口的超时时间，commit备注写成“改支付”，push后才发现没写清楚是“把超时时间从3秒改成5秒”。他觉得备注太含糊，就本地amend改了备注再强行push，结果远程仓库的历史记录直接乱了，跟他合作的测试同学pull代码时，本地分支和远程对不上，各种冲突报错，最后三个人花了快一小时才把代码历史捋顺。这种时候其实简单，直接再提交一次就行，备注写“补充说明：支付接口超时时间调整为5秒（修正前次commit备注）”，虽然多一条commit记录，但至少不会影响其他人的开发，团队协作嘛，安全第一。
日常写备注的时候多花10秒钟想清楚，比后面改来改去省事儿多了。我现在养成习惯，commit前先问自己三个问题：“这次改了什么功能？”“解决了什么问题？”“关联哪个需求/BUG号？”比如“修复购物车结算时商品数量为0仍可提交的bug（#789）”，这样不管过多久，自己还是同事看记录，一眼就知道这版改了啥，省得猜来猜去。
Git和SVN有什么区别？
Git是分布式版本控制系统，每个开发者的本地都有完整的版本库，无需联网即可提交代码；而SVN是集中式的，所有版本信息存储在中央服务器，提交需联网。Git的分支管理更轻量灵活，适合多人协作和复杂项目；SVN操作相对简单，适合小型项目或对集中管理有需求的场景。
已经提交（commit）的代码能撤销吗？
可以。如果提交后发现错误且未推送到远程仓库，可使用git commit amend修改最近一次提交（适合补充备注或修正少量代码）；若需要彻底撤销某次提交，可先用git log找到目标提交的版本号，再用git reset hard 版本号回滚到该版本（注意：此操作会丢弃回滚点后的所有修改， 谨慎使用）。
为什么需要暂存区（git add），直接提交（git commit）不行吗？
暂存区的作用是“选择性提交”。比如开发时写了A、B两部分代码，A已完成，B未写完，此时可先用git add A文件将A放入暂存区并提交，B留在工作区继续开发，避免未完成的代码混入提交记录。若直接提交，会将工作区所有修改一次性存入仓库，无法区分“已完成”和“未完成”的内容，降低版本记录的清晰度。
多人协作时遇到代码冲突，该怎么处理？
首先通过git pull拉取最新代码，若提示冲突，Git会在冲突文件中用<<<<<<< HEAD、=======、>>>>>> 分支名标记冲突区域。此时需打开文件，与相关同事沟通后保留正确代码（删除冲突标记），再执行git add 冲突文件、git commit -m “解决冲突”，最后git push即可。冲突处理的核心是“协商保留正确逻辑”，避免单方面删除他人代码。
忘记写commit备注或写错了，能修改吗？
可以。若刚提交完发现备注问题，且未推送到远程仓库，可直接用git commit amend命令，会打开编辑器让你修改备注，保存后即可更新最近一次提交的备注；若已推送到远程仓库，不 修改（可能影响他人代码历史），可补充提交一次并备注“修正：XX提交的备注错误”。日常使用中， 提交时认真填写备注，清晰描述修改内容。
