git中的rebase操作

假设你在你的项目master分支上（我们只显示最后4个提交）：

现在你想在不同的分支上开发一些很酷的新功能，所以你创建一个git checkout -b feature分支并进行两次提交。现在你master和feature分支看起来是这样的：

但是现在有人告诉你你的应用程序存在一个bug，并且你很快就会将你的分支（checkout）切换到你master分支来查找并修复这个bug。一段时间后，您修复它并推送（并部署）更改。你可以回到你的feature分支。

但是现在你意识到你有一个小问题。您的feature分支仍然存在您在master分支上修复的相同错误，并且您意识到该错误也会影响feature分支上的新代码，因此您需要将这些错误修复（提交）合并到feature分支中。但是该如何？在做feature分支之前进行错误修复。这样，具有修复代码的提交在feature分支中。你用rebase命令来做。所以，如果你在你的feature分支，你会这样做：

git rebase master

这就是你的分支会如何看起来像之后的样子：

如你所见，feature分支的历史已经改变。如果有人现在看它，认为你feature在错误修复提交后制作了你的分支。

所以这很好？但有一个问题。git rebase会改变git的提交记录，但不用担心，你的代码将保持不变，只有feature分支上的提交的提交记录会改变。这些提交记录是什么？git log，你可能会注意到，当你这样做时，你看到每个提交都有40个字符的长字符串：

commit f5cad47722bc98419fe5037753f5bbe29d3917c4
Author: John Doe <john@doe.com>
Date:   Mon Apr 23 11:49:07 2018 +0200

如果提交之前提交记录是这样的：

然后在rebase之后，feature分支上的提交记录会改变：

这就是为什么你一直听到git rebase是一个危险的命令。因为它改变了历史，你应该谨慎使用它。

但为什么这是危险的？那么，让我们假设你不是唯一一个在这个feature分支上工作的人，但是有更多的人在对它进行改变。现在你可以写你的代码将更改推送到feature远程。现在，当你的同事试图从远端拉动时feature，这个时候会发生代码冲突，因为他的本地feature分支版本的历史与远端版本不同。

所以同事代码冲突，但是他没有好的办法来解决这个问题。所以，如果您在本地分支上工作，并且尚未将其推送到远程服务器，或者您做了，但仍然只有您在该分支上工作的您，那么你可以使用rebase。