最近工作用到了rebase，对于rebase还是有点懵，仔细补了一下姿势。
一般来说，使用rebase主要是为了master分支的干净，git干净对公司来说是非常重要的。
rebase使用场景及原理
对我司来说，有一版core code是全公司统一的git仓，然后每个team会再clone出自己team的git仓，和core是同步的，后台代码会时刻sync core和team code，保证他俩是一致的。这样做是因为每个team有自己的dev branch，如果都统一提交到core git上，分支会非常脏，也不便于管理，所以每个team先在自己的git上管理好自己的master，保证是自己的master是干净的，再提PR到core上。
而对于每个team自己的git仓，如何保证master是干净的呢？就要用到rebase啦。
假设你从master上checkout了一个新的branch，做了改动准备merge到master上时，忽然发现同事已经改了code，并且先你一步merge进了master！这时候你在push会发现git提示你current branch is behind！这时候你根据之前的经验，先pull了最新的master，然后修改了conflict，重新push了一般代码。这种情况肯定不少见，所以渐渐master就惨不忍睹…
而使用rebase，则能够避免这一情况。base在整个branch中大致是表示你的branch是从哪个point开始改动的，所以rebase就是换个base，把你的branch的base换成现在最近的提交版本，这样master就不会出现分支，依然是干净的。
(很沮丧，特意买了块wacom做笔记结果却如此难用…
rebase使用方法
首先从自己的分支上check到master，拉取最新的master。当你用git clone 把git仓库clone下来时，会自动将这个仓库地址设为origin，也可以自己再加一些其他仓库的地址。origin只是一个代号，名字。
git checkout master
git fetch origin
git merge origin/master
然后再checkout回自己的branch
git checkout [branch_name]
这时候使用rebase把自己的branch的base node改成最新的master
git rebase master
确认修改你自己的branch上的commit，其中有个squash命令，可以将你自己的几次commit合并成一个commit。这样保存退出后，会开始rebase，如果碰到conflict的情况，就按照旧方法修改conflict，
git rebase --continue
参考：https://git-scm.com/book/zh/v2/Git-分支-远程分支
