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

Question

问题摘要：

当我写下这篇文章时，我意识到有很多细节，下面是标题：

• 对于在工作环境中使用SVN和Git但又希望使用远程Git (BitBucket)从工作环境外部访问相同代码、在外出时共享对此代码的更改、然后在返回办公室时安全地重新构建SVN的多个用户团队来说，什么是一个好的工作流？当其他人继续在办公室内本地使用Git SVN的时候？

在写这篇文章时，我也意识到我要求做的事情非常复杂，可能根本不可能.

The Detail:

我和一个使用SVN存储库的团队一起工作。我们中的许多人已经开始使用Git SVN，现在正在收获以下好处:在本地使用Git，随心所欲地分支，必要时合并到本地大师中，然后再返回SVN。这很好(虽然我意识到我们并没有从纯Git解决方案中获得所有的好处)。

最近，我开始使用一个私有的BitBucket作为Master，这样我就可以轻松地将代码从其他地方传输到其他地方。工作流程如下：

• 在工作中，从SVN中继=>本地工作母版进行重基。
• 来自本地工作大师=> BitBucket母版。
• 在家里，从BitBucket母版=>本地家庭母版拉出。
• 在家做编码，分支，合并，享受git。
• 从本地主页分支合并=>本地主页母版。
• 从本地家庭母版=> BitBucket母版推送。
• 在工作中，从BitBucket硕士拉到本地工作硕士。
• 对SVN干线进行重基。
• 到SVN去。

好吧，有几个步骤，但对我来说效果很好。但是，我的一些同事想要开始做同样的事情。更重要的是，我们希望能够使用我们的BitBucket Git回购没有障碍的SVN。

一些我们正在考虑的事情的例子：

• 如果我们中有一个人不在办公室，他们希望能得到最新的代码。在工作中，我可以从SVN重新建立基础，然后推到BitBucket，使我的同事可以使用最新的代码。
• 如果我们中的两个人想要共享一些更改(假设我们中有一个或者两个都不在办公室)，我们可以在BitBucket上为它创建一个特性分支，每次推送并在必要时提取它。
• 当我们满意它时，我们中的一个可以将它合并到我们的本地家庭母版中，然后推送到BitBucket母版，准备好在我们工作的时候拉它。
• 一旦回到工作中，我们中的一个人就可以将Master从BitBucket中拉到我们的本地工作母版，然后像往常一样对SVN和dcommit进行重基。

但是，假设我们中的一个已经做了这件事，那么这个团队的其他成员会发生什么呢？如果他们从BitBucket大师那里撤出，他们就会得到改变。但是，如果他们从SVN重新基地，他们也会得到改变。

如果他们两者都做了呢？这只是一个可能的障碍。我可以想到其他的步骤，如果这一切都可能陷入真正的混乱。

不幸的是，我们的持续集成工作流与SVN联系在一起，业务的其余部分也是如此。因此，我们没有真正的选择，移动到Git的整体。我们也不能从公司外部访问我们的SVN存储库。

Answer 1

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

$ subgit install path/to/svn/repository

然后，为存储库创建一个Git接口。对Git存储库的每一个推送都被转换为SVN，反之亦然。您只需设置对新创建的Git存储库的访问。

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

• 并发问题:如果有人同时使用SVN和Git，那么存储库的历史就会分道扬镳(SubGit关心并发)；
• git-svn存储库只允许类似svn的概念(例如，它不允许有Git子模块- "git svn dcommit“删除本地添加的子模块)
• git-svn不将svn:忽略转换为.gitignore
• git-svn不能正确处理行尾(即不尊重svn:eol-样式)
• git-svn不翻译匿名Git分支，在这些分支中提交永远不会进入SVN
• git-svn并不总是将Git合并提交转换为SVN svn:mergeinfo更改正确。
• 当Git->SVN翻译时，git-svn提交不保留日期。

git-svn的优点是有可能将Git镜像保存在另一台机器上；但这是以并发安全性(在同一台机器上的条件是将SVN和Git存储库锁定一段短时间)。

Answer 2

将git服务器与svn存储库同步不是一件容易的事情。如果您想使用两台服务器，一台带有git，另一台带有subversion，那么您将遇到以下问题：

• Subversion不像git那样理解分支。如果在分支之间进行git中的几次合并，这也可以传递给svn。但是对于subversion来说，一切都发生在一个分支中，因此在不丢失信息的情况下不可能发生相反的事情。
• 当您开始提交时，您的更改将被重新基于。这意味着提交将得到一个新的sha。如果将更改从subversion合并回git，则git会被混淆。

我在工作中试图实现同样的同步(在构建过程中我们也绑定到svn )，在进行了一些实验之后，我发现可靠的工作方法是使用git服务器(每个人都使用)，并同步subversion的更改，这样jenkins或您使用的集成服务器也可以获得最新的更改。实现这一点的最简单方法是只在一个方向同步，git -> svn。这意味着没有人提交svn (除了git同步进程)。

如果这个解决方案对您有用，我记录了我是如何做到的，并构建了几个脚本来自动完成它。你可以找到它，在这个岗位上。