什么时候需要 git-rebase ？
每次我阅读 git-rebase 文档时，我都会迷失方向。 在我看来，这就像一种低级操作（阅读：黑魔法）。
引用文档：
假设存在以下历史记录 当前分支是“topic”：
A---B---C 主题 / D---E---F---G大师从这一点来看，以下任一结果 以下命令：
git rebase master git rebase 主主题将是：
A'--B'--C' 主题 / D---E---F---G大师
问题是：为什么有人想做这样的事情？
一方面，它似乎“重写”历史，就好像分支从不同的点开始; 本质上，提交历史将是“一堆谎言”。
还有一点，感觉不安全。 我尝试过一次，遇到了很多冲突，一切都崩溃了。 我不记得我是如何解决这个问题的，但如果我没记错的话，它是在临时测试分支或类似的地方。
另一个问题：我是否因为不知道如何利用git-rebase而错过了一些非常酷/节省时间的功能？
编辑：
相关问题：撤消 git rebase
Everytime I read the git-rebase documentation, I get lost. It feels to me like a kind of a low-level operation (read: dark magic).
Quoting the docs:
Assume the following history exists
and the current branch is "topic":A---B---C topic / D---E---F---G masterFrom this point, the result of either of the
following commands:git rebase master git rebase master topicwould be:
A'--B'--C' topic / D---E---F---G master
The question is: Why would anyone want to do such a thing?
For one thing, it seems to "re-write" history, as if the branch started at a different point; essentially the commit history will be "a bunch of lies".
Another point, it doesn't feel safe. I tried it once, got a ton of conflicts, and all hell broke loose. I don't remember exactly how I resolved that hell, but if I recall correctly, it was on a temporary test branch or something like that.
The other question: Am I missing some really cool/time-saving set of features by not knowing how to utilize git-rebase?
EDIT:
Related question: Undoing a git rebase
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
例如，当您想要提交其他人修改的代码的补丁时，您需要使用它。 例如，如果您从软件的修订版 1.56 分支，同时维护者转移到修订版 1.57，他/她可能只会接受修订版 1.57 上的补丁。
您可以将分支重新设置为修订版 1.57，更正所有冲突，验证并重新提交补丁。
You need to use it for instance when you want to submit a patch to code that someone else's modified. For example if you branched from revision 1.56 of a software and in the meantime the maintainer moved to revision 1.57, he/she would probably accept patches only on revision 1.57.
You would rebase your branch to revision 1.57, correct all conflicts, verify and resubmit the patch.
一旦您将“topic”合并回“master”，无论如何您都会遇到这些冲突。 因此，最好时不时地将“主题”重新定位为“主控”（如果你迈出一小步比迈出一大步更容易 - 至少在我看来）。 如果在合并之前进行变基，所有“有风险”的事情都会发生在分支中，并且之后的合并会很容易。
As soon as you merge "topic" back into "master" you will have those conflicts anyway. Thus, it is better to rebase "topic" onto "master" from time to time (it's easier if if you do small steps than if you do one big step - at least imo). If you rebase before you merge, all the "risky" stuff happens in the branch and the merge is easy afterwards.
请参阅 git rebase：保持分支最新< /a> James Bowes 的博客文章
See git rebase: keeping your branches current blog post by James Bowes
首先，git中不存在不安全的操作。 rebase 有一个中止操作，所有操作都会进入引用日志，因此您可以撤消任何操作。 事实上，情况恰恰相反。
它让您可以随时自由地投入，而不必在制作过程中获得“良好”的构建。 通过将您在此过程中采取的所有步骤压缩为一次提交，您发布的修订可以是干净的。
我一直使用变基（通常通过拉取，我通常将其配置为在获取阶段后变基）。 不要将其视为重写历史 - 将其视为在发布之前为您提供清理草稿的工具。
一年后，对于项目中的任何人来说，了解您真正针对修订版
E而不是修订版G启动此功能是否很重要？不必要的递归合并掩盖了历史中更重要的部分。
First, there are no unsafe operations in git. rebase has an abort operation, and all operations make it to the reflog, so you can undo anything. It is, in fact, quite the opposite.
It allows you to feel free to commit any time you want without having to have a "good" build while you're on the path to making one. The revisions you publish can be clean by squashing all of the steps you took along the way into a single commit.
I use rebase all the time (quite often via pull which I generally have configured to rebase after the fetch phase). Don't think of it as rewriting history -- think of it as providing a tool for you to clean up your rough draft before you publish it.
In a year from now, will it be important to anyone in your project to know that you really started this feature against revision
Eand not revisionG?Unnecessary recursive merges obscure the more important parts of history.