Git Flow
最近在着手制定开发规范,想要把项目正规高效的跑起来。计划引入 Git 版本控制,Git-Flow 便成为了首选。
因为之前并没有过多接触,所以先花些时间摸索一下。
一、为什么使用 git-flow
当在团队开发中使用版本控制系统时,商定一个统一的工作流程是至关重要的。
Git 的确可以在各个方面做很多事情,然而,如果在你的团队中还没有能形成一个特定有效的工作流程,那么混乱就将是不可避免的。
基本套路:你可以定义一个完全适合你自己项目的工作流程,或者使用一个别人定义好的。
二、安装 git-flow
我们使用 Homebrew 来安装 git-flow:
brew install git-flow
之后,通过 git-flow 来初始化项目:
git flow init
这时候就会有一些配置的操作,先默认操作:直接全部选择默认即可。
git flow 是对 Git 的封装
需要强调一点:git-flow 只是封装了 git 的命令。
所以在我们初始化的时候,对仓库并没有其他改动,只是创建了几个分支。当然,如果你不想继续使用 git-flow ,那么只需要简单的停用 git-flow 的命令即可,不需要修改或者删除任何文件。
为了验证一下,我们看下目前的分支,执行:
git branch
输出
* develop
master
Windows 安装实战
安装 git
我的安装目录:C:\Program Files\Git
下载 git flow
在任一目录执行
git clone --recursive git://github.com/nvie/gitflow.git
下载后文件如下:
AUTHORS git-flow* git-flow-init git-flow-version shFlags/
bump-version* gitflow-common git-flow-release LICENSE
Changes.mdown git-flow-feature gitflow-shFlags Makefile
contrib/ git-flow-hotfix git-flow-support README.mdown
contrib 文件夹中,我们可行安装
$ cd contrib/
$ ls
gitflow-installer.sh* msysgit-install.cmd
执行安装命令
使用管理员权限执行
第二个参数指定我的 git 安装目录
.\msysgit-install.cmd "C:\Program Files\Git"
验证
git flow
usage: git flow <subcommand>
Available subcommands are:
init Initialize a new git repo with support for the branching model.
feature Manage your feature branches.
bugfix Manage your bugfix branches.
release Manage your release branches.
hotfix Manage your hotfix branches.
support Manage your support branches.
version Shows version information.
config Manage your git-flow configuration.
log Show log deviating from base branch.
查看帮助文档
feature
git flow feature help
如下:
git flow feature help
usage: git flow feature [list]
or: git flow feature start
or: git flow feature finish
or: git flow feature publish
or: git flow feature track
or: git flow feature diff
or: git flow feature rebase
or: git flow feature checkout
or: git flow feature pull
or: git flow feature delete
Manage your feature branches.
For more specific help type the command followed by --help
三、分支模式
git-flow 模式会预设两个主分支在仓库中:
- master 只能用来包含产品代码 我们不能直接工作在这个 master 分支上,而是在其他指定的,独立的特性分支中。
不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
- develop 是你进行任何新的开发的基础分支 当你开始一个新的功能分支时,它将是开发的基础。
另外,该分支也汇集所有已经完成的功能,并等待被整合到 master 分支中。
上面说到的这两个分支被称作为长期分支,它们会存活在项目的整个生命周期中。
而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的。它们是根据需要来创建的,当它们完成了自己的任务之后就会被删除掉。
四、明确分支功能
-
master 分支 最为稳定功能比较完整的随时可发布的代码,即代码开发完成,经过测试,没有明显的 bug,才能合并到 master 中。请注意永远不要在 master 分支上直接开发和提交代码,以确保 master 上的代码一直可用;
-
develop 分支 用作平时开发的主分支,并一直存在,永远是功能最新最全的分支,包含所有要发布 到下一个 release 的代码,主要用于合并其他分支,比如 feature 分支; 如果修改代码,新建 feature分支修改完再合并到 develop 分支。所有的 feature、 release 分支都是从 develop 分支上拉的。
-
feature 分支 这个分支主要是用来开发新的功能,一旦开发完成,通过测试没问题,我们合并回 develop 分支进入下一个 release 。
-
release 分支 用于发布准备的专门分支。当开发进行到一定程度,或者说快到了既定的发布日,可以发布时,建立一个 release 分支并指定版本号(可以在 finish 的时候添加)。开发人员可以对 release 分支上的代码进行集中测试和修改 bug。(这个测试,测试新功能与已有的功能是否有冲突,兼容性)全部完成经过测试没有问题后,将 release 分支上的代码合并到 master 分支和 develop 分支。
-
hotfix 分支 用于修复线上代码的 bug 。从 master 分支上拉。完成 hotfix 后,打上 tag 我们合并回 master 和 develop 分支。
需要注意:
所有开发分支从 develop 分支拉。
所有 hotfix 分支从 master 拉。
所有在 master 上的提交都必要要有 tag,方便回滚。
只要有合并到 master 分支的操作,都需要和 develop 分支合并下,保证同步。
master 和 develop 分支是主要分支,主要分支每种类型只能有一个,派生分支每个类型可以同时存在多个。
五、关于 Feature 分支
init
类似于 git init,我们随便找一个文件夹。
比如:D:\github\my-test 做测试:
pwd
D:\github\my-test
- git flow init
根据初始化的提示,命名我们的分支信息
git flow init
Initialized empty Git repository in D:/github/my-test/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] master
Branch name for "next release" development: [develop] dev
How to name your supporting branch prefixes?
Feature branches? [feature/] new
Bugfix branches? [bugfix/] bugfix
Version tag prefix? [] 1.0.0
- 查看当前分支
其他的依然和 git 保持一致
git branch
* dev
master
feature
在 Git-flow 中,通过使用 Feature 分支,使得我们在同一时间开发多个分支更加简单。
我们接到了一个 Test1 需求,使用 feature start 来启动:
git flow feature start test1
当我们开始一个新的 feature 开发后:
Switched to a new branch 'newtest1'
Summary of actions:
- A new branch 'newtest1' was created, based on 'dev'
- You are now on branch 'newtest1'
Now, start committing on your feature. When done, use:
git flow feature finish test1
- 新增需求
我们新建一个文件 feature.txt
- 提交变更
git add .
git commit -m "[Feature] add for txt"
- 完成开发
git flow feature finish test1
日志如下:
Switched to branch 'dev'
Updating 96a1a67..085c31c
Fast-forward
1.txt | 0
feature.txt | 0
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 1.txt
create mode 100644 feature.txt
Deleted branch newtest1 (was 085c31c).
Summary of actions:
- The feature branch 'newtest1' was merged into 'dev'
- Feature branch 'newtest1' has been locally deleted
- You are now on branch 'dev'
这里做了几件事情: 1.将 feature/test1 分支合并到了 develop 分支; 2.删除了 feature/test1; 3.切换到 develop 分支;
需要注意: git-flow 使用的命令是:
git merge —no-ff feature/test1
这样,在我们移除 feature 分支之前,是不会丢失任何历史记录的。
如果你还不了解 –no-ff 相关知识,可以先看看:Git merge 的 –ff 和 –no-ff。
- 查看变更记录
接着,我们看一下变更记录:
git log --oneline
085c31c (HEAD -> dev) [Feature] add for txt
96a1a67 (master) Initial commit
六、release 分支-版本发布
当我们开发完毕,需要去发布新版本的时候,我们可以使用:
git flow release start 0.1.0
日志如下:
Switched to a new branch 'release/0.1.0'
Summary of actions:
- A new branch 'release/0.1.0' was created, based on 'dev'
- You are now on branch 'release/0.1.0'
Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:
git flow release finish '0.1.0'
很清晰,我们简单说一下: 1.基于 develop 分支新建了 release/0.1.0 分支; 2.切换至 release/0.1.0 分支;
又出现了新问题: 1.这是什么意思: Bumpthe version number now! 2. last-minute fixes 又是什么意思?
那接下来我们要做什么呢?不着急,按照提示一步步来。
- 修改代码
我们修改了代码,进行add,和 commit 之后,
执行:
git flow release finish 0.1.0
七、Hotfix 线上代码
如果线上代码有问题,这时候你需要紧急修复呢?
我们可以使用 git flow hotfix :
- 开始
git flow hotfix start jartto
- 结束
git flow hotfix finish jartto
八、git-flow 流程图示
恭喜你,到这里你已经完成了 git-flow 的基本流程。为了更加整体的理解工作流,我们来看看下面这张流程图: