进一步回答我在意外发布代码到现场如何防止发生再次发生的问题。在客户 UAT 之后，我们经常让客户说他们很高兴发布部分功能，而他们希望在未来的版本中发布其他功能。
我的问题是“您如何发布 2/3（三分之二）的功能”。我会对微软等大公司如何处理类似情况感兴趣。“是的，我们只会在下一个 Word 版本中发布最初提议的功能/修复的 45/50，打包并发布”。
假设下一个版本中没有发布的这 5 个特性已经启动.. 你怎么能在发布构建和部署中忽略它们？
您如何发布 2/3 的开发功能？
如何发布可交付成果的子集？
——李
如果您事先没有考虑到这一点，那将很难做到。
但在未来，您可以按照以下方式设置自己：
获得一个真正的版本控制系统，对分支和合并都有很好的支持。从历史上看，这意味着像 git 或 Mercurial，因为 Subversion 的合并支持非常弱。（不过，Subversion 团队最近一直在努力改进他们的合并支持。）在 Windows 方面，我不知道哪种 VC 工具最适合这种情况。
决定如何组织各个功能的工作。一种方法是将每个功能保留在自己的分支上，并且仅在新功能准备好时将其合并回主分支。这里的目标是始终保持主分支几乎可交付。当功能分支不坐在那里收集灰尘时，这是最简单的——也许每个程序员一次只能处理 1 或 2 个功能，并在它们准备好后立即合并它们？
或者，您可以尝试从版本控制历史记录中挑选单个补丁。这是单调乏味且容易出错的，但对于某些非常有纪律的开发团队来说，他们编写非常干净的补丁，恰好进行 1 次完全更改，这可能是可能的。您会在 Linux 内核社区中看到这种类型的补丁。尝试查看Linux 2.6 gitweb 上的一些补丁，看看这种开发风格是什么样的。
如果您无法始终保持主干“几乎可交付”，您可能需要阅读有关敏捷编程的书籍，例如Extreme Programming Explained。如果您的新代码往往有很多错误并且需要长时间的测试才能发现基本的逻辑错误，那么世界上所有的分支和合并都将毫无用处。
更新
功能分支如何与持续集成一起工作？一般来说，我倾向于在每次签入后构建功能分支，就像主分支一样，我希望开发人员每天或多或少地提交。但更重要的是，我尝试非常积极地将功能分支合并回主分支——一个 2 周大的功能分支会让我非常非常紧张，因为这意味着有人生活在他们自己的小世界里。
如果客户只想要一些已经工作的功能怎么办？这会让我有点担心，我想问他们为什么客户只想要一些功能。他们对代码的质量感到紧张吗？我们是否在构建正确的功能？如果我们正在开发客户真正想要的功能，并且如果我们的主分支总是可靠的，那么客户应该渴望得到我们已经实现的一切。所以在这种情况下，我会首先努力寻找我们流程的潜在问题并尝试修复它们。
但是，如果这个请求有什么特殊的千载难逢的原因，我基本上会创建一个新的主干，重新合并一些分支，然后挑选其他补丁。或者禁用一些用户界面，正如其他海报所建议的那样。但我不会养成这样的习惯。
这让我想起了我在申请项目经理职位时在 Borland 被问到的一个面试问题。那里的问题措辞不同 - 一个功能中的一个主要错误无法在固定的发布日期之前修复 - 但我认为相同的方法可以工作：删除未来版本的功能的 UI 元素。
当然，这假设您想要遗漏的功能与您想要发布的其余功能没有任何影响......但如果是这种情况，只需更改 UI 比尝试进行更剧烈的更改更容易。
实际上，我认为您会做的是将代码分支以进行发布，然后在该分支上删除 UI。
它通常是版本控制的功能，但是根据项目的大小以及您必须将多少变更集/修订分类为所需或不想要的，执行类似的操作可能会非常复杂。
我过去采用的一种不同但相当成功的策略是使功能本身可配置，并将它们部署为禁用未完成的功能或还不想使用某些功能的客户。
这种方法有几个优点，您不必纠结哪些功能/修复已合并和尚未合并，并且取决于您实现配置的方式以及该功能是否在部署时完成，客户端可以改变主意，不必等到新版本发布即可利用附加功能。
这很容易，有没有做过：