Git 开发流程 git-flow

Git-Flow是什么

Git 诸多命令就像一个个零件,代码管理是够用的。但是工程化代码管理尤其是团队协作的工程化,就需要这些零件整合起来,形成一套工作流。Git Flow 就是这么一套工具。

http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html

安装

brew install git-flow-avh

初始化项目

git flow init
# 然后一路回车

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
# 功能开发
Feature branches? [feature/]
# bug修复
Bugfix branches? [bugfix/]
# 发布分支
Release branches? [release/]
# hotfix修复
Hotfix branches? [hotfix/]
Support branches? [support/]
# tag前缀,一般可以设为v
Version tag prefix? []
Hooks and filters directory? [/data/demo/.git/hooks]

Hotfix 与 Bugfix 的区别

  • Hotfix 热修复,通常是开发完成就需要立即上线,执行 hotfix finish 的时候就合并进入 main 分支,同时打好tag,就可以发布了。
  • Bugfix 也是修复bug,不是那么紧急,通常可以认为与 feature 功能分支同步开发,最后放在一个 release 进行发布。

Feature 分支新功能开发

开发环节:

  1. 开启一个新分支
  2. 立即推送到远端,避免同事推送了相同的分支
# 开启一个分支
git flow feature start pre-release-config

# 推送提交到远端,效果等同于 git push origin feature/pre-release-config
git flow publish

上线环节:

  1. feature分支开发完成,代码会合并到本地 develop
  2. 开启一个 release 分支,一般分支名为版本号,如:v1.0.0.0
  3. 完成release分支,会新建一个 release 分支命名的 tag 如: v1.0.0.0
  4. 推送 develop 和 main 分支到远端
  5. 将 tag 推送到远端

以上 5 步基本都是直接完成,不会穿插其他环节,完成后线上可以基于 main 分支发布或者基于对应版本的 tag 进行部署发布了。

需要注意的是:在开启 release 分支之前,可以对多个 feature 分支进行合并。

# feature 分支开发完成,代码会合并到 develop
git flow feature finish

# 开启 release 分支
git flow release start v1.0.0.0

# release 分支完成,新建 release 分支命名的 tag 如:v1.0.0.0,并需填写 tag 的备注信息
git flow release finish

# 以上操作除了 git flow publish 都是本地分支进行操作,

# 最后需要推送 develop 和 main 分支以及 tag 到远端
git checkout develop
git push origin develop

git checkout main
git push origin main

git push --tag

Hotfix 分支功能修复

hotfix 与 feature 大同小异,主要差异体现在 release 分支,具体见下文

开发环节:

  1. 开启新分支
  2. 立即推送到到远端,避免同事推送相同的分支
# 开启一个分支
git flow feature start typo-fix

# 推送提交到远端,效果等同于 git push origin hotfix/typo-fix
git flow publish

上线环节:

  1. hotfix 分支开发完成,会直接创建 tag,并且以hotfix分支命名,但是建议带上参数 -T 重新命名
  2. 推送 develop 和 main 分支到远端
  3. 将 tag 推送到远端

可以看到与 feature 开发不同的是,hotfix 不需要通过创建 release,可以快速操作,毕竟我们是修复,需要尽快操作完成上线。

Read more

代码 Refactoring

重构不必谈之色变。 它也不是洪水猛兽,而是开发过程中持续进行的优化过程。让我们开始学习这个主题,重新认识它的价值。 🌟整洁代码 重构的主要目的是消除技术债务。它将混乱变成整洁的代码和简单的设计。 * 对于其他程序员来说,整洁的代码是显而易见的。 我并不是在谈论超级复杂的算法。糟糕的变量命名、臃肿的类和方法、魔法数字 - 等等,所有这些都会让代码变得混乱和难以理解。 * 整洁的代码不包含重复。 每次你需要对重复的代码进行更改时,你都必须记住对每个实例进行相同的更改。这会增加认知负担并减慢进度。 * 整洁的代码包含最少数量的类和其他活动部件。 代码越少,脑子里需要记住的东西就越少。代码越少,维护工作就越少。代码越少,错误就越少。代码就是责任,保持代码简短。 * 整洁的代码通过所有测试。 如果只有 95% 的测试通过,你就知道代码不整洁。如果测试覆盖率为 0%,你就知道你完蛋了。 * 整洁的代码维护成本低! 🗑️技术债(What) 每个人都尽最大努力从头开始编写出色的代码。可能没有程序员会故意编写不干净的代码,从而损害项目。但是干净的代码在什么时

By brian

CSV 格式说明和应用

问题 我们常常将多个字符串item使用逗号拼接成一个字符串,用来表示数组,使用时再用逗号切割成为数组。比如安卓机型列表: ALN-AL10,ALN-AL10,BRA-AL00,ALN-AL00/ALN-AL80 直到有一天,苹果设备也要用到这个机型列表,而它的每个机型都带着逗号,那我们使用逗号切割就得到了错误的数据。 iPhone15: iPhone15,4 iPhone15Plus: iPhone15,5 iPhone15Pro: iPhone16,1 iPhone15Pro_Max: iPhone16,2 为了解决这个问题,首先想到了换一个分隔符,比如 | ,再比如用一些不可见字符 : 0x01。 但我们不能保证这些字符串 item 一定不包含这些特殊字符,也许还有更好的方法。 既然是逗号分隔,首先想到的就是 CSV格式,毕竟 CSV 的全称就是Comma-Separated Values逗号分隔值。它是如何解决这个问题的? CSV格式 CSV 的RFC说明文档:https://datatracker.ietf.

By brian
开启了http2,但是http2_max_field_size 还在用默认值吗?

开启了http2,但是http2_max_field_size 还在用默认值吗?

排查1个异常接口,学到一个降本和接口提速的新思路。另外找到1个charles的"bug" 现象 测试同学反馈在iOS13设备上请求接口报错,将请求复制为 curl 命令。分别导入 apifox 和 在终端执行: * 在 apifox 请求正常 ✅ * 在终端请求失败 ❌ curl: (56) Failure when receiving data from the peer 测试同学又反馈另一个手机支持请求接口返回正常。 定位 有了正常和错误的请求curl,那直接对比二者差异就很简单了。对比发现,在终端执行失败的请求中多了一个较大的Cookie: app_token。按历史经验基本能确定是因为 Cookie 这个 header 条目太大,超过服务器的限制。 找云平台确定相关配置: ELB http1: header头限制 128KB,body 限制一个10G http2:

By brian
沪ICP备2022013452号-1