这条原则说的是什么
在已经推送、并且别人可能已经拉取过的分支上做变基或其它改写历史的操作，会让旧提交与重写后的提交同时存在，协作者手里就会出现两条互不相干的历史。公共分支（主干、开发线、发布线）的正确做法是只追加提交，改写留给私有分支。
怎么判断分支是不是私有的
最直接的判断是看有没有别人引用过它，而不是凭印象。可以查看远端分支里是否包含某个提交，也可以看这条分支上有没有他人的提交记录。另一个明显信号是有没有对应的合并请求：一旦开了 PR，就等于对外声明了这条分支的历史，后续不应该再改写。
基本信息
| 适用平台 | Git 工作流通用原则，与托管平台无关 |
|---|---|
| 适用对象 | 主干、开发线、发布线等共享分支 |
| 私有分支 | 可以变基、整理、强推 |
| 判断方法 | git branch -r --contains <提交> 查看谁引用了它 |
| 补救方式 | 让协作者按变基方式拉取，或尽快合并后停止改写 |
| 制度配套 | 分支保护规则可以从机制上禁止改写 |
典型使用场景
- 制定规范：在贡献指南里写清哪些分支禁止改写历史
- 评审前自查：准备强推前确认分支是否已被他人引用
- 事故善后：同事遇到历史分叉时如何恢复对齐
- 保护主干：用平台的分支保护规则挡掉强推
- 拆分工作：把整理提交的活儿挪到私有分支上进行
常用示例
常用示例
git log --oneline origin/feature | head # 查看远端分支顶部的提交
git branch -r --contains <提交> # 远端分支里是否包含它
git for-each-ref --contains <提交> --format='%(refname:short)'
git reflog show feature | head # 本地是否有改写痕迹
git fetch --prune # 同步远端分支现状分支类型与允许的操作
| 分支类型 | 允许改写 | 典型操作 |
|---|---|---|
| 主干与发布分支 | 否 | 只追加提交，走 PR 或 MR 合入 |
| 长期开发分支 | 否 | 追加提交，定期合并 |
| 私有功能分支 | 是 | 变基、amend、安全强推 |
| 已开合并请求的分支 | 基本不变 | 改写前先与评审人沟通 |
变基已经发生的补救方式：让协作者用变基方式拉取以便对齐，或者尽快把分支合并掉并停止继续改写历史。
「只我一人用这条分支」的判断经常过期。动手前再查一次谁引用了它，尤其是在多人协作的仓库里。