Git进阶技巧：团队协作与分支管理最佳实践

引言

凌晨两点,我刚要关电脑下班,突然看到同事在群里@我:“老哥,刚才你合并的代码把我的登录功能覆盖了,现在线上用户登不进去了…”
我当时的心情,你懂的——手抖、心慌、冒冷汗。赶紧打开代码一看,满屏都是<<<<<<<和>>>>>>>这些冲突标记,我甚至分不清哪些是我的代码,哪些是同事的。那一晚我学到了一个教训:会用Git基础命令,不等于会团队协作。
如果你也有过类似的经历——分支多得自己都记不住、不敢合并代码怕出冲突、提交历史乱得像一团毛线,那这篇文章应该能帮到你。我会分享自己这几年在团队协作中总结的实战经验,从选择工作流到处理冲突,从整理提交历史到建立代码审查流程。
读完本文,你会掌握:

如何选择适合团队的分支策略
优雅地解决合并冲突的方法
用rebase整理提交历史的技巧
建立高效代码审查流程的要点

第一章：选择适合你团队的Git工作流

说实话,我刚开始带团队的时候,也不知道该用哪种Git工作流。听到别人说Git Flow很专业,就照搬过来,结果5个人的小团队每天光管理分支就要花半小时,最后大家都烦了。
后来我才明白,工作流这东西没有最好,只有最合适。

Git Flow vs GitHub Flow vs Trunk Based Development

让我用最简单的方式讲讲这三种工作流的区别:
Git Flow 就像是严格的流水线工厂,有专门的开发分支(develop)、功能分支(feature)、发布分支(release)、热修复分支(hotfix)。微软、IBM这种大公司用得多,因为他们有明确的发布周期,比如每个月发一个版本。
但对小团队来说,Git Flow太重了。我之前的团队就是这样,每次发布都要从develop分支拉一个release分支,测试完了合并到master,然后再合并回develop,光这套流程就够折腾的。
GitHub Flow 就简单多了,只有一个主分支(main/master),所有功能都从主分支拉出feature分支,开发完了就发PR合并回去。这个模式特别适合我们这种3-10人的团队,强调快速迭代和持续交付。
我现在的团队用的就是GitHub Flow,配合CI/CD自动化测试,基本上每天都能发布好几次。团队成员也觉得轻松,不用记那么多分支规则。
Trunk Based Development(主干开发)更极端一些,所有人都直接在主分支上开发,分支的生命周期通常不超过一天。Google、Facebook这种有强大自动化测试能力的公司才敢这么玩。
对我们这种普通团队来说,TBD有点太激进了。除非你的测试覆盖率能到90%以上,否则很容易把主分支搞崩。

2025年的最新趋势

最近我看了不少资料,发现2025年的趋势是混合模型。小团队(1-10人)基本都在用GitHub Flow,配合GitHub Actions或GitLab CI做自动化。中大型团队则会根据自己的情况,把Git Flow的某些部分和GitHub Flow结合起来。
比如我朋友公司,他们有个20人的团队,用的就是”GitHub Flow + release分支”的混合方案:日常开发用GitHub Flow,但每次准备发版前会拉一个release分支做稳定。
我的建议是:

1-5人的小团队:直接用GitHub Flow,别想太多
5-15人的中型团队:GitHub Flow + 简化的release流程
15人以上:考虑Git Flow或混合方案,但要配合完善的CI/CD
哦对了,还有个关键点:别过度设计。我见过太多团队一开始就搞了一套超复杂的分支策略,结果没人愿意遵守,最后又回到各自乱搞的状态。

第二章：分支管理的黄金法则

团队协作最头疼的事,就是分支管理混乱。我之前的项目有个仓库,远程分支有70多个,其中起码一半都是两年前的僵尸分支,每次找自己的分支都要翻半天。
后来我总结了一套分支管理的”黄金法则”,团队用了之后整个仓库清爽了很多。

分支命名规范

