Git 是否可以创建一个项目作为现有项目的前身？什么样的前期项目？

我在前端架构部门工作，我们维护几个框架项目。在这些中，我们定义了其他团队用于启动自己项目的基础知识。我们创建一些代码，用babel启动一个webpack开发服务器；我们使用testem、chai和mocha设置自动测试；我们创建脚本来帮助生成一些配置文件。这一切看起来都很酷，但有一个缺陷：从我们的骨架创建的项目不是从它们派生出来的，它们克隆了骨架repo，然后将它们的新项目推到另一个repo

对我们的框架项目的每一次更改都只会影响未来的项目，因为旧项目不会自动获得更改，甚至不会手动执行（这是我们目前正在尝试实施的）

所以，有这样一个结构会很好：

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

是否可以在创建项目后创建此“分叉关系”，以便我们更新父项目，而他们只需合并这些更改

这一切看起来都很酷，但有一个缺陷：从我们的骨架创建的项目不是从它们派生出来的，它们克隆了骨架repo，然后将它们的新项目推到另一个repo

但那是分叉。

Git是一个分布式系统。提交在存储库之间移动时保留其标识。如果他们克隆了您的存储库并推送到他们的存储库中，那么这些分支具有共同的历史记录，因此他们可以随时从您的存储库中提取并将基线合并到他们的项目中

GitHub、GitLab、BitBucket和类似的“fork”操作只是服务器端克隆。如果他们手动执行克隆，存储库管理器将不知道它可以执行合并，因此他们可能也必须手动执行，但没有任何东西可以阻止它

---

也就是说，合并并不能很好地覆盖一切。对于基线和在此基础上构建的项目，通常最好将基线和自定义设置作为构建系统组合的某种层，并将基线作为sumbodule签出或由构建系统作为依赖项下载

---

更新：

但我了解到，实际上新项目不是以这种方式创建的，因此它们不是叉子

还有一条路要走。软件包维护人员（例如，在Debian中）经常使用它来跟踪来自不同版本或非公共版本控制系统中版本控制的上游版本的修改。它通过维护“上游”分支来工作：

项目（下游）存储库中的初始导入是骨架（上游）某些修订的直接副本，然后在此基础上进行更改。当需要与较新的骨架（上游）合并时，将创建一个新的分支（

上游

），在其中复制并提交骨架的较新版本。然后将该分支合并到

主节点中

，以引入较新的骨架

由于3路合并算法只关心当前状态和最近的共同祖先，而不关心两者之间的修订，因此没有历史记录并不重要。只是不要丢失

上游

引用，以便下次要合并新骨架时可以对其进行更新

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

---

请注意，通过对骨架进行显式编号的发布，您将大大有助于此工作流。这样可以更容易地跟踪每个下游项目中导入和合并的版本。

我不清楚您的项目是模板的初始克隆，还是没有任何历史记录的副本（如果是克隆的话），您只需

git远程添加模板

，然后将模板repo中的更改合并到项目repo中。如果这些是副本，您还可以添加和获取远程，但稍后将您的初始提交连接到

git replace--graft

我接受了您的答案，因为它是正确的。但我了解到，实际上新项目不是以这种方式创建的，因此它们不是叉子。Sooo，谢谢你的回答和教我，但不幸的是我不能做我想做的事情：'（@DanielHernándezAlcojor，甚至还有一个工作流。跟踪事情有点困难，但在Git之前，它就被用来跟踪第三方发布的包的更改。我已经更新了答案。@DanielHernándezAlcojor，还有更高级的选项来重写下游项目的历史记录让它们看起来像是一开始就被克隆了一样，但是尽管git在这方面有很好的工具，但它需要广泛的协调，在您的情况下，这似乎是一种过激的做法。在上游分支中导入较新的副本应该可以很好地为您服务。