开发规范 - 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
  • 项目的初始生成文件
  • 任何第三方的项目、文件
• 这样做的好处：
  • 便于知道做了什么
  • 便于升级版本