首先是命名规范。我们现在强制要求所有分支名必须带前缀:

feature/ - 新功能开发
bugfix/ - bug修复
hotfix/ - 紧急热修复
release/ - 发布分支
而且必须包含任务编号,比如:feature/JIRA-1234-user-login
这样做的好处是,你一眼就能看出这个分支是干什么的,是谁负责的。之前我们有个分支叫test,三个月后根本没人记得这是测什么的,最后只能直接删掉。
还有几个避坑提示:
别用中文分支名,虽然Git支持,但在某些系统上会显示乱码
别用特殊字符,尤其是空格和@符号
用短横线-连接单词,不要用下划线_(这是业界约定俗成的规范)

分支生命周期管理

我见过最离谱的情况是,一个feature分支开了三个月都没合并,等到要合并的时候,冲突多到无法解决,最后只能重新写一遍。
所以我现在要求团队:feature分支的生命周期不能超过3天。如果一个功能太大,就拆成多个小feature,分批合并。
合并后立即删除分支,这是铁律。很多人舍不得删,觉得”万一以后要用呢”。相信我,不会的。Git有完整的历史记录,你随时可以找回合并的代码。
删除分支的命令我现在都记在手机备忘录里:

# 删除本地分支
git branch -d feature/xxx
# 删除远程分支
git push origin --delete feature/xxx

如果仓库里已经积累了很多僵尸分支,可以用这个命令清理:

# 查看已经合并到main的分支
git branch --merged main
# 批量删除(小心使用)
git branch --merged main | grep -v "main" | xargs git branch -d

分支保护策略

还有一个很重要的点:保护主分支。
我刚开始带团队的时候,大家都可以直接push到main分支,结果有一次实习生误push了未完成的代码,导致整个测试环境崩了。
后来我在GitHub/GitLab上设置了分支保护规则:

main分支禁止直接push,必须通过PR/MR
至少要有1个人approve才能合并
CI检查必须通过(包括单元测试、lint检查)
设置方法很简单,在GitHub仓库的Settings → Branches → Branch protection rules里配置就行。
这些规则看起来繁琐,但真的能避免很多低级错误。而且代码审查本身也是个很好的学习机会,团队成员可以互相学习编码风格和业务逻辑。

第三章：Git Rebase vs Merge — 什么时候用哪个?

说到rebase,我第一次用的时候真的很懵。执行完git rebase之后,看到一堆commit ID全变了,我以为代码丢了,差点吓哭。
后来才明白,rebase和merge虽然都能合并代码,但底层逻辑完全不一样。

Merge和Rebase的本质区别

我用一个生活化的类比来解释:
Merge 就像两条河流交汇,你能清楚看到两条河在哪里汇合的,汇合后形成一条更宽的河。在Git里,merge会产生一个merge commit,提交历史树会有明显的分叉。
Rebase 则像是把支流的水”重新倒”到主流中,看起来就像一开始只有一条河。Rebase会重写历史,把你的commit一个个”搬”到目标分支的后面,所以commit ID会改变。
从技术角度说:

Merge 保留了完整的历史记录,包括分支的创建和合并过程
Rebase 创造了一个线性的提交历史,更干净整洁,但丢失了分支的上下文信息

使用场景和黄金法则

那到底什么时候该用哪个呢?我的经验是:
用Merge的场景:

把feature分支最终合并到main分支
合并团队共享的分支
你想保留完整的合并历史
用Rebase的场景:
你的feature分支落后于main分支,想同步最新代码
整理自己个人分支的提交历史(还没push之前)
你想让提交历史保持线性
但是,有一个黄金法则必须记住:

永远不要对已经push到共享分支的commit进行rebase!
为什么?因为rebase会改变commit ID,如果别人已经基于你的旧commit工作了,你rebase之后他们的分支就乱了。我有个同事就犯过这个错误,结果整个团队的分支都需要重新拉,大家骂了他一个礼拜。
所以我现在的原则是:本地随便rebase,push之前想清楚。

