一种基于 gitlab 的适用于版本发布的 git-flow 协作规范

2020-12-03 552

最近自己搞了一个基于 gitlab 的适用于版本发布（非持续集成）的脱胎于 git-flow 的协作规范，发布出来大家可以作为借鉴。

Branch 规范

一共拥有以下几个（种）branch：

master：master 上的都是 production-ready 的 stable 的代码。
develop：作为开发的主分支，所有的 mr 都应当（先）合并到 develop 分支，定期 merge 到 master 发版。
release-*：LTS 版本需要有独立的 branch，以作为后续（万一）hotfix 使用，精确到 minor version，如 release-v1.2，为长期保留的分支。
feature/*：所有新的 feature（如新功能、性能优化）都应当先 checkout 到一个新的 feature 分支开发，原则上必须且只能 merge 到 develop 分支。
bugfix/*：bug 的修复分支，原则上必须且只能 merge 到 develop 分支。
test/*：test 分支主要做以下三件事：1. 增加 unit test；2. 修改仓库级别配置文件（如 .gitlab-ci.yml）；3. 用来承载一些一次性的测试（不合入 develop）。
hotfix/*：用来发布 hotfix 的分支，详见下节。
release/*：用来做发版工作（如更新版本号，bugfix）的分支，还有一个作用是 freeze feature，不允许合入 feature，可以合入 bugfix，详见下节。

branch name 应当采用下划线命名法。会在 ci 中对于 branch name 做强制检查，如果不合规会直接 fail。留出 test/* 的 branch 也是为了能够支持一些测试性的工作能够通过 ci 检查。

协作流程

开发流程

1、首先，确认自己在 develop 分支上；

2、git checkout -b feature/your_feature；

3、开发完成后，push 到 origin；

4、提 mr（如果是性能优化，请在 description 中附带上 benchcmp 的结果），target branch 为 develop，并勾选最下方两个选项：

5、等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 被勾选：

image-20191106172100840

6、如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge：

image-20191106172136296

7、done。

bugfix 流程

develop 上 bugfix

首先，确认自己在 develop 分支上；
git checkout -b bugfix/your_bugfix ；
开发完成后，push 到 origin；
提 mr，target branch 为 develop，并如开发流程一样勾选最下方两个选项；
等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
done。

release/* 上 bugfix

这里不需要直接 merge 回 develop 是因为 release/* 最终会 merge 回 develop。

首先，确认自己在 release/vX.Y.Z 分支上；
git checkout -b bugfix/your_bugfix ；
开发完成后，push 到 origin；
提 mr，target branch 为 release/vX.Y.Z，并如开发流程一样勾选最下方两个选项；
等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
done。

hotfix 流程

需要 merge 到 develop

按照 普通 bugfix 流程 完成 bug 修复，记得要更新代码中的版本号（为了防止 merge 到 master 后忘记 merge 回 develop）；
切换到 master 分支上；
git checkout -b hotfix/your_hotfix；
cherry-pick bugfix 的 commit；
检查无误后，push 到 origin；
提 mr，target branch 为 master，并如开发流程一样勾选最下方两个选项；
等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
切换到 master 分支上，打一个新的 tag；
done。

仅需要 merge 到 master

适用于需要修复的 bug 在 develop 分支上已不存在的情况。

版本号的更新不需要同步到 develop，在下次 merge 的时候解决冲突即可。

首先，确认自己在 master 分支上；
git checkout -b hotfix/your_hotfix ；
修复完成后，新增一个独立的 commit，更新代码中版本号，push 到 origin；
提 mr，target branch 为 master，并如开发流程一样勾选最下方两个选项；
等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
切换到 master 分支上，打一个新的 tag；
将第三步中更新版本号的独立的 commit cherry-pick 到 develop 分支上；
done。

需要 merge 到 LTS release branch

根据情况，完成需要 merge 到 develop 或者仅需要 merge 到 master 中的一个；
切换到 release-vX.Y 分支上（待修复的分支）；
git checkout -b hotfix/your_hotfix ；
cherry-pick hotfix 的 commit；
更新代码中版本号，检查无误后，push 到 origin；
提 mr，target branch 为 release-vX.Y，并如开发流程一样勾选最下方两个选项；
等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
切换到 release-vX.Y 分支上，打一个 tag；
done。

发版流程

发版流程比较特殊，和其它流程有较大区别，请注意细节。

这么做的原因是，如果先把 release branch merge 到 develop 分支上，再将 develop 分支 merge 进 master 的话，可能会带上预料之外的 commit（在整理 release 的时候有新的 mr 被 merge 到 develop）。

首先，确认自己在 develop 分支上；
git checkout -b release/vX.Y.Z ；
做一些发版需要的工作（如更新版本号等）；
完成后，push 到 origin；
提 mr，target branch 为 master，** 不勾选 squash 和 remove source branch**；
等待 review 通过，通过后点击 merge，请再次确认 squash 和 delete branch 未被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
切换到 master，打一个 vX.Y.Z 的 tag。
再提一个 mr，target branch 为 develop，** 不勾选 squash，勾选 remove source branch**；
等待 review 通过，通过后点击 merge，再次确认不勾选 squash，但 delete branch 被勾选；
如果 merge request 有 description，可以点击 “Modify commit message” 并点击最下方的 include description，然后再点击 merge；
done。

CI check script

#!/usr/bin/env bash
echo "branch name is: $1"if [[ ! $1 =~ ^(((feature|bugfix|test|hotfix)/.+)|(master|develop)|(release-v[0-9]+\.[0-9]+)|(release/v[0-9]+\.[0-9]+\.[0-9]+(-[a-z0-9.]+(\+[a-z0-9.]+)?)?))$ ]]; then  echo "branch name invalid!" >&2  exit 1fi

原文链接：

https://www.purewhite.io/2019/11/06/new-gitlab-git-flow-spec/

END

Kubernetes CKA实战培训班推荐：

北京：12月18-20日

本文分享自微信公众号 - K8S中文社区（k8schina）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/u/4586894/blog/4774066

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Browser connection limitations（浏览器长连接个数限制）解决方案

Browser connection limitations解决方案现象 Web界面订阅Server端长连接接口时，当订阅数量达到一定时，新建长连接将处于pending状态环境浏览器：Google Chrome 84.0.4147.135 建立长连接方法：new EventSource() 通讯方式：SSE SSE实现：org.springframework.web.servlet.mvc.method.annotation.SseEmitter 原因浏览器限制具有相同域名的HTTP连接的数量。此限制在HTTP规范（RFC2616）中定义。大多数现代浏览器每个域允许六个连接。大多数较旧的浏览器每个域仅允许两个连接。该HTTP 1.1协议规定，单用户的客户端不应该维持与任何服务器或代理多于两个连接。这就是浏览器限制的原因。有关更多信息，请参见RFC 2616 –超文本传输协议，第8节–连接。现代浏览器的限制不那么严格，允许更多的连接。RFC没有指定如何防止超出限制。可以阻止打开连接，也可以关闭现有连接。源码前端 <!DOCTYPE html> <htm...

2020-12-04

573

做为程序员，不知道你有没有想像过，如果某天，不再需要面向Google、Stackoverflow编程，不再需要Ctrl + C 和 Ctrl + V，你在IDE里敲出某个编程语言的关键词时，像导航一样，下一步的代码就已经展现出来；做为程序员，不知道你有没有想像过，如果某天，简单说几句话，或者简短写几句，就能够实现你的需求，完成代码开发。谈笑间，bug 灰飞烟灭。一切尽在弹指一挥间；做为程序员，不知道你有没有想像过，如果某天，写程序也能有个智能的助手，像出行、购物一样，告诉你哪个API调用的人更多，他们是怎么用的。那样就会空出大量的时间，去做代码之外，其它你想做的事情。当然，你也可以接更多的需求，写更多的代码嘛 :-) 这样的情况你有没有想过？关于程序员，有个调侃的笑话，大意是这样的：一个程序员，技术水平一般，经常写代码到很晚，bug 还多。他的女朋友很是心疼。后来一段时间，这哥们发现，前一天晚上遗留bug的代码，第二天在公司运行一切正常。太惊讶了。某天半夜醒来忽然发现，他女朋友在电脑上帮他改bug... 看到能写代码改bug的女朋友，是不是让前面的想法更强烈了？梦想还是要有...

2020-12-04

567

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。