说我有一些代码构成了一些很酷的东西的基本框架。我将其放入一个仓库中，我将其称为cool-app-base。
现在，对于一些很棒的应用程序，我有一些好主意。我希望他们使用cool-app-base，然后从那里开始构建。自然，我可以选择clone和orphan，以及fork和重命名，等等。为了举例，假设我为自己想要的东西做了最好的事情，并创建了{{1} }。
我不打算将{em> back 从cool-app-1贡献到cool-app-base，所以任何一个都可以。但是我要做希望能够将我可能对cool-app-1进行的任何更新都带到cool-app-base中。
问题是，cool-app-1不必关心cool-app-1的历史。我想将这些更新视为压缩的提交，因此更新可以包含“使用最新的cool-app-base更新”的提交消息并完成。这使cool-app-base的吸引力降低了，但听起来我唯一的选择是手动将fork的代码更改合并到cool-app-base中，以便我可以控制提交历史记录。
我的问题是：我该如何做得更好/“正确”？我确定我可以使用一些时髦的cool-app-1选项，但我还不很精通，因此无法自信地进行探索。
说明： git merge不是库，而是一组配置文件。尽管可以将它们分解并单独导入，但我的目的是保持它们捆绑在一起。我想让cool-app-base的文件形成cool-app-base的根，而不是嵌套在子目录中。我要解决的实际问题是，每次我想启动一个新项目时，都不需要重新创建我的包文件，目录结构和一组经过精心构造的脚本。如果我的配置位于子目录中，那么我仍然需要创建对它们的引用，在我认为只是更多样板代码的地方。
此外，尽管我认为该概念与语言无关，但我正在cool-app-1和JavaScript中使用node。
答案 0 :(得分：0)
我认为您可以使用Git Submodules，将cool-app-base用作cool-app-1的子模块。然后cool-app-1将在物理文件资源中具有子文件夹cool-app-base，两个存储库的Git历史记录都不会受到干扰。
Git使用子模块解决了这个问题。子模块允许您将Git存储库保留为另一个Git存储库的子目录。这样，您就可以将另一个存储库克隆到您的项目中，并使提交保持分开。
答案 1 :(得分：0)
您没有提及您的编程语言。但是大多数语言都带有某种程序包管理器：
如果您有使用该语言的软件包管理器，请在您的 app 项目中使用它，以包含您的 base 项目。
如果没有，我建议使用subtree而不是子模块。您可以将 base 项目包括在 app 项目的子目录中。这就像将一个提交的整个文件系统复制到另一个仓库中。您可以选择是否需要历史记录（squash）。
以后，您可以使用一个命令将其更新到较新的版本。