首先，我对Git并不十分了解，我正在寻找一些建议，因为我面临以下问题：我的部门拥有以下分支机构，并在Git中使用了持续交付管道：
我们如何进行：对于每个新功能，我们在master上创建一个新功能分支，然后在master上提交更改，以将其置于Test环境中并检查它们是否有效。因此在master上，可能准备在Prod中使用的功能以及仍处于开发/测试阶段的其他功能有不同的提交。如果更多的人从事相同的工作，例如更改相同的文件，则情况变得更加复杂。
所以我们只有DEV和PROD，不可能有另一个额外的环境。
因此，我们面临一些问题，何时该向PROD推广这些更改，例如不推广所有更改或推广尚未准备就绪的PROD。
所以我的问题是，您认为针对此特定情况的最佳实践方案是什么？因此，如果您有经验，将非常感谢您的帮助。
非常感谢您抽出宝贵的时间阅读我的问题！
答案 0 :(得分：-1)
一种常见的方法是在单独的分支上开发功能，这些分支是从您的开发分支（在您的情况下为master）中分支出来的，并且仅在完成后再合并它们。最后一部分在这里很重要：如果尚未准备好将变更推广到生产中，请不要将其合并以进行开发，而是先将其置于不会破坏内容的状态。
有关此模型的详细说明，请参见here。
这里的问题是您必须重新合并才能进行开发才能进行测试。这似乎不可行。您可以添加另一个图层，例如testing分支，在其中合并以测试更改，并且仅在它们正常工作时才将它们合并到master。但是，正如我所说，更好的方法是在功能分支上进行测试，而不是首先合并破坏性的内容以进行开发。