|
|
|
git-flow的使用规范
|
|
|
|
=========================
|
|
|
|
|
|
|
|
Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
|
|
|
|
|
|
|
|
一图胜千言，我绘制了一个关于git-flow原理示意图。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
开发流程描述：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 主分支
|
|
|
|
|
|
|
|
主分支只有两个，一个是develop，一个是master。
|
|
|
|
|
|
|
|
#### master分支
|
|
|
|
master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
|
|
|
|
|
|
|
|
#### develop分支
|
|
|
|
develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。
|
|
|
|
|
|
|
|
当develop分支上的代码已实现了一次迭代开发所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。
|
|
|
|
|
|
|
|
因此，每次将develop分支上的代码合并回master分支时，我们都可以认为一个新的可供在生产环境中部署的版本就产生了。
|
|
|
|
需要遵循如下原则：
|
|
|
|
|
|
|
|
> #### 仅在发布新的可供部署的代码时才更新master分支上的代码
|
|
|
|
|
|
|
|
每当有代码提交到master分支时，我们可以使用Git Hook触发软件自动测试以及生产环境代码的自动更新工作。这些自动化操作将有利于减少新代码发布之后的一些事务性工作。
|
|
|
|
|
|
|
|
### 辅助分支
|
|
|
|
辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。
|
|
|
|
|
|
|
|
辅助分支包括：
|
|
|
|
|
|
|
|
* 用于开发新功能时所使用的feature分支；
|
|
|
|
* 用于辅助版本发布的release分支；
|
|
|
|
* 用于修正生产代码中的缺陷的hotfix分支。
|
|
|
|
|
|
|
|
### feature分支
|
|
|
|
使用规范：
|
|
|
|
|
|
|
|
* 可以从develop分支发起feature分支
|
|
|
|
* 代码必须合并回develop分支,同时删除这个临时分支
|
|
|
|
* feature分支的命名可以使用除master，develop，release-\* ，hotfix-\* 之外的任何名称
|
|
|
|
|
|
|
|
一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
|
|
|
|
|
|
|
|
### release分支
|
|
|
|
|
|
|
|
使用规范：
|
|
|
|
|
|
|
|
* 可以从develop分支派生
|
|
|
|
* 必须合并回develop分支和master分支
|
|
|
|
* 分支命名惯例：release-*
|
|
|
|
|
|
|
|
|
|
|
|
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。**通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期**。
|
|
|
|
|
|
|
|
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。**而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）**。
|
|
|
|
|
|
|
|
成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
|
|
|
|
|
|
|
|
### hotfix分支
|
|
|
|
|
|
|
|
使用规范：
|
|
|
|
|
|
|
|
* 可以从master分支派生
|
|
|
|
* 必须合并回master分支和develop分支
|
|
|
|
* 分支命名惯例：hotfix-*
|
|
|
|
|
|
|
|
除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。
|
|
|
|
|
|
|
|
当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。
|
|
|
|
|
|
|
|
这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
|
|
|
|
|
|
|
|
### 目的
|
|
|
|
Git Flow开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束。应该说，为我们的软件开发提供了一个可供参考的管理模型。Git Flow开发模型让nvie的开发代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。
|
|
|
|
|
|
|
|
### 使用
|
|
|
|
|
|
|
|
使用 SourceTree 进行 git-flow 实践，[sourcetree下载地址](http://pan.baidu.com/s/1kTmkQBd)，命令行的请跳转到[这里](https://github.com/nvie/gitflow),这里主要使用图形化界面，为了更容易使用。
|
|
|
|
|
|
|
|
安装过程不再赘述，在window安装时，会提醒安装git，记得安装一下即可。
|
|
|
|
|
|
|
|
如果这个项目是自己建立的（以gitlab为例），登录gitlab，在右上角有个“+”，可以新建一个项目
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
填写表单，提交即可创建成功：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
如果你需要走SSH的协议，来管理这个项目，请访问setting>SSHkeys进行设置，生成key的[方法传送门](http://git.dev.yoho.cn/help/ssh/ssh)
|
|
|
|
如果不是点击http,复制后面的链接
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
打开SourceTree，如下点击克隆，黏贴那个url，选择一个本地保存目录，点击克隆，即可。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
按照惯例，需要在项目里添加一个README.md文件，用于项目说明，勾选上然后提交，本地就有了一个master分支了，勾选立即推送变更，就会同步到gitlab的代码仓库了。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
刷新刚才的gitlab页面，发现已经改变了
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我们点击下soucetree gui 下git-flow按钮，点击确定即可，本地的gitflow分支就建好了（master，develop）
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
点击推送，可以把本地的分支同步到远程仓库
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
接下来的开发就是按部就班的进行了，可以点击里面的不同动作（分支），进行开发了。
|
|
|
|
|
|
|
|
|
|
|
|
后面的操作不再赘述。
|
|
|
|
|
|
|
|
|
|
|
|
关于权限的说明，gitlab可以设置开发权限，具体参照：[传送门](http://git.dev.yoho.cn/help/permissions/permissions)
|
|
|
|
|
|
|
|
简单来讲：
|
|
|
|
|
|
|
|
项目可以分为
|
|
|
|
* 私人
|
|
|
|
项目必须明确授权给每个使用的用户。
|
|
|
|
* 内部
|
|
|
|
该项目可以由任何登录的用户被克隆。
|
|
|
|
* 公开
|
|
|
|
该项目无需任何身份验证克隆。
|
|
|
|
|
|
|
|
用户权限分为
|
|
|
|
|
|
|
|
Guest（客人）
|
|
|
|
Reporter（测试人员）
|
|
|
|
Developer（开发者）
|
|
|
|
Master（项目主人）
|
|
|
|
Owner（项目拥有者）
|
|
|
|
|
|
|
|
原则：
|
|
|
|
> 开发者在远程仓库下不具备合并到Master的权限，
|
|
|
|
|
|
|
|
> 合并Master项目负责的组长操作，如合并hotfix分支到master，release到master。
|
|
|
|
|
|
|
|
> 测试人员只有对release分支的测试权限。
|
|
|
|
|
|
|
|
> release分支主要用于一次迭代开发完成后的候选版本，供测试部门进行持续集成用。
|
|
|
|
|
|
|
|
> 在远程仓库上的临时分支合并后需要删除。
|
|
|
|
|
|
|
|
> 生产环境的版本请使用Tag进行管理，方便切换和回滚。
|
|
|
|
|
|
|
|
附录：
|
|
|
|
[gitflow备忘清单](http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html) |
|
|
\ No newline at end of file |
...
|
...
|
|
