一、前言

在使用 GitHub 时，很多同学都对「Fork 复刻」的可见性、溯源逻辑，以及手动复制代码的合规性存在疑问：我 Fork 了别人的公开仓库，会不会被原作者发现？别人再 Fork 我的仓库，到底是复刻了谁的项目？如果我手动下载别人的代码，新建仓库公开，会不会违规？

今天就结合官方规则和实操场景，一次性把这些问题讲透。

---

二、核心问题 1：复刻别人的公开仓库到我的公开仓库，别人能看到吗？

1. 结论先行

完全可以看到，且你的 Fork 仓库本身也是公开状态，无法转为私有。

（图文来自于github内置智能体 Copilot）

2. 规则解析

GitHub 对公开仓库的 Fork 有强制约束：

• 可见性强制同步：公开仓库的 Fork 必须保持公开，你无法将其改为私有。任何人访问你的个人主页，都能看到这个 Fork 仓库，也可以直接查看代码、提交记录等所有内容。
• 原作者可溯源：原仓库的所有者可以在项目的「Fork 网络」中，看到所有复刻它的仓库列表，包括你的这一份。
• 修改内容公开可见：即使你在 Fork 仓库中做了修改，只要仓库是公开的，这些修改也会对所有人可见。

3. 避坑提醒

如果你不希望别人看到你基于公开仓库的修改，绝对不能通过 Fork 实现私有修改。更稳妥的替代方案是：

1. 先通过 git clone 将公开仓库代码下载到本地；
2. 在自己的账号下新建一个私有仓库；
3. 将本地修改后的代码推送到这个私有仓库。

   1. git clone 原仓库
   2. 新建私有仓库
   3. 推送修改至私有仓库
    
   

这种方式不会被标记为 Fork，也不会关联到原仓库的 Fork 网络，不会被公开溯源。

---

三、核心问题 2：别人复刻了我复刻别人的仓库，他是复刻了谁的仓库？

1. 结论先行

别人直接 Fork 你的 Fork 仓库时，他复刻的是你的仓库，而非直接复刻最原始的上游仓库。

2. 规则解析

• Fork 网络的层级关系：所有基于同一个上游公开仓库创建的 Fork，都会属于同一个仓库网络，但存在清晰的层级关系：原始上游仓库（父项目）→ 你的 Fork 仓库（子项目）→ 别人的二次 Fork 仓库（孙项目）

• 原始仓库 → 你的Fork → 他人的二次Fork

• 溯源标识的指向：别人的二次 Fork 仓库，顶部会标注 Forked from 你的用户名/你的仓库名，而非直接标注原始上游仓库。
• PR 提交的选择权：二次 Fork 的用户提交 Pull Request（PR）时，可以自主选择目标仓库：既可以提交给你的 Fork 仓库，也可以直接提交给最原始的上游仓库，由 PR 发起者决定。

3. 场景示例

假设：

• A 是原始公开仓库所有者

• 你 B Fork 了 A 的仓库

• 用户 C 再 Fork 你的 B 仓库

• C 的仓库会显示 Forked from B/仓库名；

• C 提交 PR 时，可以选择提交给 B 的仓库，也可以选择提交给 A 的原始仓库。

---

四、核心问题 3：手动下载代码后新建公开仓库，算违反规定吗？

这是很多同学容易踩坑的地方，答案是：取决于原仓库的 LICENSE（开源许可证）条款。

（图文来自于github内置智能体 Copilot）

1. 核心判断逻辑

• 遵守原仓库的许可证条款，通常就不会违反规定；
• 若仓库没有 LICENSE，则默认著作权归原作者所有，未经授权公开或再分发可能构成侵权。
• （图文来自于github内置智能体 Copilot）

2. 合规操作步骤

第一步：查看仓库的 LICENSE 信息

• 检查仓库根目录是否有 LICENSE 文件，或 README 页面中是否有许可类型说明；
• 不同许可证对复制、再发布、署名、衍生作品和是否必须开源衍生作品有不同要求。

第二步：根据许可证类型执行对应操作

• 允许再分发的许可证（如 MIT、Apache-2.0、BSD）：在你的新仓库中完整保留原作者的版权声明和许可证文本，并遵守额外要求（如 Apache 许可证需要保留 NOTICE 文件等）。
• 传染性许可证（如 GPL）：如果你发布了包含原代码的衍生作品，通常必须以相同或兼容的许可证发布整个项目，并提供完整源代码。
• 限制性 / 专有许可证：如果许可证禁止某些用途，或没有明确允许再分发，你不能公开发布，必须获得原作者的书面许可。

第三步：GitHub 平台的额外注意事项

GitHub 的服务条款明确指出：公开仓库可以被他人查看和 Fork，但把别人受版权保护但无许可的代码公开上传到你的仓库，不会让你获得任何合法权利，这仍可能违反版权条款。

---

五、通用合规做法汇总

无论你是 Fork 还是手动复制代码，都建议按以下步骤确保合规：

1. 在公开之前，检查原仓库根目录是否有 LICENSE 文件（或 README 中的许可说明）；
2. 严格依据许可证条款，在新仓库中保留并包含原许可证文件、版权声明、必要的 NOTICE 或署名信息；
3. 如果不确定该许可证是否允许公开，或不清楚如何合规，直接联系原作者请求明确许可；
4. 若仓库没有许可证，且无法获得原作者授权，避免将代码公开，仅在私有仓库中使用。

---

六、补充说明：原仓库变更 / 删除对 Fork 的影响

很多同学担心：如果原仓库被删除或转为私有，我的 Fork 会怎么样？根据 GitHub 官方规则：

1. 原仓库被删除后，你的 Fork 依然会保留公开状态，只是会失去和原仓库的关联标识；
2. 原仓库从公开转为私有后，你的 Fork 不会自动转为私有，依然保持公开状态，但无法再同步原仓库的更新；
3. 只有当原仓库所有者主动删除所有 Fork，或 GitHub 平台介入处理时，你的 Fork 才会被影响。

---

七、总结

1. 公开仓库的 Fork 一定是公开的，任何人都能看到，且无法转为私有；
2. 别人二次 Fork 你的 Fork 仓库时，复刻的是你的仓库，溯源标识会指向你；
3. 手动下载代码后新建公开仓库，必须严格遵守原仓库的 LICENSE 条款，无许可代码不得公开；
4. 若需要私有修改，优先使用 clone + 私有仓库 的方式，而非 Fork；
5. 所有同网络的 Fork 仓库，PR 提交目标由发起者自主选择。

---

如果这篇文章帮你理清了 GitHub Fork 和开源合规的规则，欢迎点赞收藏，后续我会继续分享更多 GitHub 实操技巧～

参考与进一步阅读：

• Licensing a repository — GitHub Docs（如何查找 / 放置 LICENSE、无许可证时的法律后果、常见许可证关键词）