我目前正在一个相当复杂的开发环境中实现git使用指南，虽然我认为我已经很好地设置了基础知识，但是有一个问题，特别是我想要一些输入，如果这完全是可能。这不仅仅是一个纯粹的技术性问题，因为它更多地是关于哪个可用选项最合适。
基本上，我倾向于一个与常见的“git flow”结构（http://nvie.com/posts/a-successful-git-branching-model/）密切相关的系统，但有一些例外可以使它适应我们的开发环境。简而言之：
到目前为止，它确实帮助我们简化了我们的开发并防止了项目之间的冲突。这里引发一些争论的一个细节是;我们应该使用'--squash'选项将功能/票证分支合并回各自的起源吗？我有点喜欢这个，我喜欢它：
也许这些理由不会变得足够好，也许有充分的理由不在这种情况下使用'--squash'。有什么想法吗？
答案 0 :(得分：5)
[S]我们应该使用
--squash选项将功能/票证分支合并回各自的来源吗？
这一切都取决于你想要回购历史的精细程度。请记住，通过提交消息进行版本控制是一种代码文档形式。不顾一切地碾压肯定不是好习惯。它可能适用于修补程序分支，但很少用于实质的功能分支。
作为一个类比，想象一下，如果你问我借给我的Lost DVD盒装（即你克隆了我的回购），我就给你盒子，没有DVD，并告诉你
在这里，只需阅读背面的系列摘要。这应该告诉你足够的情节。
因此，当你想要摆脱不必要的详细或不够自足的中间步骤时，无论如何都要压缩你的提交，但是不要掩盖你的存储库的演变。
（我在this Twitter thread进一步讨论了这个问题。）
答案 1 :(得分：0)
不要压榨：小的提交对于以后使用git bisect跟踪错误非常有用，而且无论如何您都不想改变历史记录。只需使用合并提交（git merge --no-ff）即可使历史记录井井有条。