代码之家 › 专栏 › 技术社区 › Henrik Paul

SCM中的版本控制和遗留错误修复

maintenance release version-control

2

Henrik Paul · 技术社区 · 17 年前

我为这个糟糕的问题标题感到非常抱歉,但我会尝试更详细地解释我自己:

我在我的软件项目中使用Git(但我想在这种情况下,特定的软件并不重要)。和许多项目一样,我计划发布各种版本。当发布时,我可能会为提交分配一个标记,例如“1.0”。随着时间的推移,代码被黑客攻击,最终有一个版本,带有另一个标签——这次是“2.0”。

那么,为了支持这种行为,有什么好的方案:能够在旧版本中进行更改。Git似乎在某种程度上将标记等同于发布,因为 git describe [latest tag]-[commits since the tag]-[current commit hash] )那么,我可能无法完全避免使用标记。

3 回复 | 直到 17 年前

1

Jonathan Leffler 17 年前

您需要一个分支-您将在一个从发布标签开始的分支上进行维护修复和发布,而在主(主)分支上继续进行持续的开发。

2

1

Greg Hewgill 17 年前

有很多方法可以实现你想要的。

3

1

Greg Hewgill 17 年前

你一定要考虑使用一个分支来实现这一点。Git非常支持这种类型的开发。

---A---B---C[1.0]---D---E---F[2.0]---G---H

如果您在1.0中发现一个bug并想要修复它,您不能简单地在提交C和D之间插入一个新的提交。因此,您可能会创建如下分支:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]

提交C1和C2修复该分支中的问题,您可以在该分支中标记版本1.1。现在,假设您在版本2.1中做了一个更改(G),您希望将其向后移植到版本1.1,以便在那里进行相同的更改。你可以用 git cherry-pick

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]---G1[1.2]

Commit G1与Commit G相关,只是它可以应用于版本1.1而不是版本2.0之上。

git rebase