0

现在我的项目 v1（生产中）在 Trunk 中，而 v2（开发中）在 SVN 的一个分支中。v2 不太可能合并到 v1 中。

我想在不久的将来迁移到 Git，因为在 SVN 中在 v1 和 v2 之间切换非常慢，而分支驱动的开发在 SVN 中是一个痛苦。

我正在考虑使用本地 Git 存储库并暂时使用git svn，稍后在团队准备好时将 Git 存储库推送到集中式服务器。

dcommit如果我想在 SVN 中处理 v2 和 v2 分支，我的 git 工作流程应该如何？有没有更好的方法来同时管理 v1 和 v2？

谢谢！

更新：我正在考虑执行以下操作，请评论这是否是个好主意：

  1. SVN 分支头到 /branches/v1
  2. git rebase 分支/v2 在 master
  3. git svn dcommit 到主干
  4. 继续在 Master（主干）上工作

你怎么看？

4

1 回答 1

3

最好的办法是让每个人尽早迁移到 git。它只是更好地处理这样的事情。Git svn 并不是为很好地处理分支而设计的，虽然它有时可以工作，但它确实不是那么安全。恕我直言，但我不是一个 git 开发人员，我只是从尝试它和痛苦的经验中说出来。对我来说，如果上游（您自己、您的团队或其他人）可以转换为 git 总是容易得多。突然间，问题就消失了。

将来，您可以像我在Net-SNMP 转换为 git 和分支管理中所做的那样：合并所有内容，并使用 -s ours 将 v1 项目初始合并到主开发分支中。这基本上将版本历史设置为忽略新分支之间所有过去的开发差异，但允许您将新补丁应用到 v1 到树中，并且仍然将这些新补丁合并到 v2 中。这样，在 Net-SNMP 中，我们通常有 4-5 个活动分支。补丁进入最古老的最相关的分支并向上合并。突然间，我们不再有记住将补丁应用到每个分支的问题了！

简单的 git 包装脚本自动执行多分支补丁管理，整个工作几乎是无害的。只有一些主要的架构更改会引起轻微的麻烦，并且需要手动合并/移植。

于 2013-01-30T00:12:18.857 回答