以下是我关注的流程：
master分支始终与制作同步develop分支始终是下一个要发布的版本feature/feature-name分支是目前正在开发的功能。功能完成后，拉出请求从feature/feature-name引发到develop分支，然后从develop分支引入主分支。我们在github中完成所有这些工作。
但是，只要github上有pull请求，就会创建合并分支。因此，在feature/feature-name合并到develop分支后，会创建合并提交;在develop branch合并到master branch之后，会创建另一个合并提交。
因此，为了合并1个功能，我必须创建2个合并提交。
更糟糕的是，现在master分支和develop分支不再同步，因为master分支有1个额外的合并提交。
我有两个问题： 1）我是否遵循正确的结构/惯例？ 2）如何避免额外的合并提交？ ESP。如何保持master分支在开发快速转发时不会创建额外的提交？
答案 0 :(得分：1)
我的问题中似乎有一些误解，我将尝试解决这些误解。首先，你说那个
因此，为了合并1个功能，我必须创建2个合并提交。
更糟糕的是，现在master分支和develop分支不再同步，因为master分支有1个额外的合并提交。
是的，您正在创建两个合并提交，但您只在每个分支（develop和master）中创建一个提交。这就是Git合并的方式;当您将一个分支合并到另一个分支时，它会创建一个合并提交。
关于master和develop未同步，如果其他人在您之前将其他功能合并到develop，则他们可能无法同步。从功能的角度来看，假设自上一个sprint以来没有其他人对master进行更改，当您将develop合并到master时，两个分支应该在功能上相同（尽管它们的历史记录）可能看起来不同。）
你问了这个问题：
如何保持master分支在开发快速转发时不会创建额外的提交？
如果您的develop分支实际上快速转发master分支，那么我不认为您正在进行Git合并。但是，如果您无法快进master，那么解决此问题的一种方法是进行手动合并。在这种情况下，合并提交是不可避免的。
如果你真的讨厌合并提交，那么你应该考虑改用rebasing。使用git rebase，源分支始终“保持在目的地前面”，允许您始终将提交快进到目的地。
答案 1 :(得分：0)
没有正确的方法取决于您如何管理分支机构。有些是明智的，有些可能是模块化的，有些是为开发人员创建单独的分支。但关键的想法是保持本地代码与master和develop分支同步，更频繁地从开发分支中提取更新的代码。