【问题标题】:What branch do I update an applications version number?我应该更新哪个分支的应用程序版本号?
【发布时间】:2020-07-29 10:00:57
【问题描述】:

我的应用需要更改配置文件中的版本号。 如果我遵循 GIT Flow 分支方式,理想情况下我应该更改哪个分支? 是在我们创建发布分支之前开发,还是在发布分支中(然后更新回开发)?

【问题讨论】:

  • 不要。根本不要将版本号存储在 repo 的文件中。相反,从标签(最好是签名的)派生版本号。那么这个问题就没有实际意义了。
  • 为什么?在文件中存储版本号有什么问题?
  • 如果您将版本号存储在文件中,您会遇到此问题中的问题以及其他问题。该版本应该只有一个规范的来源,那就是 VCS。如果您将一个版本放入一个文件中,然后对存储库进行 3 次提交,那么您现在拥有 3 个不同版本的软件,它们都具有完全相同的版本号,并且不容易区分。

标签: git branching-and-merging git-flow


【解决方案1】:

我会在发布分支上这样做,因为如果您使用 Git Flow,这意味着您在发布之前有一个测试流程,因此可能有多个候选发布。

例如,假设您的产品版本为1.0.0,而您想要发布版本1.0.1。您从develop 中剪切了一个分支release-1.0.1,并将发布分支上的版本更改为1.0.1-pre1。这是您的第一个候选版本。您运行测试并找到阻止发布的错误。您在发布分支中修复此错误。现在您有了另一个版本为1.0.1-pre2 的候选版本。你再次测试这个新的候选版本,找到另一个错误,并修复它。您现在有了第三个候选版本1.0.1-pre3。它通过了测试并成为正式版本。现在您可以将版本号更改为1.0.1,发布并合并回develop。您对三个候选发布版本有清晰的历史记录。

如果您出于某种原因决定停止发布,例如因为在测试时您意识到新功能尚未准备好发布并且需要更多工作,您可以简单地删除 release-1.0.1 分支。在develop 上,版本仍然是1.0.0。您可以稍后使用新的发布分支发布 1.0.1

【讨论】:

  • 这很好,一切都说得通。
猜你喜欢
  • 1970-01-01
  • 2011-04-17
  • 2017-01-12
  • 1970-01-01
  • 2020-01-16
  • 2010-10-31
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多