qingger / allProject

Go to a project
Toggle navigation Toggle navigation pinning
Switch branch/tag
git_flow.md 7.99 KB

GIT FLOW规范

Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。

1. GIT FLOW 规范

项目永远存在两个分支

  • 主分支master
  • 开发分支 develop(dev)

对于master分支，任何时候这个分支拿到的，都是稳定发布版。

而develop分支，存放的是最新的开发版。

其中，项目中存在四种短期分支

  • 功能分支 (feature branch)
  • 补丁分支(hotfix branch)
  • 测试bug分支(bug branch)
  • 预发分支(release branch)

一旦开发完成，以上分支会被合并到develop/master，然后删除

对于版本发布的项目，每有一个稳定的版本，都要从master上打出一个版本，版本号按产品进行定义。

在master分支上，在新的功能增加前，只有hotfix,才允许将代码合并到这个分支，合并后，要更新小版本号。

规则定义:

  • 任何向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项目都遵守此规则。

2. 提交Commit规范

提交commit，一定要给出完整扼要的提交信息。项目经理需要检查提交的信息是否足够。每个成员也需要确保自己的提交信息完整。提交信息如下所示：

Present-tense summary under 50 characters

* More information about commit (under 72 characters).
* More information about commit (under 72 characters).

http://project.management-system.com/ticket/123

一个正式的提交功能的注释:

HOTFIX3001(UserController|CacheListener) : 解决了头部Cache没有引入的问题

1. UserController头部没有引入Cache包导致异常
2. CacheListener Log去除

http://chandao.runsa.cn:8604/pro/bug-view-3001.html

不建议通过git commit命令提交，而是建议通过SourceTree或者git cz命令进行提交。

关于git cz命令，查看: Git Commit

2.1 提交Commit内容定义

教你如何在Commit时有话可说

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简介(基本篇)

4. 其它

git分支管理流程可以查看:

Git flow 開發流程

GIT分支管理策略