git rebase基础知识 [英] git rebase basics

查看:179
本文介绍了git rebase基础知识的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近已经开始使用 git rebase ,并不是100%确定我做得对。为了这个问题,有两个来源分支, master next ,它是从

由于上一次同步, master 2提交和下一步 6:

  $ 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

当我签出 next 并执行 git rebase -i origin / master ,我得到以下内容:

  $ git status 
#在分支上下一个
#你的分支和'origin / next'已经分开了,
#并且分别有8个和6个不同的提交。

最后在执行 git pull --rebase 中, master 的两个提交位于 next 中:

  $ git log --oneline origin / next..next 
8741d09主提交#2
485a811主提交#1



  1. 这是正确的方法吗?

    / li>
  2. 为什么在 pull --rebase 中有 8和6 不同的提交运行?

  3. 是否可以简化流程?



  4. 非常感谢: p>

    解决方案

    让我们从头开始。以下是您的原始状态图:

     
    ABC(master,origin / master)
    \
    DEFGHI当您签出下一个并重新发布<$>
    $ / pre>

    c $ c>下一个 origin / master ,它在两个已经在 origin /主。这些新的提交具有主提交#2(在我的图中是 C )作为它们的祖先,而不是它们的原始祖先,其中 origin / master origin / next 在我的图中有分歧( A ),所以它们的哈希值将会不同。我相信这就是为什么你会看到 next 具有来自 origin / next 的8个不同的提交的原因:来自 origin / master 以及位于 origin / next 上的6个rehashed提交。



    > git checkout next之后;你应该有这样的:

     
    ABC(master,origin / master)
    \\
    \ D'-E'-F'-G'-H'-I'(next)
    \
    DEFGHI(origin / next)

    您可以看到 next 确实有8个不在 origin / next origin / next 确实有6个提交不在 next 。当然,这只是根据提交的SHA-1哈希值。如果你< git diff origin / next next - 实际内容应该非常密切地匹配 - diff应该只显示 B C (如图所示)。

    当您执行 git拉--rebase ,同时仍在,它从源获取更改(远程 origin / next )并将当前分支( next )重新绑定到该远程计算机上。这会导致出现 origin / next 中的下一个但不是 在新的下一个分支之后 origin / next 之后。它应该看起来像这样:

     
    ABC(master,origin / master)
    \
    DEFGHI(原点/下一个)
    \
    B'-C'(下一个)

    如果这是您想要的历史图看起来像,那么你已经成功了。然而,我怀疑你真的想看起来像中间图,特别是如果 next 是一个功能分支,您正在开发下一个项目, master 用于稳定代码和小错误修复。如果是这样,那么你应该完成 git push 而不是 git pull --rebase 以使远程反映你的版本的历史而不是其他方式。


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

    Since last sync between the two, master had 2 commits and next 6:

    $ 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 next and execute git rebase -i origin/master, I get the following:

    $ 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 master are in 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 6 different commits until pull --rebase is run?
    3. Is it possible to simplify the flow?

    Much obliged :)

    解决方案

    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 next and rebased next onto origin/master, it created 6 new commits after the two that are already on origin/master. These new commits have "master commit #2" (C in my diagram) as their ancestor, not their original ancestor where origin/master and origin/next diverged (A in my diagram), so their hashes will be different. I believe this is why you'll see that next has 8 different commits from origin/next: the 2 from origin/master and the 6 "rehashed" commits that were on origin/next.

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

    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 next does have 8 commits that aren't on origin/next, and origin/next does 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 B and C (as labeled in the diagram).

    When you do git pull --rebase while 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 next but not in origin/next to appear after origin/next on the new next branch. It should look like this:

    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 next is a feature branch where you're working on the next piece of the project and master is for stable code and small bug fixes. If so, then you should have done git push instead of git pull --rebase to make the remote reflect your version of history instead of the other way around.

    这篇关于git rebase基础知识的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