前言

官方解释：Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。 Git 是 [Linus Torvalds](https://baike.baidu.com/item/Linus Torvalds/9336769) 为了帮助管理 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 "email@example.com"

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

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

git存储

git分区

git存储分成四个部分

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

整个过程就是：

工作区--git add--暂存区--git commit--本地仓库-- git push--远程仓库
远程仓库区–-fetch–-使用refs\remotes下对应分支文件记录远程分支末端commit_id 和本地仓库区 --merge–-工作区
远程仓库区–-pull–-使用refs\remotes下对应分支文件记录远程分支末端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

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

git内部存储

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

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

git提交规则

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

commit的作用

提供更多的历史信息，方便快速浏览。
可以过滤某些commit（比如文档改动），便于快速查找信息
可以直接从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

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

git分支与版本发布规范

基本原则：master为保护分支，不直接在master上进行代码修改和提交。
开发日常需求或者项目时，从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复，功能测试完毕并且项目发布上线后，将feature分支合并到主干master，并且打Tag发布，最后删除开发分支。分支命名规范：
- 分支版本命名规则：分支类型 _ 分支发布时间 _ 分支功能。比如：feature_20170401_fairy_flower
- 分支类型包括：feature、 bugfix、refactor三种类型，即新功能开发、bug修复和代码重构
- 时间使用年月日进行命名，不足2位补0
- 分支功能命名使用snake case命名法，即下划线命名。
Tag包括3位版本，前缀使用v。比如v1.2.31。Tag命名规范：
- 新功能开发使用第2位版本号，bug修复使用第3位版本号
- 核心基础库或者Node中间价可以在大版本发布请使用灰度版本号，在版本后面加上后缀，用中划线分隔。alpha或者belta后面加上次数，即第几次alpha：
  - v2.0.0-alpha.1
  - v2.0.0-belta.1
版本正式发布前需要生成changelog文档，然后再发布上线。