geh*_*eis 8 git version-control git-rebase git-flow git-cherry-pick
我们已经使用git-flow了一段时间来开发软件框架.我们在一个存储库中有master和development分支.
最近,不同的客户开始对购买框架感兴趣,这需要为每个客户定制框架.
到目前为止,我们feature-customerXYZ从主服务器为每个客户分支了一个新分支,在那里进行了自定义并在自定义完成后保持分支打开(这可以防止产品master/ development分支的"感染" 来自定制).
与此相对应,在框架本身的发展继续使用该产品通常混帐流工作流程master,development,features,hotfixes和release分支机构.
在这种情况下发生了两种常见的情况,我认为我们的工作流程无法以最佳方式处理:
feature-customerXYZ分支的开发可以包含值得在产品master/ development分支中实现的提交.由于feature-customerXYZ分支永远不会被关闭,因此这些提交必须是rebased或者cherrypicked是产品分支,这需要在定制之后进行额外的工作并且容易出错.
在feature-customer分支打开时发现的修补程序git-flow通过将hotfix修复后的已打开分支仅合并到产品master和development分支来处理,但不会合并到打开的feature-customer分支中(更准确地说:它们不会合并到所有打开的feature分支中).
是否有一个git工作流可以简洁地处理这个？是否有一个聪明的替代,而不是merge,cherrypick或rebase的提交到产品master/ develop或开feature分店,分别？
还使用拉取请求来合并总体有效提交以
feature-customerXYZ进行开发？
是的。
那么项目维护人员可以选择哪些部分的代码对产品主控/开发有用？
不：项目维护者应该只接受易于合并（快进）的 PR，并运行测试来验证 PR 是否有效。
他/她不负责选择部件：只有开发人员应该选择它们（因为他/她知道需要暴露什么dev/ master。
因此，对于情况1，仍然需要cherry-pick或rebase，以便创建一个专用分支（与feature分开），然后通过PR提交给dev或master进行验证。
对于情况2，hotfix应该合并到develop中，并且每个功能分支都可以在自己的时间rebase最新的develop状态，因此包括hostfix