混帐：主/开发/特性分支合并提交

Question

这里是我下面的流程：

• master分支总是同步的生产
• develop分支总是被释放
的下一个版本
• feature/feature-name分支是当前正在开发的功能。

特征完成后，上拉请求从feature/feature-name提升到develop分支，然后从develop分支到主分支。我们在github中完成所有这些工作。

但是，无论何时github上有一个pull请求，这里就是创建的合并分支。因此，feature/feature-name合并到develop分支后，会创建合并提交; develop branch合并到master branch之后，将创建另一个合并提交。

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

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

我有两个问题： 1）我遵循正确的结构/练习吗？ 2）如何避免额外的合并提交？ ESP。如何保持主分支不会在开发时快速转发时创建额外的提交？

Answer 1

在我的问题中，似乎有一些误解，我会尝试解决。首先，你说

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

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

是的，你是创建两个合并提交，但你只能在创建每个分支（develop和master）一个承诺。这就是在Git中合并的方式;当你将一个分支合并到另一个分支时，它会创建一个合并提交。

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

你问这个问题：

如何保持主分支不会产生额外的承诺时，从快速转发发展？

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

如果你真的讨厌合并提交，那么你应该考虑使用rebasing来代替。使用git rebase，源分支始终“保持在目标的前面”，允许您始终将提交快速转发到目标。

Answer 2

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