熟悉 Team Foundation Server 的人通常向我询问有关分布式源代码控制的问题。
是否可以使用 Git 或 Mercurial 等 DVCS 进行源代码控制并遵守 ISO 9001 或 CMMI 等标准？
ISO 9001 和 CMMI 对哪些源代码控制工具应该和不应该有什么要求？
Git/Mercurial 是否有任何被 ISO 9001/CMMI 认为是有害的或需要具体考虑的事情？
我在http://www.ssqc.com/do25v6new.pdf找到了一些信息，但快速浏览一下，除了需要记录更改的内容、您使用的软件版本之外，它似乎并没有说明什么'已经部署，他们修复了哪些问题，并且没有理由为什么 DVCS 不应该能够结合诸如 FogBugz 之类的错误跟踪器和诸如 TeamCity 之类的 CI 服务器来处理这个问题。
首先，软件不符合 ISO 9001 标准。只有组织符合 ISO 9001。所以说的问题真的没有意义。您唯一可以问的是 Git 或 Mercurial 开发团队是否符合 ISO 9001 标准。（CMMI 也是如此）。
软件开发机构的所有 ISO 9001 真正意味着您为您所做的一切（开发、错误修复等）制定了书面流程并遵循它。好吧，您已经付钱请人来进行 ISO 9001 审核，以证明上述内容。CMMI 涉及更多，但为了讨论的目的，我们可以认为它们是相似的。
你可能不得不花很长时间才能找到一个自由软件社区项目，它费心费力地完成创建所有流程文档所需的大量繁重的工作，并且拼凑钱来支付审计费用。如果您找到它，那可能只是由于某种大型企业赞助商想要它。
如果问题是这些标准对源代码控制的使用有什么规定，那么在 ISO 9001 的情况下，那将毫无意义。一个老笑话是，如果你把你的产品从一个 10 层的窗口放到下面的装卸码头，只要这是你记录的过程并且你遵循它，这对 ISO 来说就很好。
我在 21 CFR 820（受监管的医疗设备）/ISO 13485 环境中工作，但“大局”与 ISO 9001 大致相同。我同意上述关于 ISO 9001 是关于流程而非工具的所有内容。
但是，您可能在需要实施工程设计控制程序的领域工作，而设计控制将涉及开发人员使用的流程、工具和工作说明。特别是在医疗器械领域，我们不得不担心任何影响产品安全性或有效性的软件工具。这包括用于配置管理和版本控制的工具（如果您无法控制正在构建的软件版本，则无法令人信服地说您知道该领域中的版本，因此您无法分辨联系哪些客户进行召回）。
对于此类工具，我们必须拥有“计算机系统验证”（CSV）文档。第三方工具的 CSV 包括 (1) 描述产品开发周期内的用例以及它们如何影响质量的工具规范和 (2) 可以提供客观证据证明该工具在预期用例中有效的测试用例.
对于版本控制系统，这基本上意味着一份描述您使用的功能（签入、签出、分支、标签）的白皮书以及对这些功能的一些测试，以证明它们可以工作。对于奖励积分，如果该软件有自己的测试套件，您可以包含它运行并通过自己的测试的证据。
从CMMI 主页：
CMMI 是一种流程改进方法，它为组织提供最终提高其绩效的有效流程的基本要素。
CMMI 处理的是过程，而不是工具。我的理解是，如果您有执行此操作的流程（级别 2）并遵循流程（级别 3、4、5），您可以使用粘土片进行版本控制并符合 CMMI。
我能够参与 SCAMPI C 审计，并为前雇主的两个 CMMi 流程组开发流程，我们与 CMMi 顾问就版本控制进行了深入讨论。在此过程中，我们没有使用 DVCS，但由于上述许多原因，我不明白为什么会出现问题。
就 CMMi 实际审核的内容而言，其他发帖人的说法是正确的，只要过程记录在案并且开发人员理解并可以适当地引用该过程，你应该没问题。
就确保您的团队准备好通过 CMMi 审核而言，唯一需要考虑的事情是尝试将中型/大型团队从开源 VCS（SVN、CVS）或商业 VCS（MKS、 AccuRev 等...) 到 DVCS，而没有适当的启动时间。由于过渡可能会令人不安，因此您需要确保您的团队在参与审计之前牢牢掌握任何 DVCS。
正如其他人所指出的那样，ISO 9001 与工具无关。在符合 ISO 9001 的机构工作表明他们（机构本身）是“成熟的”。在这种情况下，成熟一词表示组织严格遵守经过审核并符合 ISO 9001 的流程。涉及 Git 或 Mercurial 的流程不会以任何方式影响您成为 ISO 9001 兼容的能力（除非您不遵循这些流程）。
至少，这是我对这一切的理解。