这是我遵循的流程:
master分支始终与生产同步develop分支始终是下一个要发布的版本feature/feature-name分支是当前正在开发的功能。
功能完成后，会从 feature/feature-name 向 develop 分支提出 pull 请求，然后从 develop 分支向主分支。我们在 github 中完成所有这些工作。
但是，每当 github 上有 pull 请求时，都会创建以下 merge 分支。因此，在 feature/feature-name merge 到 develop 分支后，会创建一个 merge 提交；在 develop 分支 merge 到 master 分支 后，会创建另一个 merge 提交。
因此，为了 merge 1 个功能，我必须创建 2 个 merge 提交。
更糟糕的是，现在 master 分支和开发分支不再同步，因为 master 分支有 1 个额外的 merge 提交。
我有 2 个问题: 1)我遵循正确的结构/实践吗？ 2)如何避免额外的 merge 提交？特别是。如何让 master 分支在从开发快进时不创建额外的提交？
最佳答案
您的问题中似乎存在一些误解，我将尝试解决这些误解。首先，你说的是
Therefore, in order to have 1 feature merged, I have to create 2 merge commits.
What is worse, now master branch and develop branch are no longer in sync, because master branch has 1 extra merge commit.
是的，您正在创建两个 merge 提交，但您只在每个分支中创建一个提交(develop 和 master)。这就是 Git 中 merge 的工作原理；当您将一个分支 merge 到另一个分支时，它会创建一个 merge 提交。
关于 master 和 develop 不同步，如果其他人将不同的功能 merge 到 develop 在你之前。从功能的角度来看，假设自上一个冲刺以来没有其他人对 master 进行更改，当您将 develop merge 到 master 时，那么两者分支在功能上应该是等效的(尽管它们的历史可能看起来不同)。
您问了这个问题:
how to keep the master branch do not create extra commit when fast-forwarding from develop?
如果您的 develop 分支实际上快进了 master 分支，那么我不认为您正在执行 Git merge 。但是，如果您无法快进master，那么解决此问题的一种方法是进行手动 merge 。在这种情况下， merge 提交是不可避免的。
如果您真的讨厌 merge 提交，那么您应该考虑使用 rebase 。使用 git rebase ，源分支始终“保持在”目标之前，从而使您始终可以将提交快进到目标。
关于Git:master/develop/feature 分支 merge 提交，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32774939/