Gitflow工作流

1. 为什么会使用Gitflow工作流？

在开发大型项目时，需要团队合作开发，每个人都会创建自己的分支，在各自的分支上完成自己的模块，在项目的最后会将各个分支合并起来，这时就会出现很多问题如版本迭代，版本发布，bug 修复等；这时就需要一个分支管理政策，来更好的管理我们的代码，就形成了工作流；Gitflow是最早出现的工作流，目前为止是使用率最高的工作流

2. Gitflow工作流

Gitflow工作流 定义了一个围绕项目发布的严格分支模型; 它为不同的分支分配了非常明确的角色，并且定义了使用场景和用法。

Gitflow的五个分支

develop分支：

develop分支是必须是所有功能分支的父分支;当功能开发完成时，改动的代码应该被合并（merge）到develop分支。功能开发永远不应该直接牵扯到master。

项目实例

1. 第一步现在master 分支的基础上 创建一个develop分支，并将其上传到中央仓库中（这一步一般都是小组长或领导做的）

git branch develop
git push -u origin develop

2. 其他开发人员应该先克隆这个项目，并且为develop创建一个追踪分支

git clone 项目名
git checkout -b develop origin/develop

3. 然后基于develop分支的基础上创建自己的功能分支，并将这个分支传送到中央仓库中

git checkout -b some-feature develop
git push -u origin some-feature    

开发者就可以在这个分支写 自己的代码模块

git status //查看代码状态
git add some-file // 将代码添加到本地仓库
git commit  // 将代码提交到远程仓库中

当模块中的功能都完成后，就可以将代码合并到develop分支上，并将分支推送到中央仓库中

git pull origin develop  //确保本地的develop分支有最新的代码
git checkout develop   //切换到develop分支上
git merge some-feature  //将some-feature分支合并到develop分支上
git push  //将分支推送到远程仓库中
git branch -d some-feature   //删除本地分支

4. 当项目可以第一次正式发布时；就在develop分支的基础上创建一个release0.1分支，表示初级的预发布版本，它主要用于测试Bug,是项目正式发布前的准备工作

git checkout -b release-0.1 develop 

5. 在预测试发布版本通过之后就可以把发布分支合并入master和develop分支，然后再将发布分支删除。

git checkout master
git merge release-0.1 //合并分支
git push   
git checkout develop  
git merge release-0.1
git push
git branch -d release-0.1

6. 正式发布项目；将分支合并到master上，在master分支的基础上创建第一个发布版本0.0.1-releaseE分支 并打上合适的标签；发布版本的代码是不可以更改的

git tag -a 0.0.1 -m "0.0.1-release" master  // 给项目标注一个0.0.1的版本号的标签
git push --tags  // 将版本号提交到远程仓库

7. 当发布的项目出现了Bug，就基于master分支创建一个hotfix（热修复分支）分支，用于修复Bug

git checkout -b hotfix-#001(修复问题的编号) master
\# Fix the bug
//将修复分支的改动合并到master上，并提交到远程仓库中
git checkout master
git merge hotfix-#001
git push
//将修复分支的改动合并到delevop上，并提交到远程仓库中,提交完成后删除本地的修复分支 
git checkout develop
git merge  hotfix-#001
git push
git branch -d  hotfix-#001