高度耦合的git子模块 [英] Highly coupled git submodules

问题描述

我有一个需要拆分为两个存储库的项目：一组通用模型，以及基于这些模型的模拟和附加代码。最终可能会有多个模拟使用同一组模型，因此将它们放在单独的存储库中是一个明确的要求。显而易见的解决方案是将通用模型作为模拟的子模块。

不幸的是，这两个存储库将非常高度耦合。人们会非常频繁地将一些东西添加到他们的通用模型中，然后立即在模拟中使用它。我想这会在模拟回购的整合过程中造成很多麻烦。为了合并模拟中许多开发人员的更改，集成人员必须在公共模型子模块中进行并行合并。另一方面，它也使得使用子模块非常重要 - 仿真真的需要来知道它应该使用哪个版本的通用模型。

该项目由相当数量的人工作。大多数开发人员对git只有非常粗略的了解：他们添加文件，提交并从源头拉取很多内容，并希望拥有一个dev和stable分支。整合者自然学到了更多，但涉及子模块的任何事情对他来说肯定是新的。额外的奖励：我即将休假一个月，所以我将无法扑灭任何火灾。结果是有很多动力使工作流真正很难搞砸，并最大限度地减少与以前工作流程的差异。

所以，我的问题是：我会后悔推荐我们为此使用子模块？ （有没有更好的想法？）我可以期待人们犯下什么样的错误，所以我可以提前警告他们？有什么好的工作流程策略需要记住？

编辑：我刚刚遇到 git奴隶，这在这方面也值得一看。目前尚无法评估其网站上的功能/限制。

子模块是一个很好的选择确保参考涉及的不同组件的精确修订。

正如我在子模块的真实性质，您仍然可以更新任何子模块，前提是先提交它们（然后转到父回购站并提交）

然而，对于紧密耦合的模块，我会尽量避免：

我想这会让很多头疼我看不到一个中央集成过程有效地工作：它应该只记录新的快速记录-forward evolutions。

要想发生这种情况，任何希望推动任何事情的用户都需要先取消并重新绑定他的变化已经推到了那里。

开发人员更倾向于解决任何冲突和/或向他/她的同事询问他/她必须处理的一些修改的起源因为：

$



这个（pull，rebase，push）并不总是可能的。 b $ b

• 高级（不太基本的）涉及的Git操作（以及与当前工作流程不完全相同的工作流程）


• 所涉及的工作（考虑到来自其他贡献者的演变）


• 环境设置（最好设置一个额外的环境，就是制作这个rebase，它又是不那么基本的）

但这仍然是我想尝试的方向。

<sup>（...但是可能不是在一个月的假期之前;）

然后再次，谁需要一个所有个月的假期？！从来没有听说过这个概念）</sup>

I have a project which needs to be split into two repositories: a set of common models, and a simulation based on those models, with additional code. Ultimately there may be multiple simulations using the same set of models, so having them in a separate repository is a definite requirement. The obvious solution is to have the common models as a submodule of the simulation.

Unfortunately, the two repositories will be very highly coupled. People will be very frequently adding something to their common models then immediately using it in the simulation. I imagine this will make for a lot of headaches in the integration process of the simulation's repo. In order to merge changes from many developers in the simulation, the integrator will have to do parallel merges in the common models submodule. On the other hand, it also makes it essential to use submodules - the simulation really needs to know which version of the common models it should be using.

The project is worked on by a sizeable number of people. Most of the developers have only a very cursory knowledge of git: they add files, commit, and pull from origin a lot, and hopefully have a dev and stable branch. The integrator has naturally learned quite a bit more, but anything involving submodules will certainly be new to him. Added bonus: I'm about to take a month of vacation, so I won't be able to put out any fires. The upshot is that there's a lot of incentive to make the workflow really hard to screw up, and to minimize the difference from people's previous workflows.

So, my questions are: am I going to regret recommending we use submodules for this? (Is there a better idea?) What kind of mistakes can I expect people to make, so I can warn against them in advance? Are there any good workflow strategies to keep in mind?

Edit: I just came across git slave, which might be worth a look in this context too. Can't yet give a good evaluation of abilities/limitations beyond what's on its website.

解决方案

The submodule is a good choice for making sure to reference precise revision of the different component involved.
As I detailed in "true nature of submodules", you still can update any of the submodules, provided you commit them first (and then go to the parent repo and commit also)

However, for tightly coupled modules, I would try to avoid:

"I imagine this will make for a lot of headaches in the integration process of the simulation's repo".

I don't see a central integration process working efficiently: it should only record new fast-forward evolutions.
For that to happens, any user wishing to push anything needs to pull first and rebase his changes on top of whatever new changes were already pushed there.
The developer is more apt to solve any conflict and/or ask his/her colleagues the origin of some modifications he/she has to deal with during the rebase.

This (pull, rebase, push) isn't always possible because of:

• "advanced" (less basic) Git operations involved (and a workflow not exactly identical to the current one)
• work involved (taking into account evolutions from other contributors)
• environment setting (it can be preferable to set up an extra environment were to make that rebase, which is again "not so basic"

But that would still be the direction I would try.

^{(... but maybe not just before a one month vacation ;)
Then again, who takes a all month of vacation?! Never heard of that concept before)}

这篇关于高度耦合的git子模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！