Will.liu你有没有认真想过一个问题：如果有一天你不在了，你的GitHub账号会怎样？这个问题听起来有点冷酷，甚至有点像在写科幻小说，但作为一个常年把代码、文档、自动化脚本甚至生活记录都放进仓库里的人，我必须说：GitHub账号真的是一项实打实的数字资产，它甚至比很多人的银行余额更有价值。私有仓库里的核心代码、攒了十年的Star、组织里的管理员权限、耐心调好的GitHub Actions流水线、还有那堆只有你自己才清楚的密钥和令牌——这些东西如果没有任何交代，很可能就会因为你过世而永久封存，或者更麻烦，被平台按“账号长期未登录”判定为休眠账号，然后被删除得一干二净。
我写这份指南的初衷很简单：身边陆续有几位朋友开始问“我的GitHub账号要如何传承给家人”，而市面上的答案要么只有技术层面的数据导出教程，要么只有泛泛的法律常识，把两者结合起来、真正能落地的完整方案很少。这篇文章会从“你该盘点什么、平台怎么规定、法律文件怎么写、具体执行怎么做”四个层面，把一个GitHub账号从生前的整理到身后的交接完整捋一遍。适合独立开发者、开源项目维护者、以及任何一个把重要代码和个人资料托付给托管平台的人来参考。它不是让你马上去做一份遗嘱，而是让你知道，这件事既然迟早要面对，不如主动安排，成本其实比想象中低得多。
1. 为什么GitHub账号会成为一件“继承”难题
1.1 账号里到底装着什么，比你想象的更值钱
我们先别急着聊法律条文，先回答一个更基础的问题：GitHub账号里到底有什么值得继承？很多人第一反应是“代码仓库”，但真正摊开来看，内容远比“代码”两个字丰富得多。
我习惯把GitHub账号里的资产分成四类。
第一类是代码与内容资产。公开仓库、私有仓库、Gist、wiki、以及issue和PR里的讨论记录，全部算在内。公开仓库是开源项目的外部门面，私有仓库里的东西往往才是真正的“家底”——未公开的商业项目、个人工具集、几年攒下来的实验代码。这些东西的继承价值不亚于一台服务器或一份合同。
第二类是身份与权限资产。账号本身绑定的身份，以及在各个组织中的管理员权限、协作者关系、还有项目转移后遗留的访问权限。这类资产最容易被忽视，但它直接影响别人能不能继续操作你留下的项目。某个朋友曾经接盘一个已故开发者的开源项目，因为账号权限没有交接，连续三个月在“联系平台客服”和“找现管理员”之间来回折腾，整个过程非常痛苦。
第三类是持续集成与自动化资产。GitHub Actions的工作流定义、secrets（加密的部署密钥、云服务凭证）、Webhooks配置，以及仓库设置的默认分支保护策略。这些配置一旦失去账号管理权，就是一堆无法恢复的二进制环境，轻则流水线停摆，重则连CI/CD的密钥都拿不回来。
第四类是数据存档与个人资产。这个类别常常被忽略：issue里的备忘、项目的讨论记录、甚至某些注释里写下的个人倾向和决策过程。这些东西对于继承人来说也许不是“代码”，却是一个人对项目、对技术的真实记录，有着超越实用价值的保存意义。
1.2 法律上并没有统一的“数字资产继承”定义
如果你以为“把账号继承给家里人”就像把房产证改名一样直接，那就大错特错了。从法律角度看，“数字资产”并不是一个清晰的概念，它至少包含三个不同层次的权益：账号的登录权、账号里的内容（包括版权、数据），以及由账号衍生出来的商业价值（比如付费套餐、会员权益、软件授权）。这三层权益在法律上分属于不同性质的“东西”，继承时处理逻辑并不一样。
说得直白一点：账号本身是“访问权限”，通常受服务条款约束，平台可以规定账号不可转让甚至在用户死亡后予以注销；账号里的代码是“作品”，受知识产权法规制，版权在创作者死亡后依法由继承人继承；账号绑定的付费订阅和商业授权则属于合同债权，继承时需要向服务方主张。
这就造成一个很常见又尴尬的情况：继承人确实有权利继承代码的版权，但从平台操作上说，他没有权利登录这个账号——除非平台配合，或者生前已经完成了技术层面的一切准备。这也就解释了为什么行业里普遍认为，技术准备的价值有时比法律文件更大。换句话说，遗嘱解决的是“这些东西归谁所有”的问题，而密码管理器里的主密码和恢复码，解决的是“怎么拿到这东西”的问题。
1.3 真正值得担心的三个风险场景
把账号放着不管，会有什么实际后果？我用一个虚构但非常典型的案例来说明风险。
某开发者是一位独立开源项目的维护者，项目被不少公司用作依赖包。这位开发者突然离世后，仓库还在，但账号密码掌握在家人手里，家人并不懂Git。平台检测到账号异常，先是发现主邮箱被永久吊销（因为提供邮箱的域名到期），随后平台要求二次验证——而二次验证的恢复码被这位开发者保存在个人电脑里，电脑因为常年未开机已经无法进入系统。到最后，平台以“账号可能存在安全风险”为由暂时冻结账号，仓库虽然还在，但已经失去了所有推送和发布权限。项目社区想继续维护，却发现连转移仓库都做不到。
这种故事在真实世界里发生过很多次。风险可以归结为三类：一是“访问失效”，包括密码、邮箱、双重认证恢复码、密码管理器主密码统统无法获取；二是“冻结风险”，平台怀疑账号异常后触发安全机制，冻结所有操作；三是“删除风险”，长期无人登录的免费账号让平台很难判断是“死亡”还是“丢弃”，一段时间后可能被判定为不活跃账号并清理。想靠平台规则去对抗定期清理策略，基本不可能。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 生前就该做好的整理与盘点
2.1 先做一次彻底的资产盘点
不管最后要不要做公证遗嘱，有一件事现在就可以动手：把你GitHub账号上的家底清清楚楚列一份清单。这份清单不是为了吓唬自己，而是为了让你自己和将来的执行人，对“这个账号里到底有什么不出意外就没人知道的东西”有个整体概念。
我建议从四个维度去盘点。
账号基础信息：GitHub用户名、绑定的主邮箱、绑定的手机号、开启的双重认证方式，以及恢复码存放位置。这个信息听着基础，但很多人一旦换了手机号或者换了邮箱，就在某个角落留下一个“再也无法验证”的入口。
仓库信息：全部分为公开和私有两个类别，逐个记录仓库名称、用途说明、是否有远程备份、关键分支是否处于未推送状态。私有仓库尤其重要，因为公开仓库别人还能看到，私有仓库一旦访问失效，那就是彻底消失。
密钥与令牌：SSH Keys、Personal Access Tokens、OAuth授权应用、GitHub Actions中保存的secrets，都要记录。这些密钥是否还有效、是否存在本地备份、如果泄露会访问到哪些服务，值得单独写一份说明。很多人的部署密钥可以同时登录服务器、云存储和其他第三方账号，密钥的继承复杂度比仓库本身高得多。
其他功能数据：Gists、组织权限列表（你在哪个组织担任什么角色）、GitHub Packages、Git LFS存储用量、已开通的付费方案。这些零散内容在某些场景下恰恰是重点。
2.2 账号清单文档到底放哪里最合理
做账号清单最重要的问题不是记录，而是保密和可用性之间的平衡。我踩过坑，也曾以为把密码写在本地文档里就万事大吉，但本地文档最大的问题是：如果整台电脑一起损坏，或者家人根本不知道开机密码，它就是一纸具文。
现实中最稳妥的思路是“分成多份，放在不同地方”。密码和令牌这类核心凭证放进密码管理器，密码管理器的主密码写在一张纸上一式两份，一份放家中的保险柜，一份交给信任的家庭成员或律师（注意：是全权信任的遗嘱执行人，而不是任何亲戚都行）；而账号清单、仓库表格和整理说明，则以普通文档形式也可以打印出来，和遗嘱文件放在一起。
这里有一个很重要的原则：账号列表与密码清单最好分开存放。如果只存一份总清单，里面既有所有仓库名又有密码，那么一旦文件泄露，损失是全局性的。相反，如果密码清单和仓库列表分开，就算仓库列表被看到，充其量知道“这人有哪些项目”；就算密码清单被看到，没有仓库上下文，风险也小得多。我实际写遗嘱时，也是分别在两个信封里放这两类材料。另外，纸质材料永远不要只留一份电子文件——因为电子文件会被加密、会被遗忘、会在五年后变成打不开的旧格式。
2.3 关键信息应当细化到什么程度
清单的详略会直接影响执行人的操作难度。给继承人的文档，一定不要写到只有你本人能看懂的颗粒度，要到“一个不怎么熟悉开发环境的人也能按照步骤操作”的程度。
举个最简单的例子。密码管理器里存着一条GitHub登录信息，这没问题，但不同的人打开同一个密码管理器，看到的是同一个界面，你可能很快能找到GitHub的条目，你的执行人也未必。所以，我在整理时还会额外写一份“如何找到GitHub密码”的说明，比如“打开密码管理器后，在文件夹X中找到名为GitHub的条目，其中username部分是账号名，password部分是密码，还有一栏2FA recovery codes是恢复码”。这种说明看似冗余，实际执行时会节省大量时间。
同理，仓库清单里每一行都应该标注几列：仓库用途、重要度、是否已经在本地有其他备份、需要在继承后做哪些操作（比如目标新账号是谁）。我第一次做这份清单时，把全部仓库都写进去了，最后发现执行人根本看不明白哪些重要哪些不重要，不得不又补了一个“优先级”列。真正紧急的其实只有少数几个仓库和几个密钥，标注清楚之后，继承流程可以压缩到半天。
3. 平台规则和官方机制的正确打开方式
3.1 平台并没有账号继承功能，但有数据导出
直接说结论：到目前为止，GitHub平台并没有提供一个“账号继承”按钮，也没有一个让继承人直接接管账号的官方流程。这不是一个疏忽，而是整个行业普遍采取的做法——几乎各大托管平台都把账号视为“用户与注册人之间的服务关系”，账号和现实中的人绑定，而不是可以流通的财产。
但这绝不意味着平台什么都没有做。真正能落地的官方通道是“数据导出”和“受信任联系人”这类机制。GitHub提供在Settings里导出账号数据的入口，可以生成一份包含仓库、issue、PR、个人资料、甚至project内容的完整归档文件。这份导出的数据，继承人拿不到也没用，因为导出操作发生在账号本人有效登录的前提之下；但对生前做过准备的人来说，它是把账号“复制”出来的生命线。
同样值得关注的是，平台对“账号持有者死亡”这件事并非没有处理通道。实际遇到这种情况，通常由继承人或遗嘱执行人以“死者代表”的身份联系平台客服，提供死亡证明、遗嘱副本、遗嘱认证文件等材料，申请对账号进行特殊处理。处理的结果一般不是移交账号，而是“协助导出数据”或者“出于合规要求冻结账号并防止滥用”。虽然平台官方文档对这块写得非常含蓄，但现实处理中，有效文件齐全的情况下是有操作空间的。
3.2 双重认证和恢复码必须提前预留
如果说有什么东西比密码更容易在“继承”时卡住，那就是双重认证。现在绝大多数GitHub账号都开了TOTP双重认证，也就是用一个验证器App生成六位动态码。这个验证器App一般绑定在本人手机上，如果继承人拿到手机密码，倒还能打开App；但只要手机被重置、验证器被删除，或者本人已经换了新手机而旧手机已经消失，那么这层验证就会成为一道无解的墙。
所以在准备继承材料时，有一个动作特别关键：把GitHub账号的2FA恢复码（recovery codes）完整导出并保存。恢复码是在开启双重认证时平台生成的一组一次性拯救码，每个码只能用一次，登录时被验证器挡住，用恢复码反而能绕过验证直接进入。很多人开了2FA之后，恢复码看了一眼就关掉，完全没有存档——这等于给自己预备的数字资产传承之路埋了一个地雷。
我自己的习惯是：每开启一个账号的双重认证，就把恢复码立即复制到密码管理器的新条目里，同时打印一份放在遗嘱文件夹中。这样即便密码管理器本身也有主密码问题，纸质恢复码依然有用武之地。更好的一点是，GitHub的恢复码一旦使用或怀疑泄露，可以立即重新生成，所以这种“备份”是即时可更新的。
3.3 组织账号、私有仓库和协作权限的边界
继承的复杂度并不仅仅在一个个人账号上。只要打开过开源项目的人，大概率都加入过组织，或者自己创建过组织。组织账号和普通个人账号的处理规则完全不同：组织的Owner权限是独立的身份，你不在了，继承人想接管你拥有的项目，可能需要同时处理个人账号和组织权限两件事。
举个例子。某个开发者建了一个开源组织，里面有几个公开仓库，自己拥有Owner权限。他离世后，家人试图把他的个人账号下的私有仓库导出来，这个操作还算顺利；但想继续维护组织里的公开仓库时，却遇到了麻烦——组织没有第二个人有Owner权限，整个组织的管理权变成无人认领的状态。平台处理这种情况的节奏非常缓慢，很大程度上取决于是否能提供足够强的法律文件，比管理个人账号还要麻烦。
所以建议每一位拥有组织Owner权限的开发者，在生前的准备阶段就明确一个问题：如果你不在了，组织里（或者家人里）有谁应该被设为Co-owner？如果可能，现在就拉一个人进来做第二Owner，这才是最简单、最直接的继承准备。现实中“安排第二管理员”这种操作，远胜于一切事后法律程序。
4. 法律路径：怎么写、怎么公证、怎么执行
4.1 遗嘱里究竟该写什么，才能避免“写也白写”
聊完技术准备，再谈法律。前面说过，法律世界上并没有“GitHub账号”这个东西，所以在遗嘱里直接写“我的GitHub账号由儿子继承”，很可能连着名认证、遗嘱执行、平台审核三个环节都过不了。合适的写法，不是以“账号”为对象，而是以“我所有的、与GitHub账号相关的数字资产及其处置方式”为对象。
我可以分享一个相对稳妥的遗嘱条款写法思路，当然最终文本要交给专业律师起草，这里只说原则：
说明你拥有哪些数字身份账号，列出账号标识（用户名）和主要用途；说明这些账号中的数据（尤其是代码作品）是你个人创作的知识产权；明确处置方式，例如“全部代码仓库及相关数据由某某某某继承”；并指定遗嘱执行人，授予其具体的处理权限，包括访问、导出、转移、关闭账号等。
关键在于不要把“账号”写成“账号”，把“代码”写成“账号”。法律意义上的继承标的应该是数据和由此产生的权益，平台的操作问题留给技术准备部分去解决。
4.2 需要公证或认证的，究竟是什么文件
现实操作中，继承人最常被要求提供的法律文件包括：死亡证明、遗嘱副本、以及遗嘱认证证明（或继承权公证文书）。这些文件的办理机构通常是公证处，某些情况下需要法院的确认。
很多人忽略了一个细节：这类文件在提交给外国平台时，往往还需要翻译件和相应的公证认证流程。GitHub所在的司法管辖区可能要求不同，更通用的做法是准备一份中英双语的说明信，连同遗嘱和死亡证明一并提交。我在帮朋友处理类似情况时，发现平台客服真正关注的其实只有两件事：第一，你是不是合法有权处理此人全球资产的人；第二，你有没有能力完成账号的后续处置，比如数据导出后到底谁接收。前者的证明靠公证文件，后者的证明往往靠技术材料。
所以法律准备和技术准备不是二选一，而是紧密配合。遗嘱上写明“代码由谁继承”，技术档案里写明“怎么把代码取出来”，两者同时到位，执行流程才顺畅。
4.3 多名继承人与跨境场景的处理复杂度
数字资产继承还有一个特别容易忽略的现实问题：如果继承人不止一个，代码仓库怎么办？这和房子、存款不一样，代码仓库没法分成三份，更不合适几个继承人各自保存一份。私有仓库尤其是这样——要么共同委托一位执行人统一访问，要么在遗嘱里明确这些资产是“一人继承”而其他权益另行安排。
这里我要多说一句实话：数字资产的“共有”继承在实务中非常痛苦。多个继承人各自要导出数据、各自要有访问权、各自对项目处置发表意见，很容易让执行流程拖沓数月。所以如果你能在遗嘱里提前写明“这些数字资产整体由某某某某一人继承，其他继承人通过其他方式获得相应补偿份额”，会为执行过程省掉大量麻烦。
跨境问题则更麻烦。如果账户持有者长期居住在海外，或者继承人分居不同国家，涉及的法律文件还要考虑使用地与平台注册地法律冲突的问题。作为一个普通人，我能给的最实用的建议是：不要试图在遗嘱里一次性解决全球资产的继承问题，只针对“GitHub这个具体平台”写清楚即可，剩下的事情执行人遇到再处理。
5. 全流程实操：从立遗嘱到账号交接，我踩过的坑
5.1 第一步：两个月内做一次彻底的技术“遗嘱”整理
我建议把整件事当作一个“两个月的项目”来做，而不是一个晚上突击完成。第一次做清单时，我低估了一个问题：原来记忆中和实际账号里存在的东西差别如此之大。
第一步先盘点，第二步补备份。什么叫补备份？就是把你私有的仓库，找个不在GitHub上的外部存储位置做一次离线备份。这一步尤为重要，因为如果有一天账号被冻结、被删除，外部备份就是你数字遗产的最终保险。具体操作可以简单到用git clone把仓库拉取到本地，然后压缩加密后上传到自己的私有云存储或加密U盘。这里不用搞得多复杂，重点不是防备平台倒闭，而是防备“继承发生时账号已经无法登录”的空窗期。
第三步是确定临时执行人。在真正立遗嘱之前，先选定一到两位你完全信任的人，告诉他们：“如果我出了意外，这是存放账号清单的位置，这是密码管理器的主密码，这是需要联系的人。”这听起来像坏消息传递，实际上却是给家人省掉一场灾难的好消息。
5.2 第二步：法律文件与平台材料的配套准备
法律文件的准备，放在技术整理基本完成后去启动也不迟。找到了解数字资产的律师，可能会省心一些，但在多数情况下，哪怕是没有数字资产经验的律师，也能看到遗嘱、死亡证明、继承公证这类标准文件的写法。你真正需要向律师强调的，是数字资产的特殊性：可能存在多平台、可能存在难以量化的无形资产、可能需要跨境提交。
文件准备得差不多了，再针对“可能的平台审核”准备一份英文说明信模板。这封信以继承人身份开头，说明账号持有者已故、本人是合法继承人、请求平台提供数据导出协助或关闭账号。附上公证文件的翻译件。这封信不需要很复杂，重点是逻辑清晰和证据完整。
5.3 第三步：继承发生后的处理步骤顺序
如果真到了执行阶段，家人或执行人按什么顺序处理最重要？我自己的经验是：先解决“访问”问题，再解决“数据”问题，最后解决“处置”问题。
第一步，尝试进入账号。拿着生前留下的密码和恢复码，登录GitHub。如果账号已经触发双重认证，而恢复码派不上用场（比如已经用完了），就要走账号恢复流程，提交身份材料、出示公证文书，等待平台处理。这一步最耗时间，所以强烈建议生前就确保有人知道恢复码放哪里。
第二步，立即导出数据。登录进去以后的第一件事不是翻仓库，而是立刻在设置里导出全部账号数据。这个导出的过程可能耗时数小时甚至数天，因为平台需要打包所有仓库和元数据。导出完成后，用加密压缩包的方式存好。
第三步，决定账号去留。是继续以原账号形式运营，还是新建一个号把仓库迁移过去？如果是独立开发者，而且继承人不熟悉Git，我个人的建议是：申请账号停用或归档，把代码迁移到继承人自己名下的新账号，避免原账号继续接收登录尝试、安全警报和不相关的社区互动。迁移的核心操作是仓库转移：新账号创建一个继承者仓库，原账号把仓库转移给新账号，继承完成后原账号清理剩余内容并停用。整个过程看起来顺理成章，但前提是原账号还有登录访问权，而这一点全靠生前准备。
5.4 一件更容易被忽略的事：本地设备和密钥的安全销毁
数据继承不只有“保留”的动作，还有“删除”的动作。如果账号持有者的本地电脑里保存着大量密钥、令牌、SSH Key、云服务凭证，继承人在收到这些设备后应该先评估：本地密钥是否仍然有效？是否已从各种平台撤销授权？如果这些密钥被继续保留在设备上，而设备又落在无关人员手里，风险远大于收益。
最好在账号交接完成后，把所有关键的旧密钥统一撤销并重新生成新密钥，将旧的恢复码全部作废。这一点很重要——继承不是把一切原封不动交棒，而是要在“延续”的同时切断已经失效的关系。实际操作时，可以通过设置里的“撤销全部会话”和“失效所有SSH Key”来重置安全隐患，再在新账号上重新部署访问凭证。
6. 常见问题与避坑指南
6.1 恢复码弄丢了，还有没有救
恢复码缺失是继承场景里最尴尬的问题之一。如果密码和恢复码都拿不到，但账号绑定的邮箱还能登录，可以通过邮箱找回；但如果邮箱也因为主人去世而被注销或冻结，麻烦就成指数级上升。此时唯一的出路就是向平台申请“账号找回”流程，提交尽可能多的身份证明材料：身份证件、死亡证明、历史登录地点、绑定的手机号账单记录等，等着人工审核。
这类申请往往要一到数周甚至更久，所以最好的抢救方式从来都不是“事后补救”，而是“生前多存几份恢复码”。现在就把恢复码打印出来，收藏在你的遗嘱材料里，是成本最低、效果最好的操作。
6.2 组织账号没有第二管理员，怎么办
组织账号的问题我在前面举过例子，这里补充一个经验：组织设置里可以添加多个Owner，这个操作不需要任何法律程序，只需要现有管理员进入组织设置完成。如果你是唯一Owner，现在就应该马上拉一个你信任的人进来做第二Owner。这一点几乎是所有数字资产传承准备里，性价比最高的一分钟操作。
如果组织里第二管理员已经存在，继承流程会顺滑很多。否则就要依靠法律文件和平台客服的特殊审核，整个过程至少以月为单位计算，期间组织的公开仓库的维护、issue处理、PR合并都会停滞。
6.3 遗嘱已经写了，还需要技术清单吗
需要，而且是刚需。遗嘱只解决“归谁、怎么分”的问题，技术清单解决“怎么拿、怎么操作”的问题。两者之间的配合关系用一个场景说明：你有遗嘱，遗嘱里写了“代码由A继承”，但A连账号登录密码都拿不到，这份遗嘱的执行就只能停留在纸面上；反过来，你有完整的技术清单但没有遗嘱，继承人虽然能登录账号，却可能在法律上站不住脚，平台审核时无法自证身份。
我在实际操作中见过的顺利案例，无一例外都是两类材料齐头并进。所以不要有“我既然去找了律师，就可以不记密码”的错觉，也不要因为“反正密码都写了，就不用做公证”而省略法律流程。记住一个简单的公式：法律文件定义权益，技术文件保障访问，两者缺一不可。
6.4 账号被平台判定为不活跃，还能恢复吗
有一些情况是继承人发现账号时已经太晚：账号因为长期未登录被平台标记为不活跃账号，甚至已经进入删除流程。这种情形下，只要账号还没有被彻底清除，理论上仍然可以通过身份验证和申诉恢复。但时间窗口非常不确定，平台的保留策略也不透明，不能抱着侥幸心理。
最可靠的做法还是防患于未然：在遗嘱中明确“在我无法照顾账号期间，由执行人负责登录维护账号活跃状态”，同时在技术备忘中给执行人留下定期登录的方法。哪怕只是每月登录一次、更新一次依赖，也能让账号保持“活跃”状态，为后续正式交接争取足够时间。这件事虽然听着有点仪式化，但它正好呼应了“数字资产传承本质上不是让账号永续存在，而是让资产的转移过程可控可预期”这一最根本的目标。
写在最后的个人经验
处理过几次账号交接的实际案例之后，我对“数字资产传承”这件事有了新的理解。大多数人都把目光集中在“账号怎么登录”上，但真正常被忽视的问题是“我想让后人拿这些代码做什么”。如果只是为了保留一份回忆，备份一次数据就够了；如果真的想让项目延续，那么代码归属、维护权限、发布渠道、社区角色都要在生前想清楚。每一次交接不顺，背后都几乎可以追溯到“信息没有留下”或“留下得不够清晰”这两个原因。
我个人在经历过整理账号清单的繁琐、经历过“原来我自己有这么多密钥”的震惊之后，决定把这件事变成了一个每年年初固定做一次的例行任务。不必每年都重新立遗嘱，但至少保证新的仓库、新的密钥、新的2FA恢复码都及时同步进已有的归档里。等那个时刻真正到来时，希望它在家人手里不是一场灾难，而只是按部就班的操作。这件事并不复杂，早做一天，就早安心一天。