一、整体介绍
1、提交(提交代码到本地仓库,在拉取代码之前先提交本地修改过的文件)
2、推送(提交完之后,就利用推送,把本地库所修改的推送到服务器对应项目)
3、拉取(拉取服务器上git库代码到本地库)
4、获取(获取服务器上的变更,包括分支、标签等,如果服务器上有变更,对应的菜单上会有相应的数标出现 )
5、分支(可以在本地库创建分支,删除分支)
6、合并(合并分支,先在图标9处选择要合并到的分支,再选择12处选择要合并到的点)
7、标签(给分支中的某个点添加标签,可以用来记录版本)
8、工作副本(显示修改了还未提交的文件,或拉取时冲突的文件)
9、分支(显示本地库的分支)
10、标签(显示本地标签)
11、远程(显示远程服务器库分支及标签)
12、日志列表(显示当前分支提交的日志列表)
13、日志详情(显示某个日志的详情,也就是显示当前日志所修改的文件)
14、文件详情(显示左边单个文件所修改的内容详情)
15、工作流(当开发新功能时利用这个工作流,可很好的管理本地分支,后面详细介绍)
注:除以上之外,还有一些设置、命令行模式、贮藏、丢弃等等,大家自行摸索。
二、sourceTree工作流
当第一次点击git工作流时,会出现下图界面(配置界面,可以配置产品分支、开发分支,以及各类型分支的前缀)
配置好后再点击git工作流时,将选择你下一步将要做的模块,比如我要开发一个新的功能,当选择新的功能后,会自动生成一个分支(带有前面配置的前缀的分支)
当添加完成后,左边的分支列表会多出一个feature,这个名字就是我们前面配置功能分支前缀的默认值,在它下面会有一个test分支,test就是功能分支的名称了
注:如此就可以在此状态下开发功能了。
当开发完成后,再点击git工作流,会弹出一个框,选择“完成功能”然后直接确认
注:以上操作完成后,再看左边分支,工作流的分支不见了,自动合并到了我们的develop开发分支
三、分支介绍
1、分支共有5种类型
1) master,最终发布版本,整个项目中有且只有一个
2) develop,项目的开发分支,原则上项目中有且只有一个
3) feature,功能分支,用于开发一个新的功能
4) release,预发布版本,介于develop和master之间的一个版本,主要用于测试
5) hotfix,修复补丁,用于修复master上的bug,直接作用于master
2、master和develop上文中已介绍过,当开发中需要增加一个新的功能时,可新建feature分支,用于增加新功能,并且不影响开发中的develop源码,当新功能增加完成后,完成feature分支,将新功能合并到develop中,更新develop上的代码
1) 新建feature。首先当前开发分支指向develop,点击“Git工作流”
选择“建立新的分支”
2) 在F_add_feature分支下进行开发任务,并提交
以上操作分别增加了feature_1、feature_2、feature_3文件,共提交3次,现项目文件夹下共三个文件
当切换为develop分支后,会发现,在develop下并没有新增的三个文件,说明在feature下进行操作,并不影响develop分支源码
3) 完成feature开发后,将feature中的源码合并到develop分支。将当前分支指向F_add_feature分支,点击“Git工作流”,选择“完成功能”
预览中,表明feature分支将合并到develop,点击确定,进行提交合并,合并成功后
4) 需要再增加新的功能时,重复以上操作即可
5) 当多人协作开发时,可能会出现,不同人员对同一文件进行操作,从而引起合并冲突,对这种情况进行模拟,在当前新建两个feature,分别对feature_1文件进行修改,然后分别合并
feature_1在feature_1.txt下做如下操作
feature_2在feature_1.txt下做如下操作
先后合并F_feature_1和F_feature_2,会出现冲突
点击close,查看未提交的更改,提示feature_1.txt出现冲突,
打开feature_1.txt
出现<<<<<<< HEAD、=======、>>>>>>> feature/F_feature_2,HEAD和=号之间表示当前分支下的代码,=号和>>>>>>> feature/F_feature_2之间表示要合并的分支下的代码,>>>>>>> feature/F_feature_2表示了要合并的分支的分支名称,
根据情况区分要保留的代码,要删除的代码,最后再删除<<<<<<< HEAD、=======、和>>>>>>> feature/F_feature_2
将修改的代码再进行一次提交
一旦出现feature合并冲突,要合并的feature分支不会被删除,如F_feature_2,确保合并没有问题后,可手动删除F_feature_2
6. 当开发到一定阶段,可以发布测试版本时,可以从develop分支,建立release分支,进入预发布测试阶段。点击“Git工作流”,选择“建立新的发布版本”
预览中可以看到,release是从develop分出的,输入发布版本名‘R_v1.0’,点击确定
R_v1.0为阶段性发布版本,主要用于发布前进行测试,后续的开发工作仍旧在develop上进行,如果在测试过程中发现问题,直接在release上进行修改,修改完成后进行提交
7. 对release分支R_v1.0进行两次修改后,测试完成,可以进行正式发布,在当前分支指向R_v1.0分支下,点击“Git工作流”,选择“完成发布版本”
在预览中可以看到,R_v1.0向develop和master分别合并,点击确定,完成正式发布。
完成合并后,默认指向develop为当前分支,master增加多个版本更新,将master分支推送到origin,完成线上发布
8. 正式版本发布后,develop可继续进行后续开发,当正式版本出现问题时,需要进行问题的修改,可以在master分支建立修改补丁hotfix。将当前分支切换到master,点击“Git工作流”,选择“建立新的修复补丁”
预览中hotfix分支是从master拉去出来的,输入修复补丁名,点确定
在该分支下进行master的问题修改,修改完成后进行提交。当所有补丁问题修改完成后,点击“Git工作流”,选择“完成修复补丁”
预览中,H_fix_1向master和develop分别合并,点击确定,完成分支合并。
合并完成后,默认当前分支为develop,master分支有版本需要更新,当前分支切换为master,进行推送,完成补丁修复。
9. 在完成发布版本和完成修复补丁时,如果遇到冲突,可仿照上述5进行冲突修改,再进行后续操作