git工作原理及提交规范【干货】

前言

官方解释：Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKe

Git 保存的不是文件的变化或者差异，而是一系列不同时刻的文件快照。在进行提交操作时，Git 会保存一个提交对象（commit object）。该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。

git安装

Linux上安装

sudo yum install git

MAC上安装

如果你正在使用Mac做开发，有两种安装Git的方法。

一是安装homebrew，然后通过homebrew安装Git，具体方法请参考homebrew的文档：http://brew.sh/。

第二种方法更简单，也是推荐的方法，就是直接从AppStore安装Xcode，Xcode集成了Git，不过默认没有安装，你需要运行Xcode，选择菜单“Xcode”->“Preferences”，在弹出窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装了。

window上安装

在Windows上使用Git，可以从Git官网直接下载安装程序，（网速慢的同学请移步国内镜像），然后按默认选项安装即可。

安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！

git设置

$ git config --global user.name "Your Name"
$ git config --global user.email "[e-mail]"

因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。你也许会担心，如果有人故意冒充别人怎么办？这个不必担心，首先我们相信大家都是善良无知的群众，其次，真的有冒充的也是有办法可查的。

注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

git存储

git分区

git存储分成四个部分

1. workspace：工作空间（我们的开发代码目录）
2. index： 暂存区，.git目录下的index文件
3. Repository：本地仓库，通过git clone将远程的代码下载到本地；代码库的元数据信息在根目录下的.git目录下
4. Remote：远程仓库（比如GitHub就是一个远程仓库）

整个过程就是：

1. 工作区--git add--暂存区--git commit--本地仓库-- git push--远程仓库
2. 远程仓库区–-fetch–-使用refsremotes下对应分支文件记录远程分支末端commit_id 和 本地仓库区 --merge–-工作区
3. 远程仓库区–-pull–-使用refsremotes下对应分支文件记录远程分支末端commit_id and 本地仓库区 and 工作区

git fetch和git pull的区别

git fetch:是将远程主机的最新内容拉到本地，用户在检查了以后决定是否合并到工作本机分支中。具体操作如下:

git  fetch origin master:temp 
//本地新建一个temp分支，并将远程origin仓库的master分支代码下载到本地temp分支
git diff temp
//比较远程代码与本地代码的区别
git merge temp
//将temp分支合并到本地master分支
git branch -d temp
//如果不想保留分支，可以将其删除

git pull:基于本地的FETCH_HEAD记录，比对本地的FETCH_HEAD与远程仓库的版本号，然后git fetch获得当前的远程分支的后续版本的数据，然后利用git merge将其与本地的分支合并，可以认为是git pull是git fetch和git merge两个步骤的合并。
实际的git pull过程可以理解为：

git fetch origin master  //将远端的master分支拉取最新内容
git merge FETCH_HEAD //将拉取的最新内容与当前分支合并

git pull用法：

git pull <远程主机名>  <远程分支名>:<本地分支名>
//将远程主机的某个分支，与本地的指定分支合并

git pull合并后可能会出现冲突，需要手动解决冲突。
出现的错误提示如下

error: Your local changes to the following files would be overwritten by merge:
Please commit your changes or stash them before you merge.
//更新的代码与本地的修改代码有冲突，先提交你的改变或者先将本地修改暂存起来

解决冲突的方式：先将本地的代码暂存

git stash //先将本地修改暂存起来
git stash list  //查看保存信息
git pull     //拉取内容
git stash pop   //还原暂存的内容

git status

1. Changes to be committed：代表被add的文件，被加载到了暂存区
2. Changes not staged for commit：代表在当前分支中被修改的文件，还没有被add，存储在工作区

git内部存储

本地git项目里面的.git目录下的文件如下：

