git工做原理及提交規範

時間 2019-12-08

標籤 git 原理提交規範欄目 Git 简体版

原文原文鏈接

前言

官方解釋：Git(讀音爲/gɪt/。)是一個開源的分佈式版本控制系統，能夠有效、高速地處理從很小到很是大的項目版本管理。 Git 是 [Linus Torvalds](baike.baidu.com/item/Linus Torvalds/9336769) 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。git

Torvalds 開始着手開發 Git 是爲了做爲一種過渡方案來替代 BitKeshell

Git 保存的不是文件的變化或者差別，而是一系列不一樣時刻的文件快照。在進行提交操做時，Git 會保存一個提交對象（commit object）。該提交對象會包含一個指向暫存內容快照的指針。但不只僅是這樣，該提交對象還包含了做者的姓名和郵箱、提交時輸入的信息以及指向它的父對象的指針。npm

git安裝

Linux上安裝

sudo yum install git
複製代碼

MAC上安裝

若是你正在使用Mac作開發，有兩種安裝Git的方法。json

一是安裝homebrew，而後經過homebrew安裝Git，具體方法請參考homebrew的文檔：brew.sh/。bash

第二種方法更簡單，也是推薦的方法，就是直接從AppStore安裝Xcode，Xcode集成了Git，不過默認沒有安裝，你須要運行Xcode，選擇菜單「Xcode」->「Preferences」，在彈出窗口中找到「Downloads」，選擇「Command Line Tools」，點「Install」就能夠完成安裝了。app

window上安裝

在Windows上使用Git，能夠從Git官網直接下載安裝程序，（網速慢的同窗請移步國內鏡像），而後按默認選項安裝便可。分佈式

安裝完成後，在開始菜單裏找到「Git」->「Git Bash」，蹦出一個相似命令行窗口的東西，就說明Git安裝成功！ide

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文檔，而後再發布上線。