Git Flow工做流程

1、编写的目的

• 经过规范化的流程，使得产品、开发与测试等各个部门更高效的协同工做。
• 经过规范化的流程使得产品高效稳定运行。

2、背景

在多组员、多项目、多环境进行协同工做时，若是没有统一规范、统一流程，则会致使额外的工做量、出现版本混乱或代码覆盖。因此要减小版本冲突，减轻没必要要的工做，就须要规范化的工做流程。

3、总则

• 统一使用Git做为版本控制的主要工具。
• 统一使用GitFlow流程管理控制版本。

4、提交的准则

• 除了源码相关的东西以外，其余build产生的东西（如：maven的target文件夹，.idea文件夹等），均不能提交进入源码仓库，添加到.gitignore文件中忽略掉。
• 撰写规范的commit说明,一份好的提交说明能够帮助协做者更轻松更有效地配合工做。
• 要严格按照咱们指定的流程切换到指定分支，开发相应的功能。

5、Git Flow的流程图

6、分支简述

• 天蓝色圆点所在的线为咱们源码的主线（master）。
• 天蓝色方形指向的节点就是每个发布版本的标签（tag）。
• 紫色圆点所在的线为主要分支线（develop）。
• 橙色圆点所在的线为新功能开发分支线（feature）。
• 绿色圆点所在的线为新版本发布线（release）。
• 红色圆点所在的线为发布版本bug修复线（hotfix）。

6.1 主分支

1. master:用来记录官方发布轨迹。
2. develop:是一个集成分支，用来记录完整的开发过程轨迹。

6.2 临时的分支

1. 新功能分支（Feature Branches）

   每个新的功能或者下一个迭代的任务,都应该建立一个独立的功能分支，从develop分支中派生出来。当功能完成后，要合并（merged）回develop分支，合并后它的生命周期就结束,能够删除。新功能分支不会与master分支有直接的交汇。如图：

2. 发布分支（Release Branches）

   一旦开发的功能已经知足发布条件（或预约发布日期接近），应该合并全部知足发布条件的新功能分支到develop分支中，而后，开出一个发布分支（Release），开始准备一个发布版本。Release这个分支上不能再添加新的功能，只有bug修复和该版本为导向的任务。一旦到了发布日期，Release就要合并回master发布，而且打出版本标签。另外还须要合并回develop分支,保证develop分支是最新的.

   使用一个专门的分支来准备发布版本，使得一个团队能对当前版本进行抛光，而另外一个团队继续为下一个版本的功能作准备。它还创造了良好定义的发展阶段（例如，很容易说，“本周咱们正在准备4.0版”，并且真实地看到它在库中的结构）

3. 维护分支（Maintenance Branches）

   维护分支也就是线上bug修复分支，使用来快速修复生产环境的紧急问题

   这个分支是惟一一个开放过程当中直接从master分支派生来的分支。快速的修复问题后，它应该被合并回master和develop（或者当前发布分支），而后，master分支须要打一个版本标签。

6.3 命名约定

• 主分支名称：master
• 主开发分支名称：develop
• 标签（tag）名称：v*.RELEASE，其中”*“ 为版本号，“RELEASE”大写，如：v1.0.0.RELEASE
• 新功能开发分支名称：feature-，其中”“ 为新功能简述，如：feature-item-activity-list
• 发布分支名称：release-，其中”“为版本号，“release”小写，如：release-1.0.0
• master的bug修复分支名称：hotfix-，其中”“为bug简述，如：hotfix-item-update-bug

七.工做流程

下面具体演示如何使用工做流来管理版本发布周期。假设咱们已经存在或建立了一个源码中央存储仓库,默认建立了master分支。

7.1 建立develop分支

• 项目负责人在本地master基础上建立一个develop分支，而后，推送到服务器；

git branch develop
git push -u origin develop

• 其余开发人员，须要克隆develop中央仓库的源码，建立一个develop的轨迹版本；若是已经克隆过该项目，则不须要执行如下第一条命令。

git clone git@github.org:search-cloud/demo.git
git checkout -b develop origin/develop

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

7.2 新建feature分支

• 基于develop分支建立新功能分支(多个团队能够拉取多个功能分支,互不影响)：

git checkout -b feature/demo develop

• 推送到远程仓库:

git push

• 全部开发此新功能的人员，都在此分支上开发提交代码:

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

7.3 完成新功能开发（合并feature分支到develop）

当肯定新功能开发完成，且联调测试经过，而且新功能负责人已经获得合并feature分支到develop分支的容许；这样才能合并feature分支到develop. (若是有两个新功能同时在开发,前一个功能合并到develop,但尚未发布到release,而且下一个版本又不在这个周期发布.则第二个功能不能合并到develop,不然会出现两个新功能同时要发布到release)

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

第一条命令是确保在合并新功能以前，develop分支是最新的

注意:

• 新功能分支，永远不要直接合并到master分支。
• 合并可能会有冲突，应该谨慎处理冲突

7.4 在测试环境发布develop分支代码（提交测试）,也能够跳7.5建立release分支提测

7.5 线上版本发布流程

• 从develop中建立准备发布的release分支

• 当主测试流程完成，源码已经趋近于稳定状态，应该准备一个发布版本，确立版本号,并把master代码合并到release发布版,确保release是要发布的最新的代码

git checkout -b release-0.1.0 develop
git merge master
git push

这个分支是清理准备发布、 总体回归测试、 更新文档，不能在此分支添加与本次无关的新功能

• 继续抛光改bug
• release分支合并到master发布

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

git checkout master
git merge release-0.1.0
git push

• release分支合并到develop

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

• master打标签,用此标签代码作最后上线验证

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

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

7.6 线上Bug修复流程 当终端用户，反馈系统有bug时，为了处理bug，须要从master中建立出保营养支；等到bug修复完成，须要合并回master/develop：

• 建立hotfix分支

git checkout -b issue-#001 master

• 修改bug Fix the bug
• 完成修复，合并到master发布

git checkout master
git merge issue-#001
git push

• 打标签

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

• 合并到develop

git checkout develop
git merge issue-#001
git push