如何在使用Git分支/合并的开发分支中提交buggy提交？

我正在研究不同的Git分支策略，我一直在卡住。假设你有一个主分支。此外，你有一个开发分支，这是一个从主分支。有功能/特性分支：如何在使用Git分支/合并的开发分支中提交buggy提交？

FixFrontEnd
FixBackEnd
ChangeConfig

三种不同的开发者每一个变化。 ChangeConfig开发人员可以快速完成，提交并合并到开发分支中。该开发分支现在已经构建并部署到开发环境。有人测试了这个新配置，并且它已被批准从Dev迁移到QA环境。 FixFrontEnd和FixBackEnd分支同样可以找到成功。他们最终会继续进行质量保证。

优先级改变下和三个补丁/功能左坐在QA。新的YetAnotherChange修复/功能使其成为QA。我们在QA中发现了FixFrontEnd和ChangeConfig的问题。然而，YetAnotherChange必须立即生产。

一切我读说，开发分支合并到主分支，使用主生产创建一个新的版本，它的部署。 FixFrontEnd和ChangeConfig会不会在合并中被拖拽到主上？大家如何接近这个？

樱桃采摘似乎是一个复杂的选择。我想就如何解决这个问题提出一些好主意。我正在寻找一个简单的解决方案。另外，假设我们能够挑选提交。我们怎样才能真正相信樱桃采摘和建造的内容与我们使用开发分支构建时的相同？我在这里的树林迷路了吗？

来源

2016-11-29 Leroy Jenkins Coder

请向我们展示各个分支的一些图表。 –

实际上，前端和后端通常被视为单独的项目，并且可能会更好，因为两个独立的存储库。也许这对你的情况值得思考？ – halfer

所以你想修改生产而不需要修改FixFrontEnd和ChangeConfig分支。您可以使用这种方法来修复它。让我们举例说明通过下图：

A---B---C master 
\ 
    D----E----F----G ----L develop 
    / |  \  \ 
    H  I  J  K

假设从各修补/功能分支机构提交历史：

ChangeConfig： H和然后合并到开发分支

FixFrontEnd：我，然后合并开发分支

FixBackEnd： J然后合并开发分支

YetAnotherChange： K和然后合并到开发分支

你只需要找到d，F和L提交ID，然后使用git rebase --onto <commit id for D> <commit id for F> <commit id for L>，develop分支将不包含从FixFrontEnd和ChangeConfig变化分支机构。它可以用于生产。该图将相等于：

A---B---C master 
\ 
    D ----G ----L develop 
     \  \ 
      J  K

注：垫底期间，也有可能有冲突的文件，你需要使用git add <conflicted filename>和git rebase --continue，那么底垫仍将继续。

来源

2016-11-29 05:45:22

在生产时，这不包括FixBackEnd吗？这还没有批准生产，因为它仍然在QA中。那么，我们为什么要把它合并到主人手中呢？我认为主人应该代表什么是生产。 –

@LeroyJenkinsCoder，是的，它不包含FixFrontEnd和ChangeConfig（问题分支）。对不起，误解，我的意思是它已准备好生产。并且所有修复都在开发分支上执行，该图将等于我答案中的最后一个（我刚刚添加它）。 –

一切我读说，开发分支合并到主分支

不是真的：您可以：

上主的顶部（再快变基YetAnotherChange -forward主到YetAnotherChange HEAD）
合并master回develop
重新绑定develop之上的其余功能分支。

任何重新绑定操作都会改变这些分支的历史，因此需要与在这些分支上工作的开发人员进行良好的沟通，以便他们将工作树重置为新的分支HEAD。

来源

2016-11-29 05:45:37 VonC

如何在使用Git分支/合并的开发分支中提交buggy提交？

回答

相关问题