GIT协作流程规范
分支模型
集中式的分支模型
目前团队使用的模式属于老旧的集中式分支模型，简单的总结就是：
- 开发时： 团队的所有成员都在dev分支上开发（也支持少部分的特性分支feature-xxx）。
- 测试时： 当功能需要上测试环境测试时，把dev合并到test分支，使用test分支在测试环境中测试。
- 灰度时： 在发布到生产环境之前，需要经过灰度发布，此时需要把测试通过后的dev分支合并到master，灰度环境使用master分支进行灰度测试。
- 生产时： 最后在灰度环境也确保没问题后，直接把master发布到生产环境。
优点
- 操作容易
- 简单高效
弊端也显然易见
迭代计划内的功能临时说这版本不发或者计划内完成不了
当一个功能已经在开发当中，没有使用feature分支来开发，已经进入dev分支，然而可能由于预估时间太短，或者是逻辑没想清楚，在迭代期内无法完成，或者临时说此功能不要上，这时候还要把dev的代码清理掉，从某种意义上说dev已经被不必要的代码污染了，会增加风险。
灰度发布过程中，生产上热修复问题
灰度环境与生产环境共用一个master分支，当功能已经发到master后上了灰度，这时候如果线上有一个紧急的bug需要修复，master已经有当前迭代的代码，但是代码仍然在灰度环境。
测试过程中，代码相互交叉频率太高的问题
当某个同事正在开发某个功能，可能修改的是公共的基类，也送到test分支上测试环境测试了，但是由于开发开发了一般，代码有致命的错误，这是刚好负责的同事又休假了，整个测试环境就无法工作，要么回滚要么找同事修好要么帮他修好，也是因为不干净所导致。
支持型分支
接下来，我们的开发模式使用各种辅助分支来帮助团队成员之间的并行开发，方便追踪新特性，准备生产发布，帮助快速修复现线上产品问题。与主分支不同，这些分支总是具有有限的寿命时间，因为它们最终将被移除。
我们可能使用的不同分支有：
- Feature 分支，用于为即将发布或遥远的将来版本开发的新特性，必定会合并到dev
- Hotfix 分支，
- Release 分支
每个分支都有特定的用途，并且必须遵守严格的规则，即哪些分支可以是它们的起始分支，哪些分支必须是它们的合并目标
git分支的命名及使用规范
分支类型
- dev
- test
- master
- feat
- release
- hotfix
- docs
- chore
dev、test和master分支
- 常驻分支有：dev、test和master，dev、master必须被保护起来（不能直接push)
- dev用于开发，test分支用于测试环境，master用于生产环境
feature分支（特性分支）
命名规范
格式：feat-{jira主需求ID}-{名称}
举例：feat-YLYDZJDD-4118-plan-template
jira主需求ID，快速浏览：https://jira.mypaas.com.cn/browse/YLYDZJDD-4118
名称，一般描述分支所实现的功能
使用规范
- 由开发者从dev分支创建，最终会合并到dev或丢弃。当测试时，可以合并到test分支进行测试。
- 当功能开发完成后，需要通过gitlab的Merge Request功能进行合并。
- 当每次合并到dev之后，说明功能已经完成开发了，回归到dev之后，应当git branch -d删除（包括远端分支也要删除）。
实践
git checkout -b feature-xxx dev
// coding ...
git push origin feature-xxx
// Merge Request // 功能开发完成后
git branch -d feature-xxx
release分支（发布分支）
命名规范
格式：release-{迭代版本号}
举例：release-202010SP1
使用规范
- 一般由测试人员从dev分支创建，并公布给团队，最终必须合并到master、dev分支
- 创建release分支的时机是：可以发灰度的时候，dev已经具备了下一个版本的已测试过的全部代码
- 当灰度测试有问题时，允许直接在该分支上修复和提交
- 由于release分支是需要上灰度环境，所以必会推送到远端，成功发生产之后，应当删除
- （可选）在合并到master分支之前，可以使用git rebase命令来美化提交历史
实践
git checkout -b release-202010SP1 dev
// 灰度中...
# 合并到dev
git checkout dev
git merge --no-ff release-202010SP1
git push origin dev # 合并到master
// 使用gitlab的merge request功能 # 删除relase分支
git branch -d release-202010SP1
git branch -dr origin/release-202010SP1
git push origin release-202010SP1 --delete
hotfix分支（热修复分支）
命名规范
格式：hotfix-{jira需求ID}-{修复编号}
举例：hotfix-YLYDZJDD-4418-1
修复编号就是版本号的最后一位
强调给开发人员提bug修复，需要先提jira
使用规范
- 由开发人员从master分支创建，最终合并到master和dev
- 只在解决已在生产上的问题修复时用到，迭代开发是不需要hotfix的
- 当在灰度测试过程中，存在release分支时，hotfix分支应当合并到release分支，而不是dev
- 问题已经修复后，hotfix分支应当删除
实践
git checkout -b hotfix-xxx
// fixing... # 使用gitlab的Merge Request功能合并到master # 合并到dev
git checkout dev
git merge --no-ff hotfix-xxx # 删除分支
git branch -d hotfix-xxx
几个场景需要注意的工作
测试场景
任何分支都可以合并到test，但是过程必不可逆。
迭代开发前的准备工作
把master分支合并到dev，防止hotfix和release分支的修复遗漏。
发布到master
每一次发布master后都需要打上标签，包括release和hotfix
标签为版本号命名：{大版本号}.{小版本号}.{修复版本号}
eg: v1.2.0
如果进行热修复，hotfix-YLYDZJDD-4418-1，更新标签为v1.2.1，重新打上标签
当有不跟迭代走的功能单独上线，{小版本号}自动加1，如v1.2.1 -> v1.3.0
当Merge Request发生冲突是的解决方法
- 直接使用线上的Resolve Conflicts功能
- 本地解决1
# 先关掉线上的合并请求, close merge request
git checkout dev
git pull origin dev
git checkout -b conflict-feat-YLYDZJDD-4118-plan-template#dev dev
git merge --no-ff feat-YLYDZJDD-4118-plan-template
// resolve conflict...
git push origin conflict-feat-YLYDZJDD-4118-plan-template#dev
// 在使用Merge Request，把conflict-feat-YLYDZJDD-4118-plan-template#dev合并到dev - 本地解决2
# 先关掉线上的合并请求, close merge request
git checkout feature-YLYDZJDD-4118-plan-template
git pull origin dev
// resolve conflict...
git push origin feature-YLYDZJDD-4118-plan-template
// 在使用Merge Request，把feat-YLYDZJDD-4118-plan-template合并到dev
本地解决1，2的区别
原则上，我们都是feature分支合并到dev，尽可能避免逆向操作，dev会有其他人的代码会影响你当前的功能分支
使用conflict分支可以当做dev的一份拷贝，通过本地合并feature分支且解决冲突的方式，重新把已解决的代码更新到dev上即可
当不同的功能存在依赖关系时
如feat-1的功能写了一些公共的基类，可以提供feat-2使用，这时只需要吧feat-2合并到feat-1中，具体需要两个分支的开发者沟通
git提交的message规范
每次提交，Commit message 都包括三个部分：header，body 和 footer。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
其中，header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
git提交命令
git commit -v
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type
用于说明 commit 的类别，只允许使用下面4个标识。
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
chore：构建过程、更改配置或辅助工具的变动
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore）由你决定，要不要放入 Change log，建议是不要。
注意，此处的标识，像极了分支的类型，少了一个release。
要知道release作为type是不代表什么意义，因为当我们在release上进行提交时的场景是：代码已经上灰度了，然后需要进行小问题修复时，会在release分支上进行，而提交是的type应该为hotfix
scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如php会有：controller、service、repositories等，后序由团队商定
如果你的修改影响了不止一个scope，你可以使用*代替。
subject
subject是 commit 目的的简短描述，不超过50个字符。
其他注意事项：
以动词开头，比如新增，修改等
Body
（支持markdown格式文本）
Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
实现进度计划相关任务与完成条件合并 - 删除完成条件的逻辑
- 从相关任务的角度对进度节点进行清洗
有两个注意点:
- 永远别忘了第2行是空行
- 应该说明代码变动的动机，以及与以前行为的对比。
- 多个功能点应该以列表的形式描述
Footer
没有要求，只作为备注使用
git流程操作小结
# 迭代开始 // Merge Request: master -> dev
git checkout dev
git pull origin dev # 需求：YLYDZJDD-4118实现
git checkout -b feature-YLYDZJDD-4118-plan-template dev
// coding... # 测试功能实现
git checkout test
git pull origin test
git merge --no-ff feature-YLYDZJDD-4118-plan-template
git push origin test
// testing... # 完成开发
git commit -v // 注意commit message规范
git push origin feature-YLYDZJDD-4118-plan-template
// Merge Request: feature-YLYDZJDD-4118-plan-template ->dev # 解决冲突 // 线上直接解决 // 本地解决1
# 先关掉线上的合并请求, close merge request
git checkout dev
git pull origin dev
git checkout -b conflict-feat-YLYDZJDD-4118-plan-template#dev dev
git merge --no-ff feat-YLYDZJDD-4118-plan-template
// resolve conflict...
git push origin conflict-feat-YLYDZJDD-4118-plan-template#dev
// 在使用Merge Request，把conflict-feat-YLYDZJDD-4118-plan-template#dev合并到dev // 本地解决2
# 先关掉线上的合并请求, close merge request
git checkout feature-YLYDZJDD-4118-plan-template
git pull origin dev
// resolve conflict...
git push origin feature-YLYDZJDD-4118-plan-template
// 在使用Merge Request，把feat-YLYDZJDD-4118-plan-template合并到dev # 灰度测试（已经准备好了）
git checkout dev
git pull origin dev
git checkout -b release-202010SP2 dev
git push origin release-202010SP2 # 灰度时修复小问题
git checkout release-202010SP2
// fix bug...
git commit -v // 注意commit message规范(type: fix)
git push origin release-202010SP2 # 正式发布
// Merge Request: release-202010SP2 -> master
// tag v1.2.0 # 热修复
git checkout master
git pull origin master
git checkout -b hotfix-YLYDZJDD-4418-1 master
// fixing..
git commit -v // 注意commit message规范（type: fix）
git push origin hotfix-YLYDZJDD-4418-1
// Merge Request: hotfix-YLYDZJDD-4418-1 -> master
// tag v1.2.1
GIT协作流程规范的更多相关文章
- Git协作流程（转）
Git 作为一个源码管理系统,不可避免涉及到多人协作. 协作必须有一个规范的流程,让大家有效地合作,使得项目井井有条地发展下去."协作流程"在英语里,叫做"workflo ...
- Git协作流程
Git 作为一个源码管理系统,不可避免涉及到多人协作. 协作必须有一个规范的流程,让大家有效地合作,使得项目井井有条地发展下去."协作流程"在英语里,叫做"workflo ...
- 小团队Git协作流程
git和svn 最大的差异在于git是分布式的管理方式而svn是集中式的管理方式. 集中式 集中式代码管理的核心是服务器,所有开发者在开始coding之前必须从服务器获取代码,然后开发,最后解决冲突, ...
- 公司项目git开发流程规范
手动修改冲突之后,git add . git commit ,git push
- git 的安装使用以及协作流程
git安装: sudo apt-get install git-core git使用: 转:https://www.liaoxuefeng.com/wiki/0013739516305929606dd ...
- Git 结合Git使用Bitbucket进行代码版本管理流程规范与实践
结合Git使用Bitbucket进行代码版本管理流程规范与实践 By:授客 QQ:1033553122 目录 目录 1 一. 测试环境 2 二. 新建项目 2 三. 新建公有版本库 3 四. ...
- Git基础操作及协作流程
一整套流程帮你实践整个 Git 操作基础流程. 来源:https://docs.microsoft.com/zh-cn/learn/paths/intro-to-vc-git/ Git 介绍 配置 G ...
- Git常用命令和Git团队使用规范指南
转自:https://wsgzao.github.io/post/git/ 前言 在2005年的某一天,Linux之父Linus Torvalds 发布了他的又一个里程碑作品——Git.它的出现改变了 ...
- 前端开发工程师 - 05.产品前端架构 - 协作流程 & 接口设计 & 版本管理 & 技术选型 &开发实践
05.产品前端架构 第1章--协作流程 WEB系统 角色定义 协作流程 职责说明 第2章--接口设计 概述 接口规范 规范应用 本地开发 第3章--版本管理 见 Java开发工程师(Web方向) - ...
- Git 分支开发规范
您必须知道的 Git 分支开发规范 Git 是目前最流行的源代码管理工具. 为规范开发,保持代码提交记录以及 git 分支结构清晰,方便后续维护,现规范 git 的相关操作. 分支管理 分支命名 ma ...
随机推荐
- 从零玩转SpringBoot3-快速入门
一.简介 1.前置知识 ● Java17 ● Spring.SpringMVC.MyBatis ● Maven.IDEA 2.环境要求 环境&工具 版本(or later) Spr ...
- PostgreSQL 9.6 文档: 数据类型
章 8. 数据类型 目录 8.1. 数字类型 8.1.1. 整数类型 8.1.2. 任意精度数字 8.1.3. 浮点类型 8.1.4. 序数类型 8.2. 货币类型 8.3. 字符类型 8.4. 二进 ...
- 行行AI人才直播第13期：刘红林律师《AIGC创业者4大法律问题需注意》
行行AI人才(海南行行智能科技有限公司)是博客园和顺顺智慧共同运营的AI行业人才全生命周期服务平台. AIGC爆火至今,商业落地已成为各行各业焦点的问题.它的广泛应用也带来了一系列的法律风险和挑战.一 ...
- 《最新出炉》系列入门篇-Python+Playwright自动化测试-10-标签页操作（tab）
1.简介 标签操作其实也是基于浏览器上下文(BrowserContext)进行操作的,而且宏哥在之前的BrowserContext也有提到过,但是有的童鞋或者小伙伴还是不清楚怎么操作,或者思路有点模糊 ...
- 解决AccessDatabaseEngine.exe 32位64位安装失败问题
cmd下执行 你的路径\AccessDatabaseEngine.exe /quiet 转载于:https://www.cnblogs.com/64mb/p/10844676.html
- 如何为物联网设备注入“华为云+鸿蒙DNA”?
本文分享自华为云社区<如何为物联网设备注入"华为云+鸿蒙DNA"?看华为云IoT怎么答[华为云IoT +鸿蒙]>,作者: 华为IoT云服务. 根据市场咨询机构预测,20 ...
- 在centos7.X下安装Java
发布于 2 分钟前 2 次阅读 1.创建JDK目录 mkdir /opt/jdk 2.通过finalshell或xftp将jdk上传到/opt/jdk目录中 3.cd /opt/jdk 4.解压jd ...
- AI绘画| 迪士尼风格｜可爱头像【附Midjourney提示词】
Midjourney案例分享 图片预览 迪士尼风格|可爱头像 高清原图及关键词Prompt已经放在文末网盘,需要的自取 在数字艺术的新时代,人工智能绘画已经迅速崭露头角.作为最先进的技术之一,AI绘画 ...
- 在Jupyter中使用AI写代码，如有神助，太惊艳了
昨晚看到一个可以在JupyterLab中使用的AI代码辅助工具jupyter-ai,它的交互确实非常棒,可以直接聊天,也可以就笔记中的代码提问,最出彩的是生成笔记功能,还是蛮惊艳的. 这里就极简介绍一 ...
- AI绘图开源工具Stable Diffusion WebUI前端API对接
背景 本文主要介绍 AI 绘图开源工具 Stable Diffusion WebUI 的 API 开启和基本调用方法,通过本文的阅读,你将了解到 stable-diffusion-webui 的基本介 ...