GitFlow工作流常用操作流程

1. 主要分支介绍

1.1 master分支

主分支,产品的功能全部实现后,最终在master分支对外发布。

1.2 develop分支

开发分支,基于master分支克隆,产品的编码工作在此分支进行。

1.3 release分支

测试分支,基于delevop分支克隆,产品编码工作完成后,发布到本分支测试,测试过程中发现的小bug直接在本分支进行修复,修复完成后合并到develop分支。本分支属于临时分支,目的实现后可删除分支。

1.4 bugfix分支

Bug修复分支,基于master分支或发布的里程碑Tag克隆,主要用于修复对外发布的分支,收到客户的Bug反馈后,在此分支进行修复,修复完毕后分别合并到develop分支和master分支。本分支属于临时分支,目的实现后可删除分支。

1.5 feature分支

功能特征分支,基于develop分支克隆,主要用于多人协助开发场景或探索性功能验证场景,功能开发完毕后合并到develop分支。feature分支可创建多个,属于临时分支,目的实现后可删除分支。

2. 新功能开发工作流

2.1 切换到本地仓库工作区

cd /home/timerhunter/workspace

2.2 从远程仓库克隆代码到本地仓库

git clone https://[email protected]:8443/r/valve/V5-Lora.git

2.3 基于master分支,创建develop分支

/* 切换到master分支 */
git checkout master
/* 基于master分支克隆develop分支,并在克隆完毕后直接跳转到develop分支 */
git checkout -b develop
/* 推送develop分支到远程仓库 */
git push origin develop

注:编码工作主要在develop分支,master分支主要用来发布稳定版本

2.4 在本地仓库的开发流程

完成一个功能点或者一天的工作结束时,将代码提交到本地仓库

/* 提交修改到缓冲区 */
git add .
/* 提交修改到本地仓库 */
/* 如果是修复的BUG,应该在修改说明的最开始添加Bug#ID,多个Bug用逗号分隔,例如Bug#002,003 */
/* 如果是完成了一个指派的任务,应该在修改说明的最开始添加Task#TaskID,例如Task#165 */
git commit -m "Bug#123 修改说明"
/* 每完成一个功能点可以对代码进行打包 */
git tag -m "简要说明增加/修复/删除了什么功能" v0.0.0.170718

注:不是每一个Tag都需要提交到远程仓库,比如可以在完成一个功能点的编码工作后未编译就打一个包,仅存储于本地仓库,在编译成功&测试通过后,再打一个新的Tag包(里程碑Tag包),仅将里程碑Tag包推送到远程仓库

2.5 推送代码到远程仓库

当完成一个功能点或阶段工作时,将代码推送到远程仓库develop分支

/* 执行代码拉取操作,防止代码冲突 */
git pull
/* 解决代码冲突后,推送代码到远程仓库*/
git push origin develop

注:禁止将未编译或编译不通过的代码提交到远程仓库,如果编码工作进行未完成可以提交到本地仓库中,等待该功能点全部实现后再将代码推送到远程仓库中。

2.6 将代码发布到测试分支

阶段性的开发工作已完成,启动小批量测试工作,将代码发布到测试分支release

git checkout develop
git checkout -b release
git push origin release

2.7 测试工程师提交Bug后修复

  • 修复流程同#2.4,#2.5;
  • 注意在git commit时的修复说明中添加Bug#BugID关键字
  • 完成一个Bug修复或完成阶段性工作后,将代码推送到远程分支

2.8 测试工作完成后,合并代码到develop分支

/* 切换到develop分支 */
git checkout develop
/* 执行合并操作,将release分支代码合并到develop分支 */
git merge release
/* 如果合并报错,则解决冲突,冲突解决后继续再次执行合并 */

2.9 开发工作和测试工作都完毕后,将develop分支合并到主线

git checkout master
git merge develop

2.10 阶段开发完毕,打一个里程碑Tag包

/* 创建里程碑Tag */
git tag -m "Task#003 v1.0.0 首版发布" v1.0.0.170718
/* 推送里程碑Tag到远程仓库 */
git push origin v1.0.0.170718

3. 发布后的产品Bug修复工作流

3.1 获取Bug产品的软件发布版本号

3.2 查找里程碑Tag

 /* 查询里程碑及其提交说明 */
 git tag -n1 -l v*

3.3 基于里程碑Tag创建分支

 /* git checkout -b [创建的分支名称] [里程碑Tag名称] */
 git checkout -b bugfix-v1.0.0.170718 v1.0.0.170718

3.4 修复代码后可以查询修改过的地方

 git diff

3.5 修复完毕后分别合并到develop分支和master分支

/* 合并到develop */
git checkout develop
git merge hotfix-v1.0.0.170718
/* 提交到远程仓库develop分支 */
git push origin develop
/* 合并到master */
git checkout master
git merge hotfix-v1.0.0.170718
/* 提交到远程仓库master分支 */
git push origin master

3.6 创建新的里程碑Tag

 git tag -m "Bug#002 修复某某Bug" v1.0.1.170719
 /* 推送到远程仓库 */
 git push origin v1.0.1.170719

3.7 删除bugfix分支

