分支管理

  • 管理员从 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自己个人中心的项目到本地

  1. $ git clone http://git.jc/<自己的用户名>/<project>.git

本地关联

添加项目的源仓库

  1. $ git remote add upstream http://git.jc/<group>/<project>.git
  1. $ git remote -v
  3. origin  http://git.jc/<自己的用户名>/<project>.git (fetch)
  4. origin  http://git.jc/<自己的用户名>/<project>.git (push)
  5. upstream  http://git.jc/<group>/<project>.git (fetch)
  6. upstream  http://git.jc/<group>/<project>.git (push)

通过 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 状态，使用命令

  1. $ git rebase --abort

示例

  • 团队的远程仓库：upstream
  • 自己fork的远程仓库：origin
  • 本地clone origin的仓库：local

假设我们在 feature-xxx 分支开发，要开发一个新页面 newPage

  1. 同步 local/feature-xxx 和 upstream/feature-xxx、origin/feature-xxx 的代码
  1. //提交你本地的代码
  2. $ git:(feature-xxx) git add file
  3. $ git:(feature-xxx) git commit -m message
  4. //将你本地的分支与远程服务器分支合并
  5. $ git:(feature-xxx) git fetch upstream
  6. $ git:(feature-xxx) git rebase upstream/feature-xxx
  7. $ git:(feature-xxx) git push origin feature-xxx

如果 rebase 期间遇到冲突，先解决冲突（git add .，不要commit），然后：

  1. $ git:(feature-xxx) git add .
  2. $ git:(feature-xxx) git rebase --continue
  1. 新建特性分支 local/feature-newPage
  1. $ git:(feature-xxx) git checkout -b feature-newPage
  2. Switch to a new branch 'feature-newPage'
  3. $ git:(feature-newPage)
  1. 进行本地开发操作，完成第一个功能（或创建了需要的文件）
  2. 把本地分支推送到origin
  1. $ git:(feature-newPage) git push origin feature-newPage
  2. Total 0 (delta 0), reused 0 (delta 0)
  3. To http://git.jc/用户名/mobile.git
  4.  * [new branch]      feature-newPage -> feature-newPage
  1. 继续进行本地开发，频繁的commit，按合理的颗粒度推送到origin（推送前，适当的用git reabse -i美化commit），便于大家看到任务进度
  2. 开发完成，同步到最新代码，推送feature-newPage到origin，并登录gitlab修改merge request的title，去掉WIP标示
  1. $ git:(feature-newPage) git fetch upstream
  2. $ git:(feature-newPage) git rebase upstream/feature-xxx
  3. $ git:(feature-newPage) git push -f origin feature-newPage
  1. 等待merge，并同步进行新的开发任务

Tips

在commit过程中尽量做到按功能点提交代码，但是也要做到尽量勤快的commit，所以要用git rebase去做合并提交的工作(没有push之前一切都还来得及！！！)

假设离你上次push你有三次commit，但是你只有一个功能点

  1. $ git log --graph --oneline --all
  3. * 017d1f0 commit 4
  4. * 1e46126 commit 3
  5. * 4f4b2f6 commit 2
  6. * 4887144 commit 1
  1. $ git rebase -i HEAD~3
  1. pick 4f4b2f6 commit 2
  2. pick 1e46126 commit 3
  3. pick 017d1f0 commit 4
  1. # Rebase 4887144..017d1f0 onto 4887144 (3 command(s))
  2. #
  3. # Commands:
  4. # p, pick = use commit
  5. # r, reword = use commit, but edit the commit message
  6. # e, edit = use commit, but stop for amending
  7. # s, squash = use commit, but meld into previous commit
  8. # f, fixup = like "squash", but discard this commit's log message
  9. # x, exec = run command (the rest of the line) using shell
  10. # d, drop = remove commit
  11. #

按照说明用r去编辑commit，s去合并之前的commit

  1. pick 4f4b2f6 commit 2
  2. s 1e46126 commit 3
  3. s 017d1f0 commit 4

合并后新的commit记录：

  1. $ git log --graph --oneline --all
  3. * e41ef96 xxx-feature
  4. * 4887144 commit 1