如果箭头指向的仓库类型表明“这不是一个标准的Git仓库”,可能是有以下原因:
克隆完成后,得到的是发布后的master源码,如果想要获取最新的正在开发中的源码,需要对项目流进行初始化,点击“Git工作流”
直接点“确定”,获取develop分支源码
开发任务都是在develop分支上完成的
选择“建立新的分支”
在预览中可看到,feature分支是从develop分出的,输入功能名称,点击确定,项目结构中增加feature分支,并且当前开发分支指向新建的feature分支
以上操作分别增加了feature_1、feature_2、feature_3文件,共提交3次,现项目文件夹下共三个文件
当切换为develop分支后,会发现,在develop下并没有新增的三个文件,说明在feature下进行操作,并不影响develop分支源码
预览中,表明feature分支将合并到develop,点击确定,进行提交合并,合并成功后
需要再增加新的功能时,重复以上操作即可
当多人协作开发时,可能会出现,不同人员对同一文件进行操作,从而引起合并冲突,对这种情况进行模拟,在当前新建两个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
预览中可以看到,release是从develop分出的,输入发布版本名‘R_v1.0’,点击确定
R_v1.0为阶段性发布版本,主要用于发布前进行测试,后续的开发工作仍旧在develop上进行,如果在测试过程中发现问题,直接在release上进行修改,修改完成后进行提交
在预览中可以看到,R_v1.0向develop和master分别合并,点击确定,完成正式发布。
完成合并后,默认指向develop为当前分支,master增加多个版本更新,将master分支推送到origin,完成线上发布
预览中hotfix分支是从master拉去出来的,输入修复补丁名,点确定
在该分支下进行master的问题修改,修改完成后进行提交。当所有补丁问题修改完成后,点击“Git工作流”,选择“完成修复补丁”
预览中,H_fix_1向master和develop分别合并,点击确定,完成分支合并。
合并完成后,默认当前分支为develop,master分支有版本需要更新,当前分支切换为master,进行推送,完成补丁修复。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8