Question

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

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

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

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

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

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

Answer 1

Cherry-picking可以：

介绍duplicate commits
miss functional dependencies

我更喜欢合并（与A successfull Git branching类似mentioned desert69）：

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

当然，诀窍是在这些分支（版本2和主版）中记录合并，而不实际合并所有文件：请参阅“How do you merge selective files with 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会相信< em>其他一切 已经合并！

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

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

1 个答案: