Git Flow 工作流程
引言
编写的目的
-通过规范化的流程,使得产品、开发与测试等各个部门更高效的协同工作。 -通过规范化的流程使得产品高效稳定运行。
背景
在多组员,多项目等环境进行协同工作时,如果没有统一规范、统一流程,则会导致额外的工作量,甚至会做无用功。所以要减少版本冲突,减轻不必要的工作,就需要规范化的工作流程。
总则
-统一使用Git作为版本控制的主要工具。 -统一使用GitFlow流程管理控制版本。
提交的准则
1.除了源码相关的东西之外,其他build产生的东西(如:maven的target文件夹,.idea文件夹等),均不能提交进入源码仓库,添加到.gitignore文件中忽略掉。 2.撰写规范的提交说明。一份好的提交说明可以帮助协作者更轻松更有效地配合工作。 3.要严格按照我们指定的流程切换到指定分支,开发相应的功能。
分支简述
我们使用的分支流程:
主要分支简述
-天蓝色圆点所在的线为我们源码的主线(master)。
-天蓝色方形指向的节点就是每一个发布版本的标签(tag)。 -紫色圆点所在的线为主要分支线(develop)。 -橙色圆点所在的线为新功能开发分支线(feature)。 -绿色圆点所在的线为新版本发布线(release)。 -红色圆点所在的线为发布版本bug修复线(hotfix)。
主分支说明
代替原来的单个主线(master),我们使用两个分支来记录源码轨迹: 1.原来的master分支用来记录官方发布轨迹; 2.新的develop分支是一个集成分支,用来记录开发新功能的轨迹。
Master与Develop分支
除了master主线和develop主分支线,其他的分支都是临时的分支,有一定的生命周期的,其余的工作流程分支都是围绕这两个分支之间的区别进行的。
其他分支说明
-新功能分支(Feature Branches)
每一个新的功能都应该创建一个独立的分支,从develop分支中派生出来。当功能完成后,要合并(merged)回develop分支,合并后它的生命周期就结束。新功能分支不会与master分支有直接的交汇。如图:
Feature Branches
注意:对于所有意图和目的,新功能分支会合并到develop分支。但是,这个Gitflow工作流不会在此结束。
-发布分支(Release Branches)
一旦开发的功能已经满足发布条件(或预定发布日期接近),应该合并所有满足发布条件的新功能分支到develop分支中,然后,开出一个发布分支(Release),开始准备一个发布版本。在这个分支上,不能再添加新的功能,只有bug修复和该版本为导向的任务。一旦到了发布日期,Release就要合并回master发布,并且,打出版本标签。另外,还需要合并回develop分支。
Release Branches
使用一个专门的分支来准备发布版本,使得一个团队能对当前版本进行抛光,而另一个团队继续为下一个版本的功能做准备。它还创造了良好定义的发展阶段(例如,很容易说,“本周我们正在准备4.0版”,而且真实地看到它在库中的结构)。
-维护分支(Maintenance Branches)
维护分支也就是线上bug修复分支,使用来快速修复生产环境的紧急问题。
Maintenance Branches
这个分支是唯一一个开放过程中直接从master分支派生来的分支。快速的修复问题后,它应该被合并回master和develop(或者当前发布分支),然后,master分支需要打一个版本标签。
一个专门的错误修复开发线,可以让团队在不等待下一个发布周期,导致中断工作流程情况下解决问题。可以将维护分支当做主要的问题修复分支,与master并行。
命名约定
-主分支名称:master -主开发分支名称:develop -标签(tag)名称:v*.RELEASE,其中”*“ 为版本号,“RELEASE”大写,如:v1.0.0.RELEASE -新功能开发分支名称:feature-*or feature/*,其中“*” 为新功能简述,如:feature-item-activity-list -发布分支名称:release-*or release/*,其中*为版本号,“release”小写,如:release-1.0.0 -master的bug修复分支名称:hotfix-*or hotfix/*,其中*为bug简述,如:hotfix/item-update-bug
工作流程
下面具体演示如何使用工作流来管理版本发布周期。假设我们已经存在或创建了一个源码中央存储仓库。
工作流的基础
创建develop分支
Create Develop Branch
-项目负责人在本地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将包含缩略版本。
** 假设开始以下所有的流程之前,都已经创建好develop分支。**
新功能开发流程
1.新建feature分支
Create Feature Branch
基于develop分支创建新功能分支:
git checkout -b feature/demo develop
推送到远程仓库,共享:
git push
所有开发此新功能的人员,都在此分支上开发提交代码。
git status
git add
git commit -m "Add some-file."
2.完成新功能开发(合并feature分支到develop)
Merge Feature to Develop
当确定新功能开发完成,且联调测试通过,并且新功能负责人已经得到合并feature分支到develop分支的允许;这样才能合并feature分支到develop。
git pull origin develop
git checkout develop
git merge feature/demo
git push
git branch -d feature/demo
第一条命令是确保在合并新功能之前,develop分支是最新的。
注意:
-新功能分支,永远不要直接合并到master分支。 -合并可能会有冲突,应该谨慎处理冲突。
3.在测试环境发布develop分支代码(提交测试)
线上版本发布流程
1.从develop中创建准备发布的release分支
Create Release Branch
当主测试流程完成,源码已经趋近于稳定状态,应该准备一个发布版本,确立版本号:
git checkout -b release-0.1.0 develop
推送到远程仓库共享:
git push
这个分支是清理准备发布、 整体回归测试、 更新文档,和做其他任何系统即将发布的事情。
2.继续抛光改bug 3.release分支合并到master发布
Merge Release to Master and Develop
一旦已经满足发布条件(或已经到了预定发布日期),应该把release分支合并到master分支和develop分支中,然后,使用master发布新版本。合并release分支到develop分支是很重要的,要让release上修改的东西能在后续的开发分支中生效。
git checkout master
git merge release-0.1.0
git push
4.release分支合并到develop
git checkout develop
git merge release-0.1.0
git push
git branch -d release-0.1.0
5.打标签
Release分支在功能开发分支(develop)和公共发布版(master)中,充当一个缓冲的作用。每当有源码合并到master中的时候,应该在master上打一个标签,以便后续跟踪查阅。
git tag -a 0.1.0.RELEASE -m "Initial public release" master
git push --tags
线上Bug修复流程
当终端用户,反馈系统有bug时,为了处理bug,需要从master中创建出保养分支;等到bug修复完成,需要合并回master:
1.创建hotfix分支
git checkout -b issue-#001 master
2.修改bug Fix the bug 3.完成修复,合并到master发布
Merge hotfix to Master
git checkout master
git merge issue-#001
git push
4.打标签
git tag -a 0.1.1.RELEASE -m "Initial public release" master
git push --tags
5.合并到develop
git checkout develop
git merge issue-#001
git push
其他
附录
参考资料
-git-book
-what-is-version-control
-gitflow-workflow
Git Flow 工作流程相关推荐
- Git Flow 工作模型与使用
一. Git Flow 工作模型的原理 无规矩不成方圆,但是规矩太多了,则感觉到束缚.我们一个人工作的时候喜欢无拘无束,想怎么干就怎么干,没有人评判,没有人检验.时间久了就会盲目自大,以为增删改查熟悉 ...
- Git的工作流程简单易懂
Git的工作流程 Git的工作区域 Git的基本流程 1.将工作区的代码添加到暂存区 2.将暂存区的文件提交到本地仓库 3.将暂存区的文件提交到远程仓库 Git的工作区域 Git的基本流程 1.将工作 ...
- Hello Git(五)——Git分布式工作流程
一.Git分布式工作流程简介 与集中式版本控制系统(CVCS)不同,Git的分布式特性使得开发者间的协作变得更加灵活多样.在集中式系统中,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相同. ...
- 从一个前端项目实践 Git flow 的流程与参考
Git flow 出自 A successful Git branching model,这里使用了一个前端项目配合本文稿实施了 git flow 并记录流程作出示例和参考,对 hotfix 与持续部 ...
- Git的工作流程简介
目录 Git的工作区域 Git的基本流程 1.将工作区的代码添加到暂存区 2.将暂存区的文件提交到本地仓库 3.将暂存区的文件提交到远程仓库 Git的工作区域 Git的基本流程 图形化方式操作 命令行 ...
- 基于git的工作流程
本文针对的是追求极致.快速的产品响应团队的.以下的观点和内容都是围绕这个主题,暂时不涉及个人学习和团队学习. 在说工作流程之间,想说一下我们平常工作中遇到的一些困惑或者说现象 在一个团队里,同时有好多 ...
- Git的学习之路02 Git的工作流程、工作区、暂存区、版本库及创建版本库
Git的一般工作流程如下: 克隆 Git 资源作为工作目录. 在克隆的资源上添加或修改文件. 如果其他人修改了,你可以更新资源. 在提交前查看修改. 提交修改. 在修改完成后,如果发现错误,可以撤回提 ...
- 【Git 教程系列第 5 篇】Git 的工作流程
这是[Git 教程系列第 5 篇],如果觉得有用的话,欢迎关注专栏. Git 工作流程 第一步:克隆 Git 资源(远端仓库)作为工作目录. 第二步:在克隆的资源上添加或修改文件(如果其他人修改了,你 ...
- Git 基本工作流程
一:Git 工作区域 二:向仓库中添加文件流程(使用命令行模式进行提交) 3个相关命令: git status :查看当前状况 git add hello.php :将文件提交到暂存区 git com ...
最新文章
- 只要7天 传统便利店就能免费升级无人超市
- 一起谈.NET技术,在.NET Workflow 3.5中使用多线程提高工作流性能
- mysql 截断表_入门MySQL——基础语句篇
- Kubernetes 中创建 Pod 时集群中到底发生了些什么?
- 本月 Firefox 65 将加入 Flexbox Inspector 开发者工具
- UVaLive 7361(矩阵快速幂)
- 《Python Cookbook 3rd》笔记(4.5):反向迭代
- 同学之间互相出的一些有趣题目
- ApacheCN/iBooker 未来计划 2019.11
- ShardingSphere-Proxy 分库分表 简单示例
- [Verilog] 薄膜建盤4X4 電路程式設計
- 13-CSS基础-背景和精灵图
- WCF把书读薄(3)——数据契约、消息契约与错误契约
- JAVA根据手机号获取省份和地区
- 干货推荐 | 一个好的产品设计原则都有这些
- 虚拟机增加一块新硬盘
- 一分钟了解“查看一台windows电脑是否成功安装了CUDA”
- Surface Go使用体验——一文告诉你我为什么没有选择iPad
- 经典不等式链的一些拓展理解
- 基于python的情感分析案例-基于情感词典的python情感分析