共计 2138 个字符,预计需要花费 6 分钟才能阅读完成。
【待更新最新最全流程】克隆完成后,得到的是发布后的 master 源码,如果想要获取最新的正在开发中的源码,需要对项目流进行初始化,点击“Git 工作流”
直接点“确定”,获取 develop 分支源码
开发任务都是在 develop 分支上完成的
4. 分支共有 5 种类型
1) master,最终发布版本,整个项目中有且只有一个
2) develop,项目的开发分支,原则上项目中有且只有一个
3) feature,功能分支,用于开发一个新的功能
4) release,预发布版本,介于 develop 和 master 之间的一个版本,主要用于测试
5) hotfix,修复补丁,用于修复 master 上的 bug,直接作用于 master
5. master 和 develop 上文中已介绍过,当开发中需要增加一个新的功能时,可新建 feature 分支,用于增加新功能,并且不影响开发中的 develop 源码,当新功能增加完成后,完成 feature 分支,将新功能合并到 develop 中,更新 develop 上的代码
1) 新建 feature。首先当前开发分支指向 develop,点击“Git 工作流”
选择“建立新的分支”
在预览中可看到,feature 分支是从 develop 分出的,输入功能名称,点击确定,项目结构中增加 feature 分支,并且当前开发分支指向新建的 feature 分支
2) 在 F_add_feature 分支下进行开发任务,并提交
当切换为 develop 分支后,会发现,在 develop 下并没有新增的三个文件,说明在 feature 下进行操作,并不影响 develop 分支源码
3) 完成 feature 开发后,将 feature 中的源码合并到 develop 分支。将当前分支指向 F_add_feature 分支,点击“Git 工作流”,选择“完成功能”
预览中,表明 feature 分支将合并到 develop,点击确定,进行提交合并,合并成功后
4) 需要再增加新的功能时,重复以上操作即可
5) 当多人协作开发时,可能会出现,不同人员对同一文件进行操作,从而引起合并冲突,对这种情况进行模拟,在当前新建两个 feature,分别对 feature_1 文件进行修改,然后分别合并
先后合并 F_feature_1 和 F_feature_2,会出现冲突
点击 close,查看未提交的更改,提示 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 进行冲突修改,再进行后续操作。