qingger / allProject

Go to a project
Toggle navigation Toggle navigation pinning
shipfi
0fc187db 1 parent e852d1d0

git flow rule

Inline Side-by-side
Showing 1 changed file with 97 additions and 6 deletions
## GIT FLOW规范
Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
* [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
* [基于git的源代码管理模型](http://www.ituring.com.cn/article/56870)
### 1. GIT FLOW 规范
项目永远存在两个分支
* 主分支master
* 开发分支 develop
* 开发分支 develop(dev)
对于master分支，任何时候这个分支拿到的，都是稳定发布版。
而develop分支，存放的是最新的开发版。
其中，项目中存在四种短期分支
* 功能分支 (feature branch)
......@@ -30,7 +33,23 @@
### 2. 提交Commit
**规则定义**:
* 任何向master进行提交，都需要打tag. tag的内容为当前版本号，当由release向master进行合并，在主版本和次版本中进行变化。由hotfix分支向master进行合并，在最小版本中进行变化。
* master分支合并，必须经过PM同意后才能合并。可通过git的merge request权限定义进行操作。
* 所有的feature功能，都需要存在分支，分支可以不提交到远程库。 feature分支从当前的develop/dev分支进行派生。feature开发结束后，向develop进行rebase操作。向develop分支合并后，feature分支即可删除。
* 所有的bugfix/hotfix功能，也都需要存在分支，分支可以不提交到远程库（只要验证确认即可）。 但是如果提交后，测试人员验证后，bugfix/hotfix即可删除。
* master分支不允许修改和提交，只允许PM进行Merge/Rebase操作。除非特殊情况下（比如，修改代码量非常小），由PM允许后，才能够在dev上直接修改并提交。
* 当期功能完成后（可能存在多个feature, 多个bug分支），所有过程中产生的feature/bug分支都合并到了dev分支上。那么就由PM进行打版，版本统一向release###分支发布，release发布后，相应的本期开发的feat分支和bug分支删除。经过系统测试并产品验收后，由PM将release分支的内容合并到master上，并将release分支删除。
* 当一个bug产生后，由测试人员/开发人员登录BUG（注意，必须登录到禅道），开发人员确认此BUG是否影响到mastery主分支，如果影响，则必须从master分支签出一个hotfix分支进行修改，如果不影响，则从关联的dev/release中签出相应的bugfix分支进行修改。 修改完成后，hotfix分支需要merge到master/dev/release分支，bugfix分支需要merge到dev/release分支。bugfix/hotfix分支的名称必须包含禅道中的BUG号。
* 在一个时间，feature分支可以存在多个，bugfix/hotfix分支可以存在多个，但release分支不会有多个，只会存在一个，这一个就是从dev签出，且即将要发布到master的那个版本。当release发布到master后，PM需要将release分支删除。
* 所有前端项目/API项目都遵守此规则。
![](http://www.ituring.com.cn/download/01YiLAQQnlPV)
### 2. 提交Commit规范
提交commit，一定要给出完整扼要的提交信息。项目经理需要检查提交的信息是否足够。每个成员也需要确保自己的提交信息完整。提交信息如下所示：
......@@ -52,7 +71,6 @@ HOTFIX3001(UserController|CacheListener) : 解决了头部Cache没有引入的问题
2. CacheListener Log去除
http://chandao.runsa.cn:8604/pro/bug-view-3001.html
```
不建议通过git commit命令提交，而是建议通过SourceTree或者git cz命令进行提交。
......@@ -61,10 +79,83 @@ http://chandao.runsa.cn:8604/pro/bug-view-3001.html
### 3. 使用git rebase代替git merge
#### 2.1 提交Commit内容定义
[教你如何在Commit时有话可说](http://mp.weixin.qq.com/s?__biz=MzAwNDYwNzU2MQ==&mid=401622986&idx=1&sn=470717939914b956ac372667ed23863c&scene=2&srcid=0114ZcTNyAMH8CLwTKlj6CTN&from=timeline&isappinstalled=0#wechat_redirect)
##### 2.1.1 Commit具体格式
```
Type(Scope) : Subject
<空行>
<body>
<空行>
<footer>
```
Type表示提交所属类型，定义如下:
* feat#### : 表示新增加的功能，####表示功能编号，功能编号取自于禅道中登录的功能列表ID
* hotfix#### : 表示热补丁提交，一般产生这个提交是为当前线上环境错误进行了修正，来自的分支也是从master中分离出来的。####表示的是
* bugfix#### : 在功能性测试阶段，在测试过程中发现的BUG修复提交。这个提交只会出现在develop和release分支中。
* doc : 表示文档性提交，提交此代码不会影响任何运行逻辑。
* style : 代码格式变动，比如对代码进行格式化缩进整理，显示变动等。
* refactor : 重构，不是新增功能，也不是修改bug的代码变动，比如优化了函数内部的实现逻辑，重命名了函数，将类的功能进行重构等。
* test : 测试所使用，提交的代码为单元测试或者为某一功能测试用。
* chore : 构建过程或者辅助工具依赖的变动。比如，composer,npm变更，构建代码的变更等。
对于新的功能,
**Scope**表示本次Commit影响范围，简要说明修改会涉及的部分，使用英文或中文。
如果只修改了一个文件，即写文件的名称，但不要写后缀名，如SiteProductController。
如果修改了多个文件，则写本次修改的大概影响范围，如修改了买家的积分获取方式，影响到了积分获取，积分显示，积分兑换等 ，则可以使用 : 买家积分模块 或者 BuyerPointsMode 都是可以的。
**Subject** 则简要描述本次改动，有效示例：
```
对于买家积分显示、获得的程序变更
个人中心页面布局变化
```
**Body** : 内容是对上面subject里内容的展开，在此做更加详尽的描述，如果subject能够讲清楚此次变更的动机，则body可以不填，如果描述不清楚(尤其对于feature的提交），则必须在body中写出此次修改的动机及详细描述。有效示例:
```
因为新增了积分变化的功能，所以对于以下接口需要考虑到积分是否有效及有效期的判断:
- 个人积分显示接口(/buyer/point/)
- 积分锁定接口(/buyer/point/lock)
- 积分解锁接口(/buyer/point/unlock)
```
```
个人中心页面布局按照功能点#3333，需要作出如下变更,具体变更点和UI参考:
- UI : http://xxxx.com/
- Feature : http://xxx.com
```
**footer**里的主要放置**不兼容变更**和**Issue关闭**的信息，一般不用填写。
### 3. 使用git rebase代替git merge （尤其是针对develop派生出来的feature进行合并时）
当多个分支并行发展，需要合并时，使用rebase功能进行合并，这样在SourceTree跟踪代码变更时，会更清晰易懂。
使用rebase经常会用在多个feature分支,或者多个bug分支并行开发，最后再将多个分支合并时候所做的操作。
[参考:git rebase简介(基本篇)](http://blog.csdn.net/hudashi/article/details/7664631)
### 4. 其它
......