gitFlow

参考：

• Tutorails
• 廖雪峰git
• Git Flow工作流程

一.分支简述

• 蓝圆–主线(master)
• 紫圆–主分支(dev)（生产主线）
• 橙圆–新功能开发主线(feature)
• 绿圆–新版本发布线(release)
• 红圆–发布版本bug修复线(hotfix)

二.工作流程

工作流基础

项目负责人创建dev分支供团队开发人员围绕它进行相关操作

git branch dev
git push -u origin dev

其他人clone，创建一个dev的轨迹版本

git clone git@github.orgXXXXXXXX
git checkout -b dev origin/dev

dev这个分支将包含项目的完整历史记录，而master仅包含缩略版本。

新功能开发流程

1.新建feature分支

在dev基础上创建新分支：

git checkout -b feature/demo dev

推到远程，(然后这部分新功能代码就提交到这个上)

git push

所有开发此新功能的人员，都在这个分支上开发提交代码

git status
git add
git commit -m "Add some-file."

2.完成新功能开发（合并feature分支到dev上去）

git pull origin dev
git checkout dev
git merge feature/demo
git push
git branch -d feature/demo

注意

• 新功能分支，永远不要直接在master上合并，要在dev上进行操作
• 合并时做好冲突合并（webstrom可实现自动合并）

3.测试环境发布dev分支代码（提交测试）

线上版本发布流程

（1）从dev中创建发布的release分支

当主测试流程完成，源码已经趋于稳定，准备一个发布版本（确立版本号）,并推到远程

git checkout -b release-1.0 dev
git push

这个分支是清理准备发布、 整体回归测试、 更新文档，和做其他任何系统即将发布的事情。

（2）开发交代码改bug

（3）release分支合并到master和dev

一旦已经满足发布条件（或已经到了预定发布日期），应该把release分支合并到master分支和dev分支中，然后，使用master发布新版本。合并release分支到dev分支是很重要的，要让release上修改的东西能在后续的开发分支中生效。

master

git checkout master
git merge release-1.0
git push

dev

git checkout develop
git merge release-1.0
git push
git branch -d release-1.0

（4）打标签

Release分支在功能开发分支（dev）和公共发布版（master）中，充当一个缓冲的作用。每当有源码合并到master中的时候，应该在master上打一个标签，以便后续跟踪查阅。

git tag -a 1.0.RELEASE -m "Initial public release" master
git push --tags

线上bug修复过程

当用户反馈系统有bug，需从master基础上创建并维护hotfix新分支，解决完在合并回master

（1）创建hotfix

git checkout -b issue-#001 master

（2）修复

（3）完成后合并到master发布

git checkout master
git merge issue-#001
git push

（4）打标签

（5）合并到dev

git checkout develop
git merge issue-#001
git push

三.小结

• master仅包含缩略版本，dev包含项目完整历史记录
• 添加新功能都在dev上新生成分支feature进行操作，然后在合并回dev上
• 版本：在dev上测试流程完成，源码趋于稳定时，在dev上创建一个release作为发布版本号（其实就是master和dev之间的一个缓冲）
• 线上修bug：反馈出bug之后，在master基础上新建一个分支hotfix，在该hotfix上修好了在合并回master，并同步到dev