git-flow分支模型

分支模型：

用 git flow 初始化工程目录完成后，只能看到两个分支（长期分支）：

master 分支： 用于上线的分支，保护性分支，只包含经过测试的稳定代码，开发人员不能直接工作在此分支上，也不能直接提交改动到 master 分支上。

develop分支： 是开发人员进行任何新的开发的基础分支，当开始一个新的feature 分支的时候，要从 develop 分出去；另外此分支也汇集所有的已完成的功能，等待合并到 master 分支上线。 上面两个分支被称为 长期分支 ，存在于项目的整个生命周期中，其他分支，是临时性的，根据需要来创建，当完成了自己的任务后，就会被删掉。

feature 分支： 平常的开发工作使用最频繁的分支。

创建功能分支： 如下命令会创建一个名为”feature/” 的功能分支，该分支默认从 develop检出，在做功能性开发的时候，检出一个独立的分支，是版本控制中一个重要 的原则。

# git-flow 创建 feature 分支

$ git flow feature start <branch-name>

完成功能分支：

# git-flow 创建 feature 分支

$ git flow feature finish <branch-name>

该命令会把我们在当前分支的代码整合到‘develop’分支中去，之后，git-flow 会进行清理操作，删除当下完成的功能分支，将分支切换到‘develop’。

release 分支：

创建 release 分支：

$ git flow release start 1.1.5

当你认为现在的‘develop’分支的代码已经是一个成熟的 release 版本的时候，这意味着：首先它包括所有新功能和必要的修复；其二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候创建 release 分支了。 note：release 分支是使用版本号命名的，这个命名方案会让 Git-flow在我们完成 release 后，适当的自动去标记那些 release 提交。

完成 release 分支：

$ git flow release finish 1.1.5

上述命令会完成如下一系列操作：

• git-flow 会拉取远程仓库，确保目前是最新的版本。

• release 内容会被合并到 master和develop两个长期分支中去。这样不仅产品代码是最新的，新开的功能分支也将基于最新的代码。

• 为了便于识别和做历史参考，release 提交会被标记上这个 release 的名字 清理操作，版本分支会被删除，并且回到 develop 分支。

note： 从 Git 的角度看来，release 版本现在已经完成，依据设置，对 master的提交可能已经触发了编译部署流程。或者手动部署。

hotfix分支：

很多时候，当对 release版本做全面测试的时候，可能就会发现一些小错误，在这种情况下，git-flow会提供一个特定的hotfix工作流程。

创建 hotfix 分支:

$ git flow hotfix start bug-fixed

上述命令会创建一个名为：hotfix/bug-fixed 的分支，这是对产品代码的修复，所以 hotfix 分支是基于 master 分支检出的。 这也是和 release 分支最明显的区别，release 分支是基于 develop 分支检出的。因为不能在一个还不完全稳定的分支上对产品代码进行修复。 就像 release 一样，修复这个错误，会直接影响到项目的版本号。

完成 hotfix分支：

$ git flow hotfix finish bug-fixed

上述命令类似于发布一个 release 版本：

• 完成的改动会被合并到 master 中，同样也会合并到 develop 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中；

• 这个 hotfix 将会被标记起来以便于参考；

• 当前的 hotfix 分支将会被删除，然后切换到 develop 分支；

note： 完成 hotfix 分支之后，自动或手动启动编译部署流程

下图为整体流程图：

主要分支 master: 永远处在即将发布(production-ready)状态

develop: 最新的开发状态

辅助分支 feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop

release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master

hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge回 master 和 develop

SourceTree的基本使用

1. SourceTree是什么

• 拥有可视化界面的项目版本控制软件，适用于git项目管理
• window、mac可用

2. 获取项目代码

1. 点击克隆/新建

 

2. 在弹出框中输入项目地址，http或者ssh地址都可以

 

　　如果箭头指向的仓库类型表明“这不是一个标准的Git仓库”，可能是有以下原因

　　　　1) 项目地址获取错误

　　　　2) 没有项目访问权限

3. 点击“克隆”，等待项目克隆完成，完成后，左侧只有一个分支master

　　克隆完成后，得到的是发布后的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分支下进行开发任务，并提交

以上操作分别增加了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进行冲突修改，再进行后续操作

SourceTree使用转载自  http://www.cnblogs.com/tian-xie/