Git多人协作实战指南：从分支模型到冲突解决

git 多人协作这件事，很多团队一开始都是这样走过来的：所有人都在 main 分支上直接提交，谁 push 得晚谁就撞车，合并靠吼，回滚靠猜。等团队从三五个人涨到十几个人的时候，这条路上基本就只剩一片红红的冲突标记了。我自己的团队也是在那个阶段被迫切换思路，开始认认真真地做“不同分支下”的协作，把 main 保护起来，让每个人在独立的分支上并行推进，再通过合并流程把成果收拢回来。效果立竿见影，但过程里踩的坑也不少。

这篇文章就是把我这段时间的实战经验整理出来，讲的不是 Git 的底层原理，而是一整套可落地的分支协作方案：环境怎么准备、分支怎么命名和划分、日常操作怎么做、冲突怎么排解、操作翻车了怎么救。无论你是刚开始带团队接触 Git，还是自己用得挺熟但总在多人协作时被分支合并和冲突折磨，都可以把这篇文章当成一份参照。我尽量把命令背后的逻辑和场景也讲清楚，方便你拿去就能用，而不是背一串咒语。

1. 从同一分支的混乱到不同分支的秩序

1.1 同一分支协作为什么必然失控

想象一下一条主干道上来回跑几百辆车没有红绿灯会是什么样子。所有人在同一个分支上提交代码，本质上就是把整个团队的车都赶到同一条车道上。早期人少还行，提交频率不高，大家互相迁就一下就能过。可一旦并行开发的需求变多，两个人同时改同一个文件几乎成了每天的日常，git pull 时动不动就蹦出 CONFLICT，后面提交的人只能硬着头皮解冲突，还要担心自己是不是把别人的改动给覆盖了。

更麻烦的是，同分支协作下你没法控制“什么代码进入主干”。某个功能明明还在半成品状态，因为你提交到了 main，别人拉下来之后直接被半成品代码影响了整个项目的可运行性。这种情况发生几次之后，团队里就会滋生出一种下意识：能不在 main 上动就不在 main 上动，改什么先攒着。结果就是历史上一大堆挂着WIP的提交，谁也说不清哪个版本是能跑的。

1.2 分支协作到底解决了什么

不同分支协作的本质，是把“共享一份代码”改成“各自维护一份代码副本，在确定的节点相互合并”。每个人从主分支拉出一条功能分支，在自己的分支上随便提交、随时推送，都不会影响别人。这就好比每个人都有自己的工作间，工作间里怎么折腾都行，完工之后再走统一的质检流程把成果搬进公共仓库。

它能解决几个非常实际的问题：一是隔离，你不会在开发过程中被别人的半成品绊倒；二是并行，多人可以同时推进不同功能而不互相覆盖；三是可控，只要主分支被保护起来，任何进入主分支的代码都要经过合并请求和检查，代码质量就有了一个把关口。这也是为什么稍微正规一点的团队都会采用分支协作，不是因为它时髦，而是因为它能显著降低协作成本。

1.3 要转换的是工作习惯，不是命令记忆

很多人一听到分支协作，第一反应是“我要记住好多新命令”。其实真正需要学的命令就那么几条，难的是把原来的工作习惯改过来。比如你不能再一上来就git add . && git commit && git push，你得先确认自己在哪个分支上、要推到哪个分支、和谁合并、合并出问题了怎么回头。这些习惯的转变比命令本身更重要，后面几节我会把标准动作一步步拆开。

2. 开工前的环境准备：安装、配置与SSH免密

2.1 各平台的 Git 安装

Windows 是最省事的，直接去 Git for Windows 官网下载安装包，一路下一步就行。安装的时候有一步会让你选默认编辑器、PATH 环境变量这些，保持默认就好。装完打开一个新的 CMD 或 PowerShell，敲git --version能看到版本号就说明没问题。如果官网下载慢，国内的开源镜像站一般也都有同步，下载体验会好一些。

macOS 上如果你装了 Homebrew，一条命令就能搞定：brew install git。Linux 视发行版不同可能是sudo apt install git或sudo yum install git。装完之后同样用git --version验证。这里有个小细节：很多系统会自带一个旧版本 Git，如果你发现命令行为和你学的不一样，优先确认版本是不是太老，太老的话直接升级，省得后面被各种兼容性问题折腾。

2.2 身份信息配置

Git 每次提交都会记录两样东西：用户名和邮箱。这俩不是随便填的，它直接关联到你在远程仓库平台上的身份，最后会跟着你的提交历史展示给团队所有人看。配置命令是：

