本文探讨了Git中rebase--onto命令的多种使用场景，包括删除提交、处理长期存在的远程分支以及管理本地分支，展示了如何利用这一命令进行高效的历史记录管理。
我不是Git专家，所以我经常在Git中学习会改变我对该工具看法的东西。 当显示git rebase -i ，我停止了对提交的思考。 当我发现git reflog ，我对重新部署变得更加自信。 但是我认为我被教过的最重要的命令之一是git rebase --onto 。
恕我直言，该文件在选择结果方面仍有改进的余地。 如果拍摄树的图像，它基本上会将树的一部分连根拔起，然后将其重新种植到其他位置。
让我们用以下树为例：
o---o---o---o master
\
\---o---o branch1
\
\---o branch2 假设我们要将branch2从branch1移植到master：
o---o---o---o master
\ \
\ \---o' branch2
\
\---o---o branch1 这是一个很好的用例！ 在分支branch2 ，命令为git rebase --onto master branch1 。 这大约意味着将所有内容从branch2开始，从branch1移至master的尖端。 我通过记住第一个参数是新提交，第二个参数是旧提交来记住语法。
所以，但是有什么用例可以移动树的一部分呢？
删除提交
虽然我要删除提交的第一个反射是git rebase -i ，但它并不总是最方便的。 它需要执行以下步骤：
- 找到要删除的第一个提交
- 有效地运行
git rebase -i命令 - 在编辑器中，对于每个需要删除的提交，删除该行
- 退出编辑器
如果要删除的提交是相邻的，则将rebase --onto更容易，因为您只需要新的和旧的提交，并且可以在一行中进行“删除”。
这是一个例子：
o---A---X---Y---Z master 要删除最后3个提交X ， Y和Z ，您只需要：
git rebase--onto A Z长期存在的远程分支机构
拥有长期存在的分支通常是一个坏主意，但有时是必需的。
假设您需要将应用程序的一部分迁移到新框架，库等。 对于小型应用程序，可以由一个小型工作队来完成。 主要开发团队在周末结束时会指示您在周五离开之前提交所有内容。 当他们星期一回来时，一切都已迁移。
可悲的是，生活并不总是那么轻松，对于这样的理想情况，应用程序可能太大。 在这种情况下，工作队将与主要团队同时在专门的migration部门工作超过一个周末。 但是他们需要与main分支保持最新，并且仍然保持工作。
因此，他们不时地将migration分支重新设置在master的顶部：
git rebase--onto master old-root-of-migration这与合并不同，因为您使历史记录保持线性。
当地分行
有时，出于多种原因，我想将更改保留在本地。 例如，我可能会修改代码质量工具的其他（或更严格的）规则。 在这种情况下，我想花时间评估这是否与整个团队相关。
如上所述，这是通过定期将我的本地tinker分支重新定为master 。
如上所述，它使我可以保持历史记录的线性，并根据需要更改与tinker相关的提交。 合并将阻止我执行此操作。
结论
git rebase --onto可以有不同的用例。 最重要的问题与长期分支（无论是本地分支还是远程分支）的处理有关。
与往常一样，它只是工具带中的另一个工具，因此并非所有事物看起来都像钉子一样。
由于每个更改Git历史记录的命令，git rebase --onto应该只更改本地提交。 您已被警告！
翻译自: https://blog.frankel.ch/multiple-usages-git-rebase-onto/
扫一扫
3001
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
