Pro Git书有向后git-rebase的语法吗? [英] Has the Pro Git book got the syntax of git-rebase backwards?
问题描述
正如标题所示.我最近尝试运行git rebase命令，该命令的效果与Git专业版中有关重新设置基准的部分所产生的效果相反.也许我认为这是错误的，但是它使我发疯，因为我认为应该发生的事情失败了，我需要知道出了什么问题.
Just as the title illustrates. I recently tried to run a git rebase command that had the reverse effect from what the Git pro's section on rebasing had. Maybe I interpreted it wrong, but its driving me crazy because what I thought was supposed to happen failed and I need to know what went wrong.
我所指的部分在更有趣的基础"下，尤其是将服务器工作分支基础更改为master分支时的示例. Git重新设置.
The section that I refer to is under More Interesting Rebases, particularly with the example when you rebase the server work branch onto the master branch. Git Rebasing.
我的解释方式是，将服务器工作粘贴到主工作之上，这显然是根据插图进行的.
The way how I interpreted was that the server work would be pasted on top of the master work, which is clearly what it happening based on the illustration.
我在本地计算机上有两个分支，分别名为OTWO-3196(Capistrano配置)和origin/orgs_phase_2.我打算做的工作是在我的OTWO-3196(Capistrano配置)工作的基础上重新设置origin/orgs_phase_2工作.我在终端输入以下命令:
I had two branches named OTWO-3196 (Capistrano configurations) and origin/orgs_phase_2 on my local machine. What I intended to do was to have the origin/orgs_phase_2 work rebase on top of my OTWO-3196 (Capistrano configurations) work. I typed into the terminal this command:
git rebase OTWO-3196(basebranch) origin/orgs_phase_2(topicbranch)
我认为可以将orgs_phase_2工作放在OTWO-3196(Capistrano工作)上，而不是将OTWO-3196(Capistrano工作)放在orgs_phase_2上.这与我想要的完全相反.
What I thought would place the orgs_phase_2 work on OTWO-3196 (Capistrano work) instead placed the OTWO-3196 (Capistrano work) onto orgs_phase_2. This was the exact reverse of what I wanted.
此命令有效:
git rebase origin/orgs_phase_2 OTWO-3196
这将origin/orgs_phase_2的工作放到OTWO-3196上.
This placed the work of origin/orgs_phase_2 onto OTWO-3196.
我把命令解释错了吗?这本书不正确吗?到底发生了什么事?额外的一双眼睛会有所帮助.谢谢.
Did I interpret the command wrong? Is the book incorrect? What exactly happened? An extra pair of eyes would be helpful. Thanks.
推荐答案
我不知道您做了什么，或者认为您做了什么，但是origin/orgs_phase_2是一个远程跟踪分支.它的唯一目的是指示上一次与远程仓库中称为origin的分支引用在远程仓库中所指向的位置.这样的引用可以移动的唯一方式是通过提取或推送.特别是，您不能为远程跟踪分支重新设基.
I don't know what you did, or think you did, but origin/orgs_phase_2 is a remote-tracking branch. Its only purpose is to indicate where the branch reference called orgs_phase_2 pointed to in the remote repo called origin the last time you communicated with the latter. The only way such a reference can move is via a fetch or a push. In particular, you can't rebase a remote-tracking branch.
此外， Pro Git书是正确的. 您已将git-rebase语法向后. Git的rebase按照该书中的广告进行宣传，
Besides, the Pro Git book is correct. You have got the git-rebase syntax backwards. Git's rebase works as advertised in that book,
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
将是:
A'--B'--C' topic
/
D---E---F---G master
要解决问题，请举一个婴儿的例子，您可以在家中复制它:
To fix ideas, here is a baby example that you can reproduce at home:
#!/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
以下是显示相同历史记录的更好看的图形:
Here is a nicer-looking graph showing the same history:
现在，如果您运行
git rebase master kidscominghome
，然后运行相同的git log命令，您应该看到
and then run the same git log command, you should see
* 2acf37d (HEAD, kidscominghome) add beer
* dfac4a8 add yoghurt
* 5a0e340 (master) replace celery by cauliflower
* 7dc55b7 replace pears by apples
* 7079948 add shopping list
同样，这是显示相同历史记录的外观更好的图形:
Again, here is a nicer-looking graph showing the same history:
如广告所示，kidscominghome分支已被检出，并且仅在master上已重放只能从kidcominghome访问的提交；不是相反的方式！
As advertised, the kidscominghome branch has been checked out, and the commits that were only reachable from kidcominghome have been replayed on top of master; not the other way around!
这篇关于Pro Git书有向后git-rebase的语法吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
