Git：master/develop/feature 分支合并提交

Question

这是我遵循的流程：

• master分支始终与生产同步
• develop分支总是下一个要发布的版本
• feature/feature-name分支是当前正在开发的功能。

功能完成后，从feature/feature-name到develop分支，然后从develop分支到 master 分支提出拉取请求。 我们在 github 中完成所有这些。

但是，只要在 github 上有拉取请求，就会创建合并分支。 因此，在feature/feature-name合并到develop分支后，会创建一个合并提交； 在develop branch合并到master branch ，会创建另一个合并提交。

因此，为了合并 1 个功能，我必须创建 2 个合并提交。

更糟糕的是，现在 master 分支和 develop 分支不再同步，因为 master 分支有 1 个额外的合并提交。

我有两个问题：1）我是否遵循了正确的结构/实践？ 2）如何避免额外的合并提交？ 特别是从开发快进时如何保持主分支不创建额外的提交？

Answer 1

您的问题中似乎存在一些误解，我将尝试解决这些误解。 首先，你说

因此，为了合并 1 个功能，我必须创建 2 个合并提交。

更糟糕的是，现在 master 分支和 develop 分支不再同步，因为 master 分支有 1 个额外的合并提交。

是的，您正在创建两个合并提交，但您只在每个分支（ develop和master ）中创建一个提交。 这就是在 Git 中合并的工作方式； 当您将一个分支合并到另一个分支时，它会创建一个合并提交。

关于master和develop不同步，如果其他人在你之前将不同的功能合并到develop ，他们可能不会同步。 从功能的角度来看，假设自上一个 sprint 以来没有其他人对master进行过更改，当您将develop合并到master那么两个分支在功能上应该是等效的（尽管它们的历史记录可能看起来不同）。

你问了这个问题：

从开发快进时如何保持主分支不创建额外的提交？

如果您的develop分支实际上快进了master分支，那么我不认为您在进行 Git 合并。 但是，如果您不能快进master ，那么解决此问题的一种方法是进行手动合并。 在这种情况下，合并提交是不可避免的。

如果你真的讨厌合并提交，那么你应该考虑改用变基。 使用git rebase ，源分支总是“领先”于目标，允许您始终将提交快进到目标。

Answer 2

没有正确的方法取决于您想如何管理分支机构。 有些人是明智地做功能，有些人可能是明智地做模块，有些人为开发人员创建单独的分支。 但关键的想法是让你的本地代码与 master 和 develop 分支保持同步，更频繁地从 development 分支拉取更新的代码。