在产品开发和产品定制中使用哪个git工作流

还可以使用pull请求来合并来自 feature-customerXYZ 发展?

所以项目维护人员可以选择代码的哪些部分对产品主控/开发有用?

否:项目维护人员应该只接受对合并来说微不足道的PR(快进),并运行测试来验证PR是否正常工作。
他/她不负责选择部件:只有开发人员应该选择它们(因为他/她知道需要暴露在什么环境中) dev / master

因此,对于案例1,仍然需要cherry pick或rebase,以便创建一个专用分支(与功能分离),然后通过PR将其提交给dev或master进行验证。

rebase on the latest develop state ,因此包括hostfix

虽然理论上可以像@VonC建议的那样在专门的分支机构中保持客户偏差,但我敢说,这在技术上是非常困难的,而且无法扩展。

是的,你可以有一些工作(在Jenkins或者别的什么地方),这些工作会自动地根据主分支重新调整你的偏差,但是当涉及到工具时,你就只能靠自己了。至少,要为以下情况做好准备:

• 重新设置基础将 失败与冲突 -别紧张,吉特会让你知道的
• 成功了,但是 结果将包含逻辑冲突-这需要良好的测试覆盖率,因为没有工具能够警告您

相反,我建议 尽量减少偏差 ,然后将它们并排放在一个分支中。

如果您的项目由模块组成,这通常是可能的。您没有提到项目的任何细节,但是大多数语言都支持某种形式的模块化,所以我希望这也是您的情况。

这样,您可以尝试将偏差的扩展点集中到最小模块(理想情况下是一个)中,并在项目中拥有这些模块的多个变体。

优势显而易见:

• 这很简单
• 您的CI很容易配置为一次构建所有模块(=客户偏差)
• 而且,您不必因此而锁定分支模型,并且仍然可以使用git流或任何适合您需要的东西

唯一的缺点是,当您只为一个客户发布项目(带有标记和其他仪式)时,您也会为所有其他客户发布项目。这通常不是什么大不了的事,另一方面,它会激励我们明智地使用这些特性,这是很好的。

为了尽量减少偏差,我建议采用以下技术:

• 而最好的一个,一些偏差可能会被拒绝-虽然这是很少可能的

总结一下- 尽量减少偏差,并排建造 .

将代码库扩展到多个主分支(每个客户)将很快变得不可维护。