交互式Rebase实战

说到rebase,就不得不提git rebase -i(交互式rebase),这个功能超级强大。
我之前开发一个功能,开发过程中commit了十几次,信息都是”fix”、“修改”、“再改”这种,特别不专业。在合并到main之前,我用git rebase -i把这十几个commit整理成了3个清晰的commit。
具体操作是这样的:

# 整理最近10个commit
git rebase -i HEAD~10

执行后会打开一个编辑器,你会看到类似这样的内容:

pick a1b2c3d 添加用户登录功能
pick e4f5g6h 修复登录bug
pick i7j8k9l 再改
pick m0n1o2p 优化登录逻辑
...

你可以把操作改成:

pick - 保留这个commit
squash 或 s - 把这个commit合并到前一个
reword 或 r - 修改commit信息
edit 或 e - 暂停在这个commit,允许你修改内容
drop 或 d - 删除这个commit
比如我会把上面的改成:

pick a1b2c3d 添加用户登录功能
squash e4f5g6h 修复登录bug
squash i7j8k9l 再改
reword m0n1o2p 优化登录逻辑

这样,前三个commit会被合并成一个,第四个会提示我修改commit信息。
老实讲,第一次用的时候可能会觉得复杂,但多练几次就顺手了。而且rebase之后的提交历史真的干净太多,再也不会有”修改”、“再改”、“又改”这种尴尬的commit了。
2025年的最佳实践是:本地用rebase整理提交历史,合并到主分支时用merge。这样既保证了主分支的清晰历史,又保留了重要的合并信息。

第四章：冲突解决不再慌

说到Git冲突,我真的有心理阴影。第一次遇到冲突的时候,我看着满屏的<<<<<<<和>>>>>>>,完全不知道该怎么办,最后只能把自己的代码全删了,重新写了一遍。
后来我发现,冲突其实没那么可怕,关键是要理解它在说什么,以及掌握一些预防技巧。

预防冲突的最佳实践

其实很多冲突是可以避免的。我现在要求团队做到这几点:
1. 每天至少同步一次主分支
每天开始工作前,先执行:

git checkout main
git pull origin main
git checkout feature/xxx
git merge main  # 或者 git rebase main

这样你的feature分支就不会落后太多,合并时冲突也会少很多。
2. 小步提交、快速合并
我之前说过,feature分支生命周期不要超过3天。分支存在的时间越长,和主分支的差异越大,冲突的概率就越高。
3. 团队协作前先沟通
如果两个人要改同一个文件,最好提前说一声。我们团队现在用notion维护一个”开发中功能”的表格,谁在改什么文件一目了然。

理解冲突标记和手动解决

即使做了预防,冲突还是会发生。这时候你会看到这样的标记:

<<<<<<< HEAD
function login(username, password) {
  // 你的代码
  return api.post('/login', { username, password });
}
=======
function login(email, password) {
  // 同事的代码
  return api.post('/auth/login', { email, password });
}
>>>>>>> feature/new-login

这个标记其实很好理解:

<<<<<<< HEAD 到 ======= 之间是你当前分支的代码
======= 到 >>>>>>> feature/new-login 之间是要合并进来的分支的代码
你需要决定保留哪部分,或者把两者结合起来。比如这个例子,你可能需要和同事讨论:是用username还是email登录?接口路径改成哪个?
解决完所有冲突后,删掉这些标记,然后:

git add .
git commit -m "解决登录功能的合并冲突"

使用可视化工具提升效率

说实话,手动解决冲突真的很累,尤其是冲突多的时候。我现在基本都用VS Code内置的冲突解决工具。
在VS Code里,冲突文件会高亮显示,而且会出现几个按钮:

