别共用一个账号：多人协作的架构与权限
多一个人一起干，代码不会因此变乱——真正会失序的是责任、权限和安全。
START
代码不会乱，会乱的是责任
上一篇你已经能一个人、两台机器、两条线并行推进不弄乱了。接下来要过的坎不是机器，是人——
项目开始有第二个人碰代码了。注册账号、加权限、配来配去太麻烦，我就想：干脆两个人共用一个账号得了，反正代码放在同一个仓库里。这样会不会出事？
这个念头几乎每个刚开始带人的创业者都动过。它看起来只是"省几步注册"，实际上是在把一整层秩序提前拆掉。
先说结论：代码不会乱，责任会乱。而对一个已经承载着对外站点和内部后台的项目来说，后者才是真问题。这一篇把三件事讲清楚：为什么技术层面确实不会乱、共用账号具体会付出哪五笔代价、以及正确的架构该怎么搭、怎么从现在的样子迁过去。
MODEL
先把两个问题分开
你担心的其实是两件事，混在一起就想不清楚。
| 层面 | 你担心的 | 答案 |
|---|---|---|
| 技术层面 | 两个人同时推送，代码会不会乱？ | 不会。机制和上一篇"一个人两台机器"完全一样 |
| 管理层面 | 共用一个账号，秩序会不会乱？ | 会，而且这才是真问题 |
技术层面：真的不会乱
档案馆不关心"送图纸来的是谁"，只关心"改了哪张图的哪些行"。一个人在对外站点的目录里干活，另一个人在内部后台的目录里干活，管理员照样两份都收，自动合并。冲突的概率，和上一篇说的一模一样——目录边界清晰，就撞不上。
从纯代码的角度，"两个人"和"一个人两台机器"没有任何区别。
但"秩序"从来不只是"代码不冲突"
秩序还包括这几样：谁做的？谁批准的？谁能改什么？出事了找谁？
共用一个账号，恰恰是把这一整层全部抹掉。用比喻说：账号是档案馆发给你个人的通行证——进出留名、门禁分区、丢了能单独挂失。两个人共用一张通行证，等于档案馆的出入记录里从此只有一个名字，门禁再也分不了区。
代码层面档案馆帮你兜住了；管理层面，只能靠账号架构。
RISK
共用一个账号的五笔代价
改动历史失去归属，"考古"能力归零
所有记录的署名都是同一个。三个月后内部后台冒出一个诡异问题，你顺着历史追到那一行，看到的是"公司账号，某月某日"——你查不出是谁写的、当时在解决什么、该找谁问。
上一篇讲过，留底的价值在于查得回来。共用账号等于把全部考古资料一次性抹成匿名：记录还在，线索没了。
权限没法分级
托管平台的权限是绑在账号上的。共用账号 = 两个人权限完全相同 = 你做不了任何隔离：
- 想让做对外站点的人只读内部后台的代码？做不到
- 想让共用区（shared/）的改动必须先经你确认？做不到
- 想在某个人不再参与后只回收他一个人的权限？做不到——只能改密码，然后把新密码告诉另一个人
目录边界只是画在纸上的线，权限才是装在门上的闸。 共用账号的意思是：线你画得再清楚，闸一个都装不上——所有人对所有目录，权限完全一样。
凭据共享，是安全事故的温床
密码、双因素验证（2FA）、访问令牌（Access Token）、密钥，全都要在两个人之间来回流转。后果很具体：
- 任何一方的电脑中招或令牌泄露，你无法定位是谁泄露的，也无法单独吊销——只能全部作废重发
- 有人不再参与，唯一的补救是改密码 + 重置所有令牌 + 通知所有人，每次都是一场混乱
- 双因素验证绑在谁的手机上？另一个人每次登录都得找他要验证码
接词典里那句话——保险柜密码不写在菜谱上，也不该人手一把。 对承载着对外站点和客户数据的仓库来说，这是实打实的经营风险，不是洁癖。
会签机制（Pull Request）整个报废
多人协作最有价值的那道闸门，是改动进正式图纸之前先过一次会签——一个人提交，另一个人看过再合并。这道会签在托管平台上有个固定名字：拉取请求（Pull Request，常被简称 PR），你在任何协作场合都会听到它。
共用账号意味着"自己审自己"：署名是同一个人，平台甚至会直接拦住你，不允许你批准自己提交的东西。
你等于买了工具，却亲手把它最值钱的那道质量闸门拆了。
违反平台服务条款，账号本身有风险
这一条不是"最佳实践建议"，是硬性规定。GitHub 服务条款写得很直白：
一个登录只能由一个人使用——单个登录不得由多人共享。
企业版条款里同样重申。共享账号属于违规使用，账号存在被限制或封停的风险——而你的全部代码都在里面。省下的那几步注册，抵不上这一条的尾部风险。
ARCH
正确的架构：机构开户 + 每人一张自己的通行证
目标形态
组织（Organization） ← 仓库归公司，不归任何个人
│
├── 仓库：你的项目仓库
│
├── 成员：你（所有者 Owner）
├── 成员：做对外站点的人（他自己的个人账号）
└── 成员：做内部后台的人（他自己的个人账号）一句话：以公司名义在档案馆开一个机构户，图纸归机构；每个人拿自己的通行证进来干活。
为什么是"机构户"，而不是"挂在你个人名下再加协作者"
| 个人账号 + 加协作者 | 组织（机构户） | |
|---|---|---|
| 仓库归属 | 归你个人，你的账号出问题，公司资产跟着受牵连 | 归组织，是公司资产 |
| 权限管理 | 只能按仓库粗放授权 | 可建小组，按目录/角色细分 |
| 人员变动 | 移除协作者，历史归属容易混乱 | 移除成员，一切留痕 |
| 往后扩展 | 人一多就撑不住 | 天然支持团队增长 |
对外站点和内部后台是公司的核心数字资产。它应该挂在公司名下，而不是某个人的个人账号下——这一点比任何技术细节都重要。它也是"代码可分叉、责任不可分叉"的第一道落地。
成本：这一步基本不花钱
- 免费档的组织：私有仓库不限量、正式成员不限人数——三五个人完全够用，零成本
- 付费档：解锁的是"把约定变成强制规则"的能力（比如正式图纸禁止直接推送、必须经人会签）
建议：先用免费档把架构立起来，流程靠约定执行；等团队规模或事故成本上来了，再用付费档把约定升级成规则。顺序不要反——先有正确的账号架构，规则才有地方挂。
HOW
怎么迁过去（七步，照做即可）
每个人各自注册自己的账号
用各自的真实工作邮箱。这一步没有捷径，也是整件事的地基。
创建组织
在托管平台右上角新建组织，选免费档，组织名建议用公司名。
把仓库转到组织名下
在仓库设置页最底部的危险区里选择"转移所有权"，填入组织名。转移会保留全部改动历史、分支与议题；原地址会自动跳转，但仍建议各机器更新一下远端地址：
git remote set-url origin git@github.com:组织名/仓库名.git
git remote -v邀请成员并分配权限
在组织的成员页邀请，角色给"成员"，再到仓库设置里给写入权限。所有者（Owner）只留你自己——那是能改组织设置、能删仓库的最高权限。
每个人在自己机器上重新配置身份
必须做这一步必须做，否则记录的署名仍然是错的：
git config user.name "你的名字"
git config user.email "you@yourcompany.com"
git config user.name && git config user.email不加 --global 只对当前项目生效；确认无误后可以设成全局。邮箱必须和账号绑定的邮箱一致，否则平台上不会把这条记录关联到本人——通行证换了，署名却没换，等于白迁。
每个人各自重新配好密钥
每台机器生成自己的那一把，上传到各自的账号（流程见本专区第 1 篇）。旧的那把共享密钥，从账号里删掉。
清理旧账号
把原共享账号的密码改掉、旧令牌全部吊销。它如果还有用，可以留作管理备用，但不再用于日常开发。
迁移不会丢历史，但会从此刻起才有归属。所以越早做越值——晚一个月迁，就多一个月的匿名记录。
NEXT
多了人之后，工作流也要跟着升一级
一个人两台机器时，"改完直接推上正式图纸"还能忍。两个人以后，必须升级为：另起草案分册 → 送审 → 会签合并。
草案分册你在上一篇已经会了（纪律 2）。多的只是中间那一步：分册推上去以后，开一个拉取请求（PR）——就是第三节里说的那道会签窗口——指定另一个人看过再合并。
会签的人要看什么（不必逐行读代码）
- 改动范围对不对——对外站点的送审里，是不是莫名其妙动了内部后台的文件
- 有没有碰共用区——碰了就要重点看，并确认另一条线上的调用处也一起改了（这正是上一篇"最高危风险"的正解）
- 有没有把不该进档案馆的东西带进来——密钥、密码单、领来的零件包（接词典「环境变量」：写进去那一刻就等于公开了，事后删文件也没用）
- 记录写清楚了没有——三个月后能不能靠这一行看懂当时在干什么
看过 → 合并 → 把那一册删掉。
为什么值得多这一步
- 每一行改动至少被两双眼睛看过，这是成本最低的质量保障
- 共用区的破坏性改动会被当场拦住，而不是等另一条线崩了才发现
- 历史变得可追溯：每件事对应一次送审，有讨论、有批准、有归属
- 这套动作，和你验收 AI 写的代码是同一套——AI 一次动十几个文件，你要做的正是"看范围、看共用区、看有没有带进不该带的东西、看说明写清没有"。先把它练成人与人之间的习惯，将来人与 AI 之间才用得顺手。
想更进一步，可以把这些约定变成平台强制执行的规则（正式图纸禁止直接推送、必须至少一人批准、指定某些目录的改动只能由特定的人批）。那属于付费档的能力，也需要按你的项目结构量身配——先把架构和习惯立住，再谈强制。
两个人同时推送不会让代码紊乱，但共用一个账号会让责任、权限和安全全面失序。代码层面档案馆帮你兜住了，管理层面只能靠正确的账号架构：每人一张自己的通行证，图纸归机构，改动走会签。这不是"等规模大了再说"的事，是从第二个人加入的那一天就该做的事。
自己学的下一步
账号、权限、会签立住之后，还剩最后一道坎：你的开发能力仍然绑在某几台具体的机器上——换台电脑、临时借一台、或者想在碎片时间随时接上，就得从头折腾一遍。这就是本专区压轴那一篇。
读压轴篇找我们做
如果你的团队正处在"人开始变多、秩序还没立"的阶段——协作架构、权限分级、改动会签、共用区纪律，我们可以带着你们立一遍，立完这套规矩是你们自己在用、自己能改。
查看服务伴读词条 · 概念词典第三层