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

Git hook 开发和实践,提升自动化效率

Git hook 开发和实践,提升自动化效率

我们使用 git 进行版本控制,期间会触发很多事件,这些利用好这些事件做好自动化,能帮我提升效率。git hook 就是一个这样的工具,在特定的事件中执行特定的钩子。 ╰─➤ ls .git/hooks applypatch-msg.sample post-update.sample pre-merge-commit.sample pre-receive.sample update.sample commit-msg.sample pre-applypatch.sample pre-push.sample prepare-commit-msg.sample fsmonitor-watchman.sample pre-commit.sample pre-rebase.sample push-to-checkout.sample 设置钩子路径 git 仓库的钩子存放路径由 core.hooksPath 控制,默认是在项目的 .git/hooks。它不能使用版本控制

By brian

MacOS 安装了最新版 Docker,命令行找不到了?

它藏在 /Applications/Docker.app 中,可以使用 find 命令查看: $cd /Applications/Docker.app $find . -name "docker" ./Contents/Resources/bin/docker 将 bin 目录拼接到 PATH 环境变量即可,一般可以追加到 ~/.bashrc ~/.zshrc 中。 export PATH=/Applications/Docker.app/Contents/Resources/bin:$PATH source ~/.zshrc 使环境变量生效,执行 docker 检查版本 $ source ~/.zshrc $ docker --version Docker

By brian
飞书集成平台 x Grafana:打造监控告警系统全攻略

飞书集成平台 x Grafana:打造监控告警系统全攻略

Grafana告警内容设置 告警内容分为:告警标题、告警说明、告警详情。告警标题和告警说明用来描述告警的规则。告警详情,描述告警的规则和具体的值。 告警详情 Description 设置 1. 打印所有的标签 {{ $labels }} alertname=High CPU usage, grafana_folder=CPU alerts, instance=server1 2. 自定义格式化打印所有的标签 {{ range $k, $v := $labels -}} {{ $k }}={{ $v }} {{ end }} alertname=High CPU usage grafana_folder=CPU alerts instance=server1 3. 打印单个标签 The host {{ index $labels

By brian
沪ICP备2022013452号-1