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的同学,就应该好好用一下这个命令。这个命令自己百度一下吧,讲的人很多我就不复制粘贴了。