创建子Git存储库

时间:2018-12-14 14:28:24

标签: git

我有一个称为Template的TFS GIT存储库。我们想要从中创建多个子存储库,然后能够将更改从父存储库推送到子存储库。

顺序为:

第1部分

  1. 完成模板的设置并将其标记为v1。
  2. 创建子存储库App1
  3. 将模板放入App1

第2部分-将来的某个时刻

  1. 对模板进行更改并将其标记为v2。
  2. 将标签v2推送到App1中。

我环顾四周,找不到完全实现第二部分的方法。有什么想法吗?

1 个答案:

答案 0 :(得分:0)

虽然我认为这是一个相对罕见的用例,这是共享代码的最佳方法,但让我们看看它会发生什么。

如果您希望Template存储库将更改推送到App1存储库,则需要在Template内将App1配置为远程服务器。

/repos/template $  git remote add App1 url/of/app1/repo

然后Template就像贡献给App1的任何本地存储库一样。这意味着每次您基于模板创建新的应用程序存储库时,都必须将其添加为Template存储库中的另一个远程存储库。还要注意,git push一次只能与一个远程控制器交互,因此您可能希望将一个脚本组合在一起,以将更新推送到所有应用程序存储库。

(顺便说一句,这感觉很落后-我认为您最好将Template设置为每个应用程序仓库的远端,并设置每个应用程序仓库来监视,pull,与Template相比有所改变,这似乎是一种git友好的方式来执行您要尝试的操作-当我们继续描述push流程如何真正起作用时,这将反映在复杂性中。但是,如果您需要推送过程,则可以通过将应用程序存储库视为远程对象来Template“贡献”每个应用程序存储库。)

现在情况是,push 不能执行合并。因此,您需要为每个应用程序回购创建一个分支,当Template推送到该分支时,该分支仅前进 ,然后仍然需要有人将这些更改合并到所使用的分支中用于对应用程序进行本地更改。从Template推送到应用程序存储库时,必须确保将新的更改推送到应用程序存储库的模板分支。

实际上,不管使用基于push还是基于pull的机制,最好都具有这样的分支。唯一的不同是Template驱动分支的更新方式。但是,如果使用基于拉的模型,则每个存储库将负责其单个模板分支与模板存储库的上游关系,而不是必须维护的模板存储库(和/或向其发出的推送命令)所有模板分支关系。

无论如何,然后在App中您会遇到类似的情况

T0 <--(template)
  \
   A -- B <--(master)

一段时间后,您在Template回购中进行了一些更改,并将push的更改App到了template分支

T0 -- T1 <--(template)
  \
   A -- B <--(master)

然后有人将template合并为master并解决所有由此产生的冲突。

T0 ------ T1 <--(template)
  \         \
   A -- B -- M <--(master)

这可以根据需要重复。当然,如果应用程序仓库中有多个分支,则需要弄清楚如何将新模板更改传播到每个分支。如果每个分支中有许多分支和冲突需要解决,那可能会变得很乏味(尽管您可以利用git rerere来减少麻烦)。这就是为什么我认为,找到一种方法来分离通用代码并使用构建系统将其视为依赖项,而不是基于pushpull的方案,可能会更好。对于您正在处理的常见代码类型,这很实用。