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 ...
随机推荐
- 行行AI人才直播第11期：墨尔本大学数据科学高级讲师-宫明明《机器学习：从统计到因果，人工智能的发展之路》
行行AI人才是博客园和顺顺智慧共同运营的AI行业人才全生命周期服务平台. 马克斯·普朗克智能系统中心主任曾在国际数学家大会进行了题为 From Statistical to Causal Learni ...
- Blazor如何跟随“系统主题”？
1. 前言 跟随系统主题已经是绝大多数App和网站的标配 但是如何在Blazor中跟随系统主题? 只找到Masa Blazor技术团队发的 MAUI + Masa Blazor 开发界面跟随系统主题切 ...
- Java 调用gdal API(二)——栅格裁剪
gdal可以说是GIS数据处理比较好的工具之一,虽然也提供了Java API,但是官方文档确实太过简单,用起来确实太难受,每次都需要去参考对应的C++api,然后在对应使用. 因此小编决定从这篇文章开 ...
- Ubuntu18.04 软件源更新：图形界面
通过图形UI界面更新Ubuntu的软件源,手动修改虽然简单,但是要自己去找源,选一个系统配置好的更简单.但是新版的好像没有该功能,找到个奇葩的路径: 将Ubuntu16.04升级为Ubuntu18.0 ...
- 通配符SSL证书自动续签自动部署方案
最开始接触 https 的时候一直是使用的 阿里云和腾讯云的免费 SSL证书,免费的SSL证书用了几年后,慢慢的部署https证书的项目越来越多,时间久了发现每个网站都需要一个 SSL证书,每个SSL ...
- linux 问题： ssh登录报错，ssh_exchange_identification，多次几次可以登录
分析 怀疑是句柄数不够,和ssh的最大登录限制 确认 2.1 确认句柄数 过程: ~# systemctl status sshd | grep -i pid Main PID: 3767395 (s ...
- 部署基于etcd的coredns集群
前言 现需要为公司搭建私有DNS,私有服务器都使用私有DNS的地址,便于访问内部自定义的域名.采用CoreDNS + ETCD方案部署,coredns和etcd都以三实例运行,etcd为集群模式,使用 ...
- manacher（马拉车）算法C++详解
马拉车的定义 马拉车本质是对中心扩展法(暴力算法)的优化. 马拉车是干什么的 Manacher算法帮助我们在给定的字符串中找到最长的回文子串. 为了简单起见,我们先只处理有奇数个字符的字符串,关于偶数 ...
- 快速解决 const 与 typedef 类型组合时 ，const修饰谁的问题
C++使用typedef 给复合类型定义别名时,与const结合会产生看似"令人困惑"的类型推定,例如 typedef char* pstring; const pstring c ...
- Go Web项目结构 + 基础代码
Go Web工程 下面是项目的包图,可以通过包图来理清项目包的结构. Go Web工程 下面是项目的包图,可以通过包图来理清项目包的结构. 因为我是从Java转过来的,其实这种包的结构与Java的类似 ...