/* 删除本地分支-git branch -d [本地分支名]*/
git branch -d bugfix-v1.0.0.170718
/* 删除远程分支-git push origin :[远程分支名]*/
git push origin :bugfix-v1.0.0.170718

目前仅用到这些流程,新学有不足的地方请指出交流。

原文地址:https://www.cnblogs.com/weifeng1463/p/8507295.html

时间: 2024-07-31 02:51:57

GitFlow工作流常用操作流程的相关文章

Git基本命令和GitFlow工作流

本篇博客讲解了git的一些基本的团队协作命令,和GitFlow工作流指南 git 团队协作的一些命令 1.开分支 git branch 新分支名 例如,在master分支下,新开一个开发分支: git branch dev 2.切换到新分支 git checkout 分支名 例如,在master分支下,切换到新开的dev: git checkout dev 3.开分支和切换分支合并到一个命令 git checkout -b 新分支名 例如,新开一个开发分支,并立即切换到该分支: git chec

GitFlow 工作流

1.概述 GitFlow 工作流定义了一个围绕项目发布的严格分支模型.虽然比功能分支工作流复杂几分,但提供了用于一个健壮的用于管理大型项目的框架. GitFlow 工作流没有用超出功能分支工作流的概念和命令,而是为不同的分支分配一个很明确的角色,并定义分支之间如何和什么时候进行交互.除了使用功能分支,在做准备.维护和记录发布也使用各自的分支.当然你可以用上功能分支工作流所有的好处:Pull Requests.隔离实验性开发和更高效的协作. 2.工作方式 GitFlow 工作流仍然用中央仓库作为所

gitflow工作流简介

gitflow工作流是一种依赖于Git版本管理工具,按特定规范对项目开发.测试.上线流程进行管理的工作方式.它是一种为实现规范化管理的约定,它明确了各个分支的意义,使整个团队的分工协作更加和谐明晰. 一.gitflow工作流约定使用的分支简介 [master]项目的核心分支,也是最终对外发布的分支,唯一且稳定.仅提供可读,不可在该分支上直接修改代码. [develop]项目的开发主干分支,唯一.仅提供可读,不可在该分支上直接修改代码.新功能的开发需从该分支拉取新的分支展开.develop分支应该

Git之GitFlow工作流

一. GitFlow 介绍 1.1 什么是 GitFlow GitFlow 是一种 Git 工作流,它是团队成员遵守的一种代码管理方案 . 1.2 GitFlow 常用分支说明 分支名称 分支说明 Production 生产分支,即 Master分支.只能从其他分支合并,不能直接修改 Release 发布分支,基于 Develop 分支创建,待发布完成后合并到 Develop 和 Production 分支去 Develop 主开发分支,包含所有要发布到下一个 Release 的代码,该分支主要

gitflow工作流

开发者 创建自己的功能分支 在自己的功能分支上进行开发 提交合并请求 在维护分支和测试分支中对代码进行修改 项目经理 创建develop分支 审批合并请求 合并测试分支到主分支 gitflow演示 git checkout -b develop origin/develop # 创建并切换到本地develop分支, 设置其追踪的远程分支为origin/develop git checkout -b f_detail # 创建并切换到本地分支f_detail git branch -d f_det

git使用相关资源

git官方文档(git基础,英文版): https://git-scm.com/docs pro git(中文版): https://git-scm.com/book/zh/v2 廖雪峰的Git教程(简单易懂): https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000 git-cheat-sheet(常用git命令): http://www.cheat-sheets.org/saved

深入理解学习Git常用工作流

个人在学习git工作流的过程中,从原有的 SVN 模式很难完全理解git的协作模式,直到有一天我看到了下面的文章,好多遗留在心中的困惑迎刃而解,于是我将这部分资料进行整理放到了github上,欢迎star查看最新更新内容, https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md - 我们以使用SVN的工作流来使用git有什么不妥? - git 方便的branch在哪里,团队多人如何协作?冲突了怎么办?如何进行发布

开发环境之git:团队协作git工作流与常用命令

此篇文章只是一篇傻瓜式的,记录工作中比较规范且常见的一个git工作流需要用到的命令,让你可以快速的开始工作.而不是一些长篇大论的理论知识,如果你有用过sourcetree或者其它图形化工具,结合你正在使用的工具,敲这些命令,看图形化工具中的变化,对比思考这些命令可能会更容易吸收. 1.基本配置 刚入职公司开始做项目拉代码,需要经历的第一件事.配置个人的用户名称和电子邮件地址(通常是公司邮件地址) 1.1 配置用户名和邮箱 git config --global user.name "你的名字&q

深入理解学习Git工作流

一.译序 工作流其实不是一个初级主题,背后的本质问题其实是有效的项目流程管理和高效的开发协同约定,不仅是Git或SVN等VCS或SCM工具的使用. 这篇指南以大家在SVN中已经广为熟悉使用的集中式工作流作为起点,循序渐进地演进到其它高效的分布式工作流,还介绍了如何配合使用便利的Pull Request功能,体系地讲解了各种工作流的应用. 行文中实践原则和操作示例并重,对于Git的资深玩家可以梳理思考提升,而新接触的同学,也可以跟着step-by-step操作来操练学习并在实际工作中上手使用. 关