使用子模块创建公共回购协议 [英] creating a public repo with submodules

问题描述

我想创建一个包含多个子模块的公开回购（裸回购）。我希望不同的人克隆这个裸回购，做任何子模块的变化。更新公共回购。但是，我意识到这是非常痛苦的。我想我的回购如下所示：

我有四个独立回购。 a.kernel b.rootfs c.apps d.modules。我把它们合并成一个叫做build的superepo。从这个superepo，我做了一个裸露的repo build.git，在人们之间共享。

现在，如果有人克隆裸回购并对内核子模块进行更改，那么他必须执行以下操作才能将更改推送到公开裸回购。
$ b

1. 将它提交到本地克隆中的kernel，repo。


2. build，superepo在本地克隆中。
   
3. 将其提交给公共库中的kernel子模块。
   
4. 将其提交到build ，public superepo。


5. 取消build.git，public裸回购中的更改。
   

这一切都是痛苦的。这有点击败了我将4个回购券捆绑到1个超级宝宝的目的。有没有更好的方法去解决它。 （我假设要这样做的用户是可信任的，并且可以任意混淆）。

其他开发人员不需要克隆 build 以便更改其他独立回购。他们的工作流程应该类似于这样：

• 克隆 apps 。


• 更改应用程序。


• 将提交提交到服务器。 b

然后，你（或更好的，定期的或CI进程）只需执行 git子模块更新在 build repo然后build。

请注意，开发人员在任何时候都不得不承诺甚至可以触及） build repo。

在这个例子中，每个子模块应该是一个完全独立的存储库。如果它们不是（也就是说，如果您必须修改 build 以便在子模块中应用任何更改），那么它们不应该是子模块，而应该是<$ c的子目录$ c $> build 。

如果开发者需要在本地构建，他们应该执行以下操作：

• 克隆 build


• 编辑.gitmodules以指向每个子模块repo


• 运行 git子模块同步以将更改应用于.gitmodules

现在，他们的本地副本 build 指向其子模块的本地副本，而不是有福的服务器副本。这意味着他们可以使用 build 来测试构建整个项目，包括其本地更改，而不会影响服务器上的稳定代码。 但是，用户不需要（或推荐）将 build 中的这些更改推送到服务器。使用GitHub可以防止事故不要将其他开发人员的公钥添加到 build 回购中。

I wanna create a public repo (bare repo) which contains multiple submodules. I want different people to clone this bare repo, do the changes in any submodules. Update the public repo. However, I realized this is quite painful. I want my repo to look like below:

I have four independent repos. a.kernel b.rootfs c.apps d.modules. I combine them into one superepo called, "build". From this superepo, I make a bare repo build.git which is shared across people.

Now if someone clones the bare repo and makes changes in the "kernel",submodule, then he has to do following things to push the changes to the public bare repo.

1. commit it to "kernel",repo in the local clone.
2. commit it to "build",superepo in the local clone.
3. commit it to "kernel", submodule in the public repo.
4. commit it to "build", public superepo.
5. pull the changes in the build.git, public bare repo.

Doing all this is painful. It kind of defeats my purpose of bundling 4 repos into 1 superepo. Is there a better way to go about it. (I assume users who are gonna do it are trusted and are allowed to mess with anything.)

解决方案

I'm interested to see other answers to this, but I fear that you're overcomplicating things a bit.

It is not necessary for other developers to clone build in order to make changes to the other independent repos. Their workflow should look similar to this:

• Clone apps.
• Make changes to apps.
• Push commits up to the server.

Then, you (or better, a periodic or CI process) simply have to do a git submodule update on the build repo and then build.

Note that at no point should the developers have to commit anything to (or even touch) the build repo.

In this example, each submodule should be a completely self-contained repository. If they are not (meaning, if you have to modify build in order to apply any changes in the submodules), then they should not be submodules but rather subdirectories of build.

If the developers need to build locally, they should do the following once:

• Clone build
• Edit .gitmodules to point each submodule at their local repo
• Run git submodule sync to apply the changes to .gitmodules

Their local copy of build now points at their local copies of the submodules, rather than to the 'blessed' server copy. This means that they can use build to test build the entire project including their local changes without affecting the stable code on the server. But, it is not necessary (or recommended) for the users to push these changes in build up to the server. With GitHub you can prevent accidents by not adding the other developers' public keys to the build repo.

这篇关于使用子模块创建公共回购协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！