【问题标题】:Versioning with SemVer使用 SemVer 进行版本控制
【发布时间】:2017-08-07 23:06:59
【问题描述】:

我需要一些关于使用 SemVer 进行版本控制的帮助/建议。

我正在处理一个客户的网站,他在 Word 文档中向他的网站发送了大大小小的相关修改(就像他们一直做的那样)。

我有一个基于我的主分支的分支来进行这些新的修改,并且已经为我迄今为止所做的每个已完成的修改创建了提交。

我的想法是我将完成所有修改,然后在下一个版本 (v2.0.0) 中发布它们,因为我认为所有这些更改都是相关的,并且所有这些更改结合起来足以保证版本的增加号码。

我遇到的问题是,客户希望在 2.0.0 发布之前立即启用其中的一些修改,那么处理这个问题的最佳方法是什么 - 我会将这些完成的修改上传到现有版本并增加次要编号,或者即使所有修改都未完成,我会将其提升到 2.0.0?

在版本控制方面我有点菜鸟,但我正在努力通过阅读和尝试理解语义版本控制网站来尽可能地学习。

【问题讨论】:

  • 这真的取决于你喜欢什么。版本号只是任意数字。它们本身并没有任何意义。见programmers.stackexchange.com/questions/109103/…
  • 这个问题真的好像和git没什么关系。版本号在 git 中没有语义意义。 Git 使用提交哈希来跟踪文件更改,而不是版本号。我想也许你真的想问一下 SemVer?
  • @GoonyanHarir 如果这个问题真的是关于 SemVer 那么我不确定我是否真的称之为“基于意见”,因为 SemVer 有一些非常具体的规则处理版本号的方式。如果您确实打算询问 SemVer,请考虑编辑您的问题以使其更清楚。 (我已经为您重新标记并更改了标题。)
  • @Rik_S 我们的误解可能源于 OP 在问题末尾偷偷提到 SemVer,这很容易被忽视。这是一小段文字,完全改变了问题的上下文。
  • 对造成的混乱表示歉意。将来我会尝试更清楚地构建我的问题/意图......

标签: versioning semantic-versioning


【解决方案1】:

您应该始终考虑以下两件事:

  1. 真正的变化是什么?如果没有可见的更改,和/或如果下面没有重大更改,最好避免增加主要版本号。

  2. 客户应该如何看待您的更改?说 1.1 版或 2.0 版可能会对这些变化的感知方式产生一些影响。

因此,如果修改受到限制和/或没有可见的内容发生变化,则只增加次要项然后等待所有修改完成以将其提升到 2.0.0 可能是有意义的。

【讨论】:

    【解决方案2】:

    我建议暂时停止考虑版本,专注于分支管理。你可以从this "go-to" document on branching开始。

    如果我是你,我会

    1. 从当前为该客户端部署的任何内容派生一个分支。假设这个分支被命名为“client-acme-corp”。
    2. 从您所做的任何分支中挑选客户想要立即部署的更改。
    3. 将步骤 1 中的分支重新部署到客户端。
    4. 继续努力开发新版本。
    5. 发布完成后,将“client-acme-corp”重新定位到您的开发分支。

      Git 很聪明,因此您精心挑选的提交不应该在引入来自包含新版本的分支的相同文本更改时引起问题。 如果您不希望这样,只需在显示变基脚本时删除这些提交。

    6. 将更新后的分支重新部署到客户端。

    【讨论】:

      猜你喜欢
      • 2018-02-03
      • 2019-09-03
      • 2019-02-21
      • 2018-08-22
      • 1970-01-01
      • 2023-02-01
      • 2017-08-23
      • 2019-03-16
      • 1970-01-01
      相关资源
      最近更新 更多