什么是子模块叉的良好工作流程

Question

假设我们在github上有以下存储库结构:

company:project.git
  \- company:submodule.git

我公司的开发人员分配公司项目,使他的工作区看起来像这样:

developer:project.git
  \- company:submodule.git

对于90%的开发人员来说这很好,因为他们不更改子模块库,他们只在项目中工作.现在假设有一个新功能需要改进子模块.负责此操作的开发人员将他的工作空间转换为:

developer:project.git
   \- developer:submodule.git

到达那里并不简单,因为他需要用另一个子模块替换子模块(对于git,子模块的原始和分支是两个不同的东西).

如果这个开发人员在库上工作了一段时间,他会将这个结构提交给他的主分支,所以他在github上的fork总是使用forked子模块.

一旦他准备好开发,他就会创建一个拉取请求.问题是,合并拉取请求时,主存储库将如下所示:

company:project.git
   \- developer:submodule.git

这是有问题的,因为现在每个跟踪公司分支的开发人员都会得到开发人员的子模块.

要解决这个问题,在开发人员提出拉取请求之前,应该将他的主分支移回公司:submodule.git - 这非常尴尬,特别是因为在本地他总是仍然想要使用developer:submodule.饭桶.

我们已经尝试了几个工作流程,而上述问题是我们唯一没有良好工作流程的问题.

Answer 1

当开发人员使用特定版本的子模块创建提交时,这是一个强大的声明,即超级模块与该确切版本的子模块一起工作.如果他的代码确实与公司的子模块版本一起使用,我认为正确的做法是让开发人员:

1. 分支超模块
2. 签出子模块中的公司版本
3. .gitmodules如果开发人员从上游版本更改了该模块,则在超级模块中更新
4. 阶段并承诺改变
5. 测试一切
6. 发出拉取请求

然后他可以切换回超模块中的正常开发分支.

我不明白你的问题有以下几点:

到达那里并不简单,因为他需要用另一个子模块替换子模块(对于git,子模块的原始和分支是两个不同的东西).

相反,子模块可以是任何git存储库,只要它包含超模块指向的提交即可.如果有两个不同的远程存储库,他只需在子模块中添加一个额外的远程存储库.(.gitmodules如果他们要与其他任何人共享他们的存储库,开发人员也应该改变.)

在回复下面的评论时,或许有必要了解如何将子模块从指向一个版本切换到另一个版本.假设开发人员正在使用他们自己的存储库来存储超级和子模块,但这些存储库都是从公司的版本中克隆出来的(即大部分历史都是相同的),并且子模块位于路径上lib.开发人员现在想要切换子模块以指向公司的版本.他们可以做到以下几点:

1. 编辑url子模块的参数.gitmodules以指向公司的存储库.
2. cd lib
3. git remote add company developer@company:/srv/git/lib.git
4. git fetch company
5. git checkout -b upstream-master company/master
6. cd ..
7. git add .gitmodules lib
8. git commit -m "Switch the lib submodule to point back to the company's version"

git checkout <whatever>一旦设置了远程和分支,就可以将步骤3到5更改为.