Git合并-压扁还是不压扁？

Question

我目前正在努力在相当复杂的开发环境中实施git使用的准则，虽然我认为我的基础设置很好，但是特别有一个问题，我想请教一下是否有可能。这并不是一个纯粹的技术问题，而是更多关于哪个可用选项最合适。

基本上，我倾向于一个与通用的“ git flow”结构（http://nvie.com/posts/a-successful-git-branching-model/）紧密镜像的系统，但有一些例外使其能够适应我们的需求开发环境。简而言之：

• 一个项目将至少有一个“开发”和“主”分支
• “主”将包含最新的生产就绪代码
• “开发”将包含最新的合并代码
• 其他任何功能都将位于“功能/票证{number}”或“修补程序/票证{number}”分支中
• 功能分支将由'develop'组成，修补程序分支将由'master'组成
• 分支机构名称中的号码将始终与我们自己的更改/错误系统中的票证号码相对应
• 通过构建适当的分支或将其合并为“开发”功能，可以单独测试功能，也可以组合测试功能

到目前为止，它确实帮助我们简化了开发流程并防止了项目之间的冲突。引发争议的一个细节是：我们是否应该使用'--squash'选项将要素/机票分支合并回各自的原点？我有点喜欢它，我喜欢它：

• 用于开发的git日志保持整洁且可读，所有提交将仅声明原始分支名称（它告诉我们它是修补程序还是功能，以及票证编号）
• 即使清除了原始功能或修补程序分支，合并之后也不会引起混淆

也许这些原因还不够好，也许有充分的理由在这种情况下不使用'--squash'。有什么想法吗？

Answer 1

[S]我们是否应该使用选项将要素/机票分支合并回各自的原点--squash？

这完全取决于您希望回购历史记录的细粒度。请记住，通过提交消息进行的版本控制是代码文档的一种形式。故意压扁不是一个好习惯。修补程序分支可能很好，但实质功能分支却很少。

打个比方，想像一下，如果您要我借给我的《失落的DVD》盒装（例如，您克隆了我的存储库），而我只是给了您包装盒，没有DVD，然后告诉您

在这里，只需阅读有关封底的系列摘要。那应该告诉您有关情节的足够信息。

因此，无论如何，当您想要摆脱不必要的详细步骤或没有足够的独立性的中间步骤时，请压缩提交内容，以免混淆存储库的发展。

（我将在此Twitter线程中进一步讨论此问题。）

Answer 2

不要压扁：小的提交特别有用，特别是对于以后使用 跟踪错误git bisect，并且无论如何您都不想更改历史记录。只需使用合并提交 ( git merge --no-ff) 来保持历史记录的有序性。