目录
- 合并冲突:merge☞手动解决☞提交
- 没有合并冲突:merge(包含了提交)
- 初学git请画图操作,画图清晰明了。
1.分支策略
Git分支管理需要遵守的几个基本原则:
- 线上环境:用户能够正常访问的内容都属于线上环境。
- 线上环境非常稳定(不能出现卡顿、退出程序,这些情况都是不被允许的)所以,线上环境要求是稳定且严格。
- 线上跑的代码是master主分支的代码。master分支必须是稳定的,才可以保证线上环境是稳定的。才可以部署在线上环境。
日常开发环境:开发人员提交的代码,还未经过测试验证。(是不稳定的,存在Bug)用户不可能访问日常开发环境的。
测试团队:公司里面常常存在一些测试团队。帮助测试开发好的代码。经过一系列的测试,最终将稳定的代码合并到master分支上。
综上所述:可以体现Git分支的重要性。没有分支管理是不能完成上述这套流程的。
线上环境跑的代码都是master主分支的稳定代码(都是稳定的提交)
增加一个新的功能(需要开发):基于master的最新一次提交创建一个新的分支dev1。
若同时又增加了多个新功能,所以同时基于master创建多个分支dev2 dev3.....多个开发人员同时协同开发。
分支管理策略:Git在项目中可以实施 ——多人协作开发
合并分支推荐使用❗:no-ff模式
开发完成测试稳定之后,提交之后,再和master主分支合并(no-ff模式),有冲突解决冲突提交,没有冲突直接合并再提交。
【合并冲突no-ff模式】
【没有合并冲突no-ff模式】
2.特殊场景-Bug分支
2.1 master出现bug
介绍下在使用git的时候遇到一个场景:
- 线上环境是一个稳定的环境。它部署的是master主分支上的代码。master主分支上的代码就是一个稳定的代码。
- 我们日常生活中使用网站,APP都遇到过卡死,退出这个网站的情况。(线上环境也不是100%稳定的)此刻就是master主分支的代码出现了bug。
如何处理这种情况呢❓直接在master主分支去进行代码的修复吗❓不可以。
回答:
就是基于当前master的最新一次提交记录,创建一个bug分支。
再bug分支上,去修改这个bug。当这个bug修改完,再在分支上提交了,再切换至master合并(no-ff模式)即可。
2.2 dev2正在开发☞stash区域
有如下情景:
- 基于master创建一个dev2分支,并且在dev2分支上开发了新增功能部分代码(正在开发....),且并没和master合并提交。
- file2文件是只有一份的。在dev2上开发新功能的代码时(没有提交),切换至master也可以看到file2文件开发代码。(只是影响工作区)
- 虽然没有影响本地仓库,但是我们此刻任然不想对master分支工作区的文件做出任何修改。仅仅只在dev2分支上修改开发。(切换到master的时候并不会影响它)
怎么解决呢❓
回答:
需要先切换到dev2分支上。将新功能开发的代码保存在版本库中stash区域。
使用的命令:git stash
stash区域使用:
- git stash :将开发的代码存储进stash区域。
- stash区域:保存工作区的修改内容。(保存之后此刻dev2和master的ReadMe文件都没有)
- stash区域:.git仓库版本库里 存在一个区域称为stash,保存工作区的文件的修改
- 注意:里面存储的是已经被git追踪管理的文件的内容,没有被.git追踪管理的文件是不会被stash保存的。
- 修复完bug,把stash区域保存的file2新功能开发的内容恢复到dev2分支上继续开发。
- git stash list : 展示stash区域存储哪些文件
- git stash pop:将stash区域存储的内容,恢复到dev2分支上继续开发
【出现问题☞切换至master,master中有dev2上开发的代码】
【保存至stash区域】
【保存至stash区域之后☞master和dev2分支上新功能开发的代码都不在了】
【没有被git追踪管理文件不会被存储在stash里面】
【把stash区域存储的内容恢复到dev2分支上】
2.3 dev2正在开发master出现bug
2.3.1 fix_bug修复bug和master合并
在以上情景基础上(下面例子我们以file2文件为例):
- 首先基于master创建一个dev2分支,并且在dev2分支上开发了新增功能部分代码(正在开发....),且并没和master合并提交。
- 此时,在开发的过程中,我们发现master分支上出现了一个bug。
如何处理这种情况❓能够直接在dev2上去修复代码吗❓
回答:
不能直接在dev2上进行bug修改,违背dev2分支创建的初衷。(dev2是用来开发代码分支)所以我们需要基于master重新创建一个bug分支去修改master的bug。
假设:bug是hello liuxn应该是hello git
- 先将dev2开发的代码保存在stash区域
- 切换至master分支
- 基于master创建一个fix_bug分支(用于修改master的bug)
- 切换至fix_bug分支,修改bug
- 切换至master分支,合并fix_bug分支(no-ff模式)
- 删除fix_bug分支
- 切换至dev2分支,继续开发....(在dev2分支上bug没有修复,不影响)(原因:dev2是基于master有bug版本创建的)
- 开发完成,切换至master分支,合并dev2分支(no-ff模式)
- 删除dev2分支
2.3.2 dev2分支开发完和master合并
解决master和dev2分支合并冲突问题
第一种方式:手动解决☞很可能出现新的bug
第二种方式(推荐使用):
- 切换至dev2分支上合并master。
- 就算有冲突也可以在dev2本地分支上修改,不影响master分支。dev2上修改,并不影响master主分支。
- 在master合并dev2的分支之前,先在dev2分支上和master合并,并修改好合并冲突以及存在的bug。
- 再切换至master分支合并dev2。
【代码演示】