一、分支介绍
在版本控制过程当中,有时候需要同时推进多个任务,这样的话,就可以给每个任务创建单独的分支。
有了分支之后,对应的开发人员就可以把自己的工作从主线上分离出来,在做自己分支开发的时候,不会影响到主线分支的运行。
如图所示:
- 要开发个新功能,加个蓝色背景。那么从master上建一个分支feature-blue,开发完后,合回到master。
- 同时另外一个新功能也要做,给系统加个小游戏。同样上建一个分支feature-game进行开发。
- 发现feature-blue上有个bug,那么再从master上建一个热修复分支hot-fix进行bug修改,完事后合到master。
所以,在众多分支并行开发的时候,master上的代码是正常在服务器上运行的,不会被影响。
故使用分支有如下优点:
- 同时并行推进多个功能开发,提高开发效率。
- 各个分支在开发过程中,如果某一个分支开发失败,不会对其他分支造成影响。失败的分支可以删除掉重新开始即可。
二、分支操作
1. 查看分支
git branch -v
可以查看当前本地库有多少分支,其中*
表示当前所在的分支。
2. 创建分支
git branch 分支名
创建完成后,再次查看分支,就可以看到新建的分支hot-fix
。
3. 切换分支
当前所在还是master分支,我不想动master分支的内容,希望在hot-fix
分支上进行修改,那么现在切换到目标分支。
git checkout 分支名
已经切换成功。
现在我可以在hot-fix分支下进行文件内容的修改了,我改动hello.txt的第一行内容。
然后git add hello.txt
和git commit -m "hot-fix first commit" hello.txt
。
用cat hello.txt
可以查看文本内容,在git里 linux命令通用。
4. 合并分支
正常合并
在hot-fix
修改完内容提交之后,现在切换回master分支,并且查看文件内容,发现还是原来的样子,没有受到影响。
现在我要把hot-fix
上的内容合并到master
上:
git merge 分支名
注意,这里是把命令行后输入的分支 合并到 当前所在分支,所以我先要切回到master
上,才可以把hot-fix
合过来。
合并完成,查看master分支上的文件内容,发现hot-fix上新增的内容已经合并了过来。
冲突合并
合并分支时,两个分支在同一个文件的同一个位置有两套完全不同的修改,这就产生了冲突,这也是团队协助中最常见的场景之一了。
此时,git无法决定使用哪一个,所以必须人为的决定新代码的内容。
现在来造成一个冲突的场景:
- 在
master
分支,在hello.txt的最后一行末尾,增加新内容-"master test"。 - 切换到
hot-fix
分支,在hello.txt的最后一行末尾,增加新内容-"hot-fix test"。 - 切换到
master
分支,合并hot-fix
分支。
提示自动合并失败,因为在hello.txt
里面产生了冲突,此时查看git status
,也可以看到提示。
OK,git处理不了,只能我们亲自出马了。此时可以打开文件vim hello.txt
,会发现在文件里有冲突的提示。
有3个提示:
-
<<<<<<< HEAD
,表示当前分支。 -
=======
,相当于分界线,等号与上面的HEAD之间,是当前分支的代码。等号与下面的 hot-fix,是要合并过来的代码。 -
>>>>>>> hot-fix
,要合并过来的分支。
现在我手动处理,希望2个分支的代码都保留,那么我留下这2行代码,把其余的提示信息去掉即可。
完成后进行git add hello.txt
。
注意,在接下来的git commit操作中,就不要带文件名了,否则会报错,如下:
git此时还是不知道用哪个分支的hello.txt,所以提交的时候不要带文件名了。
可以看到合并成功,接着查看下文件内容,cat hello.txt
,结果如愿以偿。
注意,这里合并时候的修改,也只是改了master
分支的文件内容,hot-fix
分支是不受影响的,可以切到hot-fix
查看文件内容便知。
分支原理
跟版本切换一样,分支切换的底层同样是指针。
上面的2个分支master
和hot-fix
,其实都是指向具体版本记录的指针。而当前所在的分支,其实是有HEAD决定的,HEAD指向哪个分支,现在就在那个分支上。
所以,创建分支的本质就是多创建一个指针,故切换分支的本质就是移动HEAD指针。
接下来是git的团队协助相关内容。