git - Pro Git 书是否向后提供了 git-rebase 的语法？

Question

正如标题所示。我最近尝试运行一个 git rebase 命令，该命令与 Git pro 的 rebase 部分具有相反的效果。也许我解释错了，但这让我发疯，因为我认为应该发生的事情失败了，我需要知道哪里出了问题。

我提到的部分在 More Interesting Rebases 下，特别是当您将 server work 分支 rebase 到 master 分支时的示例。 Git Rebasing.

我的解释方式是服务器工作将粘贴在主工作之上，这显然是根据插图发生的情况。

我在本地机器上有两个分支，分别名为 OTWO-3196(Capistrano 配置)和 origin/orgs_phase_2。我打算做的是让 origin/orgs_phase_2 工作基于我的 OTWO-3196(Capistrano 配置)工作。我在终端中输入了这个命令:

git rebase OTWO-3196(basebranch) origin/orgs_phase_2(topicbranch)

我认为将 orgs_phase_2 工作放在 OTWO-3196(Capistrano 工作)上，而不是将 OTWO-3196(Capistrano 工作)放在 orgs_phase_2 上。这与我想要的完全相反。

但是这个命令有效:

git rebase origin/orgs_phase_2 OTWO-3196

这将 origin/orgs_phase_2 的工作放到了 OTWO-3196 上。

我是不是理解错了命令？书有错吗？究竟发生了什么？多一双眼睛会很有帮助。谢谢。

Answer 1

我不知道你做了什么，或者你认为你做了什么，但是 origin/orgs_phase_2 是一个远程跟踪分支。它的唯一目的是指示上次与后者通信时名为 orgs_phase_2 的分支引用指向远程仓库中名为 origin 的位置。这种引用可以移动的唯一方法是通过获取或推送。特别是，您不能 rebase 远程跟踪分支。

此外，Pro Git 书是正确的。 您 得到了 git-rebase 语法倒退。 Git 的 rebase 就像那本书中宣传的那样工作，

git rebase [basebranch] [topicbranch]

checks out the topic branch [...] for you and replays it onto the base branch [...]

在 git-rebase 手册页中，

Assume the following history exists and the current branch is "topic":

      A---B---C topic
     /
D---E---F---G master

From this point, the result of either of the following commands:

git rebase master
git rebase master topic

would be:

              A'--B'--C' topic
             /
D---E---F---G master

---

为了修正想法，这里有一个你可以在家里重现的小例子:

#!/bin/bash

# set things up
cd ~/Desktop
mkdir test
cd test
git init

# write an initial shopping list
printf "4 pears\n" > shopping.txt
printf "3 lemons\n" >> shopping.txt 
printf "1 stalk of celery\n" >> shopping.txt 
printf "4 bananas\n" >> shopping.txt 

# make a first commit on master
git add shopping.txt
git commit -m "add shopping list"

# modify the shopping list and make a second commit on master
sed -i '' 's/4 pears/4 apples/' shopping.txt 
git add shopping.txt
git commit -m "replace pears by apples"

# create and check out a new branch called "kidscominghome"
git checkout -b kidscominghome

# make two more commits on kidscominghome
printf "16 pots of yoghurt\n" >> shopping.txt
git add shopping.txt
git commit -m "add yoghurt"
printf "beer\n" >> shopping.txt 
git add shopping.txt
git commit -m "add beer"

# check out master, modify the file, and make one more commit
git checkout master
sed -i '' 's/stalk of celery/cauliflower/' shopping.txt 
git add shopping.txt
git commit -m "replace celery by cauliflower"

在这个阶段，输出

git log --graph --decorate --oneline --all

应该是

* 5a0e340 (HEAD, master) replace celery by cauliflower
| * d3d22d0 (kidscominghome) add beer
| * edd730d add yoghurt
|/  
* 7dc55b7 replace pears by apples
* 7079948 add shopping list

这是一个显示相同历史的更好看的图表:

现在，如果你跑

git rebase master kidscominghome

然后运行相同的 git log 命令，您应该会看到

* 2acf37d (HEAD, kidscominghome) add beer
* dfac4a8 add yoghurt
* 5a0e340 (master) replace celery by cauliflower
* 7dc55b7 replace pears by apples
* 7079948 add shopping list

同样，这是一个显示相同历史的更好看的图表:

如广告所示，kidscominghome 分支已被 check out ，只能从 kidcominghome 访问的提交已在 master 之上重播>;不是相反!