如何使用 Git 分支/合并来阻止开发分支中的错误提交？答案

【问题标题】：How to hurdle buggy commits in a develop branch using Git branching/merging?如何使用 Git 分支/合并来阻止开发分支中的错误提交？
【发布时间】：2017-04-12 21:59:03
【问题描述】：

我正在研究不同的 Git 分支策略，但我一直卡在某一点上。假设您有一个 master 分支。此外，您还有一个开发分支，它是 master 的一个分支。有功能/主题分支：

修复前端
FixBackEnd
更改配置

三个不同的开发人员进行每个更改。 ChangeConfig 开发人员快速完成、提交并合并到开发分支。该开发分支现在已构建并部署到开发环境。有人测试了这个新配置，并批准它从 Dev 转移到 QA 环境。 FixFrontEnd 和 FixBackEnd 分支也取得了同样的成功。他们最终会继续进行质量检查。

接下来会更改优先级，三个修复/功能留在 QA 中。一个新的 YetAnotherChange 修复/功能使其成为 QA。我们在 QA 中发现了 FixFrontEnd 和 ChangeConfig 的问题。但是，YetAnotherChange 必须尽快投入生产。

我正在阅读的所有内容都表明，开发分支已合并到主分支中，使用 master 为生产创建了一个新构建，并已部署它。 FixFrontEnd 和 ChangeConfig 不会在合并中被拖到 master 吗？大家是怎么处理这个问题的？

樱桃采摘似乎是一个复杂的选择。我想要一些关于如何解决这个问题的好主意。我正在寻找一个简单的解决方案。此外，假设我们能够挑选提交。我们如何才能真正相信樱桃挑选和内置的东西会像我们使用开发分支构建时一样工作？我是不是在某个地方的树林里迷路了？

【问题讨论】：

请给我们看一些不同分支的图表。
在实践中，前端和后端通常被视为独立的项目，作为两个独立的存储库可能会更好。在你的情况下，也许这值得考虑？

标签： git version-control merge workflow branch

【解决方案1】：

因此，您希望对生产进行更改不从 FixFrontEnd 和 ChangeConfig 分支进行更改。您可以使用该方法来修复它。让我们用下图来说明：

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

假设每个修复/功能分支的提交历史为：

ChangeConfig: H 然后合并到develop分支

FixFrontEnd：我再合并到develop分支

FixBackEnd: J 然后合并到develop分支

YetAnotherChange: K 然后合并到develop分支

你只需要找到 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

注意：在rebase过程中，可能存在文件冲突，需要使用git add <conflicted filename>和git rebase --continue，rebase才会继续。

【讨论】：

在生产时不包括 FixBackEnd 吗？这还没有被批准用于生产，因为它仍然处于 QA 阶段。那么，我们为什么要将它合并到 master 中呢？我认为 master 应该代表生产中的内容。
@LeroyJenkinsCoder，是的，它不包括 FixFrontEnd 和 ChangeConfig（问题分支）。对不起，我的意思是它已经准备好生产了。并且所有修复都在开发分支上执行，该图将与我的答案中的最后一个相同（我刚刚添加了它）。

【解决方案2】：

我正在阅读的所有内容都说开发分支已合并到主分支中

不是真的：你可以：

将 YetAnotherChange 重新设置在 master 之上（然后将 master 快进到 YetAnotherChange HEAD）
将master 合并回develop
在develop 之上重新设置剩余的功能分支。

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

【讨论】：