【发布时间】: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命名空间是我真正想到的。