提交规范

commit信息

commit message格式:
():

  1. type(必须)
    用于说明git commit的类别，只允许使用下面的标识。
    • feat：新功能（feature）。
    • fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
    • fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
    • to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
    • docs：文档（documentation）。
    • style：格式（不影响代码运行的变动）。
    • refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
    • perf：优化相关，比如提升性能、体验。
    • test：增加测试。
    • chore：构建过程或辅助工具的变动。
    • revert：回滚到上一个版本。
    • merge：代码合并。
    • sync：同步主线或分支的Bug。

  2. scope(可选)
    这里是否必须，以及范围是什么内容，可以看实际公司的情况。
    scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
    例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。

  3. subject(必须)
    subject是commit目的的简短描述，不超过50个字符。
    • 结尾不加句号或其他标点符号。
    • 根据以上规范git commit message将是如下的格式：
    fix(DAO):用户查询缺少username属性
    feat(Controller):用户查询接口开发

版本号

V1.0.0.20211028_base

解读一下这个版本号命名规范：

  • 第一位：版本前缀（V）
    V （version）英文版本的缩写
  • 第二位：主版本号（V1）
    当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目经理决定是否修改。
  • 第三位：副版本号（V1.0）
    当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目经理决定是否修改。
  • 第四位：修订版本号（V1.0.0）
    一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
  • 第五位：日期版本号（V1.0.0.20211028_base）
    用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
  • 第六位：希腊字母版本号（V1.0.0.20211028_base）
    希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、 release
    Base： 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
    Alpha ： 软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者 内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。
    Beta ： 该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。
    RC ： 该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。
    Release： 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。

常用命令

配置Git

//升级
git clone git://git.kernel.org/pub/scm/git/git.git
//设置用户信息
// --global 选项，该命令只需要运行一次，之后无论你在该系统上做任何事情， Git 都会使用那些信息
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
//配置默认文本编辑器
git config --global core.editor emacs

查看信息

//查看提交历史
//会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明
git log
git -p -数字//显示每次提交的内容差异，后面的“数字”显示最近n次提交
git log -stat//简略的统计信息
git log  --pretty = 格式选项//指定展示提交历史的格式
//列出所有 Git 当时能找到的配置
git config --list
//检查 Git 的某一项配置
git config <key>
//获取帮助
git help <verb>
git <verb> --help
man git-<verb>
//查看状态
//新添加的未跟踪文件前面有 ?? 标记
//新添加到暂存区中的文件前面有 A 标记
//修改过的文件前面有 M 标记
git status
git status -s 或 git status--short //简要
git status -v //详细的修改内容，将你所做的改变的 diff 输出放到编辑器中从而使你知道本次提交具体做了哪些修改
//尚未暂存的文件修改了什么地方
//git diff 本身只显示尚未暂存的改动
git diff //比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容
git diff --cached 或 git diff --staged//查看已暂存的将要添加到下次提交里的内容。初次创建并add后执行该命令会显示全部内容

合作开发

//创建一个名为 .git 的子目录
//这个子目录含有初始化的 Git 仓库中所有的必须文件
//但项目里的文件还没有被跟踪
git init

//加入跟踪
git add
//unstage
git reset
//提交
//一定要确认还有什么修改过的或新建的文件还没有 gitadd 过，否则提交的时候不会记录这些还没暂存起来的变化
git commit
git commit -m "提交信息" //将提交信息与命令放在同一行
git commit -a //自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤
//克隆的是该 Git 仓库服务器上的几乎所有数据
//默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来
//初始化一个 .git 文件夹，从远程仓库拉取下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝
git clone [url]

//克隆远程仓库的时候，自定义本地仓库的名字
//支持多种数据传输协议。下面的例子使用的是 https:// 协议，不过你也可以使用 git:// 协议或者使用SSH 传输协议
git clone https://github.com/libgit2/libgit2 mylibgit

移除文件


配置变量

  • git config 的工具来帮助设置控制 Git 外观和行为的配置变量
  • 配置变量存储在三个不同的位置：
配置变量 作用
/etc/gitconfig 文件 1. 系统上每一个用户及他们仓库的通用配置
2. 使用带有 --system 选项的git config 时，它会从此文件读写配置变量
~/.gitconfig 或 ~/.config/git/config 文件 1.针对当前用户
传递 --global 选项让 Git读写此文件
.git/config 针对该仓库

列表中每下一行都可以覆盖前几行的配置

忽略文件

  1. 创建.gitignore文件
  2. 在里面写入信息。需满足以下条件：
  • 所有空行或者以 ＃ 开头的行都会被 Git 忽略。
  • 可使用标准的 glob 模式(简化的正则表达式)匹配。
  • 匹配模式可以以（/）开头防止递归。如/TODO只忽略当前目录的TODO文件
  • 匹配模式可以以（/）结尾指定目录。如build/忽略所有build目录下的文件
  • 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。

Tips

  1. 每次准备提交前，先用 git status 看下，是不是都已暂存起来了，然后再运行提交命令 git commit。否则提交的时候不会记录这些还没暂存起来的变化，这些修改过的文件只保留在本地磁盘

顺序

//配置用户信息

//初始化或者克隆
git init 
git clone

//跟踪
git add

//提交
git status
git commit
//推送
git  push