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...