Git - 使用 rebase 将公共分支合并到 master答案

【问题标题】：Git - using rebase to merge public branch to masterGit - 使用 rebase 将公共分支合并到 master
【发布时间】：2016-04-21 08:52:52
【问题描述】：

我们目前有 3 名开发人员在一个功能分支上工作。我们不断向 feature_branch（和 origin/feature_branch）提交和推送 WIP 提交，每隔一天我们将 master 合并到 feature_branch，以确保我们及时了解所有其他正在发生的变化。

我们的 feature_branch 现在包含大约 100 个提交（包括许多合并提交），可以很容易地压缩成一个或两个提交。到目前为止，当一个特性分支上的工作完成时，我们只是将它合并回 master，这导致意大利面条日志和检查点提交被推送到 master。

相反，我们想要变基。如果我们决定我们在 feature_branch 上的工作已经完成，并且没有开发人员会从这个分支中拉取或推送新的提交 - 并且是时候将我们的更改合并回 master，那么 rebase 会违反the golden rule of rebasing？
在阅读完该主题后，在 master 之上 rebase interactive 听起来是个好主意（然后合并回 master，这将是一个 ff 合并），但我只是想确保我没有遗漏任何东西。

另外，在我们不断将 master 合并到 feature_branch 之后（为了保持更新），rebase 有什么问题吗？可以压缩合并提交吗？

谢谢！

【问题讨论】：

如果feature_branch只有一次提交，你还想避免合并操作吗？
我不是想避免合并操作..只是想弄清楚我当前的 git 流 - 如果我应该坚持使用git merge 或使用git rebase

标签： git merge git-merge git-rebase git-workflow

【解决方案1】：

rebase 与 merge 的选择在某种程度上是个人喜好问题。您拥有的链接（使用“rebase 的黄金法则”来避免对已发布的提交进行 rebase）使用了一个雅致的规则，该规则使临时用户的事情变得简单。但是，只要您和您的同事都知道如何处理它们，您和您的同事就不能事先同意允许对已发布的提交进行变基。

git 的 git 存储库中有几个故意重新设置的分支，称为 next 和 pu（pu 代表 Pick Up，而不是 skunk-odor :-)）。当你git fetch最新的git时，经常会看到这样的东西：

 + 104e649...1352ede next       -> origin/next  (forced update)
 + cf10e94...a619c8c pu         -> origin/pu  (forced update)

注意forced update，git fetch 打印出来是因为更新不是快进，而只是因为 fetch refspec 中的+ 而发生。

【讨论】：

【解决方案2】：

实际上这取决于您通常的工作流程，我不认为变基总是错误的。

例如，如果您使用基于 Garrit 的工作流程，通常与 master 一起 rebase，将您的提交压缩到单个提交中，然后将其推送到 master 以合并它。（基本上，您要掌握一个补丁，其中包含由于您的变基操作而已经部分合并的代码）。 Here 你可以找到关于这个一直使用变基的工作流的更详细的解释。

【讨论】：