我在不少开发者社群里见过这样一种态度：保护分支就是不让大家直接往 master 推代码，折腾一圈走 Pull Request，纯属给自己添麻烦。说实话，我个人早前也这么想过，直到在某个项目里亲眼看到有人把写到一半的代码直接提交到主干分支，导致全组好几天都在处理连带问题，才真正意识到保护分支不是行政流程，而是代码仓库的“交通安全规则”。这篇内容我会从新建仓库开始，把 Gitee 保护分支的配置逻辑、日常开发到合并的完整操作、合并阶段的高频踩坑、以及更进一步配合自动化的思路都过一遍。适合刚接触仓库管理的开发者，也适合想优化团队协作流程的组长或运维同学。1. 保护分支到底在防什么：先想清楚再动手1.1 一次现场事故让我理解了保护分支的必要性好几年前，我们做一个内部小项目，仓库刚建好，没有配置任何保护规则。某位同事图省事，直接在网页端编辑了 master 分支上的核心配置文件。他本意只是微调一个参数，结果保存时把文件里一段关键逻辑覆盖掉了。当天下午大家陆续拉取代码，编译直接挂掉，一堆人花了不少时间排查，最后才发现问题来自那个无意识的网页提交。那次事故之后，我总结出一个很朴素的结论：人不是机器，总会在某个瞬间注意力掉线。保护分支不是不信任团队成员，而是承认错误不可避免之后，用机制把错误挡在发布链路之前。打个比方，它就像汽车的安全带，不是为了让你撞车，而是为了在意外出现的时候把损失压到最低。你会希望一个关键配置文件的变更，至少经过一次人工确认再进入主干，这比事后复盘有价值得多。1.2 保护规则的内核是控制“怎么进”而不是控制“进不进”保护分支最容易被理解成“禁止向某些分支直接推代码”。方向没错，但这只是一个侧面。你去打开 Gitee 的保护分支设置，会看到里面有一组规则：允许推送的人、是否要求 Pull Request、需要几位评审人、是否禁止强制推送、是否要求自动化检查通过。把这些规则组合起来看，本质上回答的是三个问题：谁能改动受保护分支？改动以什么方式进入？进入之前要经过哪些检查？保护分支的核心机制，是把“提交-合并”这个动作从单人行为转变成一个多人协作流程。写代码的人负责实现，评审人负责看逻辑，自动化工具负责兜底低级失误，最后再通过一次明确的合并动作进入主干。这样每一次变更都留下线索，出了问题可以追溯到具体提交和决策环节。1.3 保护分支不等于把分支锁死还有一个很常见的误解：开启保护分支后，别人是不是就没法干活了？实际上完全不受影响。受保护的分支通常是主干分支，但日常开发都是基于主干拉出新的功能分支进行的，这些新分支默认不受保护。你可以随便提交、随意调整、随时推送。保护分支真正影响的时间点只有一个，就是从功能分支合并回主干的那一刻。这就像你在家里可以随意装修房间，但改变承重墙结构必须报备审批。前面所有自由发挥都不变，只有进主干的最后一步需要按规则来。这个设计既保证了开发自由度，又能让主干代码保持相对稳定。2. 新建仓库时的分支规划和默认设置，别给后面埋雷2.1 初始化仓库时就把基础文件补齐在 Gitee 上创建仓库时，很多人的习惯是直接跳过初始化选项，等代码写好了再上传。我的建议恰恰相反，项目一开始就把 README、.gitignore、开源许可证这三个基础文件补上。README 不是摆设，它是仓库的门面。团队新成员加进来的第一件事就是看 README，需要知道这个项目是干什么的、怎么跑起来、目录结构是什么样的。.gitignore 的重要性，我已经见过太多反面案例了。如果一开始没配好，日志、本地配置、编译产物很容易被误提交进仓库，后面就算补上忽略规则，已经进入历史记录的文件还得专门清理，过程非常麻烦。开源许可证虽然对内部项目不是刚需，但养成习惯之后做开源分享会省很多事。2.2 默认分支名最好一次性定好新建仓库时，Gitee 的默认分支通常是 master，你也可以在初始化时创建 main 或者其他名称的分支，然后在仓库设置里把它设为默认分支。分支名本身没有绝对标准，真正要留意的是改名的成本。如果仓库还是空的，改默认分支名很容易。但一旦有了几个提交，成员们也在本地克隆过了，想换默认分支就比较麻烦了：所有人的本地跟踪关系要改，后续 PR 的目标分支也要逐一调整。我见过不少项目在早期频繁改默认分支名，导致大家的本地仓库状态混乱，有人 push 到一个旧分支上，半天没人发现。所以趁仓库还没有内容，把默认分支名确定下来，后面会省去很多无谓的沟通成本。2.3 分支模型先从最简单的开始团队刚起步时，分支模型一般就是两端：主干 master，加上开发过程中临时创建的功能分支。这个阶段只保护 master 就够了，不需要一上来就配置 develop、release、hotfix 好几个层级，因为每多一个受保护分支，团队就要多承担一层流程维护成本。等到团队规模到了十人以上，或者项目开始有明确的上线节奏，再逐步引入 develop 作为集成分支，引入 release 分支做版本管理。规则的增加应该由实际需求推动，而不是提前把所有情况都预设好。我见过有些团队建仓当天就设置了多层保护，结果新人完全不知道应该往哪个分支提 PR，最后干脆绕过平台在群里传代码包，保护规则形同虚设，流程反而成了大家的负担。3. 配置保护分支规则的实操路径：一步步来3.1 入口别找错：仓库级管理与分支设置在 Gitee 仓库页面，右上角一般有管理入口，点进去之后，在左侧菜单能找到分支设置相关区域。新手容易在成员管理、WebHooks 这些入口里绕来绕去，其实只需要记住一条：分支保护属于仓库设置，不在具体的代码文件页面里。如果你进入分支列表，看到每个分支后面有设置按钮，也可以直接点击进入保护规则配置。不同入口最终指向的配置面板是同一个，找到自己习惯的路径就行。这里有一个经常被忽略的坑：如果你同时在多个仓库里做管理员，配置前一定要确认当前操作的是正确的仓库，不然在 A 仓库折腾半天，以为自己配的是 B 仓库，浪费时间不说，还可能漏掉真正的保护对象。3.2 规则项逐个说明白配置保护分支时，你会看到几类字段，它们各自控制不同维度。配置项实际作用推荐设置分支名称指定保护的对象master 或 main允许推送成员谁可以直接 push 到这个分支不设置或仅管理员PR 评审开关是否要求代码必须经过 PR 合并开启最少评审人数PR 需要几个人 approve 才能合并至少 1 人禁止强制推送是否禁止 git push -f 到这个分支开启状态检查合并前必须通过的自动化检查接入 CI 后开启允许推送和允许合并是两个独立维度，很多人在这一点上容易混淆。推送是把本地提交上传到远程，合并是执行那个真正的合并动作。某些仓库会允许少数核心成员直接推送 hotfix 分支，但对于主干分支，我们通常不建议开放任何人的直推权限。让所有改动都走 PR，最大的价值是每一次变更都有一条可追溯的记录，评审人也可以在合并之前看到完整的改动上下文。3.3 一套稳当的起步配置如果你还没有明确的团队规则，我建议先用这样一组配置跑起来：受保护分支：master直接推送：不允许任何人核心成员可执行合并：开启必须经过 Pull Request：开启最少评审人数：1 人禁止强制推送：开启这套配置的流程开销很小，但已经能把“直接改主干”这个最大风险挡在门外。配置完成后一定要验证一次。最简单的验证方式是，尝试在网页端直接编辑 master 分支上的文件并保存。如果保护规则生效，你会看到保存被拒绝或者收到权限不足的提示。只有真正看到这条拒绝消息，才算完成了保护分支的第一次落地。4. 保护分支下日常开发到合并的完整流程4.1 从受保护分支拉新分支的基础操作假设仓库默认分支是 master，你准备开发一个登录页面功能。基本操作是这样的：git checkout master git pull origin master git checkout -b feature/login-page三步操作看起来简单，但里面有一个习惯值得刻意养成：每次开发前先把本地 master 更新到与远程一致。如果本地 master 已经很旧，拉出来的功能分支就会带着一堆早已被更新的旧文件，等合并时冲突可能遍布每个文件，你根本分不清哪些是自己真正要动的内容。实践中我更倾向于在开发期间定期把远程 master 合进自己的功能分支，这比所有冲突堆到 PR 阶段再处理轻松得多。4.2 推送分支与创建 Pull Request 的关键信息代码写完并提交后，推送功能分支到远程：git push origin feature/login-page推送成功后，Gitee 页面一般会出现创建 Pull Request 的提示。创建 PR 时需要填几个关键字段，我建议把标题写成“这次改动要实现什么”，而不是“改了哪些文件”。比如“实现登录页表单校验并接入后端接口”，就比“修改 login.vue 和 api.js”更有信息量。描述部分千万不要偷懒。这个描述不是给平台看的，是给评审人看的。写清楚需求来源、改动范围、受影响模块，评审人能更快进入状态，审查质量也会更高。我自己会固定用一个简单模板：背景、改动内容、测试方式、注意事项。不用写太长，几行就够，但信息密度要够。4.3 三种合并模式的选择，直接影响提交历史Gitee 在合并 PR 时，通常提供合并提交、Squash 合并、Rebase 合并几种方式。很多团队一开始没在意，结果主干分支的提交历史变得杂乱无章，想回溯某个功能对应的代码改动都困难。合并模式提交历史表现适用场景合并提交保留完整分支历史，生成一个 merge commit需要逐条追溯每个开发步骤Squash 合并把分支上多个提交压缩成一个功能分支提交比较零碎，希望主干干净Rebase 合并按分支上的提交逐个应用到主干想保持线性历史，且每个提交都有独立意义我个人的选择策略是这样的：大多数普通功能开发用 Squash 合并，因为开发过程里的“fix typo”“update style”“merge master”这类中间提交对主干历史没什么价值，压成一个完整提交反而更清晰。如果团队成员习惯把一次提交对应一个逻辑改动，那么 Rebase 合并是不错的选择。选定合并策略之后，最好在团队规范里固定下来，不要今天 squash 明天 rebase，不然同一段项目历史的风格会很混乱。4.4 合并完成后立刻清理分支合并完成并不代表流程结束，还有一步经常被忽略：删除已合并的功能分支。Gitee 在合并页面一般会提供删除源分支的选项，也可以之后在分支列表里手动删除。如果不删，过几个月打开分支列表，你会看到几十个已合并的老分支，根本分不清对应哪个任务，还没任何实际价值。我现在的习惯是功能分支合并后第一时间清理，保持仓库分支列表干净清爽。这会带来一个额外好处：即使有人误操作想切到旧分支，也不容易选错对象。5. 合并阶段最容易踩的坑和排查思路这部分是全文实践价值最高的一节。保护分支本身不难配，难的是日常协作里频繁出现的那些“合并不了”“检查不过”“push 被拒”的复杂状态。5.1 冲突处理：别死磕在线编辑当功能分支和主干分支在同一处代码上发生过不同改动时，PR 会提示冲突。Gitee 在线编辑器在冲突较少的情况下可以用，但如果冲突涉及多个文件，网页编辑效率极低，还容易引入新的理解偏差。我倾向于在本地解决冲突：git checkout feature/login-page git fetch origin master git merge origin/master # 根据 git status 的冲突列表逐个修改 git add . git commit -m "merge origin/master into feature/login-page" git push origin feature/login-page推回远程之后，PR 会自动重新计算冲突状态。需要特别强调的是，不要等 PR 提交了才去处理冲突，而是开发期间经常把主干合进功能分支。每天合并一次和最后集中处理半天，体验差距是非常大的。5.2 检查项不通过时，先看具体失败原因PR 合并按钮不可用时，最常见的原因是检查任务未通过。这里有一个容易被忽视的点：检查任务可能有多种类型，比如单元测试、构建、静态检查，它们的失败原因各不相同。正确的排查顺序是：点开 PR 的检查标签页，定位具体失败任务。点进详情查看失败日志，定位报错模块。在本地复现问题并修复，推送新提交。刷新 PR，等待检查重新运行。还有一种情况是检查任务一直停留在 pending 状态，那通常和代码本身无关，而是 CI 配置没有正确回传结果，或者 WebHook 没有配对。这时候去检查 Gitee 的 WebHook 投递历史和 CI 平台的接收地址，比在 PR 页面反复刷新有效得多。5.3 强推被拒时，先想想自己的操作是否越界开启禁止强制推送后，如果你对受保护分支执行 git push -f，会收到明确的拒绝提示。这时候正确的操作不是去解禁保护规则，而是确认自己为什么要强推一个受保护分支。对于自己的功能分支，执行 rebase 修整历史后强推，通常是可以的，因为功能分支默认不受保护。如果试图对 master 强推，说明你的工作流已经违背了“主干分支只能通过 PR 合并”的原则。正确做法是把这几次改动整理成一个 PR，或者把本地 master 重新同步到远程现状。强推在多人协作中的破坏性非常大：两个人各自的本地仓库如果都以不同状态强推过 master，之后任何人的普通 push 都会报错，历史变得很难对齐。保护分支把这条高风险操作堵住，实质上是在保护整个团队的协作网络。6. 进阶思路：让保护分支和自动化流程配合起来配置好保护分支，只是把人的环节规范化了。更进一步的方向，是让机器也参与进来。6.1 用 WebHook 把 CI 接到 PR 生命线Gitee 仓库可以配置 WebHook，当 PR 被创建、更新、合并时，平台会向你的 CI 服务发送事件通知。CI 服务收到通知后跑一遍构建和测试，再把检查结果返回 Gitee，这个状态会直接显示在 PR 页面的检查项里。链路打通之后，保护规则里的“状态检查通过”才真正有意义。比如一个后端项目，PR 只要触发了编译错误或测试失败，合并按钮就是灰的，根本不需要评审人手动去判断代码能不能跑。配置 WebHook 时，签名校验不要省。如果不校验签名，就等于向所有知道你 WebHook 地址的人开放了事件入口，恶意伪造的请求可能触发无意义的构建任务。另一方面，CI 任务的运行时长也要合理控制，一跑四十分钟的强检查流程会严重拖慢发布节奏，团队成员很容易对流程失去耐心。6.2 多分支保护的规则设计：按稳定级别分级当仓库发展到多个分支共存后，保护规则不建议一刀切。主干分支最严，集成分支次之，功能分支完全放开，这通常是比较合理的结构。分支保护强度适用说明masterPR + 至少 2 人评审 + CI + 禁强推发布稳定代码developPR + 1 人评审 + CI集成与测试主干feature/*不保护自由开发区域Gitee 支持按分支名称模式来配置保护规则，比如 feature/* 或 releases/*。用通配符批量设置，比一条条添加分支配置高效很多，还不会漏掉新的功能分支。多分支保护的关键，是让不同稳定级别的分支拥有不同强度的把关，而不是把所有分支都按同一个标准锁起来。走到这一步，团队协作基本已经进入正轨。保护分支只是工具，真正的收益是每一次代码变动都有记录、有审查、有反馈，代码质量的风险在源头被压到最低。最后分享一个我自己的经验：保护规则一定不要试图一步到位设计得过于复杂，成员对流程的接受度是逐步建立的。先用最轻的配置跑起来，让大家感受到“master 变得不再受人随意改动”这个事实，等团队形成习惯之后，再慢慢加入评审人数要求、自动化检查这些约束。规则越少，越好执行；只有真正执行得动，保护分支才是有价值的规则，而不是挂在仓库后台的一纸空文。
我在不少开发者社群里见过这样一种态度：保护分支就是不让大家直接往 master 推代码，折腾一圈走 Pull Request，纯属给自己添麻烦。说实话，我个人早前也这么想过，直到在某个项目里亲眼看到有人把写到一半的代码直接提交到主干分支，导致全组好几天都在处理连带问题，才真正意识到保护分支不是行政流程，而是代码仓库的“交通安全规则”。这篇内容我会从新建仓库开始，把 Gitee 保护分支的配置逻辑、日常开发到合并的完整操作、合并阶段的高频踩坑、以及更进一步配合自动化的思路都过一遍。适合刚接触仓库管理的开发者，也适合想优化团队协作流程的组长或运维同学。1. 保护分支到底在防什么：先想清楚再动手1.1 一次现场事故让我理解了保护分支的必要性好几年前，我们做一个内部小项目，仓库刚建好，没有配置任何保护规则。某位同事图省事，直接在网页端编辑了 master 分支上的核心配置文件。他本意只是微调一个参数，结果保存时把文件里一段关键逻辑覆盖掉了。当天下午大家陆续拉取代码，编译直接挂掉，一堆人花了不少时间排查，最后才发现问题来自那个无意识的网页提交。那次事故之后，我总结出一个很朴素的结论：人不是机器，总会在某个瞬间注意力掉线。保护分支不是不信任团队成员，而是承认错误不可避免之后，用机制把错误挡在发布链路之前。打个比方，它就像汽车的安全带，不是为了让你撞车，而是为了在意外出现的时候把损失压到最低。你会希望一个关键配置文件的变更，至少经过一次人工确认再进入主干，这比事后复盘有价值得多。1.2 保护规则的内核是控制“怎么进”而不是控制“进不进”保护分支最容易被理解成“禁止向某些分支直接推代码”。方向没错，但这只是一个侧面。你去打开 Gitee 的保护分支设置，会看到里面有一组规则：允许推送的人、是否要求 Pull Request、需要几位评审人、是否禁止强制推送、是否要求自动化检查通过。把这些规则组合起来看，本质上回答的是三个问题：谁能改动受保护分支？改动以什么方式进入？进入之前要经过哪些检查？保护分支的核心机制，是把“提交-合并”这个动作从单人行为转变成一个多人协作流程。写代码的人负责实现，评审人负责看逻辑，自动化工具负责兜底低级失误，最后再通过一次明确的合并动作进入主干。这样每一次变更都留下线索，出了问题可以追溯到具体提交和决策环节。1.3 保护分支不等于把分支锁死还有一个很常见的误解：开启保护分支后，别人是不是就没法干活了？实际上完全不受影响。受保护的分支通常是主干分支，但日常开发都是基于主干拉出新的功能分支进行的，这些新分支默认不受保护。你可以随便提交、随意调整、随时推送。保护分支真正影响的时间点只有一个，就是从功能分支合并回主干的那一刻。这就像你在家里可以随意装修房间，但改变承重墙结构必须报备审批。前面所有自由发挥都不变，只有进主干的最后一步需要按规则来。这个设计既保证了开发自由度，又能让主干代码保持相对稳定。2. 新建仓库时的分支规划和默认设置，别给后面埋雷2.1 初始化仓库时就把基础文件补齐在 Gitee 上创建仓库时，很多人的习惯是直接跳过初始化选项，等代码写好了再上传。我的建议恰恰相反，项目一开始就把 README、.gitignore、开源许可证这三个基础文件补上。README 不是摆设，它是仓库的门面。团队新成员加进来的第一件事就是看 README，需要知道这个项目是干什么的、怎么跑起来、目录结构是什么样的。.gitignore 的重要性，我已经见过太多反面案例了。如果一开始没配好，日志、本地配置、编译产物很容易被误提交进仓库，后面就算补上忽略规则，已经进入历史记录的文件还得专门清理，过程非常麻烦。开源许可证虽然对内部项目不是刚需，但养成习惯之后做开源分享会省很多事。2.2 默认分支名最好一次性定好新建仓库时，Gitee 的默认分支通常是 master，你也可以在初始化时创建 main 或者其他名称的分支，然后在仓库设置里把它设为默认分支。分支名本身没有绝对标准，真正要留意的是改名的成本。如果仓库还是空的，改默认分支名很容易。但一旦有了几个提交，成员们也在本地克隆过了，想换默认分支就比较麻烦了：所有人的本地跟踪关系要改，后续 PR 的目标分支也要逐一调整。我见过不少项目在早期频繁改默认分支名，导致大家的本地仓库状态混乱，有人 push 到一个旧分支上，半天没人发现。所以趁仓库还没有内容，把默认分支名确定下来，后面会省去很多无谓的沟通成本。2.3 分支模型先从最简单的开始团队刚起步时，分支模型一般就是两端：主干 master，加上开发过程中临时创建的功能分支。这个阶段只保护 master 就够了，不需要一上来就配置 develop、release、hotfix 好几个层级，因为每多一个受保护分支，团队就要多承担一层流程维护成本。等到团队规模到了十人以上，或者项目开始有明确的上线节奏，再逐步引入 develop 作为集成分支，引入 release 分支做版本管理。规则的增加应该由实际需求推动，而不是提前把所有情况都预设好。我见过有些团队建仓当天就设置了多层保护，结果新人完全不知道应该往哪个分支提 PR，最后干脆绕过平台在群里传代码包，保护规则形同虚设，流程反而成了大家的负担。3. 配置保护分支规则的实操路径：一步步来3.1 入口别找错：仓库级管理与分支设置在 Gitee 仓库页面，右上角一般有管理入口，点进去之后，在左侧菜单能找到分支设置相关区域。新手容易在成员管理、WebHooks 这些入口里绕来绕去，其实只需要记住一条：分支保护属于仓库设置，不在具体的代码文件页面里。如果你进入分支列表，看到每个分支后面有设置按钮，也可以直接点击进入保护规则配置。不同入口最终指向的配置面板是同一个，找到自己习惯的路径就行。这里有一个经常被忽略的坑：如果你同时在多个仓库里做管理员，配置前一定要确认当前操作的是正确的仓库，不然在 A 仓库折腾半天，以为自己配的是 B 仓库，浪费时间不说，还可能漏掉真正的保护对象。3.2 规则项逐个说明白配置保护分支时，你会看到几类字段，它们各自控制不同维度。配置项实际作用推荐设置分支名称指定保护的对象master 或 main允许推送成员谁可以直接 push 到这个分支不设置或仅管理员PR 评审开关是否要求代码必须经过 PR 合并开启最少评审人数PR 需要几个人 approve 才能合并至少 1 人禁止强制推送是否禁止 git push -f 到这个分支开启状态检查合并前必须通过的自动化检查接入 CI 后开启允许推送和允许合并是两个独立维度，很多人在这一点上容易混淆。推送是把本地提交上传到远程，合并是执行那个真正的合并动作。某些仓库会允许少数核心成员直接推送 hotfix 分支，但对于主干分支，我们通常不建议开放任何人的直推权限。让所有改动都走 PR，最大的价值是每一次变更都有一条可追溯的记录，评审人也可以在合并之前看到完整的改动上下文。3.3 一套稳当的起步配置如果你还没有明确的团队规则，我建议先用这样一组配置跑起来：受保护分支：master直接推送：不允许任何人核心成员可执行合并：开启必须经过 Pull Request：开启最少评审人数：1 人禁止强制推送：开启这套配置的流程开销很小，但已经能把“直接改主干”这个最大风险挡在门外。配置完成后一定要验证一次。最简单的验证方式是，尝试在网页端直接编辑 master 分支上的文件并保存。如果保护规则生效，你会看到保存被拒绝或者收到权限不足的提示。只有真正看到这条拒绝消息，才算完成了保护分支的第一次落地。4. 保护分支下日常开发到合并的完整流程4.1 从受保护分支拉新分支的基础操作假设仓库默认分支是 master，你准备开发一个登录页面功能。基本操作是这样的：git checkout master git pull origin master git checkout -b feature/login-page三步操作看起来简单，但里面有一个习惯值得刻意养成：每次开发前先把本地 master 更新到与远程一致。如果本地 master 已经很旧，拉出来的功能分支就会带着一堆早已被更新的旧文件，等合并时冲突可能遍布每个文件，你根本分不清哪些是自己真正要动的内容。实践中我更倾向于在开发期间定期把远程 master 合进自己的功能分支，这比所有冲突堆到 PR 阶段再处理轻松得多。4.2 推送分支与创建 Pull Request 的关键信息代码写完并提交后，推送功能分支到远程：git push origin feature/login-page推送成功后，Gitee 页面一般会出现创建 Pull Request 的提示。创建 PR 时需要填几个关键字段，我建议把标题写成“这次改动要实现什么”，而不是“改了哪些文件”。比如“实现登录页表单校验并接入后端接口”，就比“修改 login.vue 和 api.js”更有信息量。描述部分千万不要偷懒。这个描述不是给平台看的，是给评审人看的。写清楚需求来源、改动范围、受影响模块，评审人能更快进入状态，审查质量也会更高。我自己会固定用一个简单模板：背景、改动内容、测试方式、注意事项。不用写太长，几行就够，但信息密度要够。4.3 三种合并模式的选择，直接影响提交历史Gitee 在合并 PR 时，通常提供合并提交、Squash 合并、Rebase 合并几种方式。很多团队一开始没在意，结果主干分支的提交历史变得杂乱无章，想回溯某个功能对应的代码改动都困难。合并模式提交历史表现适用场景合并提交保留完整分支历史，生成一个 merge commit需要逐条追溯每个开发步骤Squash 合并把分支上多个提交压缩成一个功能分支提交比较零碎，希望主干干净Rebase 合并按分支上的提交逐个应用到主干想保持线性历史，且每个提交都有独立意义我个人的选择策略是这样的：大多数普通功能开发用 Squash 合并，因为开发过程里的“fix typo”“update style”“merge master”这类中间提交对主干历史没什么价值，压成一个完整提交反而更清晰。如果团队成员习惯把一次提交对应一个逻辑改动，那么 Rebase 合并是不错的选择。选定合并策略之后，最好在团队规范里固定下来，不要今天 squash 明天 rebase，不然同一段项目历史的风格会很混乱。4.4 合并完成后立刻清理分支合并完成并不代表流程结束，还有一步经常被忽略：删除已合并的功能分支。Gitee 在合并页面一般会提供删除源分支的选项，也可以之后在分支列表里手动删除。如果不删，过几个月打开分支列表，你会看到几十个已合并的老分支，根本分不清对应哪个任务，还没任何实际价值。我现在的习惯是功能分支合并后第一时间清理，保持仓库分支列表干净清爽。这会带来一个额外好处：即使有人误操作想切到旧分支，也不容易选错对象。5. 合并阶段最容易踩的坑和排查思路这部分是全文实践价值最高的一节。保护分支本身不难配，难的是日常协作里频繁出现的那些“合并不了”“检查不过”“push 被拒”的复杂状态。5.1 冲突处理：别死磕在线编辑当功能分支和主干分支在同一处代码上发生过不同改动时，PR 会提示冲突。Gitee 在线编辑器在冲突较少的情况下可以用，但如果冲突涉及多个文件，网页编辑效率极低，还容易引入新的理解偏差。我倾向于在本地解决冲突：git checkout feature/login-page git fetch origin master git merge origin/master # 根据 git status 的冲突列表逐个修改 git add . git commit -m "merge origin/master into feature/login-page" git push origin feature/login-page推回远程之后，PR 会自动重新计算冲突状态。需要特别强调的是，不要等 PR 提交了才去处理冲突，而是开发期间经常把主干合进功能分支。每天合并一次和最后集中处理半天，体验差距是非常大的。5.2 检查项不通过时，先看具体失败原因PR 合并按钮不可用时，最常见的原因是检查任务未通过。这里有一个容易被忽视的点：检查任务可能有多种类型，比如单元测试、构建、静态检查，它们的失败原因各不相同。正确的排查顺序是：点开 PR 的检查标签页，定位具体失败任务。点进详情查看失败日志，定位报错模块。在本地复现问题并修复，推送新提交。刷新 PR，等待检查重新运行。还有一种情况是检查任务一直停留在 pending 状态，那通常和代码本身无关，而是 CI 配置没有正确回传结果，或者 WebHook 没有配对。这时候去检查 Gitee 的 WebHook 投递历史和 CI 平台的接收地址，比在 PR 页面反复刷新有效得多。5.3 强推被拒时，先想想自己的操作是否越界开启禁止强制推送后，如果你对受保护分支执行 git push -f，会收到明确的拒绝提示。这时候正确的操作不是去解禁保护规则，而是确认自己为什么要强推一个受保护分支。对于自己的功能分支，执行 rebase 修整历史后强推，通常是可以的，因为功能分支默认不受保护。如果试图对 master 强推，说明你的工作流已经违背了“主干分支只能通过 PR 合并”的原则。正确做法是把这几次改动整理成一个 PR，或者把本地 master 重新同步到远程现状。强推在多人协作中的破坏性非常大：两个人各自的本地仓库如果都以不同状态强推过 master，之后任何人的普通 push 都会报错，历史变得很难对齐。保护分支把这条高风险操作堵住，实质上是在保护整个团队的协作网络。6. 进阶思路：让保护分支和自动化流程配合起来配置好保护分支，只是把人的环节规范化了。更进一步的方向，是让机器也参与进来。6.1 用 WebHook 把 CI 接到 PR 生命线Gitee 仓库可以配置 WebHook，当 PR 被创建、更新、合并时，平台会向你的 CI 服务发送事件通知。CI 服务收到通知后跑一遍构建和测试，再把检查结果返回 Gitee，这个状态会直接显示在 PR 页面的检查项里。链路打通之后，保护规则里的“状态检查通过”才真正有意义。比如一个后端项目，PR 只要触发了编译错误或测试失败，合并按钮就是灰的，根本不需要评审人手动去判断代码能不能跑。配置 WebHook 时，签名校验不要省。如果不校验签名，就等于向所有知道你 WebHook 地址的人开放了事件入口，恶意伪造的请求可能触发无意义的构建任务。另一方面，CI 任务的运行时长也要合理控制，一跑四十分钟的强检查流程会严重拖慢发布节奏，团队成员很容易对流程失去耐心。6.2 多分支保护的规则设计：按稳定级别分级当仓库发展到多个分支共存后，保护规则不建议一刀切。主干分支最严，集成分支次之，功能分支完全放开，这通常是比较合理的结构。分支保护强度适用说明masterPR + 至少 2 人评审 + CI + 禁强推发布稳定代码developPR + 1 人评审 + CI集成与测试主干feature/*不保护自由开发区域Gitee 支持按分支名称模式来配置保护规则，比如 feature/* 或 releases/*。用通配符批量设置，比一条条添加分支配置高效很多，还不会漏掉新的功能分支。多分支保护的关键，是让不同稳定级别的分支拥有不同强度的把关，而不是把所有分支都按同一个标准锁起来。走到这一步，团队协作基本已经进入正轨。保护分支只是工具，真正的收益是每一次代码变动都有记录、有审查、有反馈，代码质量的风险在源头被压到最低。最后分享一个我自己的经验：保护规则一定不要试图一步到位设计得过于复杂，成员对流程的接受度是逐步建立的。先用最轻的配置跑起来，让大家感受到“master 变得不再受人随意改动”这个事实，等团队形成习惯之后，再慢慢加入评审人数要求、自动化检查这些约束。规则越少，越好执行；只有真正执行得动，保护分支才是有价值的规则，而不是挂在仓库后台的一纸空文。