Git合并-压扁还是不压扁? [英] Git merge - to squash or not to squash?

问题描述

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

I'm currently working on implementing guidelines for git usage in a fairly complex development environment, and while I think I have the basics set up pretty well, there is one question in particular I would like some input on if that's at all possible. This isn't so much a purely technical question, as in that it's more about which of the available options is most appropriate.

基本上，我倾向于采用一种与通用的"git flow"结构密切相关的系统( http://nvie.com/posts/a-successful-git-branching-model/)，但有一些例外情况使其能够适应我们的开发环境.简而言之:

Basically, I'm leaning towards a system that closely mirrors the common "git flow" structure (http://nvie.com/posts/a-successful-git-branching-model/), with some exceptions to adapt it to our development environment. In short:

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

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

So far, it's really helped us streamline our development and prevent conflicts between projects. The one detail that's spawned some debate here is; should we merge feature/ticket branches back into their respective origins with the '--squash' option? I'm somewhat of a fan of this, and what I like about it:

• development的git日志保持清晰易读，所有提交将仅声明原始分支名称(它告诉我们它是修补程序还是功能以及票证编号)
• 即使清除了原始功能或修补程序分支，合并之后也不会引起混淆

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

Maybe these reasons won't turn out to be good enough, and maybe there's good reasons not to use '--squash' in this scenario. Any thoughts?

推荐答案

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

[S]hould we merge feature/ticket branches back into their respective origins with the --squash option?

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

It all depends how fine-grained you want the history of your repo to be. Keep in mind that version control, via commit messages, is a form of code documentation. Squashing willy-nilly is certainly not good practice. It may be fine for a hotfix branch, but rarely is for a substantial feature branch.

打个比方，想像一下，如果您要我借给我的《失落的DVD》盒装(例如，您克隆了我的存储库)，我只是给了您这个盒子，没有DVD，并告诉了您

As an analogy, imagine if you asked me for a lend of my Lost DVD boxset (i.e. you cloned my repo), and I just gave you the box, no DVDs, and told you

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

Here, just read the summary of the series on the backcover. That should tell you enough about the plot.

因此，无论如何，当您想要摆脱不必要的详细步骤或没有足够的独立性的中间步骤时，请压缩您的提交，

So, by all means, squash your commits when you want to get rid of intermediate steps that are needlessly detailed or not self-contained enough, but not to the point that it obscures the evolution of your repository.

(我将在此Twitter线程中进一步讨论此问题.)

(I discuss this matter further in this Twitter thread.)

这篇关于Git合并-压扁还是不压扁?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！