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

Question

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

关于git flow的一般文档包含来自Atlassian页面的数字：

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

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

在合并为master时，我是否应该保留所有提交的提交？或者，在跟随Gitflow时，在合并到master之前压缩提交？

Answer 1

master分支用于维护发布的记录，因此每次提交都应该代表构成发布版本的开发分支的一组压缩变化。

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

Answer 2

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

更重要的是，你不应该直接从开发合并到主人。假设您正在关注git-flow，那么应该通过发布分支完成此转换。

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

Answer 3

如果您要压缩develop，release分支和master之间的合并，则很难将更改合并到release分支中以进行重新开发而不会发生文件冲突。也很难合并要开发的修补程序，然后再通过发行版将开发合并到以后再掌握。