分支管理
- 管理员从
develop
创建 feature-* 分支,注意此处需将该分支置为Protected
- 开发人员参考 【Merge Request 流程/规范】将项目 Fork 到本地,之后根据功能点提交,并发起 Merge Request
- 相关人员(管理员、项目负责人)进行
Code Review
,将代码合并到 feature-* 分支 - 提测时,由管理员将 feature-* 分支合并到
develop
分支,开始自测 - 自测完成后,将 develop 分支合并到
release
分支,然后构建测试环境 - 测试通过,将 release 分支合并到
master
分支,由测试人员进行回归 - 上线时,由管理员根据上线日期添加
Tag
,eg. ‘20180101’ - 最后,管理员将 master 分支合并到
develop
线上问题修复流程
- 管理员从
master
创建 hotfix-* 分支,注意此处需将该分支置为Protected
- 开发人员参考 【Merge Request 流程/规范】将项目 Fork 到本地,之后根据功能点提交,并发起 Merge Request
- 相关人员(管理员、项目负责人)进行
Code Review
,将代码合并到 hotfix-* 分支 - 提测时,直接在 hotfix-* 分支发版测试
- 测试通过,将 hotfix-* 分支合并到
master
分支,由测试人员进行回归 - 上线时,由管理员根据上线日期添加
Tag
,eg. ‘20180101’ - 最后,管理员将 master 分支合并到
develop
提交规范
Commit Message 第一行的提交类型必须是以下类型之一:feat
, fix
, docs
, style
, refactor
, perf
, test
, chore
, revert
feat – 实现新功能(feature)
当新需求或新功能的实现完成并测试通过时,开发人员需提交该部分变更的代码,并且按照上述的 Commit Message 格式编写提交注解。
E.g: feat: add listView components to bill search page
fix – 解决bug
当Bug修复完成并确认已经彻底解决时,开发人员需提交该部分变更的代码,并且按照上述的 Commit Message 格式编写提交注解。
E.g.1: fix: when submit button has ever been triggered, do not trigger again.(#1871)
E.g.2: fix: fix the NullPointException when updating bill.(#1891)
docs – 只针对文档(documention)变更
如果提交的改动只是针对文档的变更,则提交类型可以设为 docs
。
E.g: docs: add the document of Git Commit Message Guideline
style – 代码样式(style)变更(格式化代码,不影响代码原意)
如果提交的改动只是针对代码样式或者格式的变更,则提交类型可以设为 style
。
E.g: style: reformat service layer code
refactor – 代码重构(refactor)(既不是解决bug也不是实现新功能)
如果提交的改动是针对代码重构的,则提交类型可以填写为 refactor
。
E.g: refactor : refactor default search function
test – 添加缺少的测试(test)代码
添加的代码为测试相关的代码,则提交类型可以填写为 test
。
E.g: test: add unit test for user login function
perf – 优化系统性能(performance)
若提交的改动是针对系统性能的优化的,则提交类型填写为 perf
。
E.g: perf: improve the performance of filtering the required bill list
chore – 针对构建过程或者辅助工具的变更
chore: 日常零碎变更,这里主要是针对构建过程、辅助工具、抑或是其他无关主题代码的变更。
E.g: chore: add css preprocessor trees
revert – 回滚提交
如果当次提交是为了还原上一次提交,那么提交的消息需要以 revert:
开头,后面跟着要还原的提交的消息头。消息体的内容可以描述为:This reverts commit <要还原的提交的hash编码>
。
Merge Request 流程/规范
打开
<group>/<project>
,fork项目到自己的个人中心clone自己个人中心的项目到本地
$ git clone http://git.jc/<自己的用户名>/<project>.git |
本地关联
添加项目的源仓库
$ git remote add upstream http://git.jc/<group>/<project>.git |
$ git remote -v |
通过 fetch & rebase upstram
远程同步代码
push 到自己的远程然后通过 Merge Request
的方式合并到项目
我们用 fetch + rebase
的方式同步代码,这与 fetch + merge(pull)
的区别在于http://stackoverflow.com/questions/28140434/is-there-a-difference-between-git-rebase-and-git-merge-ff-only
如果 rebase 失败,可以退出 rebasing 状态,使用命令
$ git rebase --abort |
示例
- 团队的远程仓库:
upstream
- 自己fork的远程仓库:
origin
- 本地clone origin的仓库:
local
假设我们在 feature-xxx
分支开发,要开发一个新页面 newPage
- 同步
local/feature-xxx
和upstream/feature-xxx
、origin/feature-xxx
的代码
//提交你本地的代码 |
如果 rebase
期间遇到冲突,先解决冲突(git add .
,不要commit
),然后:
$ git:(feature-xxx) git add . |
- 新建特性分支
local/feature-newPage
$ git:(feature-xxx) git checkout -b feature-newPage |
- 进行本地开发操作,完成第一个功能(或创建了需要的文件)
- 把本地分支推送到
origin
$ git:(feature-newPage) git push origin feature-newPage |
- 继续进行本地开发,频繁的commit,按合理的颗粒度推送到
origin
(推送前,适当的用git reabse -i
美化commit),便于大家看到任务进度 - 开发完成,同步到最新代码,推送
feature-newPage
到origin
,并登录gitlab
修改merge request
的title,去掉WIP
标示
$ git:(feature-newPage) git fetch upstream |
- 等待
merge
,并同步进行新的开发任务
Tips
在commit
过程中尽量做到按功能点提交代码,但是也要做到尽量勤快的commit
,所以要用git rebase
去做合并提交的工作(没有push之前一切都还来得及!!!)
假设离你上次push你有三次commit,但是你只有一个功能点
$ git log --graph --oneline --all |
$ git rebase -i HEAD~3 |
pick 4f4b2f6 commit 2 |
# Rebase 4887144..017d1f0 onto 4887144 (3 command(s)) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # |
按照说明用r
去编辑commit,s
去合并之前的commit
pick 4f4b2f6 commit 2 |
合并后新的commit记录:
$ git log --graph --oneline --all |