“Accept Current Change” - 保留你的代码
“Accept Incoming Change” - 保留别人的代码
“Accept Both Changes” - 两边都保留
“Compare Changes” - 打开对比视图
点一下按钮就能解决冲突,比手动改方便太多了。
如果冲突特别复杂,我还会用git mergetool配合p4merge这种专业工具,可以三栏对比(基准版本、你的版本、别人的版本),看得更清楚。

冲突解决后的验证

有一次我解决完冲突,commit完就直接push了,结果发现把同事的一段关键逻辑删掉了,导致线上功能异常。那次教训让我养成了一个习惯:冲突解决后必须验证。
现在我每次解决完冲突都会:

本地跑一遍测试,确保功能正常
用git diff看一遍改动,确认没有误删代码
如果可能,让同事也review一下
这多花不了几分钟,但能避免很多线上事故。

第五章：建立高效的代码审查流程

老实讲,我刚开始工作的时候,特别反感代码审查。觉得自己写的代码已经很好了,为什么还要别人指手画脚?而且审查意见经常让我改来改去,特别浪费时间。
后来我自己开始审查别人的代码,才明白代码审查的价值远不止”找bug”那么简单。

代码审查的真正价值

我现在觉得,代码审查至少有三大价值:
1. 知识共享 - 让团队成员了解彼此在做什么,避免信息孤岛。我有好几次都是通过审查别人的PR,才知道原来某个功能可以这样实现。
2. 质量保证 - 多一双眼睛总能发现一些自己忽略的问题。有一次我写了个递归函数,自己测试没问题,结果审查的同事发现我没处理边界条件,差点导致栈溢出。
3. 技术成长 - 看优秀的代码是学习的最好方式。我的很多编码技巧都是从审查senior工程师的PR中学到的。

PR最佳实践

但是,代码审查要高效,PR本身就得写好。我们团队现在有几个约定:
PR大小要合适
一个PR最好在200-400行代码之间,最多不要超过500行。太大的PR没人愿意认真看,往往就走过场了。
如果一个功能太大,就拆成多个小PR,分批合并。比如开发一个用户系统,可以拆成:

PR1: 数据库表设计和基础model
PR2: 用户注册接口
PR3: 用户登录接口
PR4: 用户信息修改接口
PR描述要清楚
我们团队有一个PR描述模板:

## 背景
简述为什么要做这个改动
## 改动内容
- 新增了xxx功能
- 修复了xxx bug
- 重构了xxx模块
## 测试情况
- [ ] 单元测试通过
- [ ] 本地功能测试通过
- [ ] 已在测试环境验证
## 注意事项
需要注意的配置变更、数据库迁移等

这样审查的人一眼就能看懂你做了什么,为什么这么做。
Commit message要规范
我们现在参考Conventional Commits规范,commit信息必须带类型前缀:

feat: 添加用户登录功能
fix: 修复密码验证bug
refactor: 重构用户service层
docs: 更新API文档
这样做的好处是,以后可以自动生成changelog,而且回溯历史时也容易定位。

审查者和作者的职责

代码审查是双向的,审查者和作者都有责任。
审查者应该:

24小时内响应PR(不要让PR挂着好几天没人理)
提出建设性意见,不是挑刺(说”这样写不好”不如说”建议改成xxx,因为…”)
关注代码逻辑、可读性、潜在bug,而不是代码风格(风格问题交给lint)
作者应该:
及时回应评论,不要一声不吭
解释设计思路,如果审查者不理解,可能是代码写得不够清晰
虚心接受建议,即使一开始觉得不合理,也先想想为什么
我刚开始做审查者的时候,经常写”这里不对,改一下”这种评论,结果作者根本不知道我想要什么。后来我学会了这样写:“这个循环可能会有性能问题,如果数据量大的话。建议改成xxx或者xxx,你觉得呢?”这样沟通效果好多了。

2025年新趋势:AI辅助代码审查

2025年出了不少AI辅助代码审查的工具,GitHub在10月份推出了Code Quality功能,可以自动检测代码的可维护性、安全性问题。
我试用了一下,确实能发现一些我们容易忽略的问题,比如:

