git-flow工作流程

什么是 git-flow?

一旦安装安装 git-flow,你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的,这就是我们的工作流程!

git-flow 并不是要替代 Git,它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。

严格来讲,你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解,哪些工作流程是由哪些单独的任务所组成的,并且附带上正确的参数,以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了,

总的来说,git-flow 并不会为 Git 扩展任何新的功能,它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程

初始化

$ git flow init

当在项目的根目录执行 “git flow init” 命令时(它是否已经包括了一个 Git 仓库并不重要),一个交互式安装助手将引导您完成这个初始化操作,建议你使用默认的命名机制,并且一步一步地确定下去。

分支的模式

git-flow 模式会预设两个主分支在仓库中:

  • master 只能用来包括产品代码。你不能直接工作在这个 master 分支上,而是在其他指定的,独立的特性分支中(这方面我们会马上谈到)。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
  • develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时,它将是_开发_的基础。另外,该分支也汇集所有已经完成的功能,并等待被整合到 master 分支中。

这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的。它们是根据需要来创建的,当它们完成了自己的任务之后就会被删除掉。

功能开发

开发新功能

# 创建一个功能分支 rss-reed
$ git flow feature start rss-feed   #git-flow 会创建一个名为 “feature/rss-feed” 的分支(这个 “feature/” 前缀 是一个可配置的选项设置

查看帮助

$ git flow feature help

完成一个功能

$ git flow feature finish rss-feed

最重要的是,这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待:

  1. 一个在更广泛的 “开发” 背景下的全面测试。
  2. 稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。

之后,git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支,并且换到 “develop” 分支。

管理 releases

创建 release

当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时,这意味着:第一,它包括所有新的功能和必要的修复;第二,它已经被彻底的测试过了。如果上述两点都满足,那就是时候开始生成一个新的 release 了:

git flow release start 1.1.0

release 分支是使用版本号命名的,这个命名方案还有一个很好的附带功能,那就是当我们完成了release 后,git-flow 会适当地_自动_去标记那些 release 提交。

有了一个 release 分支,再完成针对 release 版本号的最后准备工作(如果项目里的某些文件需要记录版本号),并且进行最后的编辑。

完成 release

git flow release finish 1.1.0

这个命令会完成如下一系列的操作:

  1. 首先,git-flow 会拉取远程仓库,以确保目前是最新的版本。
  2. 然后,release 的内容会被合并到 “master” 和 “develop” 两个分支中去,这样不仅产品代码为最新的版本,而且新的功能分支也将基于最新代码。
  3. 为便于识别和做历史参考,release 提交会被标记上这个 release 的名字(在我们的例子里是 “1.1.0”)。
  4. 清理操作,版本分支会被删除,并且回到 “develop”。

hotfix

很多时候,仅仅在几个小时或几天之后,当对 release 版本作做全面测试时,可能就会发现一些小错误。
在这种情况下,git-flow 提供一个特定的 “hotfix” 工作流程(因为在这里不管使用 “功能” 分支流程,还是 “release” 分支流程都是不恰当的)。

创建 Hotfixes

$ git flow hotfix start missing-link

这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复,所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别,release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。

就像 release 一样,修复这个错误当然也会直接影响到项目的版本号!

完成 Hotfixes

在把我们的修复提交到 hotfix 分支之后,就该去完成它了:

$ git flow hotfix finish missing-link

这个过程非常类似于发布一个 release 版本:

  • 完成的改动会被合并到 “master” 中,同样也会合并到 “develop” 分支中,这样就可以确保这个错误不会再次出现在下一个 release 中。
  • 这个 hotfix 程序将被标记起来以便于参考。
  • 这个 hotfix 分支将被删除,然后切换到 “develop” 分支上去。

原文地址:https://www.cnblogs.com/freely/p/10092298.html

时间: 2024-07-30 00:08:36

git-flow工作流程的相关文章

Git flow 的流程

Git flow 的流程与参考 Git flow 出自 A successful Git branching model,这里使用了一个前端项目配合本文稿实施了 git flow 并记录流程作出示例和参考,对 hotfix 与持续部署略有提及,本意是用作公司内部的技术安利.所用源码及文档本身见于 github jusfr/HelloGitflow 前言 Gitflow 是一种 git 分支管理工具——说是思想也不为过,它使用既定策略区分和管理开发.测试.生产环境的代码版本,对测试与持续集成友好,

从一个前端项目实践 Git flow 的流程与参考

