我有一个项目，我们正在推出v1，并开始在v2上工作。我担心在接下来的几个月里我们会看到错误修复和v1的小功能更改，其中一些我们需要进入v2，其中一些我们需要保持分离。 （我们需要维护v1的主要功能集，但修复发现的任何错误。）
我们目前正在使用SVN。我考虑过改用Git，但我不太愿意改变工具。除了这种可能性之外，哪些一般策略和最佳实践能够尽可能简单地管理这种情况？
更新：每个人都建议我在Subversion中分支代码。对我来说这是显而易见的，我认为这是“我们正在使用SVN”声明所暗示的。显然不是。 :)不过，我会看看Mercurial和Bazaar以及Git。还有什么吗？
答案 0 :(得分：5)
使用SVN，您可以做的最好的事情是分支您的存储库：
答案 1 :(得分：3)
我们正在使用TFS，但针对您的具体问题，解决方案将非常相似：创建一个新分支
[根据您使用的应用程序环境，显然不是Microsoft]
我们从TFS中获益，因为：
答案 2 :(得分：2)
对于不同版本，最佳做法是将命名版本存储在“tags”子文件夹中。 （SVN文档建议您为每个项目都有一个trunk，tags和branches文件夹。）
每当您发布版本时，请将主干复制到tags文件夹并为其命名。该版本可以继续使用，并且可以单独对其进行错误修复并来回合并。
关于存储库布局的SVN文档：
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html
答案 3 :(得分：0)
您应该使用SVN来标记v1代码。这样，您就可以创建一个单独的代码分支来支持对该代码库的修复。
答案 4 :(得分：0)
一旦v1分支被冻结，您是否考虑过分支您的主干并在第二个分支上进行v2开发？如果您修复影响v1的v2分支上的错误，并且您想要发布v1的更新/补丁，只需将这些特定更改合并回v2分支的v1分支。
所有这一切在SVN中都是完全可行的，但使用Mercurial或Git等工具进行分支管理要容易得多。我不能告诉你它是否值得切换，因为我不了解你的公司或代码库，但是如果你能够预见到将来会出现更多版本时反复出现这种情况，那就需要考虑。
答案 5 :(得分：0)
使用 git ，您可以使用以下方法：
您的git存储库可以包含以下分支。每个修补程序分支都包含必须维护的功能版本。
master - version: 3.0.0 (latest release)
\
dev - version: 4.0.0 (next release)
|\
| hotfix-1.x - version: 1.0.1 (current hotfix 1.x)
\
| hotfix-2.x - version: 2.0.1 (current hotfix 2.x)
\
hotfix-3.x - version: 3.0.1 (current hotfix 3.x)
修正：
错误修正在hotfix-1.x中进行并合并＆＃34; up＆＃34;到hotfix-2.x并从那里到hotfix-3.x.
hotfix-1.x - ＆gt; hotfix-2.x - ＆gt; hotfix-3.x ...
也可以使用git the cherry-pick命令从hotfix-3.x到hotfix-1.x（如果需要）向后移植错误修正。使用cherry-pick命令，可以选择一个提交并将其应用于不同的分支。 Git还会检测已移动和重命名的文件，并仍然正确应用更改。
您还可以将版本分支并行添加到修补程序分支，以便在这些分支中准备版本（本示例中省略）。当您不想阻止新修订的修补程序分支时，这非常有用。如果您想了解有关修补程序和发布分支的详细信息，请结帐gitflow。
功能发布：
新功能基于dev分支，并在完成后合并回dev分支。为每个新功能版本创建一个新的修补程序分支。
步骤：
备注：
我认为当您决定保留修补程序分支时，主分支不再是非常重要的。我相信常见的gitflow方案的工作原理是，一旦完成，您就会删除修补程序分支并释放分支。您的发布应全部标记，因此可以访问。