在存储库git上同步变体 [英] syncing variations on a repository git
问题描述
我试图弄清楚如何(如果可能)设置多个git存储库以特定方式运行.基本上，我们为多个客户端提供了多个存储库，但是它们都打算共享一个系统目录.当更改一个客户端的系统目录时，应更改所有客户端的系统目录.现在，为了复杂起见，我们有用于CI开发系统的多个环境.我们目前有一个生产环境，一个客户转速环境，一个质量保证环境和一个开发环境.这些可以很好地转换为不同的分支，因为这意味着当一个工作流被批准用于下一个环境时，我们可以将该工作流分支合并到适当的环境分支中，并仅将工作流中的更改添加到该环境中.
问题在于我们的代码结构是通过以下方式设置的:我们拥有作为基本代码的系统目录，具有客户端特定代码(包括用于替换系统代码中的文件的文件)的自定义目录，并且客户端特定的配置目录.请注意，我们不是在一个面向对象的系统上，因为没有继承或扩展可以使自定义变得更容易，这会使开发变得更加复杂.
我们的目标是将该开发系统转换为GIT.我们遇到的问题是维护该共享系统目录.我们已经尝试了子模块，但是子模块需要大量维护，以防止覆盖或错误指向它们，并且由于要确保客户端qa分支始终指向繁琐的工作量，因此它们与永久性环境分支的协同工作效果也不佳到系统子模块中qa分支的主要提交，而不是WF分支中的主要提交.
我们当前的IDE是eclipse，它没有子树集成(尽管我读过的子树是它们与子模块一样复杂).我们真正需要的是在多个存储库之间传播的并行分支.因此，例如，如果我在客户端存储库中创建工作流分支，则会在系统存储库和所有其他客户端存储库中创建WF分支.而且当我进行更改并将该工作流程合并到qa中时，系统存储库的wf分支也将合并到qa分支中，但只合并了对系统文件夹的更改，而不合并了对custom和config目录所做的更改. /p>
我想知道是否有一个良好的结构可以完成类似的工作.我在其他站点和消息源上阅读的所有内容都表明，解决方案就是不那样做，但是该决定并非由我决定.高层决定要保留我们当前的开发系统.
我曾经想到的是，看看是否有一种方法可以像passthrough那样在其中创建仅包含系统模块的存储库.然后，对于每个客户端，我们克隆该存储库并添加custom和config目录.然后，当我们进行开发时，我们将克隆该客户的仓库.我想知道是否通过这种方法，是否进行了更改并提交并推送到上游，这是否会将更改一直推送到顶级仓库.同样，当我们提取变更时，如果可以从顶层仓库中提取所有信息.另一方面，必须在客户端存储库中设置.gitignore，以使其在上推流时会忽略custom和config目录，而在向下游拉时会包括那些目录.
任何对此的想法将不胜感激.另外，我们的代码托管者是私人gitlab服务器.
很抱歉，这个时间太长了，但是我觉得我们有一个非常独特(不好)的系统，需要一点解释.
未来Git用户
与git问题相比，这似乎更像是组织和体系结构问题，但我将继续解决.
您是否考虑过为每个客户端创建一个分支，然后根据需要进行合并/拉取，然后再进行推送，而不是创建一个回购协议.
不建议通过git进行部署，git并不是一种很好的部署方式.它的设计是开放的，可以记录更改并简化代码共享，因此，如果有人不小心提交了凭据，则除非您做一些疯狂的事情(否则这些疯狂的事情会破坏其他所有人的代码)，否则它们将被永久记录.大多数理智的用户都使用git来提交和共享他们的更改，将特定的分支构建到module/pkg/image/container/somethingstable-and-constant中，然后将该模块部署到其他位置到其客户端.
如果您仍然希望将其用于部署，请检出 git -钩子.您可以设置一些挂钩(例如更新或预先接收)，以在分支更新时自动提取代码.
另一种选择是将所有共享目录更多地存储到云存储服务或基于文档的NoSQL服务器中.它可以帮助您维护一个所有人都可以从中获取的单一来源.这将不是完美的，最终的一致性将在这里和那里引起很少的麻烦，但是值得这样做.对于仅在客户端磁盘上的文件很重要的情况，我只建议不要这样做.
I am trying to figure out how (if possible) to set up multiple git repositories to behave in a specific way. Basically, we have multiple repositories for multiple clients, however they are meant to all share a system directory. When a change is made to the system directory for one client, it should be made to the system directory for all clients. Now for the complication, we have multiple environments that we use for a CI development system. We currently have a production environment, client rev environment, qa environment, and development environment. These translate nicely into different branches because it means that when a workflow is approved for the next environment, we can just merge that workflow branch into the appropriate environment branch and get just the changes from that workflow added into that environment.
The problem is our code structure is set up in a way that we have system directory that is our base code, a custom directory that has client specific code (including files that get used in replacement of files in the system code) and a client specific configuration directory. Note we are not on an object oriented system which makes development even more complicated because there's no inheritance or extensions to make customizations easier.
Our goal is to convert this development system into GIT. The problem we're having is maintaining that shared system directory. We've tried submodules, but submodules require a lot of maintenance to prevent overwriting or mispointing them and don't work quite as well with permanent environment branches because of the excessive tedious amount of work to make sure that the client qa branch is always pointing to the lead commit of the qa branch in the system submodule and not to a lead commit in a WF branch.
Our current IDE is eclipse which doesn't have subtree integration (though what I've read of subtrees is that they can be just as complicated as submodules). What we really need is parallel branches across multiple repositories that get propogated. So for example if I make a workflow branch in a client repo, a WF branch gets made in the system repo and in all other client repos. And when I make a change and merge that workflow into qa, the system repo's wf branch also gets merged into the qa branch, but only with the changes to the system folder, and not changes that were made to the custom and config directories.
I was wondering if there is a good structure to make something like this work. Everything I've read on other sites and sources has said the solution is just don't do it that way, however that decision is not made by me. The higher ups are determined to keep our current development system.
One thought I had is to see if there's a way to do something like a passthrough where we create a repository that has just the system module. Then for each client we clone that repo and add the custom and config directories. Then when we do development we clone that client's repo. I was wondering if by this method, if we made a change and committed and pushed to upstream, if this would push changes all the way to the top level repo. Also when we pull down changes, if we could pull all the way from the top level repo. The other side of this would be having to set up .gitignore in the client repos in such a way that when pushing up stream it ignores the custom and config directories but when pulling downstream it includes those directories.
Any thoughts on this will be appreciated. Also our code host is a private gitlab server.
Sorry this is so long, but I feel we have a very unique (not good) system that requires a bit of explanation.
Future Git User
This seems more like an organization and architecture problem than git issue but I'll give it a go.
Rather than creating a repo, have you considered creating a branch for each client and then do merge/pull as you need and then push.
Deploying via git is not recommended, git is not a great way to deploy. Its design to be open, record changes and make sharing of code easy so if someone accidentally commits credentials, they are recorded forever unless you do some crazy things (and these crazy things will break the code for everyone else). Most sane users use git to commit and share their changes, build a specific branch into a module/pkg/image/container/something-stable-and-constant and then deploy that module elsewhere to their clients.
If you still wish to use it for deployment, checkout git-hooks. You can setup some hooks (e.g update or pre-receive) that automatically pull the code when the branch is updated.
Another alternative would be more all of the shared directory into a cloud storage service or document-based NoSQL server. It helps you maintain a single source that everyone can fetch from. This won't be perfect and eventual consistency will cause few troubles here and there, but will be worth it. I'd only advise against it for cases where files being on the client's disk right-away is important.
这篇关于在存储库git上同步变体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
