本文介绍了windows环境下的Git版本控制工具的使用说明和规范。

目录：

1 Git的安装与使用

2 Git的使用规范

3 工欲善其事必先利其器

1、Git的安装与使用

1.1 前言

Git 是Linux 开源社区为Linux的开发与维护而开发的一个项目，目前已被广泛应用，关于版本控制工具各有特点，本部门全部使用git，软件开发前必须熟练掌握git的使用，以及遵守相应操作规范。

1.2 安装

初次接触Git的用户，请抽出几分钟时间看一下https://git-scm.com/docs 的介绍文档，相信磨刀不误砍柴工。

Git 地址：https://git-scm.com/downloads

服务器端已经安装在内网服务器，本文针对Window平台的Git客户端的安装和使用。

1、安装TortoiseGit-2.5.0.0-64bit.msi 一路下一步，这只是安装了git的内核功能，要在windows下操作，需要安装界面外壳。

2、安装GitExtensions-2.50.02-SetupComplete.msi 或者 Git-2.15.0-64-bit.exe，这是两种风格的界面，主体功能差不多，个人选择的是后者，也可以两个都安装。

3、安装过程中出现较多的配置，所有选项中，全部都选带windows关键字的，否则用起来看不出问题，但是保存的记录异常。既然是界面操作，就开启鼠标右键的快捷图标。

后续一些安装选项，全部选带windows关键字的。

4、安装完成后，鼠标右键，会出现 Git GUI Here。

5、如果是新手可安装汉化补丁TortoiseGit-LanguagePack-2.5.0.0-64bit-zh_CN.msi。

1.3 基础演示

1、配置

其中用户名必须使用自己名字的全拼，不要使用简写或者其他特殊字符，以方便后期检索跟踪修改记录。 

2、创建本地版本库，git creat repository here,默认操作，即可创建版本，会在test空文件夹下生成.git 。 

3、在test下随便改动，如新加123.txt，提交改动。此时鼠标右键效果如下：

4、编辑本次修改记录 修改记录必须简洁清晰，具体规范参考下一章。

5、保存本次修改后，使用Git GUI Here->Repository->Visualize master’s History查看全部版本记录。

6、提交到远程服务器

7、同步远程分支

有时候提示提交推送失败，先确定是否服务器有新节点，先同步、合并（rebase）后再提交。 

8、分支合并

一般选择rebase，但其实它有缺点。特别提醒，进行reabse前先将当前分支新加分支名，以防操作失败，节点错乱导致当前节点消失。合并后必须先编译验证了再提交。

9、通用配置和常用功能

1.4 总结

Git的使用尤其是多人合作，注意以下几点：

1、推送服务器前先同步； 

2、两个分支版本有冲突，先rebase解决，不熟练的情况下暂时不要使用merge； 

3、版本节点不能使用中文，修改描述可以，关于修改描述的规范见下一章； 

4、编译自动生成的临时文件不要提交，可以使用TortoiseGit–>Delete and add in ignore list，可过滤指定的文件，即使有改动也不提交；

5、Git自带的比较工具比较差，可以配置使用外部比较工具。

一共三处，将Diff viewer和Merge Tool改为HA-BCompare。

这个工具的比较功能强大，显示界面清晰。

2 Git的使用规范

1.1 用户名

为保证问题跟踪方便，历史修改记录溯源，首次提交前必须设置用户名和邮箱，尤其是用户名，必须使用自己名字的小写全拼，不得使用简称或者特殊代号。

1.2 分支名

1. 功能接近的项目，尽量使用功能宏或者项目宏，从软件源码上减少分支；
2. 分支名称使用大写字母和下划线，不能包含空格或中文；
3. 临时测试或验证某个功能的分支，必须以TEST_开头，验证无误，且应用到正式项目后，最好删除远程分支；
4. 某个版本基础上小改动，为解决生产或者客户问题的版本，必须以PATCH_开头，表示当前分支只是特殊情况下使用，后续正式版本不再继续维护升级；
5. 因为需求变更，原XXX项目不得不分成2个分支，分支命名为XXX_AA和XXX_BB，其中AA和BB是两个分支的主要区别关键字，前面一样，表示两分支原属于同一个分支节点；若后续XXX_BB继续拆分，则新分支为XXX_BB_CC和XXX_BB_DD，依次类推；
6. 禁止使用XXX1 XXX2 XXX3 这种分支名，禁止设分支名为master。
7. 个人测试或者reabse前的远程分支，原作者确认已经不再需要的，必须删除远程分支，简化版本分支树形结构。

1.3 注释

修改记录规范化是本文的重点，注释按如下格式编写：

[type] message

每行内容不超过50字, type 用于指定提交的 commit 的类别，只允许以下几个动词原语：

release 发布软件时使必须有，且在第一行，后面内容是版本号

add  新增加的功能 

fix  修复某个 bug 的描述 

update  升级完善原有的基础功能上 

change 需求变更或者实现的方案改变 

docs  更新文档 

test  增加/修改测试示例代码 

merge/rebase在解决代码冲突，合并分支时使用 

create  初次创建新项目时使用 

remove  删减代码时使用 

patch 集成合并SDK补丁

message 用于指定提交的描述文字，需要注意几个事项。

1、使用中文表述，描述简洁，抓住重点，尤其对修复的问题点 

2、尽量以动词开头，如：更新，增加，修复等 

3、特别复杂的功能或流程，可描述参考某文档，并更新上传说明文档，

正确的示例：

[release] 发布V1.0.0_2021 

[fix] 修复登录框显示阴影的问题 

[update] 优化RFID卡信息读取的驱动

[test] 添加解码GNSS测试功能 

[remove] 删除多余的提示框界面相关代码

错误的示例：

[fix] 修复一个大 BUG       //具体是什么问题？ 

添加联网模块                  //没有 type [add] 

[add] 更新 API 文档接口说明    // type错误，应该是[doc] 

[release] V1.0_20210220   // release必须在第一行

3、工欲善其事必先利其器

工欲善其事必先利其器，工具的熟练掌握、合理利用，修改记录保存完整，后期检索跟踪问题，以及多项目软件切换合并才能简单易操作，才能保证代码的质量。