前言
在本文章中,我们将要详细介绍一下git中有关Git分支管理,包括理解,创建,切换,合并,删除操作相关的内容
理解分支
每次提交,Git都会把它们串成一个时间线,这条时间线就是一个分支。
截止到目前,只有一条时间线,在Git中,这个叫做主分支,及master分支
HEAD并不是指向提交,而是指向master指针,master指针才是指向提交,所以,HEAD就是指向当前分支.
每次提交,master分支就会向前移动一步,随着你不断提交,master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀
创建分支
git branch 查看当前本地所有分支
HEAD也可以指向其他分支,其中*表示当前HEAD指向的分支,被指向的分支就是当前正在工作的分支。
git branch dev 创建dev新分支
查看下面操作
我们发现master和dev指向同一个修改
切换分支
git checkout 分支名 切换分支
切换分支,HEAD指向发生改变,dev为工作分支
在 dev 分⽀下修改ReadMe⽂件,新增⼀⾏内容,并进⾏⼀次提交操作:
dev分⽀的⼯作完成,我们就可以切换回master分⽀
切换回master分⽀后,发现ReadMe⽂件中新增的内容不⻅了!!!
但是在dev分支下却存在
查看dev分⽀和master分⽀指向
切换到master分⽀之时,HEAD就指向了master,当然看不到提交了
合并分支
为了在master主分⽀上能看到新的提交,就需要将 dev 分⽀合并到 master 分⽀
git merge dev 用于合并指定分支到当前分支。
此时的状态如图所示
Fast-forward代表“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度⾮常快
删除分支
合并完成后,dev分⽀对于我们来说就没⽤了,那么dev分⽀就可以被删除掉
删除分支采用下面命令
git brabch -d
注意:如果当前正处于某分⽀下,就不能删除当前分⽀
因为创建、合并和删除分⽀⾮常快,所以Git⿎励你使⽤分⽀完成某个任务,合并后再删掉分⽀,这和直接在master分⽀上⼯作效果是⼀样的,但过程更安全
合并冲突
对同一个文件在不同分支下进行修改,并合并提交,系统不知道提交哪个,代码冲突。
首先介绍一个命令
git branch -b
创建分支并且切换到该分支下
在dev分支下进行修改并且进行提交
切换到master分支进行修改并提交
进行合并就会发生冲突
打开文件内容进行观看
Git会⽤<<<<<<<,=======,>>>>>>>来标记出不同分⽀的冲突内容
这是需要我们对不要的文件内容进行手动删除在进行提交
此时冲突就解决了
同时可用下面命令查看分支合并情况
git log --graph --pretty=oneline --abbrev-commit
最后对dev分支进行删除
分支管理策略
我们再进行分支合并时,常用的就是fast forward模式,,但是我们删除分支之后,再查看分支信息,就看不出最新提交是merge进来的还是正常提交的。
合并冲突时候,我们明显看得出是合并进来的,这就不是fast forward模式了,我们就可以从分支历史上看出分支信息了。
fast forward模式是直接把master分支指向dev的当前提交,所以合并速度非常快。
我们也可以不用fast forward模式,那么在merge时就会生成一个新的commit ,这样,我们就可以从分支历史看出分支信息。
git merge - -no-ff -m “描述信息” 合并分支
我们查看一下分支合并情况。
此时状况如图所示
所以在合并分⽀时,加上 --no-ff 参数就可以⽤普通模式合并,合并后的历史有分⽀,能看出来曾经做过合并,⽽ fast forward 合并就看不出来曾经做过合并。
分支策略
在实际开发中,我们应该按照下面原则进行分支管理
1.master分支应该是稳定的,也就是用来发布新版本的,平时不能在上面干活。
2.我们干活应该在dev分支上,也就是说dev分支是不稳定的。
比如:1.0版本发布时,把dev分支合并到master分支上,在master分支上发布1.0版本。
每个人都有自己的分支,时不时往dev分支合并就可以。
团队合作的分支就像这样
bug分支
假如我们正在dev上进行开发,开发到一半,突然发现master上有bug,需要解决。我们不通过dev进行修复bug,dev是开发新需求的,而不是用来修复bug的。
我们需要通过一个新的临时分支修复,修复后,合并分支,然后将临时分支删除。
但是我们现在dev2的代码在工作区开发了一半,还无法提交,怎末办呢??
Git提供了 git stash命令,可以将当前工作区信息进行储藏,被储藏的内容可以在捡回来某个时刻回复出来。
进行git status查看工作区,就是干净的,因此可以放心的创建新分支修复bug。
新建分支修复,修复后,合并分支,然后将临时分支删除。
bug修复完毕之后,我们还需要继续回到dev分支上进行开发。
我们需要将刚才工作区的存储进行恢复
git stash list查看存了那些
git stash pop 进行恢复,恢复同时stash也会被删除
我们也可以用git stash apply恢复,但是恢复后,stash内容并不会删除,需要手动git stash drop删除
你可以多次stash,恢复的时候,先⽤ git stash list 查看,然后恢复指定的stash,⽤命令git stash apply stash@{0}
恢复之后,继续开发,开发完毕就可以进行提交了。
我们可以发现,修复bug的内容,并不会在dev上显示,此时的状态图:
master分支目前最新的提交,,是要领先于新建 dev2 时基于的 master 分⽀的提交的,所以我们在 dev2 中当然看不⻅修复 bug 的相关代码。
我们的最终⽬的是要让 master 合并 dev2 分⽀的,那么正常情况下我们切回 master 分⽀直接合并即可,但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突,⽽代码冲突需要我们⼿动解决(在 master 上解决)。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉,因为在实际的项⽬中,代码冲突不只⼀两⾏那么简单,有可能⼏⼗上百⾏,甚⾄更多,解决的过程中难免⼿误出错,导致错误的代码被合并到 master 上。
此时的状态为:
解决:
在自己的分支上合并一下master,再让master去合并dev。我们这样做目的有冲突可以在本地分支接解决并进行测试,而不影响master.
删除临时分支
添加⼀个新功能时,你肯定不希望因为⼀些实验性质的代码,把主分⽀搞乱了,所以,每添加⼀个新功能,最好新建⼀个分⽀,我们可以将其称之为 feature 分⽀,在上⾯开发,完成后,合并,最后,删除该 feature 分⽀。
可是,如果我们今天正在某个 feature 分⽀上开发了⼀半,被产品经理突然叫停,说是要停⽌新功能的开发。虽然⽩⼲了,但是这个 feature 分⽀还是必须就地销毁,留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。(没有进行合并)
我们需要用
git branch -D dev强制删除
总结
以上就是我们对Git分支管理(理解,创建,切换,合并,删除)的相关内容的详细介绍,希望对大家的学习有所帮助,仅供参考 如有错误请大佬指点我会尽快去改正 欢迎大家来评论~~~