未处理的异常
潜在的内存泄漏
过于复杂的函数(圈复杂度过高)
但是,AI目前还无法替代人工审查。它能找到技术层面的问题,但对于设计思路、业务逻辑的合理性,还是需要人来判断。
所以我现在的做法是:AI工具先扫一遍找出明显问题,然后人再深入审查设计和逻辑。这样效率提升了不少。

第六章:常见错误和避坑指南

最后,我想分享一些我和团队踩过的坑,希望你能避开。

强制推送的危险

有一次,我的feature分支落后主分支很多,我rebase之后发现push不上去,因为本地和远程的历史不一致。
当时我不知道怎么办,就搜到了git push -f这个命令,心想”强制推送”听起来挺厉害的,就用了。
结果,我把同事刚push上去的代码全覆盖了。幸好我们有备份,否则他一天的工作就白费了。
后来我才知道,git push -f(或git push --force)是最危险的命令之一,它会用你的本地历史强行覆盖远程历史,不管远程有什么新代码。
什么情况可以用:

你的个人feature分支,而且确定没有别人在用
什么情况绝对不能用:
main/master等共享分支
任何有其他人在用的分支
如果确实需要强制推送,用git push --force-with-lease更安全,它会检查远程分支是否有新的commit,如果有就拒绝推送。

其他高频错误

除了强制推送,还有一些常见错误:
1. 直接在main分支开发
永远不要这样做。就算是改一个字的简单修改,也应该开一个分支,发PR合并。这样才有审查记录,出问题也容易回滚。
2. Commit信息太随意
“fix”、“修改”、“111”、“asdf”…我见过的奇葩commit信息太多了。以后回溯代码的时候,这些信息完全没用。
养成好习惯,每个commit都认真写信息,说清楚改了什么、为什么改。
3. 不及时删除已合并的分支
分支合并后就应该立即删除,不要留着占地方。GitHub和GitLab在合并PR时都有选项可以自动删除分支,记得勾上。
4. 盲目使用git add .
git add .会把所有改动都加到暂存区,包括一些你不想提交的文件。我就见过有人不小心把.env文件(包含密码)提交上去了。
更好的做法是用git add -p,它会逐个询问你是否要add这个改动,虽然慢一点但更安全。

团队协作规范Checklist

最后,我整理了一份团队Git规范的checklist,你可以参考:
分支管理

结论

回想起凌晨两点处理线上事故的那个夜晚,我真希望当时就掌握这些技巧。但好在,踩过的坑都变成了经验。
其实Git本身并不难,难的是在团队中达成共识。再好的工作流、再规范的流程,如果团队成员不遵守,也是白搭。
所以我的建议是:先从简单开始,逐步优化。不要一开始就搞一套超复杂的规范,而是根据团队实际情况,一点点调整。
比如:

第一周:统一分支命名规范
第二周:设置分支保护规则
第三周:建立PR审查流程
第四周:引入commit message规范
慢慢来,给团队适应的时间。
最重要的是沟通。遇到问题不要自己闷头搞,多和同事讨论。很多Git冲突本质上是沟通问题,而不是技术问题。
如果你想进一步提升Git技能,我推荐几个资源:
Atlassian Git Tutorial - 最全面的Git教程
Pro Git电子书 - Git官方出品,免费在线阅读
GitKraken或SourceTree - 可视化Git客户端,对新手更友好
下一篇文章我可能会写Git的一些高级技巧,比如cherry-pick、stash、submodule等。如果你有兴趣,可以关注我。
最后,祝你和团队的Git协作越来越顺畅,再也不用半夜起来处理merge冲突了!

Git团队协作完整流程

从选择工作流到建立代码审查流程的完整步骤，涵盖分支管理、冲突解决和最佳实践

⏱️ 预计耗时: 1 小时

1
步骤1: 选择适合团队的Git工作流
根据团队规模选择工作流：

