大型项目 feature 开发流程

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

如果不是大项目/大团队,很多细节和步骤上就没有那么讲究。

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

  1. git 服务器 上从 主分支 fork 出一个 feature 分支(纯自用) ,因为开发都在这个分支 feature-XXXXX 上;

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

  3. 疯狂写代码;

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

  5. commit 更新,并 push 到服务器上

  6. 服务器触发 feature build(测试主分支+feature) ,如果不成功,重复步骤 3 ~ 6,直至 feature 完成

  7. 提交 merge request

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

📝 说明:

  • git 服务器可以是 gitlab,bitbucket,公司自用 git 一般要本地化和深度定制,github 不合适 ¹
  • git 主分支由你的分支策略决定,可以是 master, dev, release 等 ²
  • feature 分支和管理工具如 Jira 结合(通过 issue/ticket no XXXXX),便于项目管理,追踪和构建 ³
  • CICD 服务器上构建各种开发 pipeline:feature build,dev build,release build 等 ⁴
  • 所有的代码更新必须通过 feature 分支;合并到主分支的代码一定要保障 build 成功
  • 只有主管有权限直接更新主分支,更新的内容限制在非代码信息,如版本号,项目描述等
  • feature 分支可以在合并,或者主分支 release build 后删除,由你的分支策略决定

其中的一些细节如 commint 的格式化,合并用 merge 还是 rebase,等等,不展开讨论。

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

trunk?

整个项目的开发流程,除了最基础的 feature 开发外,还有环境构建流程,发布流程,部署流程,复杂程度同样取决项目。大型项目/软件要做到运维自动化、流畅化,真的有太多的工作 🥵。

develop -> (merge) -> dev-* dev-* -> (cherry-pick) -> develop develop -> (rebase) -> staging staging -> (rebase) -> release

为什么合并到 develop 必须用 cherry-pick? 使用 merge 合并,如果有冲突,会产生分叉;dev-* 分支多而杂,直接 merge 到 develop 会产生错综复杂的分叉,难以理清提交进度。

而 cherry-pick 只将需要的 commit 合并到 develop 分支上,且不会产生分叉,使 git 提交图谱(git graph)永远保持一条直线。

再有,模块开发分支完成后,需要将多个 commit 合为一个 commit,再合并到 develop 分支,避免了多余的 commit,这也是不用 merge 的原因之一。

为什么合并到 staging/release 必须用 rebase? release 译为变基,合并同样不会产生分叉。当 develop 更新了许多功能,要合并到 staging 测试,不可能用 cherry-pick 一个一个把 commit 合并过去。因此要通过 rebase 一次性合并过去,并且保证了 staging 与 develop 完全同步。

release 也一样,测试通过后,用 rebase 一次性将 staging 合并过去,同样保证了 staging 与 release 完全同步。

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

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

npm install -g commitizen cz-conventional-changelog

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