5

问题总结：

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

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

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

细节：

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

我最近开始使用私有 BitBucket Git 存储库作为 Master 的远程，因此我可以轻松地将代码传输到其他地方或从其他地方传输代码。工作流程是这样的：

  • 在工作中，来自 SVN Trunk => Local Work Master 的 Rebase。
  • 从本地 Work Master => BitBucket Master 推送。
  • 在家里，从 BitBucket Master => Local Home Master 拉取。
  • 在家编写代码，分支，合并，享受 git。
  • 从本地家庭分支合并 => 本地家庭主。
  • 从本地 Home Master => BitBucket Master 推送。
  • 在工作中，从 BitBucket Master 拉到 Local Work Master。
  • 针对 SVN 主干变基。
  • 向 SVN 提交。

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

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

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

但是，假设我们中的一个人已经做到了这一点，那么团队中的其他人会发生什么？如果他们从 BitBucket Master 中提取，他们将获得更改。但是，如果他们从 SVN 变基，他们也会得到更改。

如果两者都做会发生什么？这只是一个可能的障碍。我能想到其他的步骤，如果这一切都可能陷入真正的混乱。

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

4

2 回答 2

3

看看为那些想要同时使用 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:ignore 翻译成 .gitignore
  • git-svn 不能正确处理行尾（即不尊重 svn:eol-style）
  • git-svn 不翻译匿名 Git 分支，这些分支中的提交永远不会进入 SVN
  • git-svn 并不总是将 Git 合并提交正确转换为 SVN svn:mergeinfo 更改
  • git-svn dcommit 在 Git->SVN 翻译时不保留 Git 提交中的日期...

git-svn 的优点是有可能将 Git 镜像保存在另一台机器上；但它通过并发安全来支付这一点（在同一台机器上是在短时间内锁定 SVN 和 Git 存储库的条件）。

于 2012-07-14T14:08:49.293 回答
1

将 git 服务器与 svn 存储库同步并非易事。如果你想使用两台服务器，一台使用 git，一台使用 subversion，你会遇到问题：

  • Subversion 不像 git 那样理解分支。如果您在分支之间的 git 中进行了几次合并，这也可以传递给 svn。但是对于颠覆来说，一切都发生在一个分支中，因此在不丢失信息的情况下不可能进行反向操作。
  • 当您 dcommit 时，您的更改将被重新设置。这意味着提交获得了新的 sha。如果您将更改从 subversion 合并回 git，git 会感到困惑。

我尝试在工作中进行相同的同步（我们在构建过程中也被绑定到 svn），经过一些试验，我发现可靠的工作是使用每个人都使用的 git 服务器，并同步更改进行颠覆，以便您使用的詹金斯或集成服务器也可以获得最新的更改。实现这一点的最简单方法是仅在一个方向上同步，git -> svn。这意味着没有人提交 svn（除了 git sync 进程）。

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

于 2012-07-14T13:10:26.510 回答