在团队开发中，很多“排查慢、协作乱、回滚难”的问题，根因并不复杂：Git 基本习惯没建立。

最常见的场景是：线上出问题后回溯提交记录，结果 git log 全是 fix、update、wip。最终只能一条条 git show 手工排查，效率极低。

本文聚焦 3 件最值得立刻落实的事：

1. 提交信息怎么写，才能“可追溯”
2. 分支怎么管理，才能“可协作”
3. rebase 和 merge 怎么选，才能“可维护”

---

1）提交信息：不要只写“改了什么”，更要写“为什么改”

很多同学都写过这样的提交：

git add .
git commit -m "fix"

短期看省事，长期看成本很高。

原因很简单：

• “改了什么”可以从 diff 看到
• “为什么这么改”只能靠 commit message

推荐格式：Conventional Commits（核心是团队统一）

建议结构：

类型(范围): 简短描述（建议 50 字以内）

可选正文：重点说明为什么这样改、有什么约束

常用类型如下：

类型	说明	示例
feat	新功能	feat(user): 新增头像上传能力
fix	缺陷修复	fix(auth): 修复 token 过期未自动刷新
refactor	重构（不改功能）	refactor(api): 提取公共请求拦截器
docs	文档更新	docs: 补充本地启动步骤
chore	构建/依赖/配置	chore: 升级 axios 至 1.6.0
test	测试相关	test(login): 新增登录接口单测
perf	性能优化	perf(home): 优化首屏图片懒加载
style	纯样式/格式调整	style: 统一缩进为 2 空格

对比：

# ❌ 信息量不足
fix
update
改了一下
wip

# ✅ 可读性和可追踪性更强
fix(auth): 修复 token 过期后未自动刷新
feat(order): 新增订单列表分页能力
refactor(user): 拆分 UserService 鉴权逻辑

提交粒度建议

原则：一个 commit 只做一件完整的事。

• ✅ feat(login): 新增短信登录流程
• ✅ fix(login): 修复验证码重复提交
• ❌ 同一提交中混入“加功能 + 改样式 + 升级依赖 + 改配置”

自检问题：

六个月后再看这条提交，是否能快速理解“改动意图”？

---

2）分支管理：不要直接在 `main/master` 上开发

单人小实验还可以“凑合”，但团队协作中直接改主干通常会导致：

• 彼此改动互相覆盖
• 未验证代码进入主干
• 出问题后回滚成本高

建议固化的 3 条规则

1. main/master 只保留可发布代码
2. 每个功能/修复使用独立分支
3. 合并后及时删除分支，避免长期堆积

分支命名建议

• 功能：feat/user-avatar
• 修复：fix/login-crash
• 重构：refactor/request-layer
• 紧急：hotfix/payment-timeout

避免无语义命名：dev、test1、aaa。

可复用流程模板

# 1. 先同步主干（以 develop 为例）
git checkout develop
git pull origin develop

# 2. 从最新主干切出功能分支
git checkout -b feat/user-avatar

# ... 开发中 ...

# 3. 推送并发起 PR
git push -u origin feat/user-avatar

# 4. 合并后清理分支
git checkout develop
git pull origin develop
git branch -d feat/user-avatar
git push origin --delete feat/user-avatar

实践提示：切分支前先 pull，冲突量会明显下降。

---

3）`rebase` vs `merge`：不是二选一，而是按场景选

先记结论：

• merge：保留分叉历史
• rebase：整理线性历史

两者都正确，关键是场景。

场景建议

场景	推荐方式	理由
feature 合并进主干	merge（或按团队策略 squash merge）	保留协作上下文，更稳
feature 同步主干进展	rebase	历史更线性，PR 更易读
提 PR 前整理 WIP 提交	rebase -i	reviewer 阅读成本更低
共享分支（多人共同开发）	避免 rebase	会改写历史，影响他人

黄金法则：个人 feature 分支可 rebase；共享分支尽量不 rebase。

常用命令模板

# 把主干最新变更同步到当前 feature 分支
git fetch origin
git rebase origin/develop

# 冲突处理后继续
git rebase --continue

# 放弃本次 rebase
git rebase --abort

# 提 PR 前整理最近 3 条提交
git rebase -i HEAD~3

# 常见动作：
# pick   保留提交
# reword 修改提交说明
# squash 合并到上一条
# drop   删除提交

---

实战清单（可直接用于团队规范）

Commit 检查

x是否写清“为什么改”

x是否遵循 type(scope): subject

x是否做到“一次提交一件事”

分支检查

x是否从最新主干切分支

x分支命名是否有业务语义

x合并后是否删除本地和远端分支

历史管理检查

x同步主干时，个人分支优先 rebase

x合入主干遵循团队 merge/squash 策略

x共享分支避免改写历史

---

结语

Git 的差距往往不在“会不会命令”，而在“是否形成一致、稳定、可复用的习惯”。

把这 3 件事落实好：

• 提交写清楚，是对未来排障效率负责
• 分支管清楚，是对团队协作效率负责
• 历史维护好，是对项目可维护性负责

下篇将继续聚焦救火场景：reflog 找回误删、stash 安全使用、.gitignore 生效机制、冲突处理流程等。

更多《软件安装&避坑&实践》系列

关注公众号：IT安装手册
博客：https://itinstall.dev