我在前端架构部门工作，我们维护着几个骨架项目。在这些文档中，我们定义了其他团队用来启动自己的项目的基础知识。我们创建一些代码以使用babel启动一个webpack开发服务器。我们使用testem，chai和mocha建立了自动测试；我们创建了有助于生成一些配置文件的脚本。一切看上去都很酷，但是有一个缺陷：从我们的框架创建的项目不会从它们中派生出来，它们会克隆框架存储库，然后将其新项目推送到另一个存储库。
对框架项目的每次更改只会影响将来的项目，因为旧项目不会自动获得更改，甚至不会手动进行更改（这是我们当前正在尝试执行的操作）。
因此，拥有这样的结构会很棒：
basic-skeleton
|--amp-skeleton
| |--amp-project-1
| |--amp-project-2
|--react-skeleton
|--react-project-1
是否可以在创建项目后 创建这种“叉子关系”，以便我们更新父项目，而它们只需要合并这些更改？
答案 0 :(得分：2)
这一切看起来都很酷，但是有一个缺陷：从我们的框架创建的项目不会从它们中派生出来，它们会克隆框架存储库，然后将其新项目推送到另一个存储库。
但是是分叉的。
Git是一个分布式系统。当提交在存储库之间移动时，提交保持其身份。如果他们克隆了您的存储库并推送到他们的存储库中，则分支具有相同的历史记录，因此它们可以随时从您的存储库中提取基准并将其合并到他们的项目中。
GitHub，GitLab，BitBucket和类似工具的“ fork”操作仅仅是服务器端克隆。如果他们手动进行克隆，则存储库管理器将不知道它可以进行合并，因此他们可能也必须手动进行，但是没有什么阻止它。
这就是说，合并与覆盖最重要的东西并不合适。对于基线和在其之上构建的项目，通常最好将基线和自定义项由构建系统组合成某种类型的层，并以sumbodule的形式检出基线，或由构建系统将其作为依赖项下载。
更新：
但是我了解到，实际上并不是以这种方式创建新项目，因此它们不是分叉的。
仍有解决方法。软件包维护者（例如Debian中）经常使用它来跟踪来自上游发行版的修改，这些发行版在不同或非公开的版本控制系统中进行了版本控制。它通过维护“上游”分支来工作：
项目（下游）存储库中的初始导入是骨架（上游）的某些修订版的直接副本，然后在此之上进行更改。当需要与较新的框架（上游）合并时，会创建一个新分支（upstream），将较新版本的框架复制并提交。然后将该分支合并到master中，以引入较新的框架。
由于三向合并算法仅关心当前状态和最近的共同祖先，而不关心它们之间的修订，因此，没有历史记录也没关系。只是之后不要丢失upstream引用，因此下次您要合并新框架时可以对其进行更新。
此工作流甚至在Git之前就已使用，并且在那里更重要，因为集中式系统无法在存储库之间（例如分布式存储库）复制历史记录。在CVS手册中甚至将其描述为“供应商分支”。这也是Git的设计用例之一，也是Git在合并过程中猜测重命名而不是跟踪文件身份的重要原因-因为当将经过压缩/压缩的发行版导入到vendor分支中时，您没有重命名信息
请注意，通过对框架进行明确编号的发行，您将大大帮助此工作流程。这样可以更轻松地跟踪每个下游项目中导入和合并的版本。