git - 与多个用户一起使用 Git SVN 和远程 Git 存储库的工作流程

Question

问题总结:

当我写这篇文章时，我开始意识到其中有很多细节，所以这里是标题:

• 对于在工作环境中使用 SVN 和 Git SVN，但又想使用远程 Git Repo (BitBucket) 从工作环境外部访问相同代码的许多用户组成的团队来说，什么是好的工作流程，不在办公室时在彼此之间共享对此代码的更改，然后在回到办公室时安全地 rebase 回 SVN？而其他人也在办公室内继续在本地使用 Git SVN？

在写这篇文章时，我也开始意识到我要求做的事情真的很复杂，而且可能根本不可能......

细节:

我和一群使用 SVN 存储库的人一起工作。我们中的许多人已经开始使用 Git SVN，现在正在收获在本地使用 Git 的好处，随心所欲地分支，必要时 merge 到我们本地的 Masters，然后再提交回 SVN。这很有效(尽管我意识到我们并没有获得纯 Git 解决方案的所有好处)。

我最近开始使用一个私有(private)的 BitBucket Git 存储库作为 Master 的远程仓库，这样我就可以轻松地将代码传输到其他地方或从其他地方传输代码。工作流程是这样的:

• 在工作中，Rebase from SVN Trunk => Local Work Master。
• 从本地工作主机推送 => BitBucket 主机。
• 在家里，从 BitBucket Master => Local Home Master pull 。
• 在家编码，分支， merge ，享受 git。
• 从本地家庭分支机构 merge => Local Home Master。
• 从 Local Home Master 推送 => BitBucket Master。
• 在工作中，从 BitBucket Master pull 到 Local Work Master。
• 针对 SVN Trunk 进行 rebase 。
• D 提交到 SVN。

好的，有几个步骤，但对我来说效果很好。但是，我的一些同事想开始做同样的事情。此外，我们希望能够在没有 SVN 负担的情况下使用我们的 BitBucket Git 存储库。

我们正在考虑的各种事情的一些例子:

• 如果我们中的一个人不在办公室，他们希望能够获得最新的代码。在工作中，我可以从 SVN rebase ，然后推送到 BitBucket，让我的同事可以使用最新的代码。
• 如果我们两个想要共享一些更改(假设我们中的一个或两个都不在办公室)，我们可以在 BitBucket 上为此创建一个功能分支，并根据需要每次推送和 pull 它。
• 当我们对它感到满意时，我们中的一个人可以将它 merge 到我们的 Local Home Master 中，然后推送到 BitBucket Master，准备好在我们回来工作时 pull 。
• 一旦回到工作岗位，我们中的一个人就可以将 Master 从 BitBucket pull 到我们的 Local Work Master，然后像往常一样对 SVN 进行 rebase 和 dcommit。

但是，假设我们中的一个人做到了这一点，那么团队的其他成员会怎样呢？如果他们从 BitBucket Master pull ，他们将获得更改。但是，如果他们从 SVN rebase ，他们也会得到更改。

如果两者都做会怎样？这只是一个可能的障碍。我可以想到其他步骤，如果这一切都可能会变得一团糟。

不幸的是，我们的持续集成工作流与 SVN 相关联，其他业务也是如此。因此，我们真的没有完全迁移到 Git 的选择。我们也无法从公司外部访问我们的 SVN 存储库。

Answer 1

看看SubGit专为那些想同时使用 Git 和 SVN 存储库的人设计的项目。如果您有权访问您的 SVN 服务器，您只需运行

$ subgit install path/to/svn/repository

之后，存储库的 Git 界面就创建好了。对 Git 存储库的每次推送都会转换为 SVN，反之亦然。您只需设置对新创建的 Git 存储库的访问权限。

一些基于 git-svn 的 SVN 脚本<->Git 镜像提供了类似的功能，但与 SubGit 相比它们有缺点:

• 并发问题:如果有人同时向 SVN 和 Git 推送，存储库历史就会发生分歧(SubGit 关心并发)；
• git-svn 存储库只允许类似 SVN 的概念(例如，它不允许有 Git 子模块——“git svn dcommit”删除本地添加的子模块)
• git-svn 不会将 svn:ignore 翻译成 .gitignore
• git-svn 不能正确处理行尾(即不遵守 svn:eol-style)
• git-svn 不翻译匿名 Git 分支，这些分支中的提交永远不会进入 SVN
• git-svn 并不总是正确地将 Git merge 提交转换为 SVN svn:mergeinfo 更改
• git-svn dcommit 在 Git->SVN 翻译时不保留 Git 提交中的日期...

git-svn的好处是可以在另一台机器上保留Git镜像；但它以并发安全为代价(在同一台机器上是在短时间内锁定 SVN 和 Git 存储库一段时间的条件)。