目录
一、概述
二、Git
2.1 安装与配置
2.2 基本指令操作
2.3 创建一个新的存储库
2.4 推送一个已有的文件夹
2.5 忽略临时文件
2.6 添加commit模板
2.7 冲突解决
二、GitFlow协作
三、Git Commit规范
四、语义化版本
为什么需要语义化版本号?
什么是SemVer?
规范
一、概述
本文将介绍Git(安装、配置、基本操作、冲突如何解决 )、GitFlow(多人开发如何协作)、Git提交规范(commit怎么写)、语义化版本(tag怎么打),文中使用了git + gitlab来操作说明。
git gitlab gitflow关系:git 是一种版本控制系统;gitlab是一个基于Git实现的在线代码仓库软件;gitflow工作流定义了不同的分支角色,分支之间何时以及如何进行交互。
二、Git
2.1 安装与配置
安装:Windows系统Git安装教程(详解Git安装过程) - 知乎
SSH密钥配置 (如果不设置 ssh 公钥每次提交代码就要输入你的帐号密码)
设置Git用户名和电子邮件地址
git config --global user.name "jsaon"
git config --global user.email "xxx@cztek.cn"
生成SSH密钥:输入以下命令以生成SSH密钥
ssh-keygen -t rsa -C "xxx@cztek.cn"
添加SSH密钥到GitLab
cat ~/.ssh/id_rsa.pub
2.2 基本指令操作
Git 常用的是以下 6 个命令:
git clone、git push、git add、git commit、git checkout、git pull
-
workspace:工作区
-
staging area:暂存区/缓存区
-
local repository:版本库或本地仓库
-
remote repository:远程仓库
2.3 创建一个新的存储库
git clone git@192.168.1.xxx:xxx/software/visionapp/czvision/vmvision.git
cd vmvision
touch README.md
git add README.md
git commit -m "add README"
git push origin master
2.4 推送一个已有的文件夹
cd existing_folder
git init
git remote add origin git@192.168.1.231:cztek/software/visionapp/czvision/vmvision.git
git add .
git commit -m "Initial commit"
git push origin master
2.5 忽略临时文件
在.git同级目录下新建一个文件 .gitignore
写入需要忽略得文件
*.o
ui_*.h
moc_*.cpp
/*.user
2.6 添加commit模板
建立一个模板文件 .gitmessage.txt,写入模板内容,内容格式要求可借鉴第3章commit规范
git config --global commit.template .gitmessage.txt
添加模板后直接使用git commit即可,无需加-m参数
2.7 冲突解决
模拟一个冲突
文件内容为demo,develop 分支 demo,feature1分支 demo
修改 develop分支 demo2
修改 feature1分支 demo3
feature1合并到develop,此时会提示冲突
方式1:gitlab上修改
点击上图按钮Resolve conflicts
方式2:本地修改
当前分支为feature1,执行以下指令
// 更新本地仓库
git fetch origin
// 将feature1更新到 最新版本
git pull origin feature1//将develop 更新到 最新版本
git checkout develop
git pull origin develop//将 feature1 合并到 develop –no-ff 在这的作用是禁止快进式合并
git merge --no-ff feature1
手动修改冲突文件,这里可以借助VSCode查看,感叹号表示有冲突的文件
修改完成后,提交代码到远程
// 查看变动的文件
git status
// 保存本次修改
git add .
git commit
//提交到远程
git push origin develop
二、GitFlow协作
图解git flow开发流程 - 知乎
在实际生产开发的过程中,如果每个人都随意的创建分支,随意的提交commit,必将导致整个git仓库非常的混乱,不易于团队协作。多人协作会采用多个分支来进行管理,其中包含几个必要分支。
master 主分支,保护分支,不可删除,打tag专用
develop 开发分支
feature 功能分支
hotfix 补丁分支
三、Git Commit规范
现在项目都使用git 进行代码的版本管理,使用 git commit -m "提交说明",进行提交, 提交说明因尽量清晰明了,说明本次提交的目的。推荐使用Angular 规范,这是目前使用最广的写法,比较合理和系统化。
Angular团队提交规范 : angular.js/DEVELOPERS.md at master · angular/angular.js · GitHubs四
### 格式Commit message 包括三个部分,Header,Body 和 Footer:1. 标题行: 必填, 描述主要修改类型和内容
2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
3. 页脚注释: 放 Breaking Changes 或 Closed Issues可以用下方的格式表示它的结构```
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
```其中,Header 是必需的,Body 和 Footer 可以省略(默认忽略),一般我们在 `git commit` 提交时指定的 `-m` 参数,就相当于默认指定 Header。不管是哪一个部分,任何一行都不得超过72个字符(或100个字符),这是为了避免自动换行影响美观。### HeaderHeader部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)#### type(必需)- **feat**:新功能(feature)
- **fix**:修补bug
- **perf**:优化相关,比如提升性能、体验
- **refactor**:重构(即不是新增功能,也不是修改bug的代码变动)
- **docs**:文档(documentation)
- **style**: 格式(不影响代码运行的变动)
- **test**:增加测试
- **chore**:构建过程或辅助工具的变动
- **merge**:代码合并#### scope(可选)scope用于说明 commit 影响的范围,哪个模块修改影响了不止一个scope,可以使用*代替#### subject(必需)subject是 commit 目的的简短描述,不超过50个字符。- 以动词开头,使用第一人称现在时,比如change,而不是changed或changes
- 第一个字母小写
- 结尾不加句号(.)### BodyBody 部分是对本次 commit 的详细描述,可以分成多行。有两个注意点- 使用第一人称现在时,比如使用change而不是changed或changes。
- 应该说明代码变动的动机,以及与以前行为的对比。### Footer需求链接BUG单链接其他链接
四、语义化版本
官方文档 : 语义化版本 2.0.0 | Semantic Versioning
为什么需要语义化版本号?
日常开发中,会经常和版本号打交道。如果没有统一的版本号管理规范,会出现各种格式的版本号。这样会不但会极大影响代码的可读性、维护性,还可能会导致代码的可用性。
错误示范:
-
开始写一个新项目 / 模块时,都从
0.0.1
起版本,直到项目不再维护时,版本还停留在0.0.48
,前两位永远都是0
。 -
API 变化巨大,而版本号雷打不动一步一个脚印。一个二方包从
0.0.8
升级到0.0.9
就引起了整个项目的崩溃。
什么是SemVer?
语义化版本SemVer是认可度最高的软件版本规范。它是由 Gravatars
创办者兼 GitHub 共同创办者 Tom Preston-Werner
所建立的一个有关如何命名软件和库(包)版本的规范,用以解决在大型项目中对依赖的版本失去控制的问题(例如你可能因为害怕不兼容而不敢去更新依赖)。
现在 Semantic Versioning 已经在开源社区中得到了广泛的认同,Node.js 的包管理工具 npm 也完全基于 Semantic Versioning 来管理依赖的版本。
规范
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
-
主版本号:当你做了不兼容的 API 修改,
-
次版本号:当你做了向下兼容的功能性新增,
-
修订号: 当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
先行版本号标识符字母数字和连接号组成,被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求
范例:1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
版本的优先层级:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。
Alpha (α):内测版 ,内部交流或专业测试人员测试使用
Beta (β):公测版,专业爱好者大规模测试使用,存在一些 Bug,不适合一般用户使用。
Gamma (λ):比较成熟的测试版。
RC (Release Candidate):候选版本
处于 Gamma 阶段,该版本已经完成了全部功能并清除了大量的 Bug。 到了这个阶段,只会修复 Bug,不会对软件做任何大的更改。
一般来说,Alpha -> Beta -> Gamma 是迭代的关系,RC1 -> RC2 是取舍的关系
Release:发行版本,正式发行的版本,已经经过测试,一般不会出现严重的 Bug,适合一般用户使用