Git 团队工作流：分支怎么开、提交怎么写、冲突怎么解

Git 学得会命令、用不好协作，是大多数团队的常态。单人开发时随便 commit 都没事，一上团队，分支怎么开、历史怎么保持清晰、冲突怎么少发生就变成了工程问题。这篇给出一套轻量可落地的团队工作流。

一、分支模型：够用就行，别过度设计

没有银弹，但一套主流的分层足够覆盖多数团队：

分支	用途	说明
main / master	线上稳定版本	受保护：禁止直接 push，只接受合并请求
develop（可选）	日常集成分支	小团队可直接 main + 功能分支，少一层是一层
feature/xxx	功能开发	从 main 切出，开发完合并回 main 后删除
fix/xxx	缺陷修复	紧急修复建议从 main 直接切，修完立即合回
release/xxx	发布前准备	版本发布窗口内只做修 bug，不发新功能

分支名建议带编号：feature/order-refund、fix/login-500，一眼能看出意图，配 issue 编号更好回溯。

二、merge 还是 rebase：各自解决什么问题

merge：保留“合并发生在何时”的真实历史，会多出 merge commit；
rebase：把当前分支的提交“移植”到目标分支顶端，历史是线性的，更好阅读，代价是改写提交。

# 合并功能分支（保留真实合并点）
git checkout main
git merge feature/order-refund

# 想让 feature 分支先同步 main 的最新代码（保持线性）
git checkout feature/order-refund
git rebase main

黄金法则：永远不要 rebase 已经推送出去、别人正在用的公共分支——那等于重写别人已经拉下来的历史，团队会“互相打架”。rebase 只用于自己尚未推送的本地提交。

三、提交信息规范：让历史可检索

主流的 Conventional Commits 约定，一句话格式为 <type>(<scope>): 描述：

feat(order): 新增退款状态流转
fix(cart): 修复数量修改后总价不刷新
docs(readme): 补充本地开发环境说明
refactor(auth): 抽取登录校验中间件
perf(list): 列表接口分页查询加索引
test(api): 补充订单接口用例
chore: 升级依赖版本

feat / fix 提交会自动体现在变更日志（changelog）里，值得写清楚；
描述用动词开头、说“做了什么”而不是“做了什么文件”；
一次提交只做一个逻辑变更，别把格式化、重构、功能混在一个 commit 里。

四、代码评审（Code Review）：合并前的最后一道关

功能分支开发完，push 后发起 Pull Request / Merge Request；
PR 描述写清楚：改了什么问题、怎么改的、怎么自测的，附截图/接口验证更佳；
合并前至少一位同事评审通过；小改动也要有人看过，防止“只有自己看得懂”的代码；
团队约定合并方式（如 squash merge 把功能压缩成一个提交），保持 main 历史干净；
CI 检查（编译、测试、Lint）通过才允许合并。

评审是发现问题的最后便宜关口，比线上事故便宜得多。给同事的评论对事不对人，用“这里会不会有 XX 风险？”代替“你写错了”。

五、冲突与事故救援：常用救命命令

# 冲突后：逐个文件解决再继续
git status            # 看哪些文件冲突
git diff              # 看冲突内容（<<<<<< ==== >>>>> 标记）
git add <file> && git commit   # 解决完标记为已解决

# 想放弃当前合并/变基
git merge --abort
git rebase --abort

# 提交完发现改错了：软回退，保留改动重新提交
git reset --soft HEAD~1

# 误删分支 / 误 reset：reflog 都能找回来
git reflog            # 查看 HEAD 的所有历史位置
git reset --hard HEAD@{2}   # 恢复到对应位置

# 临时切换任务
git stash && git switch main
git stash pop

git reset --hard 和 git push --force 是破坏性命令：前者丢弃未提交改动，后者覆盖远端历史。执行前先确认这是自己的分支、且没有别人的提交会被抹掉。

六、还有两个好习惯

保持提交小而频繁：一整天憋一个大 commit，冲突时根本没法定位；每完成一小步就提交，配合 git log --oneline --graph 随时看清全貌；
.gitignore 从第一天就配好：node_modules、dist、.env、日志等不该进仓库，用 github/gitignore 的模板起步。

工作流的意义不是限制，而是让每个人都能回答“我现在在哪、改了什么、怎么安全地合上去”。规则简单到能坚持，才叫好的规范。