在一个合理的"仅合并到主"git工作流程(例如gitflow)中 - 所有更改都发生在分支中，而分支又被合并(可能作为拉取请求的一部分) - 如何处理版本控制？
对于标记，我可以轻松地git tag特定的合并提交，没什么大不了的。
但是许多应用程序框架依赖于版本文件(例如package.json或gemspec甚至自定义文件)。
我看到几个选项：
- 将文件修改为分支的一部分。这不是很好，因为您很少事先知道哪个版本将首先合并，尤其是对于一个具有许多分支并行运行的大型团队。
- 提交后修改文件。这不是很好，因为 a- 我现在承诺 master，而 b- 自动化 CI/CD 将抓取以前的提交并发布它，但它有旧版本号和 c- 有 2 个提交来掌握一个版本，有可能检查出错误的版本;容易的人为错误。
- 将版本文件设置为模板，并从 git 标记自动生成它。这也不是很好，因为本地工具会破坏它(尝试使用无效
package.json运行npm <anything>)，并且存储库不再能够作为原子单元独立存在。
当版本控制位于作为提交一部分的文件中时，是否有一种合理的标准方法来执行此操作？
你可以采用一种策略，即人类可以通过仅合并来贡献主分支，并且只有自动化的CI/CD(例如Jenkins)可以直接在master中更改版本文件的内容。从 CI/CD 的角度来看，自动发布过程可能如下所示：
- 拉取主控(主码冻结启动)
- 运行预发布版本(使用旧版本)
- 递增 ver 文件的内容并提交
- 使用新版本运行发布版本(与 #2 不同，版本文件的内容不同)
- 将 master 推送到中央存储库(如果有人违反了 master代码冻结，则可能带有
--force)
此外，您还可以使用包含内容verfile merge=ours的 ver 文件目录中的.gitattributes保护 ver 文件免受合并到主文件的更改(请参阅此处)
听起来想要的是存储库中的模板版本文件，然后将其作为正常构建系统的一部分构建到实际版本文件中，其中包含从存储库中提取的信息。
我建议自动修订将存储库中的版本信息获取为易于使用的形式。