这是我的项目开发过程：
我在 features 分支上开发我的功能，当我完成一个分支时，我将它合并到 master 上并通过 github ui 删除它。 CircleCI 检测合并并将主服务器部署在临时服务器上。 后来我手动将主分支合并到生产分支，并将 CircleCI 部署到我的生产服务器。
我希望每次将功能分支合并到主分支时，我的 package.json 版本都会发生变化（通过 github UI）。但我不知道是否
我知道，当我将 master 合并到生产环境时，我可以通过 npm version 命令执行此操作，但是当我将分支合并到 master 时，我确实需要在 master 上自动更新版本。
不要犹豫，批评我的前进方式并告诉我你的方式。 :)
谢谢
【问题讨论】：
我认为 Github 不提供任何此类功能。但是有一些 grunt 模块会在构建期间执行此操作。您可能可以编写此脚本或拥有一个为您执行此操作的 make 文件。
我认为这不是很好的版本控制方式。完成一项功能后，您必须决定所做的更改是次要的还是主要的。有时您可能会提交重大更改。只是将版本号从 1.0.1 增加到 1.0.2 或者说 1.1.0 到 1.1.1（每次）都不会传达这些变化的幅度。 Best Practice: Software Versioning 版本控制的最佳实践已在此处介绍。
我们在我工作的地方手动管理版本控制。在每次发布之前，我们都会创建一个标签（v1.0.3、v1.1.4..etc），然后在 Github 上创建一个发布。在发布的描述中，我们放置了所有新的提交。通过提交消息，我们可以很好地了解所做的更改。如果更改仅涉及错误修复和次要功能添加，我们将增加次要编号，即。 1.2.1 至 1.2.2。 如果添加了主要的新功能，我们会增加主要版本号，即。 1.2.2 到 1.3.0。当我们添加许多重大更改时，我们会从 1.3.0 升级到 2.0.0。 有时我们对版本控制很松散。我们的 API 不是公开的，我们使用版本控制的唯一原因是用于部署和回滚。如果您希望让自己的工作开源，或者希望通过某种包管理器（例如 npm）使您的工作可用，那么您应该严格遵循 semver 版本控制。
【讨论】：