GitHub模板仓库与fork：文件相似，提交历史为何不同

两个新仓库打开后，目录和文件看起来一样，提交记录却可能相差很多。这不一定是复制过程漏了内容。GitHub把“从模板创建仓库”和fork设计成了两种不同的起点：前者用于建立新项目，后者保留与父仓库历史相关的派生关系。

官方模板文档给出的区别很具体：新的fork包含父仓库完整的提交历史，而从模板创建的仓库从一个提交开始。因此，比较这两种结果时，不能只看首页文件清单。文件描述当前内容，提交记录描述内容怎样走到当前状态；前者相似，并不要求后者也相同。

可以设想一份供团队使用的项目起始模板，里面已有目录、配置和示例文件。新项目希望沿用这些起步材料，并不一定要把模板形成过程中每次调整都作为自己的开发历史。这个假设有助于理解单一初始提交的作用，但并不表示模板功能会检查项目用途，也不是本文已创建仓库得到的测试结果。

多分支选项还有一处容易误读。创建时可以只取默认分支的结构和文件，也可以选择包括所有分支；官方同时指出，从模板生成的分支具有不相关的历史，不能在这些分支之间创建拉取请求或合并。因而“把分支都带过来了”不能直接等同于“原有分支之间的历史关系也保留下来了”。

这会影响资料迁移时的核对重点。如果交付目标只是一个新的项目起点，需要核对的是所选分支、目录和文件；如果目的是理解旧项目的演进过程，单看模板生成后的仓库就不够。这是由两种创建方式的历史语义得出的区别，不是建议在已有项目上强制改写或拼接历史。

访问条件也应单独记录。文档要求使用者能读取模板仓库；有一份模板链接，并不自动证明自己具备相应访问权限。至于组织内可以怎样创建仓库、相关文件允许怎样使用，还应核对各自的权限和许可资料，不能从“能从模板创建”推出这些问题已经解决。

本文依据2026年10月12日读取的GitHub官方说明，没有执行创建、fork或迁移。核对新仓库是否符合预期时，先明确需要的是文件起点还是历史延续，再查看实际创建方式，比把提交数量不同一概当作数据丢失更准确。