Git - 使用 rebase 将公共(public)分支 merge 到 master

Question

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

我们的 feature_branch 现在包含大约 100 个提交(包括大量 merge 提交)，可以轻松地将其压缩为一个或两个提交。到目前为止，当在功能分支上完成一项工作时，我们只是将其 merge 回 master，这导致意大利面条日志和检查点提交被推送到 master。

相反，我们想要 rebase 。如果我们决定我们在 feature_branch 上的工作已经完成，并且没有开发人员将永远不会从/向这个分支 pull 或推送新的提交 - 并且是时候将我们的更改 merge 回 master，将违反 rebase the golden rule of rebasing ?
在阅读了该主题之后，在 master 之上重新设置交互基础听起来是个好主意(然后 merge 回 master 这将是一个 ff merge )但我只是想确保我没有遗漏任何东西。

此外，在我们不断将 master merge 到 feature_branch 之后(为了保持更新)，rebasing feature_branch 有什么问题吗？压缩 merge 提交可以吗？

谢谢!

Answer 1

rebase 与 merge 的选择在某种程度上是个人喜好问题。您拥有的链接(带有“ rebase 黄金法则”的说法是避免 rebase 已发布的提交)使用有品位的规则，使临时用户的操作变得简单。但是，没有任何内容表明您和您的同事不能事先同意允许对已发布的提交进行 rebase ，只要您和他们都知道如何处理它们。

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

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

请注意 forced update，git fetch 会打印它，因为更新不是快进的，只是因为 + 在获取引用规范。