我正在阅读一篇关于git的博客文章，其中讨论了各种分支策略。本文建议，对于长期存在的功能分支，应该不断地从主分支合并到功能分支中，以保持功能分支与主分支同步，这样当功能分支合并回主分支时就不会出现问题。我很清楚这个策略。在juno Hamano的注释中，git管理员说:
我必须提醒一下，"branch out and sync often"是一个错误要避免的疾病。你通过分支来实现一个特定的目标(例如:"添加这个功能"，"修复这个bug")，以及拥有一个该任务的专用分支是保存的历史记录特别的分支可读性和可理解性，这将导致少bug。使用单独的分支就没有意义了随机合并回来从"主"的工作点上你Branch还没有准备好，master上所做的一切还没有准备好影响添加特性或修复错误的具体目标。我的问题是丢弃测试分支策略是如何工作的，它是如何使与master的最终集成更容易的?谁能提供一个更详细的例子/更容易理解的解释?标准建议避免疾病，同时确保你在分支机构所做的耗时的工作以前的fork仍然可以很好地处理由另一种方法是创建一个一次性的"测试"分支，从您的主题分支和主分支保持代码库漂移检查。
我在juno Hamano的博客Fun with ReReRe中找到了这个模式的详细解释。
基本思想是在一个不被保留的分支上做一个测试合并，然后使用git的版本功能来记录冲突是如何解决的，然后扔掉测试合并分支，当最终合并发生时，记录的合并决议将被git自动应用。