本文介绍了Pro Git书有向后git-rebase的语法吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

正如标题所示.我最近尝试运行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手册页中,

      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的语法吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-24 04:02