一、概述

二、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个字符），这是为了避免自动换行影响美观。

### Header

Header部分只有一行，包括三个字段：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
- 第一个字母小写
- 结尾不加句号（.）

###  Body

Body 部分是对本次 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 来管理依赖的版本。