qingger / allProject

Go to a project
Toggle navigation Toggle navigation pinning
shipengfei
5d67aa2f 1 parent 0fc187db

Update git_flow.md

Inline Side-by-side
Showing 1 changed file with 72 additions and 72 deletions
1 -## GIT FLOW规范 1 +## GIT FLOW规范
2 2
3 -Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。 3 +Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
4 4
5 * [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/) 5 * [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
6 -* [基于git的源代码管理模型](http://www.ituring.com.cn/article/56870) 6 +* [基于git的源代码管理模型](http://www.ituring.com.cn/article/56870)
7 7
8 -### 1. GIT FLOW 规范 8 +### 1. GIT FLOW 规范
9 9
10 -项目永远存在两个分支 10 +项目永远存在两个分支
11 11
12 -* 主分支master 12 +* 主分支master
13 -* 开发分支 develop(dev) 13 +* 开发分支 develop(dev)
14 14
15 -对于master分支，任何时候这个分支拿到的，都是稳定发布版。 15 +对于master分支，任何时候这个分支拿到的，都是稳定发布版。
16 16
17 -而develop分支，存放的是最新的开发版。 17 +而develop分支，存放的是最新的开发版。
18 18
19 -其中，项目中存在四种短期分支 19 +其中，项目中存在四种短期分支
20 20
21 -* 功能分支 (feature branch) 21 +* 功能分支 (feature branch)
22 -* 补丁分支(hotfix branch) 22 +* 补丁分支(hotfix branch)
23 -* 测试bug分支(bug branch) 23 +* 测试bug分支(bug branch)
24 -* 预发分支(release branch) 24 +* 预发分支(release branch)
25 25
26 -一旦开发完成，以上分支会被合并到develop/master，然后删除 26 +一旦开发完成，以上分支会被合并到develop/master，然后删除
27 27
28 28
29 29
30 -对于版本发布的项目，每有一个稳定的版本，都要从master上打出一个版本，版本号按产品进行定义。 30 +对于版本发布的项目，每有一个稳定的版本，都要从master上打出一个版本，版本号按产品进行定义。
31 31
32 -在master分支上，在新的功能增加前，只有hotfix,才允许将代码合并到这个分支，合并后，要更新小版本号。 32 +在master分支上，在新的功能增加前，只有hotfix,才允许将代码合并到这个分支，合并后，要更新小版本号。
33 33
34 34
35 35
36 -**规则定义**: 36 +**规则定义**:
37 37
38 -* 任何向master进行提交，都需要打tag. tag的内容为当前版本号，当由release向master进行合并，在主版本和次版本中进行变化。由hotfix分支向master进行合并，在最小版本中进行变化。 38 +* 任何向master进行提交，都需要打tag. tag的内容为当前版本号，当由release向master进行合并，在主版本和次版本中进行变化。由hotfix分支向master进行合并，在最小版本中进行变化。
39 -* master分支合并，必须经过PM同意后才能合并。可通过git的merge request权限定义进行操作。 39 +* master分支合并，必须经过PM同意后才能合并。可通过git的merge request权限定义进行操作。
40 -* 所有的feature功能，都需要存在分支，分支可以不提交到远程库。 feature分支从当前的develop/dev分支进行派生。feature开发结束后，向develop进行rebase操作。向develop分支合并后，feature分支即可删除。 40 +* 所有的feature功能，都需要存在分支，分支可以不提交到远程库。 feature分支从当前的develop/dev分支进行派生。feature开发结束后，向develop进行rebase操作。向develop分支合并后，feature分支即可删除。
41 -* 所有的bugfix/hotfix功能，也都需要存在分支，分支可以不提交到远程库（只要验证确认即可）。 但是如果提交后，测试人员验证后，bugfix/hotfix即可删除。 41 +* 所有的bugfix/hotfix功能，也都需要存在分支，分支可以不提交到远程库（只要验证确认即可）。 但是如果提交后，测试人员验证后，bugfix/hotfix即可删除。
42 -* master分支不允许修改和提交，只允许PM进行Merge/Rebase操作。除非特殊情况下（比如，修改代码量非常小），由PM允许后，才能够在dev上直接修改并提交。 42 +* master分支不允许修改和提交，只允许PM进行Merge/Rebase操作。除非特殊情况下（比如，修改代码量非常小），由PM允许后，才能够在dev上直接修改并提交。
43 -* 当期功能完成后（可能存在多个feature, 多个bug分支），所有过程中产生的feature/bug分支都合并到了dev分支上。那么就由PM进行打版，版本统一向release###分支发布，release发布后，相应的本期开发的feat分支和bug分支删除。经过系统测试并产品验收后，由PM将release分支的内容合并到master上，并将release分支删除。 43 +* 当期功能完成后（可能存在多个feature, 多个bug分支），所有过程中产生的feature/bug分支都合并到了dev分支上。那么就由PM进行打版，版本统一向release###分支发布，release发布后，相应的本期开发的feat分支和bug分支删除。经过系统测试并产品验收后，由PM将release分支的内容合并到master上，并将release分支删除。
44 -* 当一个bug产生后，由测试人员/开发人员登录BUG（注意，必须登录到禅道），开发人员确认此BUG是否影响到mastery主分支，如果影响，则必须从master分支签出一个hotfix分支进行修改，如果不影响，则从关联的dev/release中签出相应的bugfix分支进行修改。 修改完成后，hotfix分支需要merge到master/dev/release分支，bugfix分支需要merge到dev/release分支。bugfix/hotfix分支的名称必须包含禅道中的BUG号。 44 +* 当一个bug产生后，由测试人员/开发人员登录BUG（注意，必须登录到禅道），开发人员确认此BUG是否影响到mastery主分支，如果影响，则必须从master分支签出一个hotfix分支进行修改，如果不影响，则从关联的dev/release中签出相应的bugfix分支进行修改。 修改完成后，hotfix分支需要merge到master/dev/release分支，bugfix分支需要merge到dev/release分支。bugfix/hotfix分支的名称必须包含禅道中的BUG号。
45 -* 在一个时间，feature分支可以存在多个，bugfix/hotfix分支可以存在多个，但release分支不会有多个，只会存在一个，这一个就是从dev签出，且即将要发布到master的那个版本。当release发布到master后，PM需要将release分支删除。 45 +* 在一个时间，feature分支可以存在多个，bugfix/hotfix分支可以存在多个，但release分支不会有多个，只会存在一个，这一个就是从dev签出，且即将要发布到master的那个版本。当release发布到master后，PM需要将release分支删除。
46 -* 所有前端项目/API项目都遵守此规则。 46 +* 所有前端项目/API项目都遵守此规则。
47 47
48 48
49 49
50 -![](http://www.ituring.com.cn/download/01YiLAQQnlPV) 50 +![](http://resource.qingger.com/QQ%E5%9B%BE%E7%89%8720170711130718.png)
51 51
52 -### 2. 提交Commit规范 52 +### 2. 提交Commit规范
53 53
54 -提交commit，一定要给出完整扼要的提交信息。项目经理需要检查提交的信息是否足够。每个成员也需要确保自己的提交信息完整。提交信息如下所示： 54 +提交commit，一定要给出完整扼要的提交信息。项目经理需要检查提交的信息是否足够。每个成员也需要确保自己的提交信息完整。提交信息如下所示：
55 55
56 ``` 56 ```
57 Present-tense summary under 50 characters 57 Present-tense summary under 50 characters
...@@ -62,107 +62,107 @@ Present-tense summary under 50 characters ...@@ -62,107 +62,107 @@ Present-tense summary under 50 characters
62 http://project.management-system.com/ticket/123 62 http://project.management-system.com/ticket/123
63 ``` 63 ```
64 64
65 -一个正式的提交功能的注释: 65 +一个正式的提交功能的注释:
66 66
67 ``` 67 ```
68 -HOTFIX3001(UserController|CacheListener) : 解决了头部Cache没有引入的问题 68 +HOTFIX3001(UserController|CacheListener) : 解决了头部Cache没有引入的问题
69 69
70 -1. UserController头部没有引入Cache包导致异常 70 +1. UserController头部没有引入Cache包导致异常
71 -2. CacheListener Log去除 71 +2. CacheListener Log去除
72 72
73 http://chandao.runsa.cn:8604/pro/bug-view-3001.html 73 http://chandao.runsa.cn:8604/pro/bug-view-3001.html
74 ``` 74 ```
75 75
76 -不建议通过git commit命令提交，而是建议通过SourceTree或者git cz命令进行提交。 76 +不建议通过git commit命令提交，而是建议通过SourceTree或者git cz命令进行提交。
77 77
78 -关于git cz命令，查看: [Git Commit](https://mp.weixin.qq.com/s?__biz=MzAwNDYwNzU2MQ==&mid=401622986&idx=1&sn=470717939914b956ac372667ed23863c&scene=2&srcid=0114ZcTNyAMH8CLwTKlj6CTN&from=timeline&isappinstalled=0#wechat_redirect) 78 +关于git cz命令，查看: [Git Commit](https://mp.weixin.qq.com/s?__biz=MzAwNDYwNzU2MQ==&mid=401622986&idx=1&sn=470717939914b956ac372667ed23863c&scene=2&srcid=0114ZcTNyAMH8CLwTKlj6CTN&from=timeline&isappinstalled=0#wechat_redirect)
79 79
80 80
81 81
82 -#### 2.1 提交Commit内容定义 82 +#### 2.1 提交Commit内容定义
83 83
84 -[教你如何在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) 84 +[教你如何在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)
85 85
86 -##### 2.1.1 Commit具体格式 86 +##### 2.1.1 Commit具体格式
87 87
88 ``` 88 ```
89 Type(Scope) : Subject 89 Type(Scope) : Subject
90 -<空行> 90 +<空行>
91 <body> 91 <body>
92 -<空行> 92 +<空行>
93 <footer> 93 <footer>
94 ``` 94 ```
95 95
96 -Type表示提交所属类型，定义如下: 96 +Type表示提交所属类型，定义如下:
97 97
98 -* feat#### : 表示新增加的功能，####表示功能编号，功能编号取自于禅道中登录的功能列表ID 98 +* feat#### : 表示新增加的功能，####表示功能编号，功能编号取自于禅道中登录的功能列表ID
99 -* hotfix#### : 表示热补丁提交，一般产生这个提交是为当前线上环境错误进行了修正，来自的分支也是从master中分离出来的。####表示的是 99 +* hotfix#### : 表示热补丁提交，一般产生这个提交是为当前线上环境错误进行了修正，来自的分支也是从master中分离出来的。####表示的是
100 -* bugfix#### : 在功能性测试阶段，在测试过程中发现的BUG修复提交。这个提交只会出现在develop和release分支中。 100 +* bugfix#### : 在功能性测试阶段，在测试过程中发现的BUG修复提交。这个提交只会出现在develop和release分支中。
101 -* doc : 表示文档性提交，提交此代码不会影响任何运行逻辑。 101 +* doc : 表示文档性提交，提交此代码不会影响任何运行逻辑。
102 -* style : 代码格式变动，比如对代码进行格式化缩进整理，显示变动等。 102 +* style : 代码格式变动，比如对代码进行格式化缩进整理，显示变动等。
103 -* refactor : 重构，不是新增功能，也不是修改bug的代码变动，比如优化了函数内部的实现逻辑，重命名了函数，将类的功能进行重构等。 103 +* refactor : 重构，不是新增功能，也不是修改bug的代码变动，比如优化了函数内部的实现逻辑，重命名了函数，将类的功能进行重构等。
104 -* test : 测试所使用，提交的代码为单元测试或者为某一功能测试用。 104 +* test : 测试所使用，提交的代码为单元测试或者为某一功能测试用。
105 -* chore : 构建过程或者辅助工具依赖的变动。比如，composer,npm变更，构建代码的变更等。 105 +* chore : 构建过程或者辅助工具依赖的变动。比如，composer,npm变更，构建代码的变更等。
106 106
107 - 对于新的功能, 107 + 对于新的功能,
108 108
109 109
110 110
111 -**Scope**表示本次Commit影响范围，简要说明修改会涉及的部分，使用英文或中文。 111 +**Scope**表示本次Commit影响范围，简要说明修改会涉及的部分，使用英文或中文。
112 112
113 -如果只修改了一个文件，即写文件的名称，但不要写后缀名，如SiteProductController。 113 +如果只修改了一个文件，即写文件的名称，但不要写后缀名，如SiteProductController。
114 114
115 -如果修改了多个文件，则写本次修改的大概影响范围，如修改了买家的积分获取方式，影响到了积分获取，积分显示，积分兑换等 ，则可以使用 : 买家积分模块 或者 BuyerPointsMode 都是可以的。 115 +如果修改了多个文件，则写本次修改的大概影响范围，如修改了买家的积分获取方式，影响到了积分获取，积分显示，积分兑换等 ，则可以使用 : 买家积分模块 或者 BuyerPointsMode 都是可以的。
116 116
117 117
118 118
119 -**Subject** 则简要描述本次改动，有效示例： 119 +**Subject** 则简要描述本次改动，有效示例：
120 120
121 ``` 121 ```
122 -对于买家积分显示、获得的程序变更 122 +对于买家积分显示、获得的程序变更
123 -个人中心页面布局变化 123 +个人中心页面布局变化
124 ``` 124 ```
125 125
126 126
127 127
128 -**Body** : 内容是对上面subject里内容的展开，在此做更加详尽的描述，如果subject能够讲清楚此次变更的动机，则body可以不填，如果描述不清楚(尤其对于feature的提交），则必须在body中写出此次修改的动机及详细描述。有效示例: 128 +**Body** : 内容是对上面subject里内容的展开，在此做更加详尽的描述，如果subject能够讲清楚此次变更的动机，则body可以不填，如果描述不清楚(尤其对于feature的提交），则必须在body中写出此次修改的动机及详细描述。有效示例:
129 129
130 ``` 130 ```
131 -因为新增了积分变化的功能，所以对于以下接口需要考虑到积分是否有效及有效期的判断: 131 +因为新增了积分变化的功能，所以对于以下接口需要考虑到积分是否有效及有效期的判断:
132 - - 个人积分显示接口(/buyer/point/) 132 + - 个人积分显示接口(/buyer/point/)
133 - - 积分锁定接口(/buyer/point/lock) 133 + - 积分锁定接口(/buyer/point/lock)
134 - - 积分解锁接口(/buyer/point/unlock) 134 + - 积分解锁接口(/buyer/point/unlock)
135 ``` 135 ```
136 136
137 ``` 137 ```
138 -个人中心页面布局按照功能点#3333，需要作出如下变更,具体变更点和UI参考: 138 +个人中心页面布局按照功能点#3333，需要作出如下变更,具体变更点和UI参考:
139 - UI : http://xxxx.com/ 139 - UI : http://xxxx.com/
140 - Feature : http://xxx.com 140 - Feature : http://xxx.com
141 ``` 141 ```
142 142
143 143
144 144
145 -**footer**里的主要放置**不兼容变更**和**Issue关闭**的信息，一般不用填写。 145 +**footer**里的主要放置**不兼容变更**和**Issue关闭**的信息，一般不用填写。
146 146
147 147
148 148
149 -### 3. 使用git rebase代替git merge （尤其是针对develop派生出来的feature进行合并时） 149 +### 3. 使用git rebase代替git merge （尤其是针对develop派生出来的feature进行合并时）
150 150
151 -当多个分支并行发展，需要合并时，使用rebase功能进行合并，这样在SourceTree跟踪代码变更时，会更清晰易懂。 151 +当多个分支并行发展，需要合并时，使用rebase功能进行合并，这样在SourceTree跟踪代码变更时，会更清晰易懂。
152 152
153 -使用rebase经常会用在多个feature分支,或者多个bug分支并行开发，最后再将多个分支合并时候所做的操作。 153 +使用rebase经常会用在多个feature分支,或者多个bug分支并行开发，最后再将多个分支合并时候所做的操作。
154 154
155 -[参考:git rebase简介(基本篇)](http://blog.csdn.net/hudashi/article/details/7664631) 155 +[参考:git rebase简介(基本篇)](http://blog.csdn.net/hudashi/article/details/7664631)
156 156
157 157
158 158
159 159
160 160
161 -### 4. 其它 161 +### 4. 其它
162 162
163 -git分支管理流程可以查看: 163 +git分支管理流程可以查看:
164 164
165 -[Git flow 開發流程](https://ihower.tw/blog/archives/5140) 165 +[Git flow 開發流程](https://ihower.tw/blog/archives/5140)
166 166
167 -[GIT分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html) 167 +[GIT分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html)
168 168
......