Git:从上游转向开发分支

Question

我有本地master和develop分支机构.我完成所有工作develop,然后将它们合并到master发行版中.有一个远程分支,upstream/master它有我想要的更改,但我想在develop其更改之上重新定义我的更改(它共享一个共同的祖先)并将它们重新放入develop.我已经完成了git fetch upstream.

关于变基的Git书籍章节说:

$ git checkout experiment
$ git rebase master

我(假设)在我的情况下意味着:

$ git checkout upstream/master
$ git rebase develop

但后来我会upsteam/master处于独立的头状态.但是,如果我合并了upstream/master,我就会这样做develop,并且会有变化develop,例如

$ git checkout develop
$ git merge upstream/master

所以这种反叛的方式对我来说似乎很落后.我想develop在develop分支上重新定义我的更改,其变化upstream/master类似于合并的工作方式.我是否应该进行rebase upstream/master,修复任何冲突,然后添加它,将其存放并弹出develop？

希望这是有道理的,有人可以帮助我,我将非常感激.

Answer 1

最简单的(对每个人来说最明显的)方法是首先更新你的master分支,然后重新定义到更新的master,现在完全相同origin/master:

$ git fetch origin                    # Get updates from remote.
$ git checkout master                 # Now bring master into sync:
$ git merge --ff-only origin/master   # if this fails you have stuff
                                      # in your master that they don't
                                      # have in theirs, and you need
                                      # to decide what to do about it

在这一点上,如果一切顺利,master并且origin/master是相同的(你可以看到像图形观众一样gitk,或者有git log --graph --oneline --decorate),应该清楚git rebase master它将如何工作.

但你实际上并不需要这样做.你可以在上班的git rebase origin/master同时develop.(这将使你master在某个时刻未进-ED-想必你会希望它前进-ED-所以它不是真正的节省您很多,但是它是现在容易的事情.)

长期枯燥的"为什么"的一部分:git rebase需要,在其漫长的形式,三个点,该文档描述为newbase,upstream和branch:

git rebase ... [--onto <newbase>] [<upstream>] [<branch>]

如果您指定只有一个参数,如git rebase master,名称的upstream无一不newbase和branch计算.该branch是当前分支(即HEAD,它不能脱离).如果省略--onto,则将newbase其作为upstream参数.所以,如果你在develop现在,并在运行git rebase X中,branch就是develop两者newbase并upstream有X.

实际上,rebase方法(有各种内部优化,对reflog的影响有点不同):

1. 查看 branch
2. 将reference(ORIG_HEAD)保存到提交branch点
3. 将它(a la git reset --hard)重置为newbase
4. 对于upstream..ORIG_HEAD^1中的每个提交(从最旧到最新的顺序),git cherry-pick提交将其添加到刚刚重置分支.

因此,如在文档中:

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

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

当git rebase master你得到:

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

(我在这里做的就是在手册页中添加ORIG_HEAD标签并添加标签HEAD=,以显示原始提交"仍在那里",这HEAD是对它的引用topic).

那么,如果你拥有你的develop并且master他们拥有master一些额外的变化会发生什么呢？让我们画出:

A -- B -- C                         master
          | \
          |   D                     origin/master
          |
          E -- F                    HEAD=develop

现在你git rebase origin/master:

A -- B -- C                         master
          | \
          |   D                     origin/master
          |     \
          |       E' -- F'          HEAD=develop
          |
          E -- F                    ORIG_HEAD

在某些时候,你最终会移动你自己master指向提交D(并且你放弃ORIG_HEAD)给予:

A -- B -- C -- D                    master, origin/master
                 \
                   E' - F'          HEAD=develop

这与移动的一些标签是一回事.

这就是分支标签的全部,它们只是标签.每个标签指向一个(单个)提交.提交本身指向以前的提交,这是构建提交树(或"提交DAG",实际上).

^1种语法隐藏了很多"深层魔法".这意味着"所有可从标签无法访问的提交都是无法从标签访问的.这正是需要挑选的提交集合,因为那些是在"rebase"操作之前已经启用但未启用的提交它看起来像是一个基于时间的序列乍一看,而且通常在人们的头脑中起作用,但它基于提交图拓扑.有时候这会使人们绊倒:,在哪里根本不相关(因为repo中的多个提交树),意思是"每个修订版本都可以从.Git's X..YYXbranchupstreamA..BABB

Answer 2

反叛实际上是:

git checkout develop
git rebase upstream/master

(git rebase应该读取:"在我的当前分支,在这里develop,在目标分支的顶部,这里upstream/master")

最终的结果不是一个独立的头,而是新重写的develop分支.