Gitflow工作流

Gitflow工作流

1.简介

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

合理使用Gitflow可以隔离实验性开发，实现更加高效的协作；

合理使用Gitflow可以避免代码不经过验证上线的问题；

1.1 Gitflow工作方式

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

1.2 Master和Develop历史分支

相对于使用仅有的一个master分支，Gitflow工作流使用两个分支来记录项目的历史。

master分支存储了正式发布的历史，而develop分支作为功能的集成分支。

1.3 Feature功能分支

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

1.4 Release发布分支

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

常用的发布分支约定：

1.发布的分支必须来自于dev分支；
2.发布后代码合并到master，最后也需合并到dev分支；
3.分支命名: release-* 或 release/*

1.5 Hotfix维护分支

• 维护分支或说是热修复（hotfix）分支用于给产品发布版本（production releases）快速生成补丁，这是唯一可以直接从master分支fork出来的分支。
• 补丁修复完成后，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
• 为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
  你可以把维护分支想成是一个直接在master分支上处理的临时发布。

2. Gitflow示例

2.1 管理人员构建开发分支

# 在托管平台创建中央仓库，并克隆到本地：
git clone git@gitee.com:jicaifang/gitflow_test.git
# 在本地仓库创建develop开发仓库
git branch develop
# 将本地开发分支推送到远程
git push -u origin develop

• 创建过程一般由团队负责人或者项目服务人去创建并维护；

• 以后develop分支将会包含了项目的全部历史，而master分支将只包含了部分历史。

2.2 开发人员开发流程

1.构建本地仓库

# 开发人员将代码从远程仓库下载到本地
git clone git@gitee.com:jicaifang/gitflow_test.git
# 此时执行git branch只有master分支，没有develop分支
git branch
# 我们需要本地创建一个develop分支与远程分支一一对应，-b表示强制创建分支，存在则覆盖
git checkout -b develop origin/develop
# 接下来我们一切的新功能开发都是从这个develop本地分支检出，比如用户管理功能，取名为：user-feature作为功能分支
git checkout -b user-feature develop

2.开发新功能并提交远程仓库

接下来用户就在这个user-feature上进行功能开发，依旧是老套的：编辑、暂存、提交

# 模拟开发
# 添加新页面
touch user.html
# 存放到暂存区
git add user.html
# 将本地所有修改存入暂存区
git add .
# 提交
git commit -m "添加用户页面展示新功能"
# 添加了提交后，如果功能OK了，就可以直接合并到本地的develop分支后push到中央仓库
# 合并到develop本地开发分支
git checkout develop
# 合并之前先拉去最新代码，确保develop分支是最新的
git pull origin develop
# 合并功能新特性
git merge user-feature
# 推送到远程仓库
git push origin develop
# 删除本地无用的功能分支
git branch -d user-feature

3.新功能发布

用户开发完一个新功能后，时机成熟就正式发布，像功能开发一样，依旧用一个新的分支来做发布准备。这一步也确定了发布的版本号：

# 该分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，是一个专门用于改善发布的功能分支
git checkout -b release-0.1 develop
# 一旦准备好了对外发布后需要合并修改到`master`分支和`develop`分支上，并删除发布分支，此时在该节点也是理想的code-review时机
git checkout master
# 主分支合并发布分支
git merge release-0.1
# 只运行git push也可
git push origin master
# 删除本地发布分支
git branch -d release-0.1

发布分支是作为功能开发（develop分支）和对外发布（master分支）间的缓冲。只要有合并到master分支，就应该**打好Tag**以方便跟踪。

# 给master分支打一个标签，-a表示标签必须有说明 -m则指定具体说明信息
git tag -a 0.1 -m "user manager 0.1" master
# 查看打的标签
git show 0.1
# 提交标签
git push --tags

Git有提供各种勾子（hook），即仓库有事件发生时触发执行的脚本。
可以配置一个勾子，在你push中央仓库的master分支时，自动构建好版本，并对外发布。

4.紧急bug修复

对外版本发布后就可以进入下一版本的新功能开发了；

如果线上当前版本出现了一个紧急的Bug，为了处理Bug，我们可以从**master分支上拉出了一个维护分支**，提交修改以解决问题，然后直接合并回master分支：

# 在主分支检出紧急修复分支
git checkout -b issue-#001 master
# Fix the bug....
git checkout master
# 切回主分支并合并修复代码
git merge issue-#001
# 将修复的代码推动到远程仓库
git push

就像发布分支，维护分支中新加这些重要修改需要包含到develop分支中，所以小红要执行一个合并操作。然后就可以安全地删除这个分支了：

# 切回开发分支并合并
git checkout develop
git merge issue-#001
# 远程推送
git push
# 删除紧急修复分支
git branch -d issue-#001