Workflows
多人共享分支的同步边界
当多人同时在同一分支协作时，明确什么动作可以做、什么动作不该做，减少同步混乱和历史覆盖。
- 要把命令组合成稳定流程的团队成员
- 需要处理协作顺序和分支边界的人
- 知道 fetch / pull / push / branch 的基本作用
- 能理解一条分支为什么会分叉
- 照抄流程却没确认当前分支关系
- 在共享分支上用错整合方式
只要一条分支开始被多人共同依赖，很多你在个人分支上习以为常的动作都会立刻变得高风险。
在个人分支里，rebase 和 reset 可能只是整理；在共享分支里，它们可能直接制造同步事故。
主分支release 分支多人共同开发分支
同步稳定历史可解释风险可控
共享分支默认优先追加历史，而不是重写历史。
为什么共享分支特别容易踩坑
共享分支的核心特点不是“人多”，而是“别人也在依赖你当前看到的这条历史表达”。
一旦你改写了它，就不仅仅是在改变自己的视图，而是在改变别人同步时的基准。
这也是为什么共享分支上的问题常常是团队事故，而不是单人误操作。
最核心的一条原则
共享分支上优先保证“别人能稳定同步”，再考虑“历史是否足够漂亮”。
这条原则看起来保守，但它能直接降低三类风险：
- 别人 pull 之后突然分叉
- CI、tag、release note 的上下文失真
- 事故发生后说不清分支到底经历了什么
哪些动作通常是安全边界内的
通常可以做
git fetchgit pull --ff-only- 显式 merge
- 经团队约定的 review merge
这些动作的共同点是：它们大多在追加历史，或者至少不会悄悄改写别人已经看到的那部分。
需要极其谨慎
- 在共享分支上 rebase
- 修改共享分支上的提交顺序
- 变更分支上游关系但不通知团队
这些动作不是绝对不能做，但它们必须带着明确协调。
默认应避免
- 无通知 force push
- reset 覆盖共享历史
- 把共享分支当成个人整理空间
为什么这条边界更稳
共享分支真正重要的不是单个人整理历史的效率，而是整个团队的同步可预测性。
如果每个人都默认“我先整理一下，别人再拉一下就好”，最后得到的往往不是更整洁的历史，而是更高的协调成本。
它最大的风险往往不是命令本身，而是别人并不知道你已经改写了他们赖以同步的那条历史。共享分支上的很多问题，实质上都是协作预期没有对齐。
不同共享分支的风险等级也不一样
主分支 / 默认分支
风险最高。
通常应该默认只允许受控合并和受保护规则下的更新。
Release 分支
风险也很高，因为它常常对应发布状态、tag 和部署记录。
这里更要避免随手改写历史。
多人协作的功能分支
虽然比主分支低一些，但只要多人同时依赖，也不应该再按个人分支那样随意整理。
一个适合团队执行的最小规则
- 先明确哪些分支属于共享分支
- 共享分支默认不做私自 rebase 和 force push
- 同步前先 fetch，再判断关系
- 共享分支如果必须重写历史，必须显式通知相关人
- 主分支和 release 分支比普通共享分支更保守
常见误区
把共享分支当成个人分支继续整理
这通常是最常见、也最贵的误区。
觉得“我只是改了一下历史，别人拉一下就好”
别人未必知道你改了什么，也未必知道该怎么安全同步回来。
不区分不同共享分支的风险等级
主分支、release 分支和多人协作 feature 分支，风险并不相同，规则也不该完全一样。
- 这条分支是不是只有我一个人在用？
- 这个动作是在追加历史，还是在重写历史？
- 如果同事现在执行 pull / fetch / rebase，他会不会被我这个动作打断？
接下来建议继续学什么
Fetch vs pullPR merge strategy and platform settingsMerge queue workflow