变更分公司基础


145

我有一棵这样的树:

(commit 1) - master
                \-- (commit 2) - (commit 3) - demo
                                                \-- (commit 4) - (commit 5) - PRO

我必须将PRO分支移至主

(commit 1) - master
                |-- (commit 2) - (commit 3) - demo
                \-- (commit 4) - (commit 5) - PRO

我已经尝试过git rebase masterPRO分支,但是什么也没有发生。

澄清一下:我在master上工作,然后我必须进行产品演示(git checkout -b demo和一些提交)。然后,由于错误,我从演示(git checkout -b PRO和一些提交)创建了另一个分支,现在我需要将PRO分支移至master并完整保留演示。最后,demo和PRO都将从主机上挂起。


Answers:


281

用途--onto为:

git rebase --onto newBase oldBase feature/branch

鉴于您的情况:

git checkout PRO # Just to be clear which branch to be on.
git rebase --onto master demo PRO

基本上,您需要从之后demo到进行所有提交PRO,然后将它们重新基于master提交。


如果情况恰好相反,那也是走的路吗?==我从master的第二个分支签出-b,但是我想从第一个分支中签出。所以我做到了,git rebase --onto first-branch second-branch second-branch但我没有得到语法
— Fla

1
在这种情况下,git rebase --onto first-branch master second-branch
— @ Fla

9
我读了这个指南上--onto,他们怎么写帮助我git rebase --onto newBase oldBase feature/branch
— 加布

@PhilipRego那是不正确的。origin/newBase是分支的名称,就像newBase在我的示例中一样。这仅取决于您是要迁移到本地存储库(newBase)中存在的分支,还是远程服务器(origin/newBase)中存在的分支。
— loganfsmyth

@PhilipRego那些不是独立的东西。newBase是本地分支origin/newBase的名称,并且是远程分支的名称。您想要哪一个取决于您所依赖的基础。这并不是说一种方法有效,而另一种方法则无效,而是因为它们基于不同的事物。原始问题从不提及遥控器,因此在我的示例中使用遥控器将与所问的问题不匹配。
— loganfsmyth

22

我会尽量做到通用。首先,请确保您位于所需的分支上:

git checkout current-branch

然后使用以下命令(new-base-branch您要成为新基础的分支在哪里,而current-base-branch当前基础是该分支。)

git rebase --onto new-base-branch current-base-branch

如果您没有冲突,那就太好了-您已完成。如果您这样做(大多数情况下),请继续阅读。

可能会发生冲突,您将必须手动解决它们。Git的现在尝试做你之间的“三路合并” current-branch,current-base-branch和new-base-branch。大概这就是git在内部的工作方式:

  1. Git首先会在的基础current-base-branch上重新设置new-base-branch。可能有冲突;您将必须手动解决。完成之后,通常需要执行git add .和git rebase --continue。它将temp-commit-hash为此创建一个新的临时提交。

  2. 之后,Git现在将current-branch在之上重新建立您的基础temp-commit-hash。可能还会有其他冲突,您将不得不再次手动解决它们。完成后,您将继续使用git add .和git rebase --continue,之后您已经成功地重新current-branch建立了的基础new-base-branch。


注意:如果您开始搞砸了,则可以git rebase --abort在重新设置基准的过程中随时进行操作,然后回到起点。


rebase发布的命令只是给我“致命的:无效的上游'current-base-branch'”。另外,为什么甚至有必要告诉GIT当前分支的当前父分支是什么-它不应该知道吗?
— 马特·阿诺德

21

签出到PRO分支,复制此分支的最旧的(commit4)和最新的(commit5)提交哈希,然后粘贴到其他位置:

$ git checkout PRO
$ git log            # see the commit history
# copy the oldest & latest commit-hash 

删除PRO分支(为安全起见保留备份)。从创建并签出到新PRO分支master:

$ git branch PRO.bac    # create a new branch PRO.bac = PRO as backup

$ git checkout master
$ git branch -D PRO     # delete the local PRO branch
$ git checkout -b PRO   # create and checkout to a new 'PRO' branch from 'master'

拿(摘樱桃)前的提交的范围PRO分支到新的PRO分支:

$ git cherry-pick commit4^..commit5   # cherry-pick range of commits
# note the '^' after commit4

现在,如果一切正常,请强制(-f)推送到remote PRO分支并删除本地PRO.bac分支:

$ git log                  # check the commit history

$ git push -f origin HEAD  # replace the remote PRO by local PRO branch history
# git branch -D PRO.bac    # delete local PRO.bac branch

1

我使用复位和隐藏的方法略有不同,该方法避免了删除和重新创建分支以及避免了切换分支的需要:

$ git checkout PRO
$ git reset commit4 # This will set PROs HEAD to be at commit 4, and leave the modified commit 5 files in ur working index
$ git stash save -m "Commit message"
$ git reset commit 3
$ git stash save -m "Commit message"
$ git reset master --hard
$ git stash pop
$ git stash pop
$ git push --force # force if its already been push remotely

通过在逐次提交的基础上重置分支,您基本上可以一次回退该分支的历史记录一次提交。


您是否应该删除第四行“ commit”和“ 3”之间的空格?
— Alexis Wilke
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.