您应该创建一个单独的（我们称之为feature）分支。进行更改并不断地从 Main 合并到此功能分支，这样当您准备好合并回 Main 时就不会遇到巨大的合并问题。当您准备好合并和实施更改时，从您的功能分支合并到 Main，然后最终合并到发布分支。
这属于配置管理的范畴。您应该阅读Brad Appleton 的书Software Configuration Management Patterns: Effective Teamwork, Practical Integration。我不一定同意一切，但他有一些很好的建议。
CM 的其他好资源是CM Crossroads，还有 USENET 新闻组comp.software.config-mgt。
有几种方法可以做事：
在发布（或发布候选）时在主干和分支上开发。
这种方法的优点是正在进行的开发已经在主干中。唯一需要做的合并是将错误修复从一个版本传播到主干和其他版本。
每个版本的分支。在分支上开发，发布时合并到主干。
在这种方法中，当开始发布版本时，会从主干中切出一个新分支。当工作“准备好发布”时，它会合并回主干，因此主干代表发布的时间表。这里的优点是后备箱及其历史保持相当干净。所有的错误开始等都保存在分支中。缺点，特别是如果同时工作多个版本，则合并回主干可能会很痛苦，如果两个版本在主干中相互踩踏——就像是一种竞争条件。
每个功能的分支。组装功能以组成一个版本。
这与上面类似，但更细化。同样的优点/缺点也适用。
对于您想要做的事情，我会从您现有的“已发布”代码线中创建一个新分支。在新代码行中进行待定更改。当需要将其推出时，将其合并回主代码线 - 基本上是您的新功能的一个分支。
另一种方法是在当前代码库中实现“暗”的新功能，并使用配置开关让您在选择时启用它们。这样可以避免分支并让您轻松打开该功能。这确实需要额外的 QA 工作，因为他们需要对所有内容进行回归测试，以确保在“暗”模式下，系统仍然按照进行更改之前的方式工作。当然，他们还必须在启用时测试新更改，以确保它们正常工作。