0

我有一个项目，它依赖于 4 个组件，每个组件执行不同的任务。

在一个模块中完成的更改可能需要（但不一定）对其他组件进行更改。
我为每个单独的模块维护了一个 git 存储库。

So, Project
    repo1 -> Component A (PHP)
    repo2 -> Component B (NodeJS)
    repo3 -> Component C (NodeJS)
    repo4 -> Component D (JAVA)

我现在被建议为整个项目使用一个 repo。
但是，我很偏执，将来，如果模块的大小或结构增加，最好将模块维护在一个自我仓库中而不是单个仓库中。

我想实现以下目标：

  • 这些组件中的每一个都将位于不同的服务器上
  • 便于未来的开发和维护
  • 将组件自动部署到各自服务器的挂钩

为此推荐的 git 结构/工作流程是什么？

注意：
整个代码库仍然是本地的。
我尝试使用子树，现在我有一个项目，它保留了来自其他组件的所有提交，我不确定在使用子树之后，如果将来可以将模块拆分为单独的 git repo。（我听说过关于子模块的不好 的事情，所以还没有尝试过）。

4

1 回答 1

1

如果它们是可以独立更新的独立项目，则将它们保留为单独的项目。不要使用子模块，不要将它们混合到单个模块中。只需独立开发它们。

如果一个组件的更改会影响另一个组件，请使用某种 API 版本控制来处理它；确保当您对其中一个进行不兼容的更改时，您会更新版本号，这样如果有人只拉那个而不是另一个，他们会立即知道出了什么问题。

除此之外，只需将它们视为独立项目，并部署每个项目的最新版本。除此之外，没有太多需要使它复杂化。

如果它们密切相关，并且一个不能独立于另一个存在，并且几乎每个重大更改都需要其中两个一起更新，那么只需在一个大存储库中开发它们。如果事情是如此紧密地联系在一起，那么将其拆分是没有意义的。使用您的部署脚本从一个大存储库部署到不同的服务器。

无论你选择哪一个，都不要太担心。Git 的优点之一是，一旦您意识到自己做错了，以后合并或拆分存储库相当容易。如果您尝试拆分方法，但结果过于混乱或繁琐，请进行子树合并，现在您拥有一个统一的存储库。如果您尝试统一方法并且它变得太大？运行git filter-branch它以分离出子组件的每个子目录，现在您有几个独立的存储库（在这种情况下请保留原始存储库，因此您实际上拥有完整的统一历史记录，以防将来变得相关）。

于 2013-09-28T07:46:27.593 回答