3

在工作中，我们使用 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 散列，并确保仅备份每个文件的唯一版本。诀窍是所有备份存储库都必须是同一存储库的一部分才能获得空间效率。

问题是当两个拥有完全不同分支的人为他们的分支选择相同的名称时。EG 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 钩子中记录的推送钩子在之后立即重写 ref 的名称它写了，然后可以在回来的路上做一些事情来扭转这个过程，但它感觉很脆弱。有人有更好的主意吗？

编辑：对于 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"
    }
}
4

2 回答 2

2

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

如果您运行此命令：

git push omni-backup feature:bob-feature

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

于 2010-07-13T20:06:26.753 回答
1

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

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

然后我会生产一些不错git archive的东西omni-backup并将其存放起来。

于 2010-07-13T20:01:53.377 回答