我在github上托管了一个具有以下结构的项目
github.com/example/allpackages
.
├── .git
└── packages
├── example-1
├── example-2
└── example-3
在每次推送到github时,我希望每个包的内容都被推送到一个对应于回购名称的仓库,例如。
github.com/example/example1
.
├── .git
└── example1
github.com/example/example2
.
├── .git
└── example2
等
任何人都对如何自动化有任何想法?有人提到使用Travis-CI执行此任务,但我找不到任何有关如何工作的细节。
我理想的解决方案:
非常感谢任何有关开始研究的指导。提前谢谢!
编辑:
@VonC建议使用子模块,并使用git submodule foreach --recursive
优点:
git submodule foreach --recursive
允许对多个子模块进行单次提交缺点:
git submodule foreach --recursive
很麻烦,并不像常规提交一样优雅。针对此特定用例。 “包裹”repos例如github.com/example/example1
只会在某种意义上被读取。我不会直接向他们推。他们只会在allpackages
更新时收到更新。需要创建它们的唯一原因是因为使用它们的包管理器需要为每个包分开回购。
答案 0 :(得分:3)
如果您将所有exampleX
个文件夹声明为git repos,并将其设为allpackages
的父级回复exampleX
,则:
每个cd allpackages
git push --recurse-submodules=on-demand
个回购在GitHub上都有自己的 submodules
(upstream repo),你可以将每个人都推到他们各自的回购
{{1}}
一个命令,所有被推送。
答案 1 :(得分:2)
Github不会运行repo hooks。设置一个带有更新后挂钩的github代理仓库,它会调整this answer中的自动跟踪,然后转发推送,就像我读到的那样,它将满足规定的要求。
虽然如此,我和VonC在一起。如果你不使用子模块,你就会被这样的东西困住 - 而且实际上,它只不过是脆弱的,残缺的,隐形的子模块,只适用于那个回购,一旦有人推动就会保证会破坏除了代理之外的任何地方。对于你自己的工作来说,在一个私人仓库中可以非常方便,并且有很多方法可以将这个脆弱性推向更远的地方,但是对于一个共同的学科来说,它还不够健壮。
对于共享工作,我打赌你迟早会转到子模块,发现它们并不是很神秘。所以请忽略这一点并接受VonC's answer: - )
答案 2 :(得分:1)
我仍然喜欢干净"submodule" approach I recommended earlier。
但另一种将repo的一个文件夹推送到独立upstream repo的更为hackish的方法是使用嵌套repo 技术:
cd myrepos
git clone https://github.com/example/example1
git clone https://github.com/example/allpackages
cd allpackages/packages/example-1
git --git-dir=../../../example1/.git add .
git --git-dir=../../../example1/.git commit -m "commit for example1"
git --git-dir=../../../example1/.git push
对于example1 GitHub repo,可以考虑allpackages/packages/example-1
:--git-dir
的工作树使得Git认为allpackages/packages/example-1
是一个(嵌套的)git repo,它有一个远程'origin
'引用GitHub。
但是:这意味着3种不同的推送命令,除非你wrap those commands in a script and call that scripts through an git alias:
git config alias.pushall '!sh pushall.sh'