1-5人小团队：
• 使用GitHub Flow（简单快速迭代）
• 只有一个主分支main/master
• 所有功能从主分支拉出feature分支开发
• 开发完发PR合并，配合CI/CD每天可发布多次

5-15人中型团队：
• GitHub Flow + 简化release流程
• 需要发布时创建release分支
• 测试完成后合并到main

15人以上：
• 考虑Git Flow或混合方案
• Git Flow适合有明确发布周期的大公司
• 包含develop/feature/release/hotfix分支

不推荐：
• Trunk Based Development需要90%+测试覆盖率，太激进
• 2025年趋势是混合模型，别过度设计
2
步骤2: 建立分支管理规范
分支命名规范：使用统一前缀（feature/新功能、bugfix/bug修复、hotfix/紧急热修复、release/发布分支），必须包含任务编号（如feature/JIRA-1234-user-login），用短横线-不用下划线_，不用中文和特殊字符。分支生命周期管理：feature分支不超过3天，合并后立即删除（git branch -d feature/xxx，git push origin --delete feature/xxx），批量删除已合并分支（git branch --merged main | grep -v "main" | xargs git branch -d）。分支保护：在GitHub/GitLab设置main分支禁止直接push必须通过PR，至少1人approve才能合并，CI检查必须通过。
3
步骤3: 掌握Rebase和Merge的使用场景
Merge场景：把feature分支最终合并到main分支，合并团队共享的分支，想保留完整的合并历史。Rebase场景：feature分支落后于main想同步最新代码，整理个人分支提交历史（还没push之前），想让提交历史保持线性。黄金法则：永远不要对已经push到共享分支的commit进行rebase（会改变commit ID导致别人分支乱），本地随便rebase push之前想清楚。交互式Rebase：git rebase -i HEAD~10整理最近10个commit，使用pick/squash/reword/edit/drop操作。2025年最佳实践：本地用rebase整理提交历史，合并到主分支时用merge。
4
步骤4: 预防和解决Git冲突
预防冲突：每天至少同步一次主分支（git checkout main && git pull origin main && git checkout feature/xxx && git merge main），小步提交快速合并（feature分支不超过3天），团队协作前先沟通。理解冲突标记：<<<<<<< HEAD到=======是你的代码，=======到>>>>>>>是要合并的代码。使用可视化工具：VS Code内置冲突解决工具（Accept Current Change/Accept Incoming Change/Accept Both Changes/Compare Changes），git mergetool配合p4merge三栏对比。解决后验证：本地跑一遍测试确保功能正常，git diff看一遍改动确认没有误删代码，让同事也review一下。
5
步骤5: 建立高效的代码审查流程
PR最佳实践：大小200-400行最多500行，如果功能太大拆成多个小PR分批合并。PR描述用模板包含背景/改动内容/测试情况/注意事项。Commit message用Conventional Commits规范带类型前缀（feat/fix/refactor/docs）。审查者和作者职责：审查者24小时内响应PR，提出建设性意见关注代码逻辑可读性潜在bug，作者及时回应解释设计思路虚心接受建议。2025年趋势：AI辅助代码审查（GitHub Code Quality自动检测可维护性安全性问题），AI先扫一遍找出明显问题，人再深入审查设计和逻辑。
6
步骤6: 避免常见错误和建立团队规范
禁止操作：不要在main分支直接开发，不要对共享分支使用git push -f（用git push --force-with-lease更安全），不要rebase已push到共享分支的commit，不要提交未经测试的代码。其他高频错误：commit信息太随意（用Conventional Commits规范），不及时删除已合并分支，盲目使用git add .（用git add -p更安全）。团队协作规范Checklist：分支管理（统一命名规范、包含任务编号、生命周期不超过3天、合并后立即删除、设置分支保护），代码提交（commit信息符合规范、每个commit只做一件事、提交前运行lint和测试、不提交敏感信息），代码审查（PR大小合理、描述清晰、至少1人approve、CI检查通过、24小时内响应），冲突处理（每天同步主分支、解决后运行测试、不确定及时沟通）。

