0

我试图弄清楚如何(如果可能)设置多个 git 存储库以特定方式运行。基本上,我们有多个客户端的多个存储库,但是它们都意味着共享一个系统目录。当对一个客户端的系统目录进行更改时,应该对所有客户端的系统目录进行更改。现在复杂的是,我们有多个用于 CI 开发系统的环境。我们目前有生产环境、客户端rev环境、qa环境和开发环境。这些可以很好地转换为不同的分支,因为这意味着当工作流被批准用于下一个环境时,我们可以将该工作流分支合并到适当的环境分支中,并将来自该工作流的更改添加到该环境中。

问题是我们的代码结构是这样设置的,我们有一个系统目录,它是我们的基本代码,一个自定义目录,其中包含客户端特定代码(包括用于替换系统代码中的文件的文件)和客户端特定配置目录。请注意,我们不是在一个使开发更加复杂的面向对象系统上,因为没有继承或扩展来使定制更容易。

我们的目标是将这个开发系统转换为 GIT。我们遇到的问题是维护该共享系统目录。我们已经尝试过子模块,但是子模块需要大量维护以防止覆盖或错误指向它们,并且由于确保客户端 qa 分支始终指向的工作量过多而繁琐,因此不能很好地与永久环境分支一起使用到系统子模块中的 qa 分支的主要提交,而不是到 WF 分支中的主要提交。

我们当前的 IDE 是没有子树集成的 eclipse(尽管我读到的子树是它们可以像子模块一样复杂)。我们真正需要的是跨多个被传播的存储库的并行分支。因此,例如,如果我在客户端 repo 中创建一个工作流分支,则会在系统 repo 和所有其他客户端 repo 中创建一个 WF 分支。当我进行更改并将该工作流合并到 qa 中时,系统 repo 的 wf 分支也会合并到 qa 分支中,但仅包含对系统文件夹的更改,而不是对自定义和配置目录所做的更改。

我想知道是否有一个好的结构来做这样的事情。我在其他网站和来源上读到的所有内容都说解决方案就是不要那样做,但是这个决定不是我做出的。上级决心保持我们现在的发展体系。

我的一个想法是看看是否有一种方法可以做一些类似直通的事情,我们创建一个只有系统模块的存储库。然后对于每个客户端,我们克隆该存储库并添加自定义和配置目录。然后,当我们进行开发时,我们会克隆该客户的存储库。我想知道是否通过这种方法,如果我们进行了更改并提交并推送到上游,这是否会将更改一直推送到顶级仓库。同样,当我们拉下更改时,如果我们可以从顶级回购中一路拉下来。另一方面,必须在客户端 repos 中设置 .gitignore ,这样当向上推送时它会忽略自定义和配置目录,但在向下游拉时它包括这些目录。

对此的任何想法将不胜感激。我们的代码主机也是一个私有的 gitlab 服务器。

对不起,这太长了,但我觉得我们有一个非常独特(不好)的系统,需要一些解释。

未来的 Git 用户

4

1 回答 1

1

这似乎更像是一个组织和架构问题,而不是 git 问题,但我会试一试。

您是否考虑过为每个客户端创建一个分支,然后根据需要进行合并/拉取,然后推送,而不是创建存储库。

不推荐通过 git 部署,git 不是一个很好的部署方式。它的设计是开放的,记录更改并使代码共享变得容易,所以如果有人不小心提交了凭据,除非你做了一些疯狂的事情(这些疯狂的事情会破坏其他人的代码),否则它们会被永久记录下来。大多数理智的用户使用 git 提交和共享他们的更改,将特定分支构建到模块/pkg/image/container/something-stable-and-constant 中,然后将该模块部署到其他地方到他们的客户。

如果您仍希望将其用于部署,请查看git-hooks。您可以设置一些挂钩(例如更新或预接收),在更新分支时自动拉取代码。

另一种选择是将更多的共享目录放入云存储服务或基于文档的 NoSQL 服务器中。它可以帮助您维护每个人都可以从中获取的单一来源。这不会是完美的,最终的一致性会在这里和那里造成一些麻烦,但这是值得的。我只建议不要在文件立即在客户端磁盘上很重要的情况下使用它。

于 2016-09-21T23:10:06.483 回答