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

Question

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

5

问题概述：

我们有一个使用 SVN 仓库的团队。我们中的一些人已经开始使用 Git SVN，并且现在正在享受本地使用 Git 的好处，随意分支，必要时合并到我们的本地主干，然后提交回 SVN。这很有效（尽管我意识到我们没有获得纯 Git 解决方案的所有好处）。

我最近开始将私人 BitBucket Git 存储库用作主干的远程存储库，以便可以轻松地在其他位置之间传输代码。工作流程如下：

1. 在工作中，从 SVN 主干重新定义 => 本地工作主干。 2. 从本地工作主干推送 => BitBucket 主干。 3. 在家里，从 BitBucket 主干拉取 => 本地家庭主干。 4. 在家中编写代码，分支，合并，享受 Git。 5. 从本地家庭分支合并 => 本地家庭主干。 6. 从本地家庭主干推送 => BitBucket 主干。 7. 在工作中，从 BitBucket 主干拉取到本地工作主干。 8. 重新定义与 SVN 主干的差异。 9. 提交到 SVN。

详细情况：

我们希望找到一个适合许多用户的团队的良好工作流程。他们在工作环境中使用 SVN 和 Git SVN，但是还想使用远程 Git 存储库（BitBucket）从工作环境外访问相同的代码，彼此之间共享对这些代码的更改，然后在回到办公室时安全地重新定义为 SVN。而其他人仍然在办公室内本地使用 Git SVN？

我们正在考虑以下一些事例：

1. 如果我们中有人不在办公室，他们希望能够获得最新的代码。在工作中，我可以重新定义 SVN 然后推送到 BitBucket，使我的同事可以使用最新的代码。 2. 如果我们中的两个人想要共享一些更改（假设其中一个或两个人都不在办公室），我们可以在 BitBucket 上为此创建一个功能分支，并根据需要进行推送和拉取。 3. 当我们对其感到满意时，我们中的一个人可以将其合并到我们的本地家庭主干中，然后推送到 BitBucket 主干，准备好在我们回到工作时进行拉取。 4. 回到工作后，我们中的一个人可以从 BitBucket 拉取主干到我们的本地工作主干，然后重新定义与 SVN 的差异并提交，就像往常一样。

假设我们其中一人已经完成了这个任务，那么团队的其他成员会发生什么？如果他们从BitBucket Master拉取代码，他们会得到修改后的代码。但是，如果他们从SVN上进行rebase操作，他们也会得到更新后的代码。

如果他们两者都做了呢？而且这只是可能出问题的其中一种情况。我可以想到其他几组步骤，这些步骤也可能让整个过程变得混乱。

不幸的是，我们的持续集成工作流与SVN绑定在一起，整个业务也是如此。因此，我们实际上不能完全转向Git。我们也无法从公司外部访问我们的SVN存储库。

- Holf

我们团队也面临着同样的问题，这是因为我们正在从svn过渡到git，而svn存储库将消失。我们将拥有一个与svn一样公开的git存储库，并且我们的持续集成工作流程可以转移到git上。如果我是你，我会更加努力地尝试从svn转移到git，而不是同时维护两者，对我们来说同时维护两者非常痛苦。 - jolivier

是的，我同意，如果能够转移到Git上，那将会简单得多。 - Holf

2个回答

1

同步git服务器和svn存储库并不容易。如果您想使用两个服务器，一个用于git，另一个用于subversion，那么您将遇到问题：

- Subversion无法像git一样理解分支。如果在git之间进行了几次合并，则可以将其传递给svn。但是对于Subversion来说，所有事情都发生在一个分支中，因此反向操作将丢失信息。 - 当您执行dcommit时，您的更改会被重新基于。这意味着提交会获得新的sha。如果您将更改从subversion合并回git，则git会感到困惑。

我曾经试图在工作中实现相同的同步（我们也被绑定到svn进行构建过程），经过一些尝试后，我发现可靠的方法是使用由所有人使用的git服务器，并将更改同步到subversion，以便jenkins或您使用的集成服务器也可以获取最新更改。实现这一点的最简单方法是仅单向同步，即git-> svn。这意味着除了git同步进程外，没有人提交到svn。

如果这个解决方案对您有用，我记录了我是如何做到的，并构建了一些脚本来自动完成它。您可以在此帖子中找到它。

- Mario F

这看起来很棒。我一定会试试看。 - Holf

我研究了一下，如果你能保证没有人会触碰Subversion Repo，那么这是一个很好的方法。不幸的是，在我们的环境中，我们无法做到这一点。我们需要一些用户能够像往常一样继续使用Subversion。 - Holf

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dmitry Pavlenko · Accepted Answer

请看SubGit项目，该项目旨在为那些想同时使用Git和SVN存储库的人提供帮助。如果您可以访问您的SVN服务器，只需运行

SubGit

$ 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合并提交翻译为SVN svn:mergeinfo更改
git-svn dcommit无法保留Git提交中的日期，而Git->SVN翻译可以...

git-svn的优点是可以在另一台机器上保留Git镜像；但它为此付出并发安全的代价（在同一台机器上是锁定SVN和Git存储库以进行翻译的短时间条件）。