我有一个名为Template的TFS GIT存储库。我们希望从中创建多个子存储库，然后能够将更改从父级推送到子级。
顺序是：
第1部分
第2部分 - 在未来的某个时刻
我环顾四周，无法找到如何让第二部分发生。有什么想法吗？
虽然我认为这是一个相对罕见的用例，这是分享代码的最佳方式，但让我们来看看它需要什么。
如果你想让Template repo将更改推送到App1 repo，那么在Template中你需要将App1配置为远程。
/repos/template $ git remote add App1 url/of/app1/repo
然后Template就像任何贡献给App1的本地存储库一样。这意味着每次基于模板创建新的应用程序仓库时，您都必须将其添加为Template仓库中的另一个远程。另请注意，git push一次只与一个遥控器进行交互，因此您可能希望将一个脚本放在一起，以便将更新推送到所有应用程序回购。
（顺便说一句，这感觉很落后 - 我认为你最好让Template成为每个app repo的遥控器，然后设置每个app repo监视器，并且pull，从Template改变。这看起来更像是一个git友好的方式做你想做的事情 - 这将反映在复杂性中，因为我们继续描述push过程将如何真正起作用。但如果你想要推进过程，那么让Template“贡献”每个应用程序回购通过将应用程序repos视为遥控器是这样做的方法。）
现在的问题是，push无法执行合并。所以你需要每个app repo都有一个只在Template推送它时才会进展的分支，然后有人仍然必须将这些更改合并到用于本地更改应用程序的分支中。当您从Template推送到app repo（s）时，您必须确保将新更改推送到app repos'模板分支。
事实上，无论你使用的是基于push还是pull的机制，你最好还是选择这样的分支。唯一的区别是Template驱动的分支如何更新。但是如果你使用了基于拉的模型，那么每个repo将负责其单个模板分支与Template repo的上游关系，而不是模板repo（和/或发给它的push命令）必须维护所有的模板分支关系。
无论如何，然后在App你会有类似的东西
T0 <--(template)
\
A -- B <--(master)
在Template回购中经过一段时间你做了一些改变，你push那些变化到Apps template分支
T0 -- T1 <--(template)
\
A -- B <--(master)
然后有人必须将template合并到master并解决任何由此产生的冲突。
T0 ------ T1 <--(template)
\ \
A -- B -- M <--(master)
这可以根据需要重复。当然，如果您在app repo中有多个分支，则需要弄清楚如何将新模板更改传播到每个分支。如果每个分支和冲突都需要解决，那么这可能会变得相当繁琐（尽管也许你可以利用git rerere来减轻麻烦）。这就是为什么我认为，而不是基于push-或pull的方案，找到一种方法来分离公共代码并使用您的构建系统将其视为依赖可能会更好地为您服务，如果它对于常见类型是实用的你正在处理的代码。