Git flow 出自 A successful Git branching model,这里使用了一个前端项目配合本文稿实施了 git flow 并记录流程作出示例和参考,对 hotfix 与持续部署略有提及,本意是用作公司内部的技术安利.所用源码及文档本身见于 github jusfr/HelloGitflow 前言 Gitflow 是一种 git 分支管理工具——说是思想也不为过,它使用既定策略区分和管理开发.测试.生产环境的代码版本,对测试与持续集成友好,与敏捷.迭代的思路一致. 1 准

Git 分支工作流程

3.4 Git 分支 - 利用分支进行开发的工作流程 利用分支进行开发的工作流程 现在我们已经学会了新建分支和合并分支,可以(或应该)用它来做点什么呢?在本节,我们会介绍一些利用分支进行开发的工作流程.而正是由于分支管理的便捷,才衍生出了这类典型的工作模式,你可以根据项目的实际情况选择一种用用看. 长期分支 由于 Git 使用简单的三方合并,所以就算在较长一段时间内,反复多次把某个分支合并到另一分支,也不是什么难事.也就是说,你可以同时拥有多个开放的分支,每个分支用于完成特定的任务,随着开发的推

基于git的工作流程

本文针对的是追求极致.快速的产品响应团队的.以下的观点和内容都是围绕这个主题,暂时不涉及个人学习和团队学习. 在说工作流程之间,想说一下我们平常工作中遇到的一些困惑或者说现象 在一个团队里,同时有好多事件要解决.有的是产品迭代,有的是bug修改,有的可能是技术结构调整等.怎么去保证他们之间的独立性? 什么时候应该切分支?合并后的分支还能再作修改吗?分支什么时候需要删除?什么时候这个分支的生命周期才算完成? 主干可以修改代码吗?多少次分支合并到主干才发布一个版本? 什么时候版本才算稳定.什么时候才

Git手册 - 工作流程

如果代码已经通过测试,那么则可以采取以下步骤或流程完成代码的合并: 1)切换至master分支,记住千万别直接提交修改至master分支: #git checkout master 2)基于master分支新建个临时分支,并切换至新建的分支 #git checkout -b branchName 3)将要提交的代码添加至新建的分支 #git checkout develop [files/folder]        //这里develop分支添加过来的文件会自动替换掉新建分支中的同名文件,并且

git 基本工作流程

Git常用命令: http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html git config --help  查看帮助 git config --global user.name 如果有则修改 如果没有则添加 xxx git config user.email    如果有则修改 如果没有则添加 xxxxxxxxxxx 查看全局级的config,命令:git config --global -l 编辑git配置文件命令: git

[git]git的工作流程

git有三个区域(如图): 基本信息设置 1)设置用户名   git config --global user.name  "帐号名" 2)设置用户名邮箱  git config --global user.email  "注册的邮箱" git的使用步骤 1)在本地电脑,创建一个文件夹  (可以使用命令 [mkdir 文件夹名称]  |   使用win菜单) 2)初始化git仓库 ( 使用命令 [git  init] ),在本地产生.git文件夹 ----- 3)创

git工作流程

一般工作流程如下: 克隆 Git 资源作为工作目录. 在克隆的资源上添加或修改文件. 如果其他人修改了,你可以更新资源. 在提交前查看修改. 提交修改. 在修改完成后,如果发现错误,可以撤回提交并再次修改并提交. Git 的工作流程示意图: git的工作区.暂存区和版本库 基本概念: 工作区:就是你在电脑里能看到的目录. 暂存区:英文叫stage, 或index.一般存放在"git目录"下的index文件(.git/index)中,所以我们把暂存区有时也叫作索引(index). 版本库

git概念及工作流程详解

git概念及工作流程详解 既然我们已经把gitlab安装完毕[当然这是非必要条件],我们就可以使用git来管理自己的项目了,前文也多多少少提及到git的基本命令,本文就先简单对比下SVN与git的区别及理解git几个重要概念. 至于什么是git,git的发展历史,网上已经有很多资料,可以自行google或百度. 关于git与svn的区别 这里不针对git与svn的区别详细深究,以便对双方的优缺点了解更多些. 1) 最核心的区别Git是分布式的,而Svn不是分布的. 能理解这点,上手会很容易,声明

Git的工作模式和工作流程

git的优缺点 git属于分布式版本控制系统:客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整的镜像下来. 优点: 1.由于任何人每次提取操作,实际上都是一次对代码仓库的完整备份,因此近乎所有的操作都可以在本地执行,速度就是相当的快,并且可以在网络断开的时候操作仍然不受影响,可以频繁的进行提交更新,等到有网络的时候再上传到远程的镜像仓库就可以了. 2.git的分支模型,相当的轻量级,被称为"必杀技". 缺点: 1.每个开发人员都拥有所有的代码,不利于核心代码的保密(如果有重