做后端和前端一起联调的时候最怕的不是代码冲突而是“明明是一个项目大家却在各自的分支里改出了平行宇宙”。尤其是团队一多、分支一乱今天你合并了别人的功能明天别人又把你刚刚修好的 bug 覆盖了Git 历史看起来像一团毛线。这篇文章聊的就是 Git 多人协作的进阶场景不同分支下的并行开发。我会从分支模型设计、日常切换、合并策略、提交历史整理、图形化工具实操到高频报错排查把真正用得上的细节和坑都摊开讲适合刚接触 Git 不久、但已经在团队里被分支搞到头大的同学。这一篇是系列的第二次分享上一篇主要讲的是同一条分支上多个人怎么推拉同步这一篇的重点是“分支之间的协作”。你可以把它当成一份实操笔记也可以直接按章节当速查表来用。我尽量少讲废话多给能直接抄的步骤和命令也把我自己踩过的坑、试过之后觉得好用的习惯一并写出来。1. 分支协作的核心设计先把规则定下来1.1 为什么“不同分支下的协作”比单纯推拉复杂得多同一分支下的多人协作大家其实是一条流水线你推我拉按顺序前进就行。不同分支下就完全不一样了每个人在自己的分支里改代码最终要通过“合并”这个动作把结果汇到一起。问题在于合并发生的时间点不可控你合并的时候别人的代码可能已经走了很远也可能正好改到了同一个文件的同一段逻辑。我见过不少团队初期完全没有分支概念所有人都在 master 上干活功能上线全靠手动挑代码后来某次发布前发现 master 已经乱到没人敢动才老老实实开始用分支。这个过程的本质其实是单分支只适合个人项目多人协作必须靠分支把“并行开发”和“最终整合”拆开。分支不是用来炫技的它是把团队的工作空间隔离出来的手段让每个人在互不干扰的前提下干活最后再通过合并把大家的成果统一起来。隔离带来了自由也带来了成本。你不再直接看到别人的改动所以代码冲突的概率变高了你长时间不拉取远端本地分支会越来越“偏”合并时差异就会越来越大。所以不同分支下的协作核心不是命令记多少而是先掌握三个节奏分支怎么建、多久同步一次远端、合并前做什么检查。1.2 常用的分支模型主干发布、功能分支与 Git Flow不同团队分支模型差异很大我见过最朴素的只有 master 和 dev 两条分支也见过完整的 Git Flow 五层分支。选哪套不一定是越高大上越好而是看发布节奏和团队大小。下面是我实际对比下来比较有代表性的三套模型分支模型分支组成适用场景优缺点主干发布型master/main 临时分支小团队、持续发布简单直接但功能之间互相影响大功能分支型master feature/* 分支中型团队、迭代明确隔离性好合并时集中处理冲突Git Flowmaster / develop / feature / release / hotfix多版本并行、需要严格发布管理结构完整但流程较重小团队容易累我自己比较推荐中小团队用“功能分支型”每个功能从 master 拉一条 feature/xxx 分支开发完合并回 master合并后立刻删除远端分支保持分支列表清爽。这套模式下分支数量可控也不容易出现 hotfix 和 feature 之间的历史纠缠。1.3 分支命名和提交信息的约定分支一多命名就是信息。我的习惯是feature/功能描述-编号比如feature/user-login-1024修复问题用hotfix/问题描述-编号比如hotfix/payment-timeout-2077。这样别人在切换分支、看远端分支列表的时候一眼就知道这条分支要干嘛不用点开日志猜。提交信息同样值得统一。团队里如果有人提交写“fix bug”、有人写“更新”、有人干脆不写过两周回看历史基本等于看天书。建议简单约定一个格式类型(范围): 描述比如feat(user): 增加手机号登录、fix(order): 修复重复支付提示。类型可以按 team 自己定常见的是 feat、fix、docs、refactor、test。这跟写不写代码规范一样不是强制但养成习惯后排查问题真的快很多。2. 多分支并行开发的日常操作切换、保存与同步2.1 切换分支前必须处理的工作区状态不同分支下的协作最高频的操作就是git switch老版本是git checkout。很多人第一次切分支就遇到报错“Your local changes would be overwritten by checkout”其实就是工作区里有改动没提交Git 怕切过去把你的本地修改覆盖掉所以拦住了。我处理这种情况有一套固定动作先git status看清楚当前工作区到底改了什么如果是没改完的半成品就用git stash暂存等切到目标分支、干完手头的事再切回来执行git stash pop。stash 相当于把你的改动放进一个临时的“口袋里”后续可以随时取出来继续改。有一点特别容易踩git stash pop并不是永远一帆风顺。如果在你 stash 之后这条分支本身也被别人改过并合并了那么 pop 的时候可能直接给你一个“CONFLICT”——又变成一次冲突处理。所以好的习惯是stash 前先记录好自己改了哪几个文件恢复冲突的时候心里才有数。不想用 stash 的另一种办法是直接在当前分支上新建一个临时提交比如git commit -m wip: 临时保存等后面整理历史再通过git rebase -i合并。这招更适合你只是短暂切一下分支、马上要回来继续场景至少工作区是干净的随便切。2.2 同时维护多个本地分支的实用技巧worktree很多前端同学问过我一个问题同一个项目我同时在 vscode 里打开多个窗口一个窗口看 release 分支一个窗口开发新功能为什么这边切分支那边就变这是因为同一个工作目录在一个时刻只能检出一个分支。你在一个目录里切换分支等于把它整个目录下的代码换成另一个状态。想要同时让多个分支的代码并行存在可以用git worktree。它允许你在额外目录里再检出一个分支出来比如我现在主目录在 develop 分支同时我又想改 release 分支上的一个紧急问题就执行git worktree add ../myproject-release release这样myproject-release目录下就是 release 分支的完整代码两个目录互不干扰vscode 直接开两个窗口分别打开即可。实测下来这个功能非常稳是处理“同项目多分支同时开发”的官方方案。需要注意的是同一个分支不能在多个 worktree 里同时检出这是 Git 的硬性限制。而且加了 worktree 之后后续如果不想用了要在主目录执行git worktree remove ../myproject-release不能直接手删目录否则会留下管理记录。2.3 拉取远端分支与保持本地分支同步在多人协作场景下每天开工后的第一件事我建议是git fetch而不是直接git pull。fetch只把远端更新拉到本地“远端跟踪分支”不会动你当前工作区pull等于fetch merge它直接会改变你的工作区。如果你在本地要为别人刚创建的功能分支建一个对应的本地分支最保险的方式是git fetch origin git checkout -b feature/user-login origin/feature/user-login这样本地分支会直接跟踪远端分支后续git pull和git push都会自动关联不用每次加参数。在实际工作里保持同步频率很重要。我见过太多人一条分支干两三个星期期间从不 pull最后合并的时候差异大到冲突铺满屏幕光解决冲突就花掉大半天。比较好的节奏是功能分支每完成一个小步骤就 push 一次远端每个工作日至少 fetch 一两次如果发现自己分支和主干差得越来越远尽早处理越拖越痛。3. 分支合并merge、rebase 与 cherry-pick 的取舍3.1 merge 和 rebase 怎么选优先级是什么分支开发的最终动作就是合并。Git 合并有两种主要方式git merge和git rebase。它们的结果差别很大团队协作中必须有个统一偏好否则历史会非常乱。merge 的特点是“保留真实”它会把两条分支的异动合并成一个新的合并提交历史里能清楚看到哪几个分支汇合了。rebase 的特点是“重放”它把当前分支的提交一个个摘下来接到目标分支的最新提交后面形成一条线性历史。从可读性上看rebase 出来的历史干净得多但从安全性上看rebase 会重写提交 ID不适合对已经推送到远端的共享分支操作。我的使用建议非常明确功能分支合并回主干使用git merge必要时加--no-ff保留合并节点。功能分支同步主干最新代码优先用git rebase避免产生无意义的合并节点。已经 push 到远端、且别人可能也在用的分支绝不随便 rebase。这里特别推荐一个习惯合并功能分支时用git merge --no-ff feature/xxx。就算功能分支落后--no-ff也会保留一个明确的合并提交线上回滚时一眼就能看到“这次上线包含了哪几个合并”而不会把提交全部快进成一条看不见边界的线。3.2 冲突处理实操从看懂标记到完成合并冲突永远无法完全避免但能通过流程把它降到最低。一旦出现冲突Git 会在文件里写入冲突标记长这样 HEAD 当前分支的这一段代码 被合并分支的这一段代码 feature/user-login下面的部分是你当前分支的代码下面是待合并分支的代码。你要做的不是选一边或者两边都保留而是理解这两段代码分别想干什么然后写出正确的整合结果再把冲突标记全部删干净。我处理冲突的固定流程是打开冲突文件逐个看完冲突段。如果这段逻辑比较复杂去问另一条分支的负责人“这句话为什么这么改”不要自己硬猜。改成正确代码后保存文件执行git add file标记为已解决。全部解决后执行git commitmerge 会默认生成合并提交信息。很多人栽在冲突排查上是因为没有看全。这里分享一个命令git diff --name-only --diff-filterU可以列出所有处于冲突状态的文件配合git mergetool还能调起可视化对比工具。我建议每次都把“冲突文件列表”完整过一遍再接下一步宁可多看一眼也别提交漏了。3.3 把其他分支的某部分功能迁过来cherry-pick 的实战用法工作中经常会遇到这种场景feature/A 做了一堆功能但其中有一个小改动比如修了个公共方法feature/B 现在就要用。总不能让 B 把整个 A 合并过来那样会把还没准备好的功能全部拖进来。这时候就该用git cherry-pick它的作用是把某条分支上的指定提交提取出来放到当前分支上重放一次。使用方法很简单git checkout feature/B git cherry-pick a1b2c3d4a1b2c3d4是你在 feature/A 分支上看git log拿到的提交哈希。如果功能由多个提交组成可以一次拿一段范围git cherry-pick a1b2c3d4..e5f6a7b8这里的范围是左开右闭也就是不包含a1b2c3d4这个提交。想连第一个也一起拿就用git cherry-pick a1b2c3d4^..e5f6a7b8。cherry-pick 同样可能冲突解决方案和 merge 冲突一样解决后git cherry-pick --continue即可。我自己的经验是能整条分支合并就别用 cherry-pick能用 cherry-pick 就别手动复制粘贴代码。手动复制大段代码是最危险的做法因为丢失上下文和提交记录后后续追查问题会非常痛苦。4. 提交历史整理与分支清理让 Git 日志保持可读4.1 修改最近一次提交commit --amend 的正确姿势很多人在刚提交完就发现少了一个文件、或者提交信息写错了。不需要再补一个“fix: 补充”的垃圾提交直接用git commit --amend修改上一次提交即可。git add 忘记加的文件 git commit --amend -m feat(user): 增加手机号登录注意amend 实际上是把当前提交替换成一个全新提交提交 ID 会变化。所以这条命令只适合还没有 push 到远端共享分支的提交。如果已经 push 了且别人已经基于它继续开发那最好不要 amend实在要改就得git push --force-with-lease强推但这对其他人影响很大属于万不得已的操作。--force-with-lease比--force更安全简单说就是它会检查远端有没有别人更新如果远端变了会拒绝强推。这里顺手提一句任何情况下的强推都要谨慎它会让远端的提交历史“消失”别人如果没来得及拉取可能直接崩掉。4.2 多个提交需要整理时rebase -i 的用途如果想改的不是最后一次提交而是最近几个提交比如想把三个小提交合并成一个完整的提交或者想把某个提交的描述改掉用git rebase -i HEAD~3会打开一个编辑界面列出最近三条提交记录。在这个界面里每一行开头有一个命令pick表示保留squash表示把当前提交合并到上一个提交reword表示只改提交信息edit表示停下来修改内容。想合并三个提交为一条就把后两行的pick改成squash保存后跟随提示完善新的提交信息即可。同样地rebase -i改写的是历史不要对已经推送到远端且多人共用的提交执行。如果只是想整理自己功能分支上的多个小提交再合并到主干那是没问题的。中途任何一步出错都可以用git rebase --abort恢复到操作之前的状态这句话值得刻在脑子里。4.3 删除不需要的分支本地与远端的正确清理方式很多人分支用完不删远端分支列表越来越长。我自己清理分支的习惯是功能合并进主干确认没问题后就立刻把远端功能分支删掉然后本地也删。删除命令如下# 删除远端分支 git push origin --delete feature/user-login # 删除本地分支 git branch -d feature/user-login本地删除时-d是安全删除Git 会检查该分支是否已经合并进来如果没合并过它会拒绝执行这时如果想强制删除用-D。但在删除一个未合并的分支前强烈建议先确认上面没有丢失的代码因为-D不回退。远端分支删除后本地执行git fetch --prune可以把本地已经过期的远端跟踪分支引用也清理点。在 vscode 里可以看到远端分支列表变干净。很多编辑器不自动清理这些“远程分支残留”所以命令行里跑一下fetch --prune很有必要。4.4 分支删除后Git 里的“历史包袱”怎么处理分支删除只是删了引用实际提交还留在仓库的对象库里。偶尔觉得仓库体积越来越大想彻底清理可以执行git gc --prunenowgc是垃圾回收--prunenow会立即清除所有不可达对象。它对日常协作不是必需操作通常过一段时间 Git 也会自动做类似的清理。我一般只会在删除了一大批大文件提交、或者想给仓库瘦身时才主动执行。另外如果发现 .git 目录大得离谱大多是有人在历史里提交过大文件只删分支是不够的那就要用git filter-repo去改写历史了这属于另一个话题。5. 图形化工具实操TortoiseGit 与 IDEA/VS Code 的分支操作5.1 TortoiseGit 切换分支的菜单位置Windows 下很多人都用“小乌龟”TortoiseGit因为它不用记命令右键就完事。切换分支的入口在目录右键 → TortoiseGit → Switch/Checkout弹出的窗口里选择目标分支即可和git switch等价。小乌龟在切换分支时也会检查工作区是否存在未提交改动有的话同样会报错处理方式和命令行一致先 stash 或提交。它的优势是可视化冲突合并界面很直观尤其适合批量处理多个文件冲突的场景。我印象很深的一点是它的日志窗口可以直接用右键选择两个提交做比较排查问题时比命令行里反复 diff 效率高不少。5.2 IDEA 下复制项目后切换分支的坑IDEA 右下角的分支按钮是目前我用过的 Git 图形化操作里比较顺手的一个点击可以快速切换分支、创建新分支、推送、拉取。有一个高频问题就是复制了一个主项目作为新项目后怎么切换分支很多人发现右侧分支列表是空的或者切了之后代码不变。原因通常是复制出来的项目没有正确识别 Git 根目录。解决方法是File → Settings → Version Control → Directory Mapping把复制项目的根目录和 Git 仓库对应上或者重新通过 VCS → Enable Version Control Integration 开启 Git 管理然后再点右下角分支按钮就有分支列表了。新项目 clone 拉取远端仓库时IDEA 也可以在向导里直接填 Git 仓库 URL选好目录就自动 clone。关键一点是 clone 下来默认在默认分支通常是 master/main想基于它建功能分支右下方分支列表里点 New Branch 即可会自动切过去。5.3 VS Code 下同项目多分支并行开发的安排VS Code 的 Git 操作主要集中在左侧源代码管理图标顶部默认显示当前分支名点开可以切换、创建分支。有些前端同事习惯一个人同时维护不同分支的代码比如一个窗口看线上稳定版本一个窗口改新功能配合我前面提到的git worktree就能让 VS Code 两个窗口指向不同目录各自独立分支并行开发实测非常舒服。唯一的注意点是 .vscode 目录不要提交进 Git建议在 .gitignore 里加上.vscode/。否则多人协作时插件配置、调试配置一冲突整个仓库都会变得烦人。5.4 IDEA 里如何把一个分支合并到另一个分支IDEA 的分支合并逻辑也很直观先切换到“接收方”分支也就是你希望代码合并进的那个分支再打开右下角分支菜单选择“被合并方”分支点击 Merge into Current 即可。这个流程和命令行是同一个道理只是把git merge feature/xxx图形化了。不过我建议即使你习惯图形化操作也至少记住几个关键命令因为很多时候 IDE 会莫名其妙卡住或者状态不对打开命令行看一眼git status、git log --oneline --graph立刻能定位问题。工具只是入口Git 本身才是根本。6. 高频报错与问题排查速查表6.1 “fatal: not a git repository (or any of the parent directories): .git”这个报错几乎每个新手都会遇到。字面含义是当前目录不属于任何 Git 仓库。常见原因是把命令窗口开错目录了或者项目目录本身没有被git init又或者项目是从别人那里直接复制过来的丢了 .git 目录。排查方法三步走先pwd看当前路径再git rev-parse --show-toplevel看 Git 仓库根目录在哪如果确实没有仓库就回到项目根目录执行git init。严格说git init只是初始化如果代码已经在远端仓库更推荐git clone url而不是自己 init 再接 remote这样可以避免很多“我不是仓库”后续问题。6.2 Gitee 密钥配置与 HTTPS 免密和远程仓库协作第一关是认证。Gitee 的 SSH 配置流程是本机生成密钥ssh-keygen -t rsa -b 4096 -C 你的邮箱然后把~/.ssh/id_rsa.pub里的内容复制到 Gitee 后台 SSH 公钥设置里。配置好之后执行ssh -T gitgitee.com如果收到成功验证提示就说明通了。如果使用 HTTPS 协议不想每次输入账号密码Windows 上开启凭据管理器即可git config --global credential.helper manager这样第一次输入后就会记在系统凭据里后续不用重复输入。我自己的仓库一般用 SSH因为密钥相比密码更安全也更省事换电脑时只需要把私钥复制过去。6.3 分支上 commit 但未 push 的代码怎么撤回这是个非常经典的问题比如在 IDEA 上错误地 commit 了一个半成品但还没有 push。此时需要区分你是想保留改动还是彻底丢弃。保留改动并撤销提交用软回退git reset --soft HEAD~1这条命令会退回到提交前状态所有改动都留在工作区其实是暂存区想继续改就改想重新提交就重新提交。如果想连暂存状态也退掉、只保留工作区改动git reset --mixed HEAD~1如果想彻底丢掉改动用硬回退git reset --hard HEAD~1注意--hard会把工作区里那段代码恢复成上一个提交的状态自己写的一大段半成品会直接消失且不可恢复。所以我个人的建议是能不 hard 就别 hard宁可先 soft 下来看一眼再决定哪怕是不要的代码复制到记事本里放着也花不了几秒钟。6.4 换行符、中文路径显示与文件大小写问题多人协作跨 Windows/macOS/Linux 时CRLF 和 LF 的换行符问题非常烦人。最常见的现象是明明只改了一行代码但 diff 显示整个文件全变。原因就是 Git 把换行符差异暴露出来了。团队层面建议统一配置# Linux/macOS 上 git config --global core.autocrlf input # Windows 上 git config --global core.autocrlf true另外 Git 默认会把非 ASCII 的文件名转义显示中文目录在命令行里乱得没法看。执行git config --global core.quotepath false之后中文文件名就能正常显示了这个热词里的git -c diff.mnemonicprefixfalse ...和它类似都是关掉 Git 的转义让输出更直观。还有一个隐蔽的问题Git 默认对文件名大小写不敏感把UserDao.java改名成userdao.java时Git 可能不识别。如果遇到这种问题用两条命令处理git mv UserDao.java userdao.java # 或者 git config core.ignorecase false建议项目一开始就确定命名规范大小写问题一旦混进仓库后面的清理成本非常高。我在实际工作里最深的体会是多人协作场景下Git 技术本身并不是越复杂越好真正决定顺畅程度的是团队约定。分支命名统一、提交信息清晰、每天保持同步、合并前先看 diff、合并后及时跑测试这些看起来不起眼的习惯远远比你会不会 rebase 更值钱。最后再分享一个小技巧每次大合并之前先在脑子里问自己一句“我最近一次的本地分支状态是不是已经 push 过了”如果答案是否定的就先 push 再合并这样就算合并现场一塌糊涂你也永远有一条安全线可以退回去。