【发布时间】：2020-01-29 21:23:29
【问题描述】：
在我的新公司中，我们使用 master - develop - feature git 工作流程，其中的细节对我来说有点奇怪：
我们不使用 release 分支，而是将 develop 合并到 master 每个版本（压缩），其中包含一个包含发布更改日志的提交消息，这对我的同事来说非常重要..
发生的事情是他修复了一个主合并提交（只是修复了提交消息）并强制推送了这个重写的提交。 我们无法弄清楚的是如何从这一点着手。
我不这么认为，但有什么办法可以在没有的情况下继续工作：
- 向
master添加额外的提交 - 将
develop重新定位到master，因为这会导致丢失整个develop历史记录 - 重置最后一个
master合并提交并再次合并整个版本
【问题讨论】：
-
听起来好像你有一个发布分支，但它叫做
master，你的master叫做develop。 -
嗯，没错，但是只有一个发布分支，不是每个发布都有一个..
-
我明白了……如果您想在 3.0 发布后发布 2.1，这可能会成为一个问题……我认为您需要然后开始创建发布分支，但是您可能只在需要 2.1 时才创建它们（即从 2.0 版本的提交开始创建一个 release_2 分支）。
-
这是一个在持续交付设置中非常合理的设置，其中 master 发布到 prod。没有发布稳定性的 GitFlow 风格。只是我们不应该发生的力量。我会更好地撤消 master 上的合并提交，然后再次将 develop 合并到 master 中。现在我的猜测是，您最好的方法是将 master 上的强制提交合并回 develop（您可能可以将所有内容都解决为 keep-mine），然后在 master 中挑选任何其他修补程序进行开发。
-
不打算发布旧版本的维护版本，因此这不应该成为问题。 3.0 发布后，不会再有任何版本 2 更新。
标签： git