聊聊Git版本控制工具使用说明和规范

 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客户端的安装和使用。

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

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

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

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

 

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

 

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

1.3 基础演示

配置

 

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

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

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

 

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

 

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

 

提交到远程服务器

 

同步远程分支

 

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

分支合并

 

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

通用配置和常用功能

 

1.4 总结

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

推送服务器前先同步;

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

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

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

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

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

[[383754]]

 

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

 

2 Git的使用规范

1.1 用户名

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

1.2 分支名

功能接近的项目，尽量使用功能宏或者项目宏，从软件源码上减少分支;

分支名称使用大写字母和下划线，不能包含空格或中文;

临时测试或验证某个功能的分支，必须以TEST_开头，验证无误，且应用到正式项目后，最好删除远程分支;

某个版本基础上小改动，为解决生产或者客户问题的版本，必须以PATCH_开头，表示当前分支只是特殊情况下使用，后续正式版本不再继续维护升级;

因为需求变更，原XXX项目不得不分成2个分支，分支命名为XXX_AA和XXX_BB，其中AA和BB是两个分支的主要区别关键字，前面一样，表示两分支原属于同一个分支节点;若后续XXX_BB继续拆分，则新分支为XXX_BB_CC和XXX_BB_DD，依次类推;

禁止使用XXX1 XXX2 XXX3 这种分支名，禁止设分支名为master。

个人测试或者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、工欲善其事必先利其器

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

本文转载自微信公众号「嵌入式系统」，可以通过以下二维码关注。转载本文请联系嵌入式系统公众号。