git config --global user.name "你的名字" git config --global user.email "你常用的邮箱"

加上--global表示这些配置对当前用户的所有仓库生效。你可以在项目目录下运行git config --list查看当前配置，确认没写错。如果某个仓库想用不同的身份，去掉--global在仓库内重新设置即可。

2.3 SSH 密钥与免密登录

日常协作中你总要往远程仓库 push 代码，每次都要输密码会很影响心情，更别提有些平台对密码验证本身就有限制。更稳的做法是配 SSH 密钥，一次性配置，之后push、pull、clone都走密钥验证，不需要再输密码。

生成密钥很简单：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

回车之后会让你确认保存位置和设置口令，直接一路回车就好。生成的密钥默认在~/.ssh/id_rsa.pub，这是公钥，可以放心复制给别人；同目录下的id_rsa是私钥，打死也不能外传。查看公钥内容：

cat ~/.ssh/id_rsa.pub

然后登录你使用的 Git 平台（Gitee、GitHub、GitLab 都类似），在个人设置的“SSH 公钥”页面把这段内容粘贴进去保存。验证是否配好，以 Gitee 为例：

ssh -T git@gitee.com

如果返回一段欢迎信息，说明 SSH 通道已经打通，从此告别密码输入。

2.4 SSH 认证失败的常见排查思路

有不少人卡在第二步就跑不过去，常见报错是ssh: connect to host ... port 22: Connection refused或者Permission denied (publickey)。前者一般是网络或端口问题，后者基本就是公钥没配对。我建议按这个顺序排查：先跑一次ssh -T git@gitee.com看返回信息；再确认你当前用户目录下确实存在id_rsa.pub；最后回平台检查公钥是不是粘贴完整，复制时不要带多余空格和换行。还有一个容易忽视的点：如果你电脑上有多个 Git 平台账号，默认的id_rsa可能已经被别的平台占用，这时候需要在~/.ssh/config里对不同域名指定不同的密钥文件，属于进阶玩法，先用单平台的标准流程跑通就够日常用了。

3. 分支模型设计：哪些分支常驻，哪些分支用完即弃

3.1 一张分支角色清单

聊分支协作，第一步不是学命令，而是定好规矩。没有规矩的分支最后会变成巨大的垃圾场，谁也不知道哪些分支还活着、哪些已经废弃。我比较推荐一套轻量化的分支模型，不重但够用：

