Question

我有本地master和develop分支机构。我在develop上完成所有工作，然后将它们合并到master版本中。有一个远程分支upstream/master，它有我想要的更改，但我想在develop（它共享一个共同的祖先）的基础上更改我的更改，并将它们放回{{1 }}。我已经完成了develop。

Git book chapter on rebasing说要做：

git fetch upstream

我（假设）在我的情况下意味着：

$ 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？

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

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无法前进 - 大概在某些时候你会想要它前进 - 所以它并没有真正为你节省太多。但它是现在更容易做到。）

漫长的无聊＆＃34;为什么＆＃34;部分：git rebase以长篇形式提供三个点，文档描述为 newbase ， upstream 和< EM> branch ：

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

如果您只指定一个参数，例如在git rebase master中指定 upstream 以及 newbase 和 branch 。 branch 是当前分支（即HEAD，不得分离）。如果省略--onto， newbase 将被视为 upstream 参数。因此，如果您现在develop，并且您运行git rebase X，则 branch 为develop，并且 {{ 1}} 和 newbase 是upstream。

实际上，rebase方法（有各种内部优化，对reflog的影响有点不同）：

查看 X
将引用（branch）保存到 ORIG_HEAD 指向的提交
将其重置（la branch）至 git reset --hard
对于newbase ¹中的每个提交（从最旧到最新的顺序），upstream..ORIG_HEAD承诺将其添加到刚刚重置的分支。

因此，如文档中所述：

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，以显示原始提交是＆＃34;仍然在那里＆＃34; ，HEAD=是对HEAD）的引用。

那么，如果您拥有topic和develop并且他们的master中有一些额外的更改，会发生什么？让我们画出：

master

现在你A -- B -- C master | \ | D origin/master | E -- F HEAD=develop：

git rebase origin/master

ORIG_HEAD

这与移动的一些标签是一样的。

分支标签的全部内容，它们只是标签。每个标签指向一个（单个）提交。提交本身指向以前的提交，这是构建提交树（或者＃34;提交DAG＆＃34;，真的）。

¹ A -- B -- C -- D master, origin/master \ E' - F' HEAD=develop语法隐藏了很多＆＃34;深刻的魔法＆＃34;。这意味着＆＃34;所有从标签 Git's X..Y 可以从标签 Y 无法访问的提交。这正是需要挑选的提交集合，因为那些是 X 上的提交，而不是 branch upstream，其中A..B根本与A无关（因为回购中有多个提交树），意味着＆＃34;每个修订版都可以从B。

Answer 2

rebase实际上是：

git checkout develop
git rebase upstream/master

（git rebase应为：“将我当前的分支，此处develop，置于目标分支之上，此处为upstream/master”）

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

Answer 3

您正在寻找的命令是：

git checkout develop
git rebase upstream/master

然而，Git比这更聪明，你可以将upstream / master配置为develop的上游跟踪分支：

git branch --set-upstream-to upstream/master develop

现在当你执行git rebase时，它会自动使用'upstream / master'。但更好的是，这些命令：

git fetch origin
git rebase upstream/master

只需简单操作即可简化：

git pull --rebase

Git：从上游转向开发分支

3 个答案: