我们遵循标准模式来促进从主干到分支的更改，再到生产版本的标记。当我们需要修补生产中的更改时，更改会影响分支，并从该分支创建一个新标签。目前，作者有责任确保更改也被拉到主干并进行测试。不幸的是，在修复当前生产问题、测试和部署的热潮中，有时作者未能将更改拉到主干，我们只有在下一次回归时才意识到这一点。我的一位同事建议，也许我们可以更改策略以首先在主干上测试所有更改，并且只有来自主干的更改才能提升到分支。
优点：
- 避免错过将更改拉到主干的策略解决方案
缺点：
- 在修复生产问题时，我想测试我对将要转移到生产的分支代码的即时修复，而不是可能已经移到更远的主干。对快进副本进行更改然后为分支代码修改补丁所浪费的时间似乎很尴尬。与此相对的可能是，主干移动方式与分支不同的情况可能并不多（如范式转变）。
在开源项目中通常如何处理这些事情？也随时指出任何其他优点或减轻缺点。