git rebase 基础知识

git rebase basics

提问by David Kurid?a

I have started using git rebaserecently and am not 100% certain I'm doing it right. For the sake of the question, there are two branches in origin, masterand next, which was branched from master.

我git rebase最近开始使用，但不能 100% 确定我做对了。为了这个问题， originmaster和有两个分支，next从master.

Since last sync between the two, masterhad 2 commits and next6:

自上次两者之间同步以来，master有 2 次提交和next6 次：

$ git log --oneline origin/next..origin/master
59b5552 master commit #2
485a811 master commit #1

$ git log --oneline origin/master..origin/next
4ebf401 next commit #6
e9b6586 next commit #5
197ada0 next commit #4
4a2c3c6 next commit #3
040a055 next commit #2
84537bf next commit #1

When I checkout nextand execute git rebase -i origin/master, I get the following:

当我结帐next并执行时git rebase -i origin/master，我得到以下信息：

$ git status
# On branch next
# Your branch and 'origin/next' have diverged,
# and have 8 and 6 different commits each, respectively.

And finally after doing git pull --rebase, the two commits from masterare in next:

最后做后git pull --rebase，从两次提交master是next：

$ git log --oneline origin/next..next 
8741d09 master commit #2
485a811 master commit #1

Questions:

问题：

1. Is this correct approach?
2. Why are there 8 and 6different commits until pull --rebaseis run?
3. Is it possible to simplify the flow?

1. 这是正确的方法吗？
2. 为什么在运行8 and 6之前会有不同的提交pull --rebase？
3. 是否可以简化流程？

Much obliged :)

多谢 ：）

回答by Mike Seplowitz

Let's start from the beginning. Here's a diagram of your original state:

让我们从头开始。这是您原始状态的图表：

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (next, origin/next)

When you checked out nextand rebased nextonto origin/master, it created 6 new commits after the two that are already on origin/master. These new commits have "master commit #2" (Cin my diagram) as their ancestor, not their original ancestor where origin/masterand origin/nextdiverged (Ain my diagram), so their hashes will be different. I believe this is why you'll see that nexthas 8 different commits from origin/next: the 2 from origin/masterand the 6 "rehashed" commits that were on origin/next.

当您检出next并重新定位next到 时origin/master，它在两个已经存在的提交之后创建了 6 个新提交origin/master。这些新提交将“主提交 #2”（C在我的图中）作为它们的祖先，而不是它们的原始祖先在哪里origin/master和origin/next分歧（A在我的图中），因此它们的哈希值会有所不同。我相信这就是为什么你会看到next8 个不同的提交来自origin/next：2 个来自origin/master和 6 个“重新散列”的提交origin/next。

After git checkout next ; git rebase -i origin/master, you should have this:

之后git checkout next ; git rebase -i origin/master，你应该有这个：

A-B-C  (master, origin/master)
 \   \
  \   D'-E'-F'-G'-H'-I' (next)
   \
    D-E-F-G-H-I  (origin/next)

You can see that nextdoes have 8 commits that aren't on origin/next, and origin/nextdoes have 6 commits that aren't on next. Granted this is just according to the SHA-1 hashes of the commits. The actual content should match very closely if you git diff origin/next next-- the diff should just show the changes from Band C(as labeled in the diagram).

您可以看到next确实有 8 个不在 on 的提交origin/next，并且origin/next确实有 6 个不在 on 的提交next。当然，这只是根据提交的 SHA-1 哈希值。实际内容应该非常匹配，如果您git diff origin/next next- 差异应该只显示来自B和C（如图中标记的）的变化。

When you do git pull --rebasewhile still on next, it fetches changes from the source (the remote origin/next) and rebases the current branch (next) onto that remote. This causes the changes that were in the nextbut notin origin/nextto appear after origin/nexton the new nextbranch. It should look like this:

当您git pull --rebase在 onnext时执行此操作，它会从源（远程origin/next）获取更改并将当前分支 ( next) 变基到该远程。这导致了在变化next，但不是在origin/next后出现origin/next的新的next分支。它应该是这样的：

A-B-C  (master, origin/master)
 \
  D-E-F-G-H-I  (origin/next)
             \
              B'-C' (next)

If this is what you wanted the history graph to look like, then you've succeeded.

如果这是您希望历史图表的样子，那么您就成功了。

However, I suspect you really wanted things to look like the middle diagram, especially if nextis a feature branch where you're working on the next piece of the project and masteris for stable code and small bug fixes. If so, then you should have done git pushinstead of git pull --rebaseto make the remote reflect your version of history instead of the other way around.

但是，我怀疑您真的希望事情看起来像中间图，特别是如果next您正在处理项目的下一部分并且master用于稳定代码和小错误修复的功能分支。如果是这样，那么您应该这样做git push而不是git pull --rebase让遥控器反映您的历史版本，而不是相反。

回答by Sam

Start with the very simple steps for rebasing your branch with the master; Name;

从使用 master 重新设置分支的非常简单的步骤开始；姓名;

git-rebase

Synopsis;

概要;

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
        [<upstream>] [<branch>]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
        --root [<branch>]
git rebase --continue | --skip | --abort | --edit-todo

Description; Assume the following history exists and the current branch is "sample":

描述; 假设存在以下历史记录并且当前分支是“sample”：

 A---B---C sample
         /
    D---E---F---G master

From this point, the result of either of the following commands:

从这一点来看，以下任一命令的结果：

git rebase master
git rebase master sample

would be:

将是：

A'--B'--C' sample
                 /
    D---E---F---G master

NOTE: The latter form is just a short-hand of git checkout samplefollowed by git rebase master. When rebase exits sample will remain the checked-out branch.

注意：后一种形式只是git checkout sample后跟git rebase master. 当 rebase 退出时，sample 将保持为检出分支。

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped. For example, running ‘git rebase master` on the following history (in which A' and A introduce the same set of changes, but have different committer information):

如果上游分支已经包含您所做的更改（例如，因为您邮寄了一个应用到上游的补丁），那么该提交将被跳过。例如，在以下历史记录上运行“git rebase master”（其中 A 和 A 引入了相同的更改集，但具有不同的提交者信息）：

A---B---C sample
         /
    D---E---A'---F master

will result in:

将导致：

 B'---C' sample
              /
D---E---A'---F master

All these were the diagramatic understanding of the rebase process. Once you resolve the conflicts being found after typing git rebase masterresolve the conflicts and type git add -uto add the changed codes to the repository. after that perform the command git rebase --continueand continue resolving the conflicts and and repeating the command ;

所有这些都是对 rebase 过程的图解理解。一旦解决了在键入后发现git rebase master的冲突，解决冲突并键入git add -u以将更改的代码添加到存储库。之后执行命令git rebase --continue并继续解决冲突并重复命令；

git add -u 

and

和

git rebase --continue 

until no conflicts being found. At last the final command will be ,

直到没有发现冲突。最后的最终命令将是，

git push --force origin sample(your branch name)