如何在Git中实现语义版本控制？

Question

我已经能够说服我的小组使用语义版本控制并转移到git（来自CVS，所有开发都发生在主干上）。

这就是我们一直在使用的东西（版本分支表示某种新功能的引入）：

master
*
|
*   * version 2.0 branch
|  /
* *
|/
*   * version 1.0 branch
|  /
* *
|/
*
|
...

问题是，当需要在版本1.0分支上进行错误修复时，该修补程序需要回显到版本2.0和主数据库。 我们一直在挑选，但我觉得这比我想要的更容易出错（我觉得随着时间的推移它会变得无法管理）。

我们正在做的事情有一些限制 - 它是遗留代码，并且没有进行大量测试（开始引入单元测试，非常少的集成测试），因此保持这些版本分支的稳定性（不介绍很多回归错误）很重要。

你们有没有比采摘樱桃更好的方法来解决这个问题？ 有更好的工作流程可供使用吗？ 非常感谢您提供的任何帮助。

Answer 1

樱桃采摘可以：

• 引入重复提交
• 错过功能依赖

我更喜欢合并 （类似于desert69 提到的成功的Git分支 ）：

• 创建一个专用于buxfix_xxx的分支（在版本1之上）
• 将version1合并到该buxfix_xxx分支（快进）
• 将buxfix_xxx合并到version 2和master分支

当然，诀窍是在这些分支（版本2和主版）中记录合并而不实际合并所有文件：请参阅“ 如何使用git-merge合并选择性文件？ ”。

如果你只有几个文件要合并，我就是这样做的：

# make git believe we are merging everything
git checkout version2
git merge --no-commit bugfix_xxx

# but reset everything to version2
# (while the merge is still in progress!)
git checkout version2 -- .

# merge only the few files we need:
git checkout --patch bugfix_xxx -- path/to/file1
git checkout --patch bugfix_xxx -- path/to/file2
git checkout --patch bugfix_xxx -- path/to/file3

# add and commit, concluding the merge

关于那些合并的好处是，下一个（从version1到version2和master ）将自然限于下一个错误修复，因为git将相信其他一切 已经合并 ！

因此，您投入第一个错误修正后端的时间将为下一个支付费用。