使用分支命名空间有效备份许多版本的git仓库

Question

在工作中，我们使用Perforce进行版本控制。这有一些问题：1）使用这种集中模型，我们无法检查更改，直到它们准备好进行回归。这意味着我们在开发过程中没有版本控制。 2）我们不备份我们的仓库的客户端视图，所以我们的工作是不安全的，直到我们可以检查它.3）除非我们要求设置集成分支，否则我们在分享代码时遇到问题。我正在尝试为想要使用git来解决这些问题的开发人员设置一个可选的git工作流。

计划是使用git-p4与perforce服务器连接并创建私有git仓库。这照顾1）。我计划使用Git Pro（http://progit.org/book/ch5-1.html）中描述的集成管理器工作流程让我们的开发人员发布公共存储库，照顾3）。

最后，我想要一个开发人员可以推送他们的更改的地方，以便他们可以进入夜间备份/异地备份。我们现在不备份客户端视图的原因是因为每个人的客户端视图每晚进行归档备份是空间效率低下的。我们有很多开发人员，他们生成了很多代码。我们不能冗余地备份每个人的客户端视图。我们只想保留他们正在制作的唯一更改。

我的想法是有一个简单的git repo，称之为omni-backup，每个人都可以推动他们所有的分支（并随意提出替代方案）。这将利用git的空间高效sha-1散列并确保只备份每个文件的唯一版本。诀窍是所有备份存储库必须是同一个repo的一部分才能获得空间效率。

问题是，两个分支完全不同的人为他们的分支选择了相同的名称。例如。 Bob有一个feature分支，Jane有一个feature分支，但它们有不同的功能。如果Bob推送全向备份，Jane将无法进行，因为它不会是一个快速合并。

现在我理想的是，当Bob推送他的功能分支时，分支将被重命名为bob-feature遥控器上的omni-backup。当他从omni-backup中提取功能时，他会回来bob-feature。

这在git中似乎并不容易实现。看起来我可以使用http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html post-receive hook中记录的push hook在写入后立即重写ref的名称，然后可以执行某些来反转该过程。回来的路上，但感觉很脆弱。任何人都有更好的主意吗？

---

编辑：for VonC（因为代码很糟糕） 你的方式听起来很有希望，VonC，但我不知道它是一个获取的事实将击败命名空间的问题。你是否建议知道如何重命名分支的cronjob？

喜欢（真的很脏）：

foreach my $user (@users) {
    my @branches = split(/s/,cat `$LDAPSERVER/$USER/$REPO/.git/refs/heads`);
    foreach my $branch (@branches) {
        system "git fetch $LDAPSERVER/$USER/$REPO/$BRANCH:+$USER$BRANCH"
    }
}

Answer 1

如果您可以让开发人员遵循某些指导原则，git push可以正确执行此操作。

如果您运行此命令：

git push omni-backup feature:bob-feature

其中omni-backup是存储库的远程引用，然后bob的功能分支将推送到omni-backup上的bob-feature。但是如果把它委托给开发人员是不可取的，那么切换流程的方向并使用omni-backup拉动开发人员的存储库，正如VonC建议的那样，是更好的解决方案

Answer 2

为什么开发人员需要推送到omni-backup回购？

出于备份目的，我宁愿将不同开发人员的存储库注册为远程存储库，并在所有远程存储库上每晚（从git fetch服务器）执行omni-backup。 这样，没有分支名称可能串通。一个更自动化的过程（开发人员不必明确地推送他/她不直接使用的回购，但只考虑备份）

然后我会从omni-backup中产生一个漂亮的小 git archive 并存储起来。