大家好！我是民工哥。
對於Git，相信大多數程式設計師並不會感到陌生。
作為目前世界上最先進的分散式版本控制系統（沒有之一），Git 是一個開源的分散式版本控制軟體，用以有效、高速的處理從很小到非常大的專案版本管理。 Git 最初是由Linus Torvalds設計開發的，用於管理Linux核心開發。隨著時間的推移，Git 發展到今天，已經成為了眾多開發者必備的開發工具。
如果你平時學習Git時感覺到枯燥乏味，不妨試一試這個好玩的小遊戲，透過別一種方式，在娛樂中去學習。
下面是其中的演示例子：
Git 簡介
Git 是一個開源的分散式版本控制系統。
什麼是版本控制？
版本控制是一種記錄一個或若干檔案內容變化，以便將來查閱特定版本修訂情況的系統。
什麼是分散式版本控制系統？
介紹分散式版本控制系統前，有必要先了解一下傳統的集中式版本控制系統。
集中化的版本控制系統，諸如 CVS，Subversion 等，都有一個單一的集中管理的伺服器，儲存所有檔案的修訂版本，而協同工作的人們都透過客戶端連到這臺伺服器，取出最新的檔案或者提交更新。
這麼做最顯而易見的缺點是中央伺服器的單點故障。如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。要是中央伺服器的磁碟發生故障，碰巧沒做備份，或者備份不夠及時，就會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄。
分散式版本控制系統的客戶端並不只提取最新版本的檔案快照，而是把程式碼倉庫完整地映象下來。這麼一來，任何一處協同工作用的伺服器發生故障，事後都可以用任何一個映象出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對程式碼倉庫的完整備份。
可參考：
Git 從入門到精通：
https：//mp。weixin。qq。com/s？__biz=MzI0MDQ4MTM5NQ==&mid=2247494947&idx=4&sn=8f07adcb499a053462d636af15138133&chksm=e918883fde6f01294ddfbcfdbac6fcc5dc2e9b191c78c1446709885a83d8eb1b992584fb7ea0&token=1267489950&lang=zh_CN#rd
Git vs SVN
Git 和 SVN 孰優孰好，每個人有不同的體驗。
Git是分散式的，SVN是集中式的
這是 Git 和 SVN 最大的區別。若能掌握這個概念，兩者區別基本搞懂大半。因為 Git 是分散式的，所以 Git 支援離線工作，在本地可以進行很多操作，包括接下來將要重磅推出的分支功能。而 SVN 必須聯網才能正常工作。
Git複雜概念多，SVN簡單易上手
所有同時掌握 Git 和 SVN 的開發者都必須承認，Git 的命令實在太多了，日常工作需要掌握add，commit，status，fetch，push，rebase等，若要熟練掌握，還必須掌握rebase和merge的區別，fetch和pull的區別等，除此之外，還有cherry-pick，submodule，stash等功能，僅是這些名詞聽著都很繞。
在易用性這方面，SVN對於新手來說會更有好一些。但是從另外一方面看，Git 命令多意味著功能多，若我們能掌握大部分 Git 的功能，體會到其中的奧妙，會發現再也回不去 SVN 的時代了。
Git分支廉價，SVN分支昂貴
在版本管理裡，分支是很常使用的功能。在釋出版本前，需要釋出分支，進行大需求開發，需要 feature 分支，大團隊還會有開發分支，穩定分支等。在大團隊開發過程中，常常存在建立分支，切換分支的求。
Git 分支是指標指向某次提交，而 SVN 分支是複製的目錄。這個特性使 Git 的分支切換非常迅速，並且建立成本非常低。
而且 Git 有本地分支，SVN 無本地分支。在實際開發過程中，經常會遇到有些程式碼沒寫完，但是需緊急處理其他問題，若我們使用 Git，便可以建立本地分支儲存沒寫完的程式碼，待問題處理完後，再回到本地分支繼續完成程式碼。
更多關注Git與Svn的比較請參閱：
通俗易懂｜用好Git 和 SVN ，輕鬆駕馭版本管理
Git 工作原理
文字不好理解，請看
圖文詳解 Git 工作原理
Git 安裝
Debian/Ubuntu 環境安裝
如果你使用的系統是 Debian/Ubuntu ， 安裝命令為：
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \> libz-dev libssl-dev$ apt-get install git-core$ git ——versiongit version 1。8。1。2
Centos/RedHat 環境安裝
如果你使用的系統是 Centos/RedHat ，安裝命令為：
$ yum install curl-devel expat-devel gettext-devel \> openssl-devel zlib-devel$ yum -y install git-core$ git ——versiongit version 1。7。1
Windows 環境安裝
在 Git 官方下載地址下載 exe 安裝包。按照安裝嚮導安裝即可。
建議安裝 Git Bash 這個 git 的命令列工具。
Mac 環境安裝
在 Git 官方下載地址下載 mac 安裝包。按照安裝嚮導安裝即可。
Git配置
Git 自帶一個 git config 的工具來幫助設定控制 Git 外觀和行為的配置變數。這些變數儲存在三個不同的位置：
/etc/gitconfig 檔案： 包含系統上每一個使用者及他們倉庫的通用配置。如果使用帶有 ——system 選項的 git config 時，它會從此檔案讀寫配置變數。\~/。gitconfig 或 \~/。config/git/config 檔案：只針對當前使用者。可以傳遞 ——global 選項讓 Git 讀寫此檔案。
當前使用倉庫的 Git 目錄中的 config 檔案（就是 。git/config）：針對該倉庫。
每一個級別覆蓋上一級別的配置，所以 。git/config 的配置變數會覆蓋 /etc/gitconfig 中的配置變數。
在 Windows 系統中，Git 會查詢 $HOME 目錄下（一般情況下是 C：\Users\$USER）的 。gitconfig 檔案。Git 同樣也會尋找 /etc/gitconfig 檔案，但只限於 MSys 的根目錄下，即安裝 Git 時所選的目標位置。
Git 基本概念
版本庫
當你一個專案到本地或建立一個 git 專案，專案目錄下會有一個隱藏的 。git 子目錄。這個目錄是 git 用來跟蹤管理版本庫的，千萬不要手動修改。
雜湊值
Git 中所有資料在儲存前都計算校驗和，然後以校驗和來引用。這意味著不可能在 Git 不知情時更改任何檔案內容或目錄內容。這個功能建構在 Git 底層，是構成 Git 哲學不可或缺的部分。若你在傳送過程中丟失資訊或損壞檔案，Git 就能發現。
Git 用以計算校驗和的機制叫做 SHA-1 雜湊（hash，雜湊）。這是一個由 40 個十六進位制字元（0-9 和 a-f）組成字串，基於 Git 中檔案的內容或目錄結構計算出來。SHA-1 雜湊看起來是這樣：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 中使用這種雜湊值的情況很多，你將經常看到這種雜湊值。實際上，Git 資料庫中儲存的資訊都是以檔案內容的雜湊值來索引，而不是檔名。
檔案狀態
在 GIt 中，你的檔案可能會處於三種狀態之一：
已修改（modified）
- 已修改表示修改了檔案，但還沒儲存到資料庫中。
已暫存（staged）
- 已暫存表示對一個已修改檔案的當前版本做了標記，使之包含在下次提交的快照中。
已提交（committed）
- 已提交表示資料已經安全的儲存在本地資料庫中。
工作區域
與檔案狀態對應的，不同狀態的檔案在 Git 中處於不同的工作區域。
工作區（working
） - 當你 git clone 一個專案到本地，相當於在本地克隆了專案的一個副本。工作區是對專案的某個版本獨立提取出來的內容。這些從 Git 倉庫的壓縮資料庫中提取出來的檔案，放在磁碟上供你使用或修改。
暫存區（staging）
- 暫存區是一個檔案，儲存了下次將提交的檔案列表資訊，一般在 Git 倉庫目錄中。有時候也被稱作 `‘索引’‘，不過一般說法還是叫暫存區。
本地倉庫（local）
- 提交更新，找到暫存區域的檔案，將快照永久性儲存到 Git 本地倉庫。
遠端倉庫（remote）
- 以上幾個工作區都是在本地。為了讓別人可以看到你的修改，你需要將你的更新推送到遠端倉庫。同理，如果你想同步別人的修改，你需要從遠端倉庫拉取更新。
分支（Branch）
分支是為了將修改記錄的整個流程分開儲存，讓分開的分支不受其它分支的影響，所以在同一個資料庫裡可以同時進行多個不同的修改
主分支（Master）前面提到過 master 是 Git 為我們自動建立的第一個分支，也叫主分支，其它分支開發完成後都要合併到 master
標籤（Tag）
標籤是用於標記特定的點或提交的歷史，通常會用來標記釋出版本的名稱或版本號（如：publish/0。0。1），雖然標籤看起來有點像分支，但打上標籤的提交是固定的，不能隨意的改動，參見上圖中的1。0 / 2。0 / 3。0
HEAD
HEAD 指向的就是當前分支的最新提交圖片
以上概念瞭解的差不多，那就可以繼續往下看。
Git 命令
建立倉庫
克隆一個已建立的倉庫：
# 透過 SSH$ git clone ssh：//user@domain。com/repo。git#透過 HTTP$ git clone http：//domain。com/user/repo。git
建立一個新的本地倉庫：
$ git init
新增修改
新增修改到暫存區：
# 把指定檔案新增到暫存區$ git add xxx# 把當前所有修改新增到暫存區$ git add 。# 把所有修改新增到暫存區$ git add -A
提交修改到本地倉庫：
# 提交本地的所有修改$ git commit -a# 提交之前已標記的變化$ git commit# 附加訊息提交$ git commit -m ’commit message‘
儲藏
有時，我們需要在同一個專案的不同分支上工作。當需要切換分支時，偏偏本地的工作還沒有完成，此時，提交修改顯得不嚴謹，但是不提交程式碼又無法切換分支。這時，你可以使用 git stash 將本地的修改內容作為草稿儲藏起來。
官方稱之為儲藏，但我個人更喜歡稱之為存草稿。
# 1。 將修改作為當前分支的草稿儲存$ git stash# 2。 檢視草稿列表$ git stash liststash@{0}： WIP on master： 6fae349 ：memo： Writing docs。# 3。1 刪除草稿$ git stash drop stash@{0}# 3。2 讀取草稿$ git stash apply stash@{0}
撤銷修改
撤銷本地修改：
# 移除快取區的所有檔案（i。e。 撤銷上次git add）$ git reset HEAD# 將HEAD重置到上一次提交的版本，並將之後的修改標記為未新增到快取區的修改$ git reset
刪除新增。gitignore檔案前錯誤提交的檔案：
$ git rm -r ——cached 。$ git add 。$ git commit -m “remove xyz file”
撤銷遠端修改（建立一個新的提交，並回滾到指定版本）：
$ git revert
徹底刪除指定版本：
# 執行下面命令後，commit-hash 提交後的記錄都會被徹底刪除，使用需謹慎$ git reset ——hard
更新與推送
更新：
# 下載遠端端版本，但不合併到HEAD中$ git fetch
推送：
# 將本地版本推送到遠端端$ git push remote
檢視資訊
顯示工作路徑下已修改的檔案：
$ git status
顯示與上次提交版本檔案的不同：
$ git diff
顯示提交歷史：
# 從最新提交開始，顯示所有的提交記錄（顯示hash， 作者資訊，提交的標題和時間）$ git log# 顯示某個使用者的所有提交$ git log ——author=“username”# 顯示某個檔案的所有修改$ git log -p
顯示搜尋內容：
# 從當前目錄的所有檔案中查詢文字內容$ git grep “Hello”# 在某一版本中搜索文字$ git grep “Hello” v2。5
分支
增刪查分支：
# 列出所有的分支$ git branch# 列出所有的遠端分支$ git branch -r# 基於當前分支建立新分支$ git branch
切換分支：
# 切換分支$ git checkout
標籤
# 給當前版本打標籤$ git tag
合併與重置
merge 與 rebase 雖然是 git 常用功能，但是強烈建議不要使用 git 命令來完成這項工作。
因為如果出現程式碼衝突，在沒有程式碼比對工具的情況下，實在太艱難了。
你可以考慮使用各種 Git GUI 工具。
合併：
# 將分支合併到當前HEAD中$ git merge
重置：
# 將當前HEAD版本重置到分支中，請勿重置已釋出的提交$ git rebase
更多命令參考：
三年 Git 使用心得 & 常見問題整理
Git 分支開發
Git 是目前最流行的原始碼管理工具。為規範開發，保持程式碼提交記錄以及 git 分支結構清晰，方便後續維護，現規範 git 的相關操作。
分支命名
1、master 分支
master 為主分支，也是用於部署生產環境的分支，確保master分支穩定性， master 分支一般由develop以及hotfix分支合併，任何時間都不能直接修改程式碼
2、develop 分支
develop 為開發分支，始終保持最新完成以及bug修復後的程式碼，一般開發的新功能時，feature分支都是基於develop分支下建立的。
feature 分支
開發新功能時，以develop為基礎建立feature分支。
分支命名： feature/ 開頭的為特性分支， 命名規則： feature/user_module、 feature/cart_module
release分支
release 為預上線分支，釋出提測階段，會release分支程式碼為基準提測。當有一組feature開發完成，首先會合併到develop分支，進入提測時會建立release分支。如果測試過程中若存在bug需要修復，則直接由開發者在release分支修復並提交。當測試完成之後，合併release分支到master和develop分支，此時master為最新程式碼，用作上線。
hotfix 分支
分支命名： hotfix/ 開頭的為修復分支，它的命名規則與feature分支類似。線上出現緊急問題時，需要及時修復，以master分支為基線，建立hotfix分支，修復完成後，需要合併到master分支和develop分支
更多開發規範請參閱：
全網最全的 Git 分支開發規範手冊
|
掌握這10條規範，輕鬆搞定Git！
Git這些高階用法，喜歡就拿去用！
Git 提交規範
為什麼需要規範？
無規矩不成方圓，程式設計也一樣。
如果你有一個專案，從始至終都是自己寫，那麼你想怎麼寫都可以，沒有人可以干預你。可是如果在團隊協作中，大家都張揚個性，那麼程式碼將會是一團糟，好好的專案就被糟踐了。不管是開發還是日後維護，都將是災難。
這時候，有人提出了何不統一標準，大家都按照這個標準來。於是 ESLint，JSHint 等程式碼工具如雨後春筍般湧現，成為了專案構建的必備良品。
Git Commit 規範可能並沒有那麼誇張，但如果你在版本回退的時候看到一大段糟心的 Commit，恐怕會懊惱不已吧。所以，嚴格遵守規範，利人利己。
具體請參閱：
你可能會忽略的 Git 提交規範
Git使用技巧
只有在遇到問題的時候，才體會到技巧帶來的好處！
常見企業工作流程
主要介紹，企業中常用的 Git 工作流程！
Git Flow
主幹分支
穩定分支
開發分支
補丁分支
修改分支
Github Flow
建立分支
新增提交
提交 PR 請求
討論和評估程式碼
部署檢測
合併程式碼
Gitlab Flow
帶生產分支
帶環境分支
帶釋出分支
日常使用最佳實踐
總結日常工作中應該遵循的
Git 使用方式
和方法！
使用命令列代替圖形化介面
使用命令列來操作，簡潔且效率高
提交應該儘可能的表述提交修改內容
區分 subject 和 body 內容，使用空行隔開
subject 一般不超過 50 個字元
body 每一行的長度控制在 72 個字元
subject 結尾不需要使用句號或者點號結尾
body 用來詳細解釋此次提交具體做了什麼
使用 。gitignore 檔案來排除無用檔案
可使用模板檔案，然後根據專案實際進行修改
基於分支或 fork 的開發模式
不要直接在主幹分支上面進行開發
在新建的分支上進行功能的開發和問題的修復
使用 release 分支和 tag 標記進行版本管理
使用 release 分支釋出程式碼和版本維護（release/1。32）
使用 tag 來標記版本（A-大feature功能。B-小feature功能。C-只修bug）
常用命令彙總整理
日常使用只要記住
6 個命令
就可以了。
無論是開發、運維，還是測試，大家都知道Git在日常工作中的地位。所以，也是大家的必學、必備技能之一。
但是呢，民工哥，也經常在後臺看到讀者說，命令太多了不好記啊，時間長了不用又忘記了等等的吐槽。是啊，要學一門技術真難，何況現在技術更新、迭代這麼快。。。。。
所以，對於學習Git這門技術，要是有一個一看就懂，一學就會的入門資料就好了。前不久，國外的一位小姐姐寫了一篇這樣的文章《CS Visualized： Useful Git Commands》。作者是來自英屬哥倫比亞的小姐姐 Lydia Hallie，在這篇文章裡面，她透過生動形象的動畫，以更加直觀的方式，向開發者展示 Git 命令中的 merge、rebase、reset、revert、cherry-pick 等常用騷操作的具體原理。
小姐姐用動畫圖解Git命令，一看就懂！
# 工作區 -> 暫存區$ git add
# 工作區 <- 暫存區$ git checkout ——
# 工作區 <- 本地倉庫$ git reset
更多關於Git的使用技巧介紹請查閱：
學會這 11 條，你離 Git 大神就不遠了！