使用分支命名空间有效地备份多个版本的 git repo

Posted 2023-03-06

【中文标题】使用分支命名空间有效地备份多个版本的 git repo

【英文标题】：Efficiently backup many versions of a git repo with branch namespacing

【发布时间】：2010-07-13 19:49:56

【问题描述】：

在工作中，我们使用 Perforce 进行版本控制。这样做存在问题：1）使用这种集中式模型，我们无法在更改准备好回归之前签入更改。这意味着我们在开发过程中没有修订控制。 2) 我们不备份仓库的客户端视图，因此在我们签入之前我们的工作是不安全的。 3) 我们在与每个人共享代码时遇到问题，除非我们请求设置一个集成分支。我正在尝试为希望使用 git 解决这些问题的开发人员设置一个可选的 git 工作流程。

计划是使用 git-p4 与 perforce 服务器交互并创建一个私有 git repo。这需要处理 1)。我计划使用 Git Pro (http://progit.org/book/ch5-1.html) 中描述的集成管理器工作流程让我们的开发人员发布公共存储库，并处理 3)。

最后，我想要一个开发人员可以推送更改的地方，以便他们可以进行夜间备份/异地备份。我们现在不备份客户视图的原因是因为对每个人的客户视图进行夜间存档备份是空间效率低下的。我们有很多开发人员，他们编写了大量代码。我们不能冗余地备份每个人的客户视图。我们只想保留他们所做的独特更改。

我的想法是拥有一个裸 git 存储库，称为 omni-backup，每个人都可以将所有分支推送到（并随时提出替代方案）。这将利用 git 节省空间的 sha-1 散列，并确保仅备份每个文件的唯一版本。诀窍是所有备份存储库都必须是同一存储库的一部分才能获得空间效率。

问题是当两个拥有完全不同分支的人为他们的分支选择相同的名称时。例如。 Bob 有一个feature 分支，Jane 有一个feature 分支，但它们用于不同的功能。如果 Bob 推送到全备份，Jane 将无法这样做，因为它不会是快进合并。

现在我最理想的情况是，当 Bob 推送他的功能分支时，该分支将在 omni-backup 远程重命名为 bob-feature。当他从omni-backup 提取功能时，他会返回bob-feature。

这在 git 中似乎并不容易实现。看起来我可以使用http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html post-receive 钩子中记录的推送钩子在它写入后立即重写 ref 的名称，然后 something 可以在回来的路上扭转这个过程，但感觉很脆弱。谁有更好的主意？

---

编辑：用于 VonC（因为代码在 cmets 中很烂） 你的方式听起来很有希望，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"
    

【问题讨论】：

我刚刚回复了您的（已删除）评论；）听起来很复杂。一个简单的 git fetch 来更新 omni-backup 的 refs/remotes/xxx 命名空间是我真正想到的。

【参考方案1】：

如果您可以让开发人员遵循某些准则，git push 可以正确地做到这一点。

如果你运行这个命令：

git push omni-backup feature:bob-feature

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

【讨论】：

当然不希望相信开发者，呵呵。但我不知道这个版本的推送，所以谢谢。

【参考方案2】：

为什么需要开发者推送到omni-backup repo？

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

然后我会从omni-backup 中生成一个漂亮的小git archive 并将其存放起来。

【讨论】：

@masonk：只要您不尝试合并分支（这可能来自两个不同的存储库但具有相同的名称可能完全不同），您应该将它们放在各自的远程存储库中name 命名空间 -- refs/remotes/xxx -- 在omni-backup repo)

是的，这基本上正是我想要的。谢谢！