GitFlow日常使用总结

GitFlow 使用#

Git 是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目
Git 是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理
GITFLOW 就是提供了一种方便快捷的管理项目版本 / 分支的功能，也算是一种规范类型，具体看团队规范。它把你需要用 git 分几步命令的操作使用 git flow 仅仅只需一个命令就搞定了另外团队成员都是使用这种统一规范创建的版本啦分支不会乱套。

GitFlow 安装#

需要先安装 Git 现在一些高版本的 Git 中已经集成了 gitflow
如果没有的话上跳 github->gitflow 这里有详细的安装说明

GitFlow 的简单实用#

准备工作#

更新 master 分支
更新 develop 分支

初始化#

$ git flow init

然后他会询问你一些基本的命名设置直接一路回车默认就可以了

注意：如果是第一次创建的项目或者有命名不规范的分支结构的时候在执行 init 初始化的时候会让你多选择一些选项

Which branch should be used for bringing forth production releases?
master【这里就是列出的可选分支列表】
Branch name for production releases: [master]

像这个就是在询问你准备生产环境的一个分支他默认给了你推荐的是 master 就是最后那个中括号的内容就是默认推荐的像我之前有过不规范的命名分支瞎写的这里他就会给你推荐最新的那个分支如果你不想用默认的可以直接在后面打上需要作为生产环境的分支的名字以前不是很懂就胡乱打了个分支结果跪了都是泪，推荐 master 哦

Branch name for “next release” development: [develop]

这个是在问你选择开发环境的一个分支一般推荐是 develop 他默认的也是的不想选别的直接回车
后面还有一些选择统统默认好了

Git flow feature#

如果你准备开发一个新的功能

$ git flow feature start your-branch-name

start 后面就是你要创建的分支的名字一般新功能使用 feature 分支在后面默认中他是帮你从 develop 分支为基础创建的这个新的分支
当你完成功能开发需要推送到服务器上时

$ git flow feature finish your-branch-name

他会帮你新功能分支上的内容合并到 develop 分支上并删除该 feature 分支，然后切换回 develop 分支你可以通过 git log 命令来查看他的具体操作哦

Git flow release#

当你的功能点都完成后你需要发一个发布的版本我们可以创建一个 release 分支这个也是基于 develop 分支创建的

$ git flow release start v0.0.1

注意这个 release 版本的命名我们一般习惯是 v+3 位数因为这是一个新的项目还没有 tag 标签就从 0 开始了那就是 v0.0.1 了这个看公司规定吧
如果有 tag 标签请先使用 git tag 命令来查询最近的 release 版本在此基础上 + 1 作为新的版本号比如查询出来的最近的是 v1.2.3 那新创建的版本推荐名：v1.2.4 因为我们开发中 3 位的都是 release 版本号所以只需要找最近的一个 3 位数的 release 版本号就行了如果你们固定的不是 3 位数就要看具体的喽

当我们完成这个发布分支验证测试完需要正式发布了我们只需要执行

git flow release finish v0.0.1

他在后面会帮我们合并到 master 并打上 tag 标签并删除该 release 分支同时合并到 develop 保证 2 个分支的同步

那现在我们在使用 git tag 命令就能看到 tag 标签了就是我们刚刚完成的那个分支的版本号

$ git tag
v0.0.1

Git flow hotfix#

当我们出现 bug 需要修复又不想影响发布分支可以新建一个 hotfix 分支来修复 bug

$ git flow hotfix start v0.0.1.1

它在后面是从 master 分支帮我们创建的这个 hotfix 新分支

注意这个命名版本号：我们一般习惯使用 v+4 位数来命名版本号需要先查询最新的一个 release 分支因为 release 是 3 位的在他的基础上加一位因为我们上面刚刚完成的 release 版本号是 v0.0.1 所以我们新建的 hotfix 分支的名字就是 v0.0.1.1
eg: 如果我们 git tag 出的最新 release 为 v1.2.3 那我们的 hotfix 分支可以命名为 v1.2.3.1 以此类推

当我们彻底修复 bug 需求提交合并