多个分支就是在版本库中有多条提交的记录线条,如下图所示,蓝色的master是一个分支,红色的dev也是一个分支,HEAD所指的是当前的分支:
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
之前我们了解到,当生成git版本库的时候,会自动生成一个master分支,是主分支,HEAD指向的是当前分支。一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:
每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。
现在我们来创建一个新的分支dev,使用命令git checkout -b dev
,表示创建了分支dev并且切换到dev分支,相当于下面两条命令git branch dev
和git checkout dev
然后可以用git branch
来查看分支,如下图所示*所指的就是当前分支:
现在的分支状况就像下面:
我们现在的当前分支是dev,现在对README.txt做个修改,添加一行create a branch named dev
然后提交
现在dev分支的工作完成了,再git checkout master
切换回master分支,切换回master分支后,再查看一个README.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:
现在,我们把dev分支的工作成果合并到master分支上,使用命令git merge dev
,表示合并指定分支dev到当前分支master上,再查看README.txt就可以看到dev分支的最新提交:
现在的分支状况就像下面:
实际上就是直接把master指向dev的当前提交,就完成了合并。
合并完分支后,甚至可以删除dev分支。使用命令git branch -d dev
,删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支:
结构图:
原文地址:http://blog.csdn.net/changjiangbuxi/article/details/45457429