考虑一个团队在两个主要环境TEST-ENV和MASTER（生产环境）中，在多个项目和多个分支之间使用C# dotnet和Nuget包
当前在MASTER分支和TEST分支中有一个名为X的Nuget软件包，其版本为1.0
开发者A基于MASTER Branch版本1.0和Nuget X版本1.0创建名为BranchA的分支，在该分支中，开发者将Nuget X更新为版本1.1，并将其开发（开发A）合并到测试ENV分支。
开发人员B根据主分支创建了一个名为BranchB的分支（两个分支都是基于master 1.0）。在这个分支中开发者还需要更新Nuget X，（至版本1.2），但是如果他这样做，他将覆盖掘金包中的开发A。2而且他可能不会在本地将掘金更新到1.1版本，然后继续到1。2，因为在分支B中没有处理新金块（开发A）的代码。
因此，我们处理此问题的当前方式是告诉开发人员B等待开发人员A到达主分支，然后将主分支1.1合并到分支B，并且仅在此之后才更新金块并将开发人员B推送到测试ENV。
所包含的图像演示了我们当前关于在多个分支中同时更新相同Nuget的工作流
这种动态变化实际上降低了团队的效率，因为在这种情况下，某些开发人员需要停止他们的工作，等待QA批准不同的开发人员的工作。
有没有一种方法可以优化这个工作流程？但是仍然保持每个开发分别到达主分支的事实（允许回滚到特定的开发）
1条答案
按热度按时间bnl4lu3b1#
在任何时候，开发人员B都可以在branchA或
Test Env 1.x之上 rebase 分支，以便在新的上下文中重放他们的开发。这样，他们就可以在本地测试devB是否与devA或正在测试的内容兼容。
他们可以提交他们的工作进行测试，因为他们在现有提交的基础上添加新的提交。
这可以使用例如GitLab merge trains来进一步自动化/检查：
使用合并序列对合并请求进行排队，并在合并到目标分支之前验证它们的更改是否协同工作。
但这取决于您的Git存储库托管服务。