Uninote
Uninote
用户根目录

开发规范 - git

git 规范总览

  • 总的原则:每一个 commit 都应该方便别人和自己查阅!
  • 认真思考每一个文件是否需要加入 git,要加入的:
    • 各种 版本 lock 文件要加入 git 管理
  • 不要加入的:
    • 临时文件,各种 runtime 生成文件,.idea 等 IDE 生成文件
    • 包管理安装的安装包(node_module..., php vendor 除外)
    • 日志文件
    • 各种压缩包
    • 所有随着项目的运行容易变化的文件,如:安装包
  • 自己必须 review 每一行的变化是否要加入 git
  • 一个 commit 只做一件事情,参考
    • 特别注意,一个 commit 绝对不要去格式化和自己无关的代码,相关代码也尽量不要去格式。如果确实有必要大量格式,建议先在一个独立的 commit 中进行,再做相关任务
    • 不要格式化 vendor/node_modules等第三方的代码
  • 不要提交的修改:
    • 无意义的修改(空格、空行等)
    • 无意义、临时的日志输出(TBD:日志输出规范)

git message

TBD

  • 必须带 task、bug id,并附上链接

conflict 解决

冲突解决一定要使用 GUI 工具,无特殊理由统一使用 beyond compare。绝对禁止直接在文本编辑器中解决冲突。

分支规范

  • feature 分支不要引入和 feature 不相关的 commit,除非是有依赖关系的。

分支名规范

  • 正式分支要有意义,开发者自己名字的分支没有意义,不要合并进入正式分支

合并规范

  • merge 节点不要做多余的操作,仅合并。
    • 不要修改 merge 的 message、更不要删除冲突清单记录
    • 不是冲突行,不要修改
    • 合并和的后续处理(保证系统正常运行),要通过后续若干 commits 实现。
  • 开发分支只能合并到 master,不能相互合并;分支内必须 rebase

合并前需要:

  • 通过自动化 lint、测试
  • 必须 review,由 reviewer merge/cherry-pick:单节点cherry-pick,两个以上的merge
  • merge 要 rebase 到最新后再用 no-ff 合并
    • Tip:可以先尝试合并,如果冲突太多,报备后可以不用 rebase
  • 每个节点都要符合规范,不符合的要合修改(包括拆分、合并)后重新 commit
  • review 后提测,测试通过后合并
  • 没有发布规划的内容不要合并到 master

master - online 分支合并规范

  • 基于 master 新建 online 分支,后面的 bug 修复都基于 online 修改。
  • 发布前 master 不要再有改动,hot fix 都在 online 上进行;发布之后再用 no-ff 的方式合并回 master,master 开始接受新的改动合并。
  • 发布后的 hot fix 在 online 进行,要定期合并回 master,仍然用 no-ff 方式

git force push

  • 比如当前远端master的版本为 old-master,此时 force push,然后需要通知所有人,执行以下命令:
# 注意不要执行 git pull !!
git fetch origin
git rebase --onto origin/master <old-master> master
  • 注意需要将 old-master 替换为实际的 hash 值
  • 慎用 force push,或者使用前咨询团队成员

git init commit

  • 初始状态一定要生成一个 commit
    • 项目的初始生成文件
    • 任何第三方的项目、文件
  • 这样做的好处:
    • 便于知道做了什么
    • 便于升级版本

开发规范

技术路线

点赞(0) 阅读(1) 举报
目录
标题