何时不应该对提交进行版本标记？

上下文：我最近发现了语义版本控制，并且正在尝试确定如何在我自己的项目中最佳地实际使用它。

鉴于semver需要对主要更改，次要更改和补丁进行版本控制，何时不应使用更​​新的版本标记提交？在我看来，每项更改都将属于这些类别之一，因此，应对每项更改进行版本控制，但是当我查看GitHub上的各种流行项目时，这似乎并不是事情的完成方式（只是看一下实际上，大型项目只有数以百计的标签才有成千上万次提交。

SemVer关注版本发布，而不是提交。如果您的版本控制模型恰巧要求对master的每次提交都是一个发行版，那么可以，将需要根据更改的程度来标记每个commit。

通常，尽管如此，项目会在master上开发一款最稳定的产品，并标记它们认为值得支持的发行版。当他们这样做时，他们将根据其版本控制方案进行标记，而不必特别是SemVer。

版本号分配给发行版。通常，并非每个提交都应该是一个发布。有几个原因。

首先，当您说您“测试”每个提交时，都有测试级别。一台机器上运行一个自动化测试套件很好，但是在复杂的软件中，它可能无法解决所有问题。有些问题可能是特定于硬件或配置的，某些问题可能更多地是关于人为主观的考虑，而不是关于可测试的需求。

其次，增加主版本号应该是一个罕见的动作。基本上，这意味着需要手动检查与软件有关的所有内容，以查看其是否与任何已删除的功能有关。

这样的结果是，如果您准备长期支持这些功能，则应仅在完整版本（而非alpha / beta）中向“公共API”添加功能。

第三，减少广泛使用的版本数量很有帮助。即使在一个稳定的分支上，将多个修订汇总在一起并发布一个版本通常也比为每个修订发布一个版本更好。

似乎很明显地说，但是：版本号的目的是让您轻松确定任何人正在运行的软件版本。

如果任何人都有机会访问代码的特定迭代，并且否则不易确定唯一标识符，则该迭代应具有唯一的版本号。我认为这是“第一条规则”。因此，不同的发行版显然需要不同的版本号。

但是，还有更多的作用：

确保这一点的一种方法是在每次提交时增加版本号，但这通常不是一个好主意。要进行相对较小的更改可能需要几次提交/迭代，并且由于大量累积的更改然后0.0.2-> 0.0而使外部版本0.0.1-> 0.0.2令人迷惑.56，因为有人犯了空格，一次只能修复一个文件，并且没有改变任何功能。

从“每个完整版本一个版本”到“每次提交一个版本”的路途到底有多长：您，其他用户以及您愿意使用哪些系统来填补空白。

我个人习惯于处理小型项目，很高兴使用git hash，直到其他人使用的版本以及每个版本的凹凸版本为止（无论我希望有多少人使用它）。但是，在较大的公司和较大的项目中，使用了语义版本号以外的内容，但保真度低于每次提交，例如使用发行候选编号。这些具有优点，但是增加了复杂性。

合并到主服务器的每个请求都应进行版本控制。

如果它不应该是新版本（至少是补丁程序），则可能不应该将其合并到母版中，因为功能/修复/等不完整。

但是，根据团队的工作流程，您仍然可能最终要提交多次提交，而无需版本。如果在拉取请求中有多个提交没有被压榨（在我看来，它们不应该被压榨），您可能最终仍然会有10个提交和一个新版本。