问题描述
这可能是一个愚蠢的语义学问题，但是无论如何我还是在问，以防我没有从正确的角度看待这个问题。
比方说，我有一个具有master和feature分支的简单存储库-feature具有单个提交，此后将针对Hotfix的提交添加到master：
* 8aa11d5 (HEAD -> master) Hotfix
| * 73f496e (feature) Feature Added
|/
* d9588fc Initial File
然后我通过执行“ git rebase master feature”将“ feature into master”重新建立基础，结果如下：
* aeaafd0 (feature) Feature Added,'rebased onto master'
* 8aa11d5 (HEAD -> master) Hotfix
* d9588fc Initial File
在这一点上，唯一改变的分支是功能，因为我已经将master的修补程序提交合并到其中。为什么然后在git docs和在线文章中将此操作称为“重新掌握”？您的立即响应可能是“这是因为，当您随后将功能部件合并到母版中时，将出现提交链，就好像功能提交已嫁接到母版上一样”。我同意这一点，结果如下：
* aeaafd0 (HEAD -> master,feature) Feature Added,'rebased onto master'
* 8aa11d5 Hotfix
* d9588fc Initial File
但是，在我执行基准调整的时间点上，这不是真的。重新确定基础肯定创建了一个链接到主提示的提交，因此，如果我合并两个分支（快速向前合并），那么是的，我已经将基础+合并到了主提示上。换句话说，“重新掌握”的术语意味着未来的操作尚未发生。
是否使用此术语，是因为假定合并将始终在逻辑上遵循重组？还是因为我看错了方向？
解决方法
因为master所指向的提交是通过在其“顶部”添加提交来构建新的基于重新建立历史记录的地方。这并不意味着您要更改命名分支，因为该参数甚至不必成为一个分支，它只是命名一个提交。您只是在收集一段历史并将其放到其他地方。