git rebase使用_020

git rebase 使用

rebase:顾名思义 ==变基==

假设现在从master 分支上,切出一个本地开发分支mydev

git checkout -b mydev

这时候master上的git记录是这样子的

A-->B-->C-->D

这个时候另外一个开发人员把ta的dev分支合并到master分支了
tadev

A-->B-->C-->D
            |-->E-->F-->G

• 查看git记录

git lg or git log

实际上现在master上的分支的git 提交记录已经是这样子的了：

A-->B-->C-->D-->E-->F-->G

但是你本地上的分支还是这样的，你分别了提交了 3个 commit记录。

            |—->M-->N-->O
A-->B-->C-->D

这时，你的代码开发完成了，需要合并代码。这时候有两种选择：

直接

git merge 

或者

 经过 git rebase  再提交 git merge 

git merge

如果直接git merge,假设你提交commit的时间和刚才合并进去的其他人的dev分支是有重合的：

A-->B-->C-->D
            |-->E       |-->F-->G
                |-->M-->N       |-->O

这样的提交的记录就比较乱，假设现在需要回退代码什么的，就有点小麻烦了，就需要一个文件去回退。对于多人协作的话 就比较需要git rebase

git rebase

先对mydev分支进行 git rebase 操作

这时候分支的提交记录就会变为如下所示：

A-->B-->C-->D-->E-->F-->G
                        |-->M-->N-->O

会把mydev分支新增的commit记录新增在master分支最新的后面，这个时候push分支，就需要强制更新你的分支。再提交merge。

git push -f 

变基的作用就是修整历史，将分支历史并入主线。

git rebase 注意事项

• 确保没有其它分支同时更改同一个文件
• git rebase前需要确保master分支为最新。
• 变基会修整历史，然后将分支历史并入主线，可以理解成美化过的历史，而合并则可以不修改历史，让分支历史依然独立存在，可以看作原始的历史。
• 永远不要对已经推到主干分支服务器或者团队其他成员的提交进行变基，我们选择变基还是合并的范围应该在自己当前工作范围内。

• 如果git rebase之后提示冲突的话，需要解决冲突：

  • 解决冲突后 add 更改的文件

  git add 

  • 无需 commit, 继续 rebase

  git rebase --continue

git rebase还有一些其他的操作，

• 放弃git rebase

git rebase --abort

• 压缩最近几次提交

git rebase -i HEAD~4 合并最近4次提交

http://blog.codingplayboy.com...