如何使这个MKS源代码完整性工作流适应Git？ 请考虑以下情况： 目前正在使用MKS源代码完整性（是的，这会造成伤害） 一些开发人员每周两次向开发分支签入功能（或部分功能）。 一个功能的签入与其他功能的签入交织在一起 示例：版本1、3、5用于功能A，版本2用于功能B，版本4用于功能C 每周一次，已验证的功能检入到生产分支。 通常需要合并未经验证的功能的更改 示例：功能A（来自上面）投入生产，但不是功能B和C，因此我们不想采用rev 1、3、5（放弃2和4），但rev 3在开发时可能需要与rev 2的更改合并；合并将被撤消

转到Git（耶！）。什么样的工作流会尊重该约束

我已经读了很多关于它的书，每个工作流似乎都是基于这样一个假设：在某个时间t，特性a、B和C将被完成。如果不是的话，我想t被推迟了

在我的例子中，没有急于及时完成功能，永远。每个开发人员处理一个或多个功能。如果准备好了，就开始生产。如果不是，请继续改进。每周都会进行生产构建。极为罕见的是，生产中没有新的代码更改，但它是以任何方式构建的。大多数情况下，一打功能投入生产

希望足够清楚。如果您需要更多详细信息，请告诉我

（编辑）考虑的工作流程：

在私有分支中开发功能

第一次推动开发，作为一个单一的承诺

继续在私人部门工作

推动更多的开发更改，仍然是一次提交

功能已准备好生产；将私人分支机构与生产分支机构合并

重设基础工作流：

在第二步中，私人分支机构可以在推进之前根据最新的开发负责人进行重新调整。但这样做，当在第4步重新调整时会发生什么？第一次重组后的所有变化，现在是发展的一部分，都将从新重组的私人分支机构中剥离出来，不是吗？这将在投入生产时产生问题

合并工作流：

在第二步，私人分支机构可以与最新的开发负责人合并

• 合并提交可以在私有分支中丢弃，使私有分支不受开发分支中发生的事情的影响。但是这样做，每次在开发中检查某些内容时，都必须一次又一次地进行相同的合并

• 合并提交可以保留，并且推进开发只需要与自上次签入以来的新内容合并。但当投入生产时，私有分支现在将携带来自其他功能的更改。Cherry picking可以用于只选择相关的变更集，但这需要开发人员手动决定签入的内容，并且容易出错

---

我会将每个特性放在它自己的分支中（充分利用Git轻量级的分支）。一旦特征准备就绪，主特征可以合并到特征分支中，特征可以被验证，然后分支可以合并到主特征（或生产，或任何：）中

---

我在这里使用的另一个附加功能是让开发人员推送到他们自己的远程回购，然后让一个人负责将更改从开发人员的远程回购拉到主“受祝福的”存储库中。这有助于保持受祝福的存储库的控制和“纯洁性”。

我会将每个特性放在它自己的分支中（充分利用Git轻量级的分支）。一旦特征准备就绪，主特征可以合并到特征分支中，特征可以被验证，然后分支可以合并到主特征（或生产，或任何：）中

---

我在这里使用的另一个附加功能是让开发人员推送到他们自己的远程回购，然后让一个人负责将更改从开发人员的远程回购拉到主“受祝福的”存储库中。这有助于保持对神圣存储库的控制和“纯洁性”。

我使用过Git，并且至少在某种程度上理解了它的工作原理。功能分支肯定是我要使用的东西。不过，我不确定正确维护该功能分支的最佳方法。由于开发分支在其生命周期内会有几次推送，并且可能会有几次合并/冲突，当该功能分支最终准备就绪时，它可能会包含一些尚未准备就绪的功能的一部分。每个功能都应该有自己的功能分支。只有准备就绪的功能进入根分支（开发或主功能），并且功能分支将根分支合并到它们中（反之亦然），以保持最新。功能完成后，删除分支，使其不再是维护标题是的，每个功能都有自己的分支。但是开发人员不能完全测试自己的私有分支，因为有太多的测试，处理大量不同的DBMS，让每个开发人员的客户机保持最新状态将是一场噩梦。因此，为了测试在私有特性分支中所做的更改，这些更改必须经常与其他开发人员的更改集成到开发分支中。功能分支肯定是我要使用的东西。不过，我不确定正确维护该功能分支的最佳方法。由于开发分支在其生命周期内会有几次推送，并且可能会有几次合并/冲突，当该功能分支最终准备就绪时，它可能会包含一些尚未准备就绪的功能的一部分。每个功能都应该有自己的功能分支。只有准备就绪的功能进入根分支（开发或主功能），并且功能分支将根分支合并到它们中（而不是相反）