git rebase 变基

git-rebase-变基

rebase 变基

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

git rebase 变基场景描述：

  • 两个分支master、dev，其中dev分支是在master分支上的提交点E拉出的分支
  • 在两个分支合并之前，master分支有了新的提交F、G
  • 此时合并dev分支到master分支是不被允许的
  • 因为git不知道怎么处理ABC与FG的关系了，会提醒你需要先在本地rebase

变基： 简单说就是修改dev分支的基础节点由E变到G

通俗解释：

rebase，变基，可以直接理解为改变基底。dev分支是基于master分支的E拉出来的分支，dev的基底是E。而master在E之后有新的提交，就相当于此时要用master上新的提交来作为dev的新基底。实际操作为把E之后dev的提交存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（新节点新commit id），如此dev分支的基底就相当于变成了G而不是原来的E了

具体操作

由于master是主分支，所以我们都是去改变其它分支的基，故先切到需要变基的分支

无冲突rebase

    # 没有冲突的情况下，依次执行如下步骤即可
    git checkout dev

    git rebase master -i   (-i表示交互模式)

    git push -f     (因为修改了commit记录，需要强push)

有冲突rebase

    git checkout dev

    git rebase master -i   (-i表示交互模式)
    # 有冲突时，到这一步已经开始报错，这时需要手动解决冲突才可以
    git rebase --continue
    # 如果没有冲突，则说明已经可以继续后一步了，但是如果还有冲突，则需要不断处理冲突并执行这一步，知道没有冲突报错为止
    git push -f     (因为修改了commit记录，需要强push)

git rebase 产生冲突的处理方式

  1. git rebase –skip

抛弃本地的 commit，采用远程的 commit。慎用：因为你本地的修改都会失去。

  1. git rebase –abort

效果是：终止这次 rebase 操作

  1. git rebase –continue

手动处理冲突的文件：执行git add .，再 git rebase –continue，反复操作直到解决完所有冲突，并合并到分支上。

大部分公司其实会禁用rebase，不管是拉代码还是push代码统一都使用merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序

发表回复