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

时间 2019-12-20

标签 git 原理提交规范干货栏目 Git 繁體版

原文原文链接

前言

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

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

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

git安装

Linux上安装

sudo yum install git

MAC上安装

若是你正在使用Mac作开发，有两种安装Git的方法。json

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

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

window上安装

在Windows上使用Git，能够从Git官网直接下载安装程序，（网速慢的同窗请移步国内镜像），而后按默认选项安装便可。ide

安装完成后，在开始菜单里找到“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–-使用refsremotes下对应分支文件记录远程分支末端commit_id 和本地仓库区 --merge–-工做区
远程仓库区–-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

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文档，而后再发布上线。