git个人理解就两个作用
第一：让master分支代码看着起来整洁
第二：合并一些提交

说一下老生常谈的场景master分支和dev分支，真是场景肯定不会就两个分支，下面用m代表master，d代表dev

先说低一点：让master分支代码看着起来整洁
假如m分支有第一个提交“frist commit”，接下来产品来需求了，你肯定git checkout -b dev到d分支，你开发这个功能用了30天每天下班你commit一次，这时候你的d分支就有了d1、d2、d3…到d30，假如你是大神开发的代码一个bug都没有通过了测试，现在要合并到master上了，这时候需要执行git rebase master，这句话什么意思呢？rebase英文翻译变基，通俗点变一个基础，假设git提交就是盖楼房，如果你有2个分支就好比盖了两栋房子，m楼和d楼，每栋楼都有自己的地基，你在m楼先盖了一层“frist commit”然后去盖d楼了，你盖了30层（d1、d2、d3…d30），现在说给你d楼的地基变成了m楼，什么意思呢？就是说在你d楼下面先盖一个和m楼一样的然后把d楼再盖上去。这在现实里肯定不可能是吧，但是你就想象git是一个特牛逼的包工队，他先把d楼给用老吊车给吊了起来（等同于git先用临时文件保存d分支）然后在d楼下面盖了一个和m楼一模一样的目前只有一层“first commit”，然后再用老吊车把d楼放了上去，这就是git rebase master，这时候你的m楼和d楼第一层是一样的了是不是？
现在最后一步了，最终你要交付给产品的是m分支你还是需要把d分支的合并上去，git checkout master，git merge dev，这两句很好理解了吧，相当于你最后交付给产品的是m楼，git包工队又回到了m楼（git checkout master），然后要把d楼盖好的30层楼用老吊车给吊过来放上去。就实现了frist commit 、d1 、d2、d3 …d30楼的壮举。

再说第二点：合并一些提交
现实开发中的产品肯定是不断的迭代，例如一个月一个大版本，你的master分支上应该只保留你大版本的提交，比如frist commit 、功能1、功能2、功能3…，而不应该把每一个功能具体的实现细节也保留在master分支，假设功能1的开发人员水平很差疯狂的debug提交了1000个commit，那你的master分支还能看吗？master分支上的每一个提交都应该有价值的，比如功能3上线后有问题可以立刻回退到功能2，如果你的master分支脏乱差，真的该好好想一想。所以就要用到rebase -i commit id,把多个提交合并成一个提交，比如刚才说的那个1000个commit的同学，就应该好好用一下这个命令。这个命令自己百度一下吧，讲的人很多我就不复制粘贴了。