我有以下情形:两个远程裸存储库repo1和repo2。他们应该分享一个分支,即事实上,经常推动有关特定分支的回购。这些更改应同步到repo2。同步两个裸存储库的分支
我认为,同步意味着像基于钩子或某物的自动拉动。喜欢这个。
你有一个想法,如何满足abov提到的要求?
非常感谢!
我有以下情形:两个远程裸存储库repo1和repo2。他们应该分享一个分支,即事实上,经常推动有关特定分支的回购。这些更改应同步到repo2。同步两个裸存储库的分支
我认为,同步意味着像基于钩子或某物的自动拉动。喜欢这个。
你有一个想法,如何满足abov提到的要求?
非常感谢!
设置一个将转发更改的挂钩。您可以使用四个钩子中的选项:pre-receive
,update
,post-receive
和post-update
。
在推动过程中的前两个运行,所以他们减慢速度,但可以中止它。后两者在推后运行,所以用户不必等待它们,但是它们不能中止它并需要单独的通知错误的方法。
该代码将大部分类似,很容易。简单post-update
(文件hooks/post-update
在repo1
)的变体将是:
#!/bin/sh
for ref; do
if [ refs/heads/branch-to-mirror = "$ref" ]; then
git push repo2 "$ref"
fi
done
的pre-receive
/update
需要说git push repo2 $newsha:branch-to-mirror
因为当地分支机构尚未更新。条件当然可以不同;任何能够证明该分支应该在repo2
中镜像的东西。
一个update
挂钩,中止推repo1
如果无法转发至repo2
是:
#!/bin/sh
set -e
if [ refs/heads/branch-to-mirror = "$1" ]; then
git push repo2 "$3:$1"
fi
的set -e
用于传播出现了错误的脚本。或者,|| exit 1
可以添加到应该传播的命令失败。这个钩子为每个更新的ref调用一次,所以没有循环。参数是ref名称,旧的SHA1和新的SHA1,推送需要使用新的SHA1,因为本地ref尚未更新。
非常感谢! Post-update对我来说很适合gitolite。只需添加一个符号链接并使用您的脚本。你会解释一下如何处理这个预先接收的中止钩子? –
@JohnRumpel:'pre-receive'钩子只能作为一个整体中止推送,而'update'钩子只能拒绝更新未能推送到'repo2'的引用。我认为后者更合适,所以我增加了相应的样本。 –