git - 是否可以创建一个项目作为现有项目的前身？某种预 fork 项目？

Question

我在前端架构部门工作，我们维护着几个骨架项目。在这些中，我们定义了其他团队用来启动自己的项目的基础知识。我们创建一些代码来使用 babel 启动 webpack devserver；我们使用 testem、chai 和 mocha 设置自动化测试；我们创建有助于生成一些配置文件的脚本。这一切看起来很酷，但有一个缺陷:从我们的骨架创建的项目不会从它们 fork ，它们克隆骨架存储库，然后将新项目推送到另一个存储库。

对骨架项目的每次更改只会影响 future 的项目，因为旧项目不会自动获取更改，甚至不会手动执行(这是我们目前正在尝试强制执行的操作)。

所以，如果有这样的结构就太好了:

basic-skeleton
|--amp-skeleton
|  |--amp-project-1
|  |--amp-project-2
|--react-skeleton
   |--react-project-1

是否可以在创建项目之后创建这种“ fork 关系”，以便我们更新父项目并且他们只需 merge 这些更改？

Answer 1

It all seems cool, but there is one flaw: the projects created from our skeletons don't fork from them, they clone the skeleton repo and then push their new project to another repo.

但这是 fork 。

Git 是一个分布式系统。当提交在存储库之间移动时，它们会保留其身份。如果他们克隆您的存储库并推送到他们的存储库中，则分支具有共同的历史记录，因此他们可以随时从您的存储库中提取并将基线 merge 到他们的项目中。

GitHub、GitLab、BitBucket 等的“fork”操作只是服务器端克隆。如果他们手动进行克隆，存储库管理器将不知道它可以进行 merge ，因此他们可能也必须手动进行，但没有什么可以阻止它。

---

也就是说， merge 并不适合覆盖事物。对于基线和在其之上构建的项目，通常最好将基线和自定义设置为由构建系统组合的某种层，并将基线作为 sumbodule check out 或由构建系统作为依赖项下载。

---

更新:

But I've learned that actually the new projects aren't created this way and thus they're not forks.

仍有办法解决这个问题。软件包维护者(例如在 Debian 中)经常使用它来跟踪在不同或非公共(public)版本控制系统中进行版本控制的上游版本的修改。它的工作原理是维护一个“上游”分支:

项目(下游)存储库中的初始导入是骨架(上游)的某些修订的直接副本，然后在此基础上进行更改。当需要与较新的骨架(上游) merge 时，会创建一个新分支(上游)，将骨架的较新版本复制到其中并提交。然后将该分支 merge 到master中以引入更新的骨架。

由于三向 merge 算法只关心当前状态和最近的共同祖先，而不关心两者之间的修订，因此您没有该历史记录并不重要。只是之后不要丢失上游引用，这样您就可以在下次想要 merge 新骨架时更新它。

这个工作流程甚至在 Git 之前就已被使用，并且在 Git 中更为重要，因为集中式系统无法像分布式系统那样在存储库之间复制历史记录。 CVS 手册中甚至将其描述为“供应商分支”。这也是 Git 的明确设计用例之一，也是 Git 在 merge 期间猜测重命名而不是跟踪文件身份的一个重要原因 - 因为将 tarred/zipped 版本导入供应商分支时，您没有重命名信息.

请注意，通过对骨架进行明确编号的发布，您将极大地帮助此工作流程。它可以更轻松地跟踪每个下游项目中导入和 merge 的版本。