标签:顺序 feed 目录 work 严格 生命周期 操作 alt target
一旦安装安装 git-flow,你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的,这就是我们的工作流程!
git-flow 并不是要替代 Git,它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。
严格来讲,你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解,哪些工作流程是由哪些单独的任务所组成的,并且附带上正确的参数,以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了,
总的来说,git-flow 并不会为 Git 扩展任何新的功能,它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程
$ git flow init
当在项目的根目录执行 “git flow init” 命令时(它是否已经包括了一个 Git 仓库并不重要),一个交互式安装助手将引导您完成这个初始化操作,建议你使用默认的命名机制,并且一步一步地确定下去。
git-flow 模式会预设两个主分支在仓库中:
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的。它们是根据需要来创建的,当它们完成了自己的任务之后就会被删除掉。
开发新功能
# 创建一个功能分支 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” 分支中去。在这里它需要等待:
之后,git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支,并且换到 “develop” 分支。
创建 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
这个命令会完成如下一系列的操作:
很多时候,仅仅在几个小时或几天之后,当对 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 版本:
标签:顺序 feed 目录 work 严格 生命周期 操作 alt target
原文地址:https://www.cnblogs.com/freely/p/10092298.html