合并时自动与 master 同步开发答案

【问题标题】：Automatically syncing develop with master on merge合并时自动与 master 同步开发
【发布时间】：2019-03-26 16:18:45
【问题描述】：

我目前正在从事一个涉及持续集成和部署的项目。我们使用 Git Flow 的方法工作，其中创建了一个 feature/* 分支来处理功能，然后在合并请求经过同行评审后将其合并到 develop 中。一旦我们想发布一个新版本，我们就创建一个release/x.y.z 分支，一旦获得批准，我们就合并到master。

这里的问题是，当前项目要求每个新构建（因此在 release/x.y.z 或 master 分支上的每个提交/合并）通过增加构建号来具有唯一的构建号。这个过程工作得很好，除了一旦某些东西被合并到 master 中，我们不会自动将它合并回 develop，这意味着最终，我们将拥有相似版本的相同内部版本号。

我们使用 GitLab Enterprise 和 GitLab Runners 来运行我们的构建过程并增加内部版本号，然后在提交消息中使用 [skip ci] 标记将其提交回来，以防止启动新的构建。我熟悉最常规的 git 命令，但我不确定如何自动化将更改从 master 分支合并回 develop 的过程，而无需手动合并或创建合并请求，最好不要用version bump 提交弄乱整个提交历史。

我有什么选择？

【问题讨论】：

标签： git gitlab gitlab-ci

【解决方案1】：

如果您可以将版本拆分到单独的文件中，则可以仅将其保存在主文件中。对于候选版本，您可以构建快照。否则，您将不得不合并事物以进行开发...

【讨论】：

不幸的是，发布分支也被构建并作为测试发布。如果有人之前安装了 release 分支版本（具有不同的 API 端点），如果 master 分支的版本不更高，他们将无法安装 master 分支版本。
这意味着所有分支必须共享相同的版本文件。实际上，构建工具正在与 git flow 对抗。
这并不完全正确。基本上，如果develop 是版本1337，那么每次提交到release/x.y.z 都会增加它。因此，当版本修复或测试了它的错误时，版本可能是1340，然后以1340 的形式发布到master，这会将其增加到1341。然后我需要关闭循环，将其合并回develop。我们正在与多个开发人员合作，因此不在版本控制范围内的文件只会导致问题或添加另一个系统来维护，而我们的 CI 设置的目标是让事情变得更简单。
定期合并master进行开发其实是推荐的方式。例如在主服务器上完成的热修复