🗂 目录

大型项目 feature 开发 git 流程

December 1, 2021 • 预计阅读时间 3 分钟

经历了好几个公司和开发团队,git 的使用流程依旧不清晰

看到网上已经太多 git 教程,不重复 git 的用法,这里重点是开发实战流程。

开发流程

  1. Git 服务器上从开发分支产生出一个 feature-xxx 分支;

  2. 把 feature-xxx 分支 clone 到本地;

  3. 疯狂写代码;

  4. 同步服务器上 feature 分支(pull & rebase)并解决冲突 + 本地测试,重复直至无更新 & 冲突;

  5. commit 更新,并 push 到 服务器 feature 分支上;

  6. 服务器触发 feature build,如果不成功,拒绝 merge 请求,重复步骤 3 ~ 6,直至 feature 开发完成

  7. 提交 merge request 到开发分支

  8. 主管 code review,检查 feature build 成功,则同意 merge request,feature 上的更新合并到开发分支上,触发 dev build,如不成功,通知主管,回到步骤 3

分支策略说明

分支策略可简单,可复杂(trunk-based,git flow,github flow 等等),因为和项目管理策略,测试策略,发布策略,等等相关,如生产环境需要支持多版本,多客户。策略没有绝对好坏,原则是维护尽量少的分支。策略和执行好坏有关,如网上有人建议或膜拜 Google 的 trunk-based 策略,而忘了自己软件项目的特点。每个人都有盲区,老大也未必靠谱:

branch-comment
  • 主分支/master 主分支 ➡ 生产环境

    branch-master

    主分支对应生产环境,一般不允许直接在主分支上做修改

  • 开发分支/dev 开发分支 ➡ 开发集成测试环境

    branch-dev

    开发分支用于集成测试,以及用户测试,有条件的可以细化不同的测试环境,如 release,staging

  • feature 分支 feature分支 ➡ feature测试环境

    从开发分支上 fork 出 feature 分支:

    branch-feature

    所有的开发工作都在本地 feature 分支上进行 由于是团队协作,例如 Raj 也在开发同一 feature:

    branch-feature

    每个开发者都要做pullrebase的两个动作(下载同事的 commit 到本地):

    branch-feature

    缺认无误后可以merge回开发分支(经主管同意)

    branch-feature
  • 发布分支/release 开发分支 ➡ 测试环境

    经过一定阶段,从开发分支产生发布分支,测试成功可以 merge 回主分支:

    branch-featrelease
  • hotfix 分支 hotfix分支 ➡ hotfix测试环境

    可以考虑 hotfix 分支来修改生产环境出现的 bug:

    1. 从主分支产生 hotfix 分支;
    2. 开发
    3. 测试(hotfix 测试环境)
    4. merge 回 master 以及开发分支
    branch-hotfix

hotfix 分支用来支持对多版本生产环境,但使环境和开发流程变得复杂,如果不是多版本,可以使用 feature 分支来修改 bug

Git 使用规范和检查

commit msg

目前主流的 commit 前缀包括以下部分:

build:表示构建,发布版本可用这个
ci:更新 CI/CD 等自动化配置
chore:杂项,其他更改
docs:更新文档
feat:常用,表示新增功能
fix:常用:表示修复 bug
perf:性能优化
refactor:重构
revert:代码回滚
style:样式更改
test:单元测试更改

加强工具:

> npm install -g commitizen cz-conventional-changelog

git hook

git hook 分为客户端 hook 和服务端 hook。

客户端 hook 主要有四个:

  • pre-commit:提交信息前运行,可检查暂存区的代码
  • prepare-commit-msg:不常用
  • commit-msg:非常重要,检查提交信息就用这个钩子
  • post-commit:提交完成后运行

服务端 hook 包括:

  • pre-receive:非常重要,推送前的各种检查都在这
  • post-receive:不常用
  • update:不常用

大多数团队是在客户端做校验,所以可以用 commit-msg 钩子在客户端对 commit 信息做校验,社区有成熟的方案:husky + commitlint。

DevOpsgit

  上一篇:AWS Certified Solutions Architect Professional

  下一篇:股市抄底原则

comments powered by Disqus