1. refs：存储git各种引用的目录，包含分支、远程分支和标签
2. objects：是存储git各种对象及备用的对象库，包含正常的压缩和压缩后的
3. info：存储git信息的目录，比如判处特定后缀的文件
4. index：暂存区
5. hooks：存储git钩子的目录，钩子只在特定事件发生时触的脚本，比如：提交之前，提交之后
6. description：项目描述
7. config：代码库几倍的配置文件
8. ORIG_HEAD：针对某些 危险操作 ，Git通过记录HEAD指针的上次所在的位置ORIG_HEAD提供了回退的功能。当你发现某些操作失误了，比如错误的reset到了一个很早很早的版本，可以使用 git reset --hard ORIG_HEAD回退到上一次reset之前。
9. HEAD：代码库当前分支的指向
10. FETCH_HEAD： 是一个版本链接，记录在本地的一个文件中，指向着目前已经从远程仓库取下来的分支的末端版本。
11. COMMIT_EDITMSG：commit编辑

git提交规则

对于一个英文水平有限的IT人员在项目中很多时候使用git commit， message往往会写的不尽如人意，或者当你使用git log时往往不知道之前提交的是什么东西，修改了什么，这样对以后的查看很不友好。git 提交有一个成熟的工具（Commitizen）

commit的作用

1. 提供更多的历史信息，方便快速浏览。
2. 可以过滤某些commit（比如文档改动），便于快速查找信息
3. 可以直接从commit生成Change log。

commitizen安装使用

安装

npm install -g commitizen

package.json配置

{
    "name": "application-name",
    "version": "0.1.0",
    "scripts": {
      "commitmsg": "validate-commit-msg",
      "commit": "git-cz ",
      "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
    },
    "devDependencies": {
      "commitizen": "^2.3.0",
      "validate-commit-msg": "^2.11.1",
      "conventional-changelog-cli": "^1.2.0",
      "husky": "^0.13.1"
    }
}

新建.vcmrc文件，添加内容如下

{
  "helpMessage": "\nPlease fix your commit message (and consider using https://www.npmjs.com/package/commitizen)\n",
  "types": [
    "feat",
    "fix",
    "docs",
    "style",
    "refactor",
    "perf",
    "test",
    "chore",
    "revert"
  ],
  "warnOnFail": false,
  "autoFix": false
}

commit规范

每次提交，Commit message 都包括三个部分：header，body 和 footer。

<type>(<scope>): <subject> #header
// 空一行
<body>
// 空一行
<footer> 

commit type

1. feat： 新增 feature
2. fix: 修复 bug
3. docs: 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE等等
4. style: 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
5. refactor: 代码重构，没有加新功能或者修复 bug
6. perf: 优化相关，比如提升性能、体验
7. test: 测试用例，包括单元测试、集成测试等
8. chore: 改变构建流程、或者增加依赖库、工具等
9. revert: 回滚到上一个版本

git分支与版本发布规范

1. 基本原则：master为保护分支，不直接在master上进行代码修改和提交。

2. 开发日常需求或者项目时，从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复，功能测试完毕并且项目发布上线后，将feature分支合并到主干master，并且打Tag发布，最后删除开发分支。分支命名规范：

   • 分支版本命名规则：分支类型 分支发布时间 分支功能。比如：feature_20170401_fairy_flower
   • 分支类型包括：feature、 bugfix、refactor三种类型，即新功能开发、bug修复和代码重构
   • 时间使用年月日进行命名，不足2位补0
   • 分支功能命名使用snake case命名法，即下划线命名。

3. Tag包括3位版本，前缀使用v。比如v1.2.31。Tag命名规范：

   • 新功能开发使用第2位版本号，bug修复使用第3位版本号

   • 核心基础库或者Node中间价可以在大版本发布请使用灰度版本号，在版本后面加上后缀，用中划线分隔。alpha或者belta后面加上次数，即第几次alpha：

     • v2.0.0-alpha.1
     • v2.0.0-belta.1
4. 版本正式发布前需要生成changelog文档，然后再发布上线。