为什么git rebase不带参数会按它的方式工作? [英] Why does git rebase with no arguments work the way that it does?

问题描述

我经常会执行不带任何参数的 git rebase ，并发现Git不再使用我配置的上游作为基础，而是使用了-fork-point 选项并针对...进行其他调整，导致我的提交消失.

Every so often I'll perform a git rebase with no arguments and discover that instead of rebasing against my configured upstream, Git has used the --fork-point option and rebased against...something else, causing my commits to disappear.

这与 git rebase 的文档所述:

This is in line with what the documentation for git rebase says:

如果未指定< upstream>，则在分支中配置上游.< name> .remote和branch.< name> .merge选项(有关详细信息，请参见git-config [1])，假定使用-叉点选项.

我的问题是:为什么这样工作?就我个人而言，我觉得如果我不带任何选项运行 git rebase ，我想根据已配置的上游分支进行基准化.如果我想以其他为基础，我会这样说.

My question is: Why does it work this way? Personally, I feel that if I run git rebase with no options, I want to rebase against the configured upstream branch. If I wanted to rebase against something else, I'd say so.

显然，Git的开发人员有其他想法，所以我想知道是否有人可以用一种可以帮助我记住这一区别的方式来解释这种想法.

Apparently the developers of Git think otherwise, so I'm wondering whether someone can explain the thinking in a way that'll help me remember this distinction.

推荐答案

通常， git rebase 的签名是

git rebase --onto< newbase>< upstream>< branch>

其中，在< branch> 与< branch> 和< upstream>的合并基础(即分支点")之间提交.重放到< newbase> 上.

where the commits between <branch> and the merge base (i.e. "branch point") of <branch> and <upstream> are replayed onto <newbase>.

通常，用户签出要重新设置基准的分支，并使用以下命令在命令中指定上游

Typically, the user checks out the branch they want to rebase and specifies the upstream in the command with

git rebase< upstream>

被解释为

git rebase --onto< upstream>< upstream>头.

如果要重新设置基准的分支具有跟踪分支，则可以自行调用 rebase 而不使用选项或参数，并且它将被重播到跟踪分支(例如， origin/branch >)

If the branch to rebase has a tracking branch, rebase can be called by itself without options or arguments and it will be replayed onto the tracking branch (e.g. origin/branch) as

git rebase --onto< origin/branch><起源/分支>头

在这种情况下， rebase 重播HEAD与HEAD和 origin/branch 的 git merge-base --fork-point 之间的提交>，这与HEAD和 origin/branch 的 git merge-base 略有不同.AFAIK，当分支和远程曾经指向相同的基准，但是后来又将远程重播到不同的基准时，这很有帮助.

In this case though, rebase replays the commits between HEAD and git merge-base --fork-point of HEAD and origin/branch, which is slightly different than the git merge-base of HEAD and origin/branch. AFAIK, this helps when the branch and remote used to point to the same base, but the remote later got replayed onto a different base.

无论何时指定上游，默认情况下都不使用-fork-point ，所以我最好的猜测是Git开发人员想要的是-fork-点为默认值，当指定了远程上游并且它们无法区分本地上游和远程上游时.然后，针对他们的解决方案是自己引入 git rebase ，将默认选项从-no-fork-point 切换为-fork-point ，并且只有在为该分支设置了跟踪分支时，它才能起作用.

Whenever upstream is specified, --fork-point is not used by default, so my best guess is that the Git developers wanted --fork-point to be default when a remote upstream is specified and they didn't have a way to differentiate between a local upstream and a remote upstream. A solution for them would then be to introduce git rebase by itself, switching the default option from --no-fork-point to --fork-point in that case, and only make it work when a tracking branch is set for the branch.

不过，我认为让命令成功运行而没有选项是危险的(因为在输入选项和参数之前，它可能是偶然运行的).如果您想自己运行 git rebase 并使其像指定上游时一样运行，则必须显式提供-no-fork-point (即 git rebase --no-fork-point ).同样，这仅在分支具有跟踪分支时有效.

Still, I think letting the command run successfully without options is dangerous (as it may be run by accident before options and arguments are entered). If you'd like to run git rebase by itself and have it run as it does when you specify an upstream, you have to explicitly supply --no-fork-point (i.e. git rebase --no-fork-point). Again, this only works when the branch has a tracking branch.

这篇关于为什么git rebase不带参数会按它的方式工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！