Git：何时以及为何使用git rebase

Question

每当我开始开发任何新功能时，我都会结帐到新分支并使用develop分支重新定位该分支。在我的情况下，develop是基础分支。如果在我正在处理功能分支时更新了开发分支，我只需要签出以开发分支并获取该分支的拉动，然后签出到我的功能分支并再次使用develop分支进行重新设置。

我想知道如果我在这个过程中执行git merge而不是git rebase会发生什么。

git workflow：

git checkout develop
git pull origin develop

git checkout -b CM-255/feature
git rebase develop   #what will happen if i use git merge here instead of git rebase
git commit -m "example"
git push origin CM-255/feature

create pull request for CM-255/feature
pull request merged into master branch

Answer 1

rebase的主要好处是它开始了一种更“清洁”的方法。

首先，它消除了git merge所需的不必要的合并。

其次，变基也会产生完美的线性项目历史，您可以在其中跟踪整个项目路径的开始， 没有任何问题。这样可以使用git log, git bisect and gitk等命令更轻松地导航项目。

但这个故事有两种妥协解决方案：

• 安全性和可追溯性：如果您不遵循黄金法则 重新定位，重写项目历史可能是灾难性的 为您的协作工作流程。而且，不太重要的是，rebasing 失去merge commit提供的上下文，如果你看不到的话 上游变化已纳入资源。

理解整个过程的最佳方式是阅读以下文章：

Merging vs Rebasing

此外，我还留下了总结一个很好的应用示例的图片：

存储库初始状态

Dev-B：Origin Synchronization

Dev-B：rebase

Dev-B：最终变基

Dev-B：最终与源同步

Answer 2

在您的工作流程中，最大的区别在于develop上有新的提交。在这种情况下，如果您使用merge而非rebase，则会收到一条提交merging branch develop的提交。这是通过git将您本地分支的更改与develop上的内容相结合。

当你进行rebase时，git会接受你的本地提交并将它们放在一边。然后它从开发中带来变化并将它们添加到您的分支。完成此操作后，它会一次重新提交一次提交。

我更喜欢rebase，因为它保持了我的分支上的历史清洁。一般来说，两者之间没有功能差异。因为任何发生的冲突将在合并或应用提交时解决。