Git 进阶工作流：从 rebase 到 cherry-pick 的团队协作最佳实践

一、Git 不是学会 add/commit/push 就够了

很多人用 Git 的方式是"习惯性 commit + 习惯性 push"，就像一个每次保存文档都复制全篇的人。Git 真正的价值不在"备份代码"，而在"记录开发过程中的每一个决策和每一次思路演变"。一个干净的 Git 历史应该让新人读到 README 后能沿着提交记录理解项目是怎么一步步构建起来的。

大多数团队的困惑是：Git 分支到底怎么管？主流有两种流派：GitHub Flow 只有 main 和 feature 两个层级，追求简单快速；Git Flow 加入了 develop、release、hotfix 等多层分支，追求规范的发布流程。团队规模 20 人以下用前者，50 人以上用后者。

二、三个进阶技巧

一）rebase 的正确使用姿势

rebase 把当前分支的提交"移植"到目标分支的最新节点上。它让历史变成一条直线——可读性远超 merge 产生的分叉图。但从公共分支 rebase 是危险的——任何人基于旧 commit 的开发都会冲突。黄金法则：只 rebase 你自己还没 push 的本地提交。

二）cherry-pick 的实用场景

在 release 分支发现一个 Bug，修完后想把这个修复同步回 main——这正是 cherry-pick 的最佳场景。

三）交互式 rebase -i

`git rebase -i HEAD~5` 让你重新编辑最近 5 个提交——合并多个小提交为一个有意义的提交、修改提交信息、删除实验性提交。在 push 到远端之前整理本地历史，这是对同事阅读体验最基本的尊重。

三、提交信息的写作规范

Commit message 是写给 6 个月后的自己的。推荐 Conventional Commits 规范：`类型(范围): 简短描述`。类型包括 feat、fix、docs、refactor、test。正确的提交信息应该回答"为什么改"而不是"改了什么"——code diff 已经告诉你改了什么。