Gitflow工作流

Gitflow工作流

Gitflow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

Gitflow工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。

Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个明确的角色，并定义分支之间如何和什么时候进行交互。 除了使用功能分支，在做准备、维护和记录发布时，也定义了各自的分支。 当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。

1. 工作方式

   Gitflow工作流仍然用*仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要*仓库中。

2. 历史分支

   相对于使用仅有的一个master分支，Gitflow工作流使用两个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。

   剩下要说明的问题围绕着这2个分支的区别展开。

3. 功能分支

   每个新功能位于一个自己的分支，这样可以push到*仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。

4. 发布分支

   一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。

   使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。

   常用的分支约定：

   用于新建发布分支的分支: develop
   用于合并的分支: master
   分支命名: release-* 或 release/*
   

5. 维护分支

   维护分支或说是热修复（hotfix）分支用于给产品发布版本（production releases）快速生成补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

   为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

6. 总结

   1. Gitflow工作流分支

      分支	作用
      master	迭代历史分支
      dev	集成最新开发特性的活跃分支
      f_xxx	feature 功能特性开发分支
      b_xxx	bug修复分支
      r_xxx	release 版本发包分支

   2. Confict冲突解决

      • 方式一

        1. 获取最新代码

           git fetch
           

        2. 对比代码

           git diff origin/dev
           

        3. 修改冲突地方后提交并推送代码

        4. 发起合并请求

      • 方式二

        1. 拉取并合并最新代码

           git pull origin dev
           

        2. 查看冲突代码

           git status
           

        3. 修改冲突代码后提交并推送代码

        4. 发起合并请求

   3. 开发流程

      流程:
      开发人员:
      	1.创建本地dev分支, 并和远程dev分支关联.
      	2.拉取最新的dev代码
      	3.创建功能分支f_xxx.
      	4.编写代码, 提交分支, 推送到远程(备份, 合并请求)
      	5.切换到dev, 删除已完成的功能分支. 重复2-5.
      	
      	* 如果代码有冲突, 有两种方式解决冲突.
      		1.检查冲突原因, 把文件修改至没有冲突.
      		2.在本地合并, 解决冲突. 再推送到远程, 请求合并
      合并请求的程序员:
      	1.收到合并请求.
      	2.处理合并请求.
      		正常合并
      		代码冲突, 拒绝合并
      小结:
      	一般来说, 谁冲突, 谁解决.
      个人习惯:
      	f_xxx: 功能开发的分支
      	b_xxx: 修复bug的分支
      	r_xxx: 发布新版本的分支