团队共用一个仓库时，把「成员权限」当成一个开关，是最容易出事的做法。读、写、合并这三件事在主流托管平台上通常分属不同配置项：读决定能不能看到代码和提交历史，写决定能不能把提交推到分支，合并决定能不能把变更落进主分支。给宽了，误推和绕过评审的成本由整个团队承担；给窄了，日常提交会卡在推送或合并那一步。可行的顺序是：先确认当前谁实际持有写权限，再逐项核对主分支保护开了哪些开关，最后按新人最小路径逐级开通。

建议把权限拆成读、写、合并三层分别核对：先用只读账号确认可见范围，再用第二个账号试推验证写权限，最后在主分支保护里确认禁止直推、评审通过要求、允许合并者三项开关。合并权通常绑定在保护规则上，而不是绑定在成员角色上，所以改成员列表不等于改谁能合并。具体可勾选项和默认值需要结合所用托管平台和版本确认，不要照搬别的仓库配置。

先把读权限、写权限和合并权限分开看

三层权限不是包含关系的简单叠加。多数平台上写权限隐含读权限，但合并权往往由「角色 + 分支保护规则」共同判定，光看成员列表看不出谁能合并。下表用于逐条对照，避免把三种能力混成一句「给某人成员权限」。

核对时最容易漏的是小组继承：把一个小组加进仓库，组内所有成员会同时获得对应权限，成员列表里看不出这个中间层。如果组是外部同步进来的，人员变动会直接改变仓库写权限范围，建议定期回到仓库访问列表确认最终生效账号。

在仓库设置里逐项核对谁有写权限

目标是把「谁当前能推代码」变成一份可核对的名单，而不是凭印象。步骤可以固定成三步：

1. 进入仓库设置里的成员/协作/访问管理页，切换到完整列表视图，逐个账号记录角色名称，区分只读、写、管理三类。
2. 对每个小组成员，展开看组内成员，把继承来的权限补进名单；标注哪些是外部同步的组。
3. 重点标出同时具有写权限和管理权限的账号，这类账号既能改代码也能改保护规则。

名单核对完，用另一个账号（不要用管理员凭据）做一次实际推送验证，这是唯一能确认规则是否真的生效的方式：

git remote -v
git switch -c perm-check-yourname
git commit `--allow-empty` -m "perm check"
git push origin perm-check-yourname

预期观察：无写权限的账号推送会被远端拒绝，提示通常是权限不足或分支保护；有写权限的账号推送成功，说明该账号确实持有写权限。测完记得删除这个临时分支，避免污染分支列表。注意要用被验证账号自己的凭据或密钥，用共享密钥测出来的结果没有意义。

主分支保护要确认哪几项开关

保护规则的作用是把「合并要谨慎」从个人习惯变成平台强制。以下开关建议逐项确认，不要只看是否开启，还要看具体取值：

• 是否禁止直接推送到主分支：开启后所有变更必须走评审请求。同时确认强制推送是否单独关闭，两者在不同平台上常是两个开关。
• 是否要求评审通过：确认最少审批人数、是否允许作者自批、更新的提交是否会作废旧审批。这几项决定了评审是不是「走个形式」。
• 是否要求分支在合并前保持最新：开启后落后主分支的评审请求需要先更新或变基，能减少合并后主分支状态不明的情况。
• 是否要求状态检查通过：把自动化检查设为合并前置条件，检查没跑完时合并按钮不可点。
• 是否限制允许合并的账号或角色：这一项直接决定「谁能按合并按钮」，是评审人和合并者分离的关键。
• 是否禁止删除受保护分支、是否允许管理员豁免：豁免等于后门，建议明确谁有豁免权并记录下来。
• 允许的合并方式：合并提交、压缩合并、变基合并通常建议只保留一种，避免历史结构随操作者习惯变化。

逐项确认后，最好用一个低风险变更实际走一遍流程，观察按钮状态和拒绝提示，比只看配置页更可靠。

评审人和合并方式之间的关系

有人能改代码却不能合并，是因为评审权限和合并权限的判定位置不同：写权限作用在分支上，合并动作受保护规则里的「允许合并者」约束。评审请求的典型流转如下：

1. 作者推送分支并创建评审请求，状态为待评审，触发者是作者。
2. 评审人查看差异、留言、批准或要求修改，触发者是评审人。此时评审意见只影响状态，不改变代码。
3. 作者根据意见补提交，或解决与主分支的冲突，触发者是作者。部分平台会因为新增提交而作废已有批准，需要重新批准。
4. 保护规则的全部前置条件满足后，合并按钮变为可点击，这一步由平台判定。
5. 具备合并权限的人选择合并方式并执行合并，触发者是合并者；主分支更新，源分支是否自动删除按仓库配置决定。

理解这条链的价值在于定位卡点：如果合并按钮一直灰着，先看是缺少审批、分支落后还是检查未通过，而不是直接去改成员权限。反过来，如果某个账号能直接改主分支，说明保护规则里存在豁免或该账号拥有规则管理权，需要单独确认。

新人加入时的最小开通路径

按级开通、每级都验证一次，能避免一次给到写权限后反复回收。建议顺序如下：

1. 只读起步：先加入只读角色，验证 clone 能成功、push 被拒绝，确认可见范围符合预期。
2. 开写分支权限：授予写权限，但主分支保护保持禁止直推。让新人推一个临时分支，确认推送成功、直推主分支被拒。这一步同时验证了保护规则确实生效。
3. 加入评审人：先只给评审资格，不给合并权。验证其能批准评审请求，但合并按钮不可点或被规则阻断。这一步能提前暴露权限配置的分层是否清晰。
4. 开放合并权限：把账号加入保护规则允许合并的名单，用一个低风险变更走完整流程，确认可以合并且历史记录署名正确。

需要回退时，路径与开通相反：先从允许合并名单移除，再回收写权限，最后处理只读角色。合并历史可以用命令做一次抽查，确认实际操作者与预期一致：

git fetch origin
git log `--first-parent` `--merges` `--pretty`=format:'%h %an %s' origin/main | head -20

这条命令只看历史署名，不能反映当前配置，所以查完之后仍要回到仓库设置页核对规则。人员离职或转组时，重点检查两处：成员与小组继承关系，以及保护规则里的合并者名单和豁免账号。只改成员列表而忘记改保护规则，是权限回收里最常见的遗漏。