6

我已经能够说服我的团队使用语义版本控制并迁移到 git（从 CVS，所有开发都发生在主干上）。

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

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

问题是，当需要在 1.0 版分支上进行错误修复时，该修复需要回显到 2.0 版和 master。我们一直在挑选，但我觉得这比我想要的更容易出错（而且我觉得随着时间的推移它会变得难以管理）。

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

你们有比挑选樱桃更好的方法吗？有更好的工作流程可以使用吗？非常感谢您提供的任何帮助。

4

1 回答 1

5

樱桃采摘可以：

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

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

当然，诀窍是在这些分支（version2 和 master）中记录合并，而不实际合并所有文件：请参阅“如何使用 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

这些合并的好处是，下一个（从version1toversion2和master）自然会被限制在下一个错误修复中，因为 git 会相信其他所有东西都已经合并了！

因此，您在错误修复的第一个反向移植上投入的时间将为下一个错误修复付出代价。

于 2013-03-09T09:37:43.917 回答