Sourcetree 上进行git-flow功能测试（超级详细）

声明：本文参考了以下链接的内容。非常感谢。如侵权，请联系我删除。
参考链接
一、在开源中国上添加项目。

二、克隆项目到本地仓库。克隆完成后，只有一个master分支。

三、对工作流进行初始化
克隆完成后，得到的是发布后的master源码，如果想要获取最新的正在开发中的源码，需要对项目流进行初始化，点击“Git工作流”

四、点击确定按键后，可以得到develop的开发分支。

所有的开发任务都是在develop上进行的，也就是说master分支只是一个傀儡政权，真正在做事情的是develop。

五、分支的类型。
分支共有5种类型

　　1) master，最终发布版本，整个项目中有且只有一个

　　2) develop，项目的开发分支，原则上项目中有且只有一个

　　3) feature，功能分支，用于开发一个新的功能

　　4) release，预发布版本，介于develop和master之间的一个版本，主要用于测试

　　5) hotfix，修复补丁，用于修复master上的bug，直接作用于master
六、功能分支的作用。
master和develop上文中已介绍过，当开发中需要增加一个新的功能时，可新建feature分支，用于增加新功能，并且不影响开发中的develop源码，当新功能增加完成后，完成feature分支，将新功能合并到develop中，更新develop上的代码。

七、建立新的功能分支。
鼠标点击Git工作流，选择建立新的功能。

功能分支建立完毕后的效果如下：

八、添加三个功能，并分别进行三次不同的提交。

如果此时将分支切换到develop和master上，发现文件夹下并没有新增这三个文件，说明，在feature分支下进行操作，并不影响到master和develop分支下的源码。

九、假设功能全部完成，那么将feature下的源码合并到develop分支下。
将当前分支指向F_add_feature分支下，然后点击git工作流下的完成功能。

将feature分支下的源码合并到develop分支下，同时自动删除feature分支。合并成功后的效果如下。

八、多人协作开发。
这种情况常见于大型项目的情况下，对项目进行分工，每个人负责实现项目的某个功能，然后再将不同的功能进行合并。
但是，当多个人对同一个文件进行操作时，就会出现合并冲突，此时需要某一个工程师进行手动修改，并且确保所有的功能都正常运行时，再进行提交。

下面对这种情况进行模拟。
在develop分支下新建两个功能分支，分别对feature1文件进行修改。
1、F_add_feature1对feature1文件修改如下，然后进行提交。

2、提交后的情况如下。

3、将当前分支切换到F_add_feature2分支下。
打开文件夹，可以看到该分支下的feature1文件并没有被修改。现在对其进行如下修改。

4、暂存后，提交文件到本地仓库。

5、分别将两个功能分支合并到develop分支。
将当前分支切换到F_add_feature1分支下，然后年级Git工作流。选择完成功能。

可以看到F-add_feature1分支已经被合并到develop分支了。

6、将F_add_feature2分支合并到develop分支。
将当前分支切换到F_add_feature2分支下，点击Git工作流。选择完成功能。

会出现如下的错误。

打开feature1文件，可以看到如下所示。

出现<<<<<<< HEAD、=======、>>>>>>> feature/F_feature_2，HEAD和=号之间表示当前分支下的代码，=号和>>>>>>> feature/F_feature_2之间表示要合并的分支下的代码，>>>>>>> feature/F_feature_2表示了要合并的分支的分支名称。

根据实际的情况，进行修改。一定要确保修改后的文件可以完成合并之前的全部功能。

将修改后代码进行提交。

一旦出现feature合并冲突，要合并的feature分支不会被删除，如F_feature_2，确保合并没有问题后，可手动删除F_feature_2。

九、开发到一定阶段就到了项目上线的时候了，这个时候就需要对外发布版本。
1、我们可以从develop分支下建立Realease分支，进入预发布测试阶段。点击Git工作流，选择建立新的发布版本。

2、R_v1.0为阶段性发布版本，主要用于发布前进行测试，后续的开发工作仍旧在develop上进行，如果在测试过程中发现问题，直接在release上进行修改，修改完成后进行提交。
3、、假设在测试过程中，发现了一个bug。需要向feature2中添加一段代码。如下。

4、修改后，提交到本地仓库。

5、对release分支R_v1.0进行修改后，测试完成，可以进行正式发布，在当前分支指向R_v1.0分支下，点击“Git工作流”，选择“完成发布版本”

在预览中可以看到，R_v1.0向develop和master分别合并，点击确定，完成正式发布。

6、完成合并后，默认指向develop为当前分支，master增加多个版本更新，将master分支推送到origin，完成线上发布。

推送到远程仓库后，如下所示

十、正式版本发布后，develop可继续进行后续开发，当正式版本出现问题时，需要进行问题的修改，可以在master分支建立修改补丁hotfix。将当前分支切换到master，点击“Git工作流”，选择“建立新的修复补丁”。

假设，这个bug是要在feature3中，添加一段代码。
在该分支下进行master的问题修改，修改完成后进行提交。

提交到本地仓库。

当所有补丁问题修改完成后，点击“Git工作流”，选择“完成修复补丁”。

预览中，H_fix_1向master和develop分别合并，点击确定，完成分支合并。

合并完成后，默认当前分支为develop，master分支有版本需要更新，当前分支切换为master，进行推送，完成补丁修复。