git 作为现在最为主流的版本管理工具,优点有很多,其中最为显著的一点就是分支管理。
作为一款优秀的版本管理工具,我在日常开发中也在使用,固定分支有两个,分别是 master
和 develop
,日常开发和测试都是针对 develop
进行,这造成一个问题就是,每当上线版本发现bug的时候,develop
分支已经有下个版本正在开发的代码,从 tag 创建出来的分支合并到
master
后,难以合并到 develop
。
基于上面的问题,上网搜索了 git 的工作流,其中讲的最多的就是 git flow
,下面就将 git flow
的学习结果总结如下。
发图镇楼
Branch
主分支:
master
发布到线上的代码应该和这个分支一致。
develop
日常开发分支,其他分支基本围绕这个分支。
临时性分支:
feature/*
新功能研发分支,从 develop
创建,研发完成,合并到 develop
。
release/*
预发布分支,从 develop
创建,进行测试,并修复 bugs。最终会合并到 develop
和 master
分支。
hotfix/*
紧急修复分支,从 master
创建,最终会合并到 develop
和 master
分支。
Tag
tag 永远只在 master
分支创建。
release/*
分支合并到 master
之后,推送 master
到远端,然后创建 tag
, 推送 tag
到远端。
hotfix/*
分支合并到 master
之后,推送 master
到远端,然后创建 tag
, 推送 tag
到远端。
操作流
我们根据上面的理论,进行一次完整操作。
创建 develop 分支
新仓库默认是 master
分支,master
分支只作为发布版本,日常开发都要基于开发分支 develop
。从 master
分支创建 develop
分支:
git checkout -b develop master
推送 develop
分支,到远端:
git push origin develop
v0.1.0 开始开发
现在来开发第一个版本 v0.1.0
,首先从 develop
创建分支 feature/v0.1.0
:
git checkout -b feature/v0.1.0 develop
推送到远端:
git push origin feature/v0.1.0
各种 v0.1.0
版本功能代码的提交…
…….
v0.1.0 完成开发
开发完成后,将 feature/v0.1.0
合并到 develop
分支:
git checkout develop
git merge --no-ff feature/v0.1.0
--no-ff
参数的意思是不进行快速合并,merge
命令默认会进行“快进式合并(fast-farward merge)”,直接将 develop
指向 feature/v0.1.0
,这里使用阮一峰在Git分支管理策略中的图片。
加上--no-ff
参数后,合并的时候会生成一个新节点。可以保证版本演进的清晰。
推送到远端:
git push origin develop
删除 feature/v0.1.0
:
git branch -b feature/v0.1.0
预发布
开发完成之后,要进行测试,fix bugs。创建预发布分支:
git checkout -b release/v0.1.0 develop
git push origin release/v0.1.0
各种测试,各种蹂躏,各种 fix bugs ……
发布版本
经过测试和修复,终于要上线了,合并 release/v0.1.0
到 master
和 develop
:
#合并到master
git checkout master
git merge --no-ff release/v0.1.0
git push origin master
#打上tag
git tag -a v0.1.0 -m "publish v0.1.0"
git push origin v0.1.0
#合并到develop
git checkout develop
git merge --no-ff release/v0.1.0
git push origin develop
#删除 release/v0.1.0
git branch -d release/v0.1.0
出 bug 了
代码上线之后,出 bug 是谁都不愿意看到的,但是难免会出的嘛。下面我们进行修复,下面我们从 master
创建 hotfix/v0.1.0
分支,进行修复工作:
git checkout -b hotfix/v0.1.0 master
git push origin hotfix/v0.1.0
修复完成之后合并到 master
和 develop
分支:
#合并到master
git checkout master
git merge --no-ff hotfix/v0.1.0
git push origin master
#打上tag
git tag -a v0.1.1 -m "publish v0.1.1"
git push origin v0.1.1
#合并到develop
git checkout develop
git merge --no-ff hotfix/v0.1.0
git push origin develop
#删除 hotfix/v0.1.0
git branch -d hotfix/v0.1.0
利与弊
各个分支,各司其职,清晰可控。
经常切换分支,容易进行误操作(在不对应的分支上进行提交,细心能够解决)。
Git-flow 工具
由 git flow
提出者 Vincent Driessen开发的 git flow
工具。
Install
Homebrew
brew install git-flow
MacPorts
port install git-flow
wget
wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash
cURL
curl -L -O https://raw.github.com/nvie/gitflow/develop/contrib/gitflow-installer.sh
sudo bash gitflow-installer.sh
操作流
在项目根目录初始化 git flow
:
git flow init
会出现如下的一系列问题,都是设置各个分支前缀,直接回车默认值:
Which branch should be used for bringing forth production releases?
- master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
初始化完成之后,当前分支会变成 develop
分支。
v0.1.0 开始开发
输入如下命令,会从 develop
分支创建出 feature/v0.1.0
分支。
git flow feature start v0.1.0
推送分支到远端:
git flow feature publish v0.1.0
#或者
git push origin feature/v0.1.0
v0.1.0 完成开发
输入如下命令,会把 feature/v0.1.0
分支合并到 develop
分支,并删除 feature/v0.1.0
分支。
git flow feature finish v0.1.0
预发布
输入如下命令,会从 develop
分支创建出 release/v0.1.0
分支:
git flow release start v0.1.0
#推送到远端
git flow release publish v0.1.0
#或者
git push origin release/v0.1.0
发布版本
输入如下命令,会把 release/v0.1.0
分支合并到 develop
分支和 master
分支,并删除 release/v0.1.0
分支。
git flow release finish v0.1.0
出 bug 了
输入如下命令,会从 master
创建 hotfix/v0.1.1
分支。
git flow hotfix start v0.1.1
修复完成,输入如下命令,会合分别合并到 master
和 develop
:
git flow hotfix finish v0.1.1
抄袭文献
1,Git 工作流程
2,Git分支管理策略
3,A successful Git branching model
4,gitflow
5,使用GIT FLOW管理开发流程
6,git-flow 的工作流程