常见问题

小团队应该选择哪种Git工作流？

推荐使用GitHub Flow，原因：

• 简单快速：只有一个主分支，所有功能从主分支拉出feature分支
• 快速迭代：配合CI/CD每天可发布多次
• 学习成本低：团队成员容易理解和遵守

不推荐Git Flow的原因：
• 流程复杂：需要维护develop/feature/release/hotfix多个分支
• 适合大公司：有明确发布周期的大团队才需要
• 小团队用起来太繁琐，每天光管理分支就要花很多时间

2025年趋势：混合模型，小团队用GitHub Flow，中大型团队把Git Flow的部分功能结合进来。关键点：别过度设计，选择适合团队规模的方案。

分支管理有哪些黄金法则？如何避免分支混乱？

分支命名规范：
• 使用统一前缀（feature/新功能开发、bugfix/bug修复、hotfix/紧急热修复、release/发布分支）
• 必须包含任务编号（如feature/JIRA-1234-user-login）
• 用短横线-连接单词不用下划线_（业界约定俗成）
• 不用中文分支名（虽然Git支持但在某些系统上会显示乱码）
• 不用特殊字符（尤其是空格和@符号）

分支生命周期管理：
• feature分支生命周期不能超过3天（如果一个功能太大就拆成多个小feature分批合并）
• 合并后立即删除分支：
- git branch -d feature/xxx删除本地
- git push origin --delete feature/xxx删除远程
• 批量删除已合并分支：git branch --merged main | grep -v "main" | xargs git branch -d

分支保护策略：
• 在GitHub/GitLab设置main分支禁止直接push必须通过PR/MR
• 至少要有1个人approve才能合并
• CI检查必须通过（包括单元测试、lint检查）
• 设置方法在GitHub仓库的Settings → Branches → Branch protection rules里配置

Rebase和Merge有什么区别？什么时候用哪个？

本质区别：

Merge：
• 就像两条河流交汇，能清楚看到两条河在哪里汇合，汇合后形成更宽的河
• 在Git里merge会产生merge commit，提交历史树会有明显的分叉
• 保留了完整的历史记录包括分支的创建和合并过程

Rebase：
• 则像是把支流的水"重新倒"到主流中，看起来就像一开始只有一条河
• Rebase会重写历史把你的commit一个个"搬"到目标分支的后面，所以commit ID会改变
• 创造了一个线性的提交历史更干净整洁但丢失了分支的上下文信息

使用场景：
• Merge适合：把feature分支最终合并到main分支、合并团队共享的分支、想保留完整的合并历史
• Rebase适合：feature分支落后于main想同步最新代码、整理个人分支提交历史（还没push之前）、想让提交历史保持线性

黄金法则：
• 永远不要对已经push到共享分支的commit进行rebase（因为rebase会改变commit ID，如果别人已经基于你的旧commit工作了，你rebase之后他们的分支就乱了）

原则：本地随便rebase，push之前想清楚。

2025年最佳实践：本地用rebase整理提交历史，合并到主分支时用merge。

如何预防和解决Git冲突？

预防冲突：

1) 每天至少同步一次主分支：
• 每天开始工作前：git checkout main && git pull origin main && git checkout feature/xxx && git merge main或git rebase main

2) 小步提交快速合并：
• feature分支生命周期不要超过3天，分支存在时间越长和主分支差异越大冲突概率越高

3) 团队协作前先沟通：
• 如果两个人要改同一个文件最好提前说一声
• 用notion维护"开发中功能"表格谁在改什么文件一目了然

理解冲突标记：
• <<<<<<< HEAD到=======之间是你当前分支的代码
• =======到>>>>>>>之间是要合并进来的分支的代码
• 你需要决定保留哪部分或把两者结合起来
• 解决完所有冲突后删掉这些标记然后git add . && git commit

使用可视化工具：
• VS Code内置冲突解决工具（Accept Current Change保留你的代码、Accept Incoming Change保留别人的代码、Accept Both Changes两边都保留、Compare Changes打开对比视图）
• git mergetool配合p4merge三栏对比（基准版本、你的版本、别人的版本）

解决后验证：
• 本地跑一遍测试确保功能正常
• git diff看一遍改动确认没有误删代码
• 如果可能让同事也review一下

如何建立高效的代码审查流程？PR最佳实践是什么？

代码审查价值：
• 知识共享（让团队成员了解彼此在做什么避免信息孤岛）
• 质量保证（多一双眼睛总能发现一些自己忽略的问题）
• 技术成长（看优秀的代码是学习的最好方式）

PR最佳实践：

1) PR大小要合适：
• 最好200-400行代码之间最多不要超过500行
• 太大的PR没人愿意认真看，如果功能太大拆成多个小PR分批合并

2) PR描述要清楚：
• 用模板包含背景/改动内容/测试情况/注意事项
• 这样审查的人一眼就能看懂你做了什么为什么这么做

3) Commit message要规范：
• 参考Conventional Commits规范，commit信息必须带类型前缀：
- feat/添加新功能
- fix/修复bug
- refactor/重构
- docs/更新文档
• 这样做的好处是以后可以自动生成changelog回溯历史时也容易定位

审查者和作者职责：

审查者应该：
• 24小时内响应PR（不要让PR挂着好几天没人理）
• 提出建设性意见不是挑刺（说"这样写不好"不如说"建议改成xxx因为..."）
• 关注代码逻辑可读性潜在bug而不是代码风格（风格问题交给lint）

作者应该：
• 及时回应评论不要一声不吭
• 解释设计思路（如果审查者不理解可能是代码写得不够清晰）
• 虚心接受建议即使一开始觉得不合理也先想想为什么

Git团队协作有哪些常见错误？如何避免？

常见错误：

1) 强制推送的危险：
• git push -f或git push --force是最危险的命令之一，会用你的本地历史强行覆盖远程历史不管远程有什么新代码
• 绝对不能用：main/master等共享分支、任何有其他人在用的分支
• 如果确实需要强制推送用git push --force-with-lease更安全，它会检查远程分支是否有新的commit如果有就拒绝推送

2) 直接在main分支开发：
• 永远不要这样做，就算改一个字的简单修改也应该开一个分支发PR合并
• 这样才有审查记录出问题也容易回滚

3) Commit信息太随意：
• "fix"、"修改"、"111"、"asdf"这些奇葩commit信息以后回溯代码时完全没用
• 养成好习惯每个commit都认真写信息说清楚改了什么为什么改

4) 不及时删除已合并的分支：
• 分支合并后就应该立即删除不要留着占地方
• GitHub和GitLab在合并PR时都有选项可以自动删除分支记得勾上

5) 盲目使用git add .：
• 会把所有改动都加到暂存区包括一些你不想提交的文件
• 有人不小心把.env文件包含密码提交上去了
• 更好的做法是用git add -p它会逐个询问你是否要add这个改动虽然慢一点但更安全

团队协作规范Checklist：

分支管理：
• 统一命名规范、包含任务编号、生命周期不超过3天、合并后立即删除、设置分支保护

代码提交：
• commit信息符合规范、每个commit只做一件事、提交前运行lint和测试、不提交敏感信息

代码审查：
• PR大小合理、描述清晰、至少1人approve、CI检查通过、24小时内响应

冲突处理：
• 每天同步主分支、解决后运行测试、不确定及时沟通

禁止操作：
• 不要在main分支直接开发
• 不要对共享分支使用git push -f
• 不要rebase已push到共享分支的commit
• 不要提交未经测试的代码

24 分钟阅读 · 发布于: 2025年11月24日 · 修改于: 2026年1月22日

Easton

技术开发

引言