git flow rule

shipfi
Commit 0fc187db8a08c78cc3afe2c9e472b297c58e7f03 0fc187db 1 parent e852d1d0
Showing 1 changed file with 97 additions and 6 deletions
Docs/Rules/PHPCoding/git_flow.md
--- a/Docs/Rules/PHPCoding/git_flow.md
View file @0fc187d
+++ b/Docs/Rules/PHPCoding/git_flow.md
View file @0fc187d
 ## 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. 其它