• main（或master）：主分支，永远是能跑能发布的稳定代码，受保护，不允许直接 push。
• develop（可选）：集成分支，所有功能分支完成之后先合到这里，做联调和集成测试。
• feature/*：功能分支，从一个需求拉出来，开发完合并回去后即删除。
• hotfix/*：紧急修复分支，从main直接拉出来，修复线上问题后合回main和develop。

对于十来个人的团队，我甚至建议连develop都可以先省掉，直接走main+feature/*的简化模式。分支层级越多，合并链路越长，管理成本越高。先跑通最简单可靠的模型，再根据团队节奏调整，比一开始就搞一套庞大的 Git Flow 要务实得多。

3.2 分支命名规范

分支名是团队沟通的一部分。好的分支名让人一眼就知道这个分支在做什么、对应什么需求。我常用的格式是：

feature/需求编号-功能简述

例如feature/20240715-login-page表示一个登录页功能。hotfix同理，比如hotfix/order-amount-error。别小看这一条，当你的远程仓库里躺着几十个分支时，一个规范的名字能帮你快速定位目标，而不是点开每一个分支看提交记录猜它是干嘛的。命名规范不一定完美，但一定要有，而且最好写进团队文档里，新成员来了直接照抄。

3.3 主分支保护与合并权限

在我的实践里，main分支的写权限必须收回来。做法是在 Git 平台的项目设置里开启“保护分支”，把允许推送的成员设为空或仅限维护者。这样一来，任何人想把自己的代码合入main，都必须走合并请求（PR/MR），在平台上经过代码评审之后再点击合并。这是整个分支协作模型里最关键的一环，也是很多小团队容易忽略的：分支拉了一堆，最后所有人还是往main上硬推，那等于白搭。

合并请求的好处不光是代码评审，它还会把改动集中成一个清晰可见的提交历史和讨论记录，下次出问题排查时，你能快速知道“这块代码是哪个合并请求、哪个功能带进来的”。这一步看起来是流程上的事，实际省掉的是未来大量的排查成本。

4. 分支协作的标准动作：创建、提交、推送与合并

4.1 创建功能分支的标准起手式

无论你用的是命令还是图形工具，开始一个功能的流程应该是一样的。先切到main并拉取最新代码，保证自己的起点是最新的稳定版本：

git switch main git pull origin main

然后基于最新的main创建并切换到功能分支：

git switch -c feature/20240715-login-page

-c是--create的简写，表示创建并切换。老版本 Git 可能不支持git switch命令，那就用等价的git checkout -b feature/20240715-login-page，效果一样。创建完分支后用git branch --show-current确认一下当前分支，别稀里糊涂在main上改了半天代码才发现没建分支。

4.2 提交与推送的正确姿势

在分支上做开发的时候，提交频率要高于你单机开发的时候。我见过有人攒了一周的改动一次性 commit，到了合并时发现和别人的功能大量重叠，解冲突解到怀疑人生。正确的姿势是小步提交：一个功能点完成、一个文件修改稳定，就提交一次。提交信息也要有实质内容，别写update、fix这种谁都看不懂的话，我给团队推荐的格式是feat: 添加登录页表单校验、fix: 修复订单金额计算错误，前缀标明类型，后面做啥一目了然。

提交的命令是：

git add src/pages/Login.vue git commit -m "feat: 添加登录页表单校验"

注意我刻意没有用git add .。按文件添加能避免你把临时文件、调试代码、本不该提交的配置一并带进仓库。推送功能分支到远程：

git push -u origin feature/20240715-login-page

加上-u是为了将本地分支和远程分支建立跟踪关系，之后在该分支上直接输入git push就能推送，不需要每次指定远程名和分支名。

4.3 merge 还是 rebase：合并方式怎么选

这是团队协作里最容易吵起来的话题。我的立场很明确：对于大多数团队，日常合并用merge就好，别一上来就 rebase。merge会保留每个人的独立提交历史，形成一个分叉再合并的图形，虽然看起来不够“线性”，但胜在真实、安全，冲突解决也是基于三方合并，心智负担低。

rebase是把你的提交“搬”到目标分支的最新提交之后，历史变成一条直线，看起来非常清爽。但代价是你的提交哈希全部改变，如果这期间有人已经拉过你的分支代码，他会遇到一堆强行更新的问题。用 rebase 要遵守一条铁律：只 rebase 自己还没推出去的本地提交。团队里如果每个人都频繁 rebase 共享分支，那基本就是互相制造麻烦。

如果你是自己管理本地提交历史，想整理成一串干净的提交再推出去，rebase 可以放手用；如果是把功能分支合回团队主分支，我推荐直接在平台合并请求里选merge或squash merge。squash merge会把功能分支上的所有提交压缩成一个提交合入目标分支，历史非常干净，适合一个功能对应一次合并的场景。

4.4 把一个分支合并到另一个分支的实战命令

工作中经常有这种需求：同事要求把 A 分支的功能合并到你的 B 分支一起联调，或者把 B 分支合到 A 分支验证效果。操作本身不复杂：

# 切到目标分支 git switch B # 拉取最新代码 git pull origin B # 把 A 分支合并进来 git merge A

如果是把已经推送到远程的分支合进来，可以先拉取远程分支再合并，也可以直接指定：

git pull origin A

这条命令相当于git fetch origin A && git merge origin/A，适合快速把别人的分支拉进来联调。合并完成后如果有冲突就着手处理，没冲突就git push推送到远程 B 分支。这里提醒一句：往别人的功能分支里合并代码之前，先和对方打声招呼，不然对方下一次 push 时又是一堆合并和解冲突，容易引发不愉快。

4.5 cherry-pick：只要某几个提交，不要整个分支

有些时候你不需要把一个分支整体合并过来，只想把其中某几个提交搬到另一个分支。比如你在feature-A上写了三个提交，其中只有一个修复严重 bug 的提交需要立刻上main，剩下的功能还在开发中。这时用git cherry-pick最合适。

先查看目标提交的哈希：

git log --oneline

找到那串哈希值后，切换到要搬入的分支，执行：

git switch main git pull origin main git cherry-pick a1b2c3d

如果只想搬连续的几个提交，可以用范围写法git cherry-pick A..E。cherry-pick 的过程同样可能冲突，解决方式和普通合并一样，解决后git cherry-pick --continue提交即可。这个命令特别适合“从旁支迁移稳定修复”的场景，不用因为一个提交就拉出一大堆无关代码。

5. 代码冲突的完整排解链路

5.1 冲突是怎么产生的，为什么躲不掉

合并冲突是多人协作里绕不开的坎，本质上它不丑陋，反而是 Git 对你代码的一种保护。冲突产生的唯一原因就是两个分支修改了同一个文件的同一个区域，而 Git 无法判断哪个版本才是“正确”的，只能把选择权交给你。你可以想象两个人同时在一张纸上改同一行字，各自存了一个版本，现在要把两份合起来，总得有个人裁定谁的字压过谁。

5.2 从冲突标记到解决：一个完整实例

假设两个分支都改了一个README.md，我来演示一次完整的解决过程。执行git merge feature/login-page后 Git 报冲突：

Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.

打开README.md你会看到冲突标记：

<<<<<<< HEAD 这是 main 分支上的描述 ======= 这是 feature/login-page 分支上的描述 >>>>>>> feature/login-page

<<<<<<<和=======之间是当前分支（HEAD）的内容，=======和>>>>>>>之间是合并进来的分支内容。这一步你是裁判，把不要的部分删掉，保留正确的描述，最后把三个标记行也一起删掉。保存文件后：

git add README.md git commit -m "merge: 合并 README 描述"

merge 引起的冲突，解决之后直接commit就能完成合并；如果是 rebase 或 cherry-pick 途中遇到的冲突，解决之后不能直接commit，而是用git rebase --continue或git cherry-pick --continue，这个区别不少新手会卡一下。

5.3 减少冲突的实战技巧

冲突虽然躲不掉，但频率完全可以降下来。我总结了三条实际有效的经验：一是按模块分工，尽量让不同的人负责不同目录和文件，从源头降低交集的概率；二是频繁从main同步代码到自己的功能分支，积攒的差异越小，合并时越不容易大面积碰撞；三是一次性别干太长时间，一两天的分支还好，一两周的长寿分支合并时几乎必然迎来大规模冲突。如果功能确实很长，可以切分成多个小功能分支依次合并，别一个分支拖到天荒地老。

6. 分支操作翻车后的急救手册

6.1 commit 信息写错了：git commit --amend

刚提交完就发现 commit message 写了个错别字，或者漏掉了一个文件没提交，这个时候不用新建一个“补救”提交，用git commit --amend就能修复上一次提交。改 message 是这样的：

git commit --amend -m "feat: 添加登录页表单校验"

这个命令会用新的提交替换上一次提交，相当于给上一个 commit 改了名字。如果你只是想补一个漏掉的文件，可以：

git add 忘掉的文件 git commit --amend --no-edit

加上--no-edit是告诉 Git 不要改动 message，保持原样。

这里有一条非常重要的红线：amend只能用在还没有推送到远程的提交上。如果这个提交已经被别人拉走，你再 amend 就等于把一个“篡改”过的历史强行推送出去，所有人都会遇到合并问题。已经 push 的提交不要 amend，老老实实新增一个提交说明修正即可。

6.2 删掉本地 commit 但没 push 的代码

热搜里有个问题特别典型：在 IDEA 或命令行里提交了一个 commit，但还没有 push 到远程，现在后悔了，想把这个提交连同改动一起删掉。这可以用git reset解决，关键是选对模式：

HEAD~1表示上一个提交。如果你想删掉最近两个提交，就用HEAD~2。用--hard的时候要格外谨慎，因为改动会彻底消失，没有任何后悔药；确定不要了再用。如果提交已经推送到远程，那就不能用 reset 硬删了，正确做法是用git revert生成一个反向提交来“撤销”，这种方式不会篡改历史，对协作方也最安全。

6.3 删除本地和远程分支的完整姿势

功能合并完，分支就没用了，该删就删，不然远程仓库会膨胀成一片分支坟场。删除本地分支：

git branch -d feature/old

-d会检查该分支是否已经被合并，如果没合并会报错不让你删，防止误删工作成果。如果你确定这个分支不要了就改用git branch -D feature/old强制删除。删除远程分支：

git push origin --delete feature/old

远程分支被人删了之后，其他同事本地的分支列表里还会残留引用，执行一次git remote prune origin可以清理掉远程已经不存在的分支记录。VSCode 里删除分支后偶尔还会在源代码管理栏看到旧分支名，刷新或关闭重开窗口就能解决，本质问题还是本地引用没清理干净。

6.4 同一项目多分支同时开发：git worktree

这是我最想安利给团队的小技巧之一。有时候你需要在多个分支间并行操作，比如当前在 A 分支开发新功能，同时要去看一眼 B 分支上的一个紧急问题。常规做法是先 commit 或 stash 当前改动再切分支，来回折腾很烦。git worktree可以让你在一个仓库里同时检出多个分支到不同目录，完美解决场景冲突。

# 在项目根目录相邻位置创建一个新目录，检出 feature-B 分支 git worktree add ../myproject-b feature-B

之后你可以打开../myproject-b这个目录，里面就是feature-B分支的完整工作副本，本地和另一个目录的 A 分支互不干扰。处理完不用了再移除：

git worktree remove ../myproject-b

对于“VSCode 同项目多分支同时开发”这类需求，worktree 就是标准答案，比复制整个项目文件夹要正确得多，因为它保持同一个 Git 版本库的元数据，提交历史完全连贯。

7. 图形化工具里的分支操作：IDEA、VSCode与小乌龟

7.1 IDEA 里的分支切换、合并与新建

很多读者日常开发工具是 IDEA，没必要硬要求所有人背命令行。IDEA 的分支入口在右下角，显示当前分支名的小按钮，点开之后能看到所有本地分支和远程分支。切换分支直接双击目标分支名就行；新建分支在分支列表顶部选择New Branch，填名字后点创建并切换；合并分支时，先切到目标分支，再从列表里选择要合并的分支，点击Merge Selected into Current。

IDEA 里遇到冲突会弹出一个合并对话框，左边是本分支的版本，右边是合并进来的版本，中间可以手动编辑最终内容，处理完标记为已解决。还有人问“IDEA 复制了一个主项目，复制的项目怎么切换分支”，这个问题的核心往往是复制后的项目 Git 远程地址还是指向原仓库，需要在Git > Manage Remotes里把 remote 地址改掉，再执行git fetch，分支列表就会更新成自己仓库的分支。另外一个常见场景是新建项目时从 Git 拉取代码，直接在欢迎页选Get from VCS，粘贴仓库地址就能 clone 下来，关联的分支会同步加载。

7.2 VSCode 的源码管理与分支清理

VSCode 的 Git 能力全靠左侧的“源代码管理”图标。分支切换在左下角的源代码管理面板里，点击分支名就能看到分支列表并切换。合并分支的操作也比较顺手：先切到目标分支，打开命令面板输入Git: Merge Branch，选择要合并进来的分支即可。VSCode 解决冲突用的是可视化编辑器，冲突文件里能看到Accept Current Change、Accept Incoming Change、Accept Both Changes三个按钮，点哪边就保留哪边，比我手工删标记要直观不少。

清理删除的分支在 VSCode 里有两种常见情况：本地分支没有删除干净，用命令面板输入Git: Delete Branch选择删除；远程分支被别人删掉了，但本地依然显示，需要在源代码管理面板的刷新按钮旁执行Git: Fetch (Prune)，把已经不存在的远程分支引用清掉。记住这一点，就不会再遇到“明明删了怎么还在列表里”的困惑。

7.3 小乌龟（TortoiseGit）的日常操作

Windows 上有一批老用户比较习惯用左右键选菜单里的小乌龟图标操作 Git。小乌龟最常用的是右键菜单里的Pull、Switch/Checkout、Merge，整体逻辑和命令行一致。切换分支时选择Switch/Checkout，在弹出的窗口里选中目标分支即可；合并时选Merge，填入要合并的分支，有冲突会弹出冲突文件列表，双击文件手动解决保存后再Add标记为已解决。

小乌龟有一点比命令行直观：每一次操作都会弹出一个进度窗口，过程是成功还是失败、哪个文件冲突，都看得特别清楚，适合不习惯黑窗口的开发者。不过它本质还是 Git 命令的图形化封装，理解了分支协作的整体流程之后，用哪个工具只是习惯问题。团队协作时我的建议是：负责人统一推荐一种主流方式，但不要强制所有人都用同一款工具，因为分支模型和合并流程才是协作的核心，工具只是手感差异。

最后的体会是，不同分支下的多人协作，真正的难点从来不在于记住几条 Git 命令，而在于把团队的协作秩序建立起来。分支再干净、命令再熟练，如果每个人都随心所欲地推代码、合并、删分支，最后还是乱成一锅粥。我自己的经验是：先把分支命名规则、主分支保护、小步提交这三件事立起来，团队的协作效率就能比在 main 上直接堆代码高出一大截。再往后遇到冲突、误操作，就用上面这些方法从容处理，用顺手了你甚至会开始享受这种各做各的、收工统一合并的节奏。