Gitflow:在从发布分支合并到master时,我应该压缩提交吗？

Question

我将合并我的发布分支到master,我想知道是否应该在合并到master时将提交从开发转换为单个合并提交.

关于git flow的一般文档包含Atlassian页面中的这类数据:

在这些图中,只有单个提交出现在master上,而不是所有提交的提交.

实际上,我喜欢有一个只发布提交的主分支的想法.

合并成主人时,我应该保留所有提交的提交吗？或者在关注Gitflow时,在合并到master之前压缩提交？

Answer 1

主分支用于维护发布的记录,因此每个提交应该代表构成发布版本的开发分支的一组压缩变化.

压缩提交可以更容易地查看发布中的更改以及在必要时从发布提交创建修补程序分支.使用发布版本号标记每个压缩的提交.

我喜欢这个想法，但你如何以优雅的方式实现它？意思是：如果我试图在不同的时间点将开发/发布分支合并压缩到主分支，新的压缩提交/PR 与之前压缩的提交没有共同的历史记录，并导致合并冲突。这可以通过在压缩提交后将 master 合并回 develop 来缓解，但是接下来的 develop->master merge-squash 认为您所做的每个提交都应该是提交消息中的一个行项目。 (7认同)
@AbePralle 强调的完全相同的问题不会发生在“release”分支上吗？该评论并没有真正解决这个问题，这似乎是迄今为止 8 个人主要关心的问题，其他答案都在争论相反的解决方案。我认为对于如此高票数的答案进行阐述/修改是有必要的。 (5认同)
@AbePralle你不应该将开发分支合并到master，而是创建一个发布分支。我已经停止使用 GitFlow 很久了，所以我记不清具体的策略了。我强烈建议摆脱开发分支，而只从 master 分支。降低复杂性将为您节省大量时间。 (4认同)

Answer 2

在我看来,请记住,这只是一个意见,你可能会得到不同的答案,你不应该在从开发分支合并到master中时压缩提交.这样做会失去很多已经发生的变化的历史.例如,几乎所有我提交的提交都标有一个问题编号,因此可以通过git历史记录将完整的跟踪功能反馈到所引发的问题中,以及为什么要进行更改.

更重要的是,你不应该直接从发展成为主人.假设您正在关注git-flow,那么应该通过发布分支完成此转换.

如果您曾询问,在功能或修补程序分支上,是否应该将提交压缩,那么这将是一个不同的答案.在这些情况下,可以说分支应该足够小以仅保证一次提交,因此在这些情况下,在合并到目标分支之前,我几乎总是将提交重新绑定并压缩为单个提交.

但是在开发分支上可以看到完整的历史记录,而这一分支始终存在.主分支是发布的记录,因此每个提交应该代表一组压缩的变化. (18认同)
保留历史记录的另一个原因是 git bisect 命令。如果您有一个版本很好，而下一个版本有错误，那么能够转到开发分支并 git bisect 这一系列更改是很有价值的。该命令将引导您直接找到引入该错误的单个修复。如果没有历史记录，您必须手动检查进入错误版本的所有更改。 (7认同)
@GlenThomas 挤压到底有什么好处？我的意思是，您可以在 master 上以任何方式使用标签，这将清楚地识别版本。 (7认同)
@GlenThomas如果我需要来自master的hotix分支，然后我将合并到master中，我如何将该提交合并到develop中？如果我将 commit master 压入 dev 不会有问题吗？ (5认同)
我也赞同这一点。你不应该打壁球，因为它也给我们带来了问题。 (4认同)

Answer 3

如果您压缩开发、发布分支和主控之间的合并，则很难将发布分支的更改合并回开发而不发生文件冲突。也很难将修补程序合并到开发中，然后通过发布将开发合并回主版本。