如果你覺得學習 Git 很枯燥，那是因為你還沒玩過這款游戲！
點擊關注公眾號，回復“1024”獲取2TB學習資源！
大家好！我是民工哥。
對于Git，相信大多數程序員并不會感到陌生。
作為目前世界上最先進的分布式版本控制系統（沒有之一），Git 是一個開源的分布式版本控制軟件,用以有效、高速的處理從很小到非常大的項目版本管理。Git 最初是由Linus Torvalds設計開發的，用于管理Linux內核開發。隨著時間的推移，Git 發展到今天，已經成為了眾多開發者必備的開發工具。
如果你平時學習Git時感覺到枯燥乏味，不妨試一試這個好玩的小游戲，通過別一種方式，在娛樂中去學習。
下面是其中的演示例子：
需要這款游戲的讀者可以點擊下方公眾號名片回復關鍵詞 Git小游戲 獲取
Git 簡介
Git 是一個開源的分布式版本控制系統。
版本控制是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統。
介紹分布式版本控制系統前，有必要先了解一下傳統的集中式版本控制系統。
集中化的版本控制系統，諸如 CVS，Subversion 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。
這么做最顯而易見的缺點是中央服務器的單點故障。如果宕機一小時，那么在這一小時內，誰都無法提交更新，也就無法協同工作。要是中央服務器的磁盤發生故障，碰巧沒做備份，或者備份不夠及時，就會有丟失數據的風險。最壞的情況是徹底丟失整個項目的所有歷史更改記錄。
分布式版本控制系統的客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。這么一來，任何一處協同工作用的服務器發生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的提取操作，實際上都是一次對代碼倉庫的完整備份。
可參考：Git 從入門到精通
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?--version
git?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?--version
git?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 會查找 目錄下（一般情況下是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?list
stash@{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?
#?將HEAD重置到上一次提交的版本，并保留未提交的本地修改
$?git?reset?--keep?
#?放棄工作目錄下的所有修改
$?git?reset?--hard?HEAD
#?將HEAD重置到指定的版本，并拋棄該版本之后的所有修改
$?git?reset?--hard?
#?用遠端分支強制覆蓋本地分支
$?git?reset?--hard?
#?放棄某個文件的所有本地修改
$?git?checkout?HEAD?
刪除添加.gitignore文件前錯誤提交的文件：
$?git?rm?-r?--cached?.
$?git?add?.
$?git?commit?-m?"remove?xyz?file"
撤銷遠程修改（創建一個新的提交，并回滾到指定版本）：
$?git?revert?
徹底刪除指定版本：
#?執行下面命令后，commit-hash?提交后的記錄都會被徹底刪除，使用需謹慎
$?git?reset?--hard?
$?git?push?-f
更新與推送
更新：
#?下載遠程端版本，但不合并到HEAD中
$?git?fetch?
#?將遠程端版本合并到本地版本中
$?git?pull?origin?master
#?以rebase方式將遠端分支與本地合并
$?git?pull?--rebase?
推送：
#?將本地版本推送到遠程端
$?git?push?remote?
#?刪除遠程端分支
$?git?push?
$?git?push?
#?發布標簽
$?git?push?--tags
查看信息
顯示工作路徑下已修改的文件：
$?git?status
顯示與上次提交版本文件的不同：
$?git?diff
顯示提交歷史：
$?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?branch?--track?
#?刪除本地分支
$?git?branch?-d?
#?強制刪除本地分支，將會丟失未合并的修改
$?git?branch?-D?
切換分支：
#?切換分支
$?git?checkout?
#?創建并切換到新分支
$?git?checkout?-b?
標簽
#?給當前版本打標簽
$?git?tag?
#?給當前版本打標簽并附加消息
$?git?tag?-a?
合并與重置
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
主干分支
穩定分支
開發分支
補丁分支
修改分支
創建分支
添加提交
提交 PR 請求
討論和評估代碼
部署檢測
合并代碼
帶生產分支
帶環境分支
帶發布分支
總結日常工作中應該遵循的 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?add?
#?暫存區?->?本地倉庫
$?git?commit?-m?"some?info"
#?本地倉庫?->?遠程倉庫
$?git?push?origin?master??#?本地master分支推送到遠程origin倉庫
#?工作區?<-?暫存區
$?git?checkout?--?
#?暫存區?<-?本地倉庫
$?git?reset?HEAD?
#?本地倉庫?<-?遠程倉庫
$?git?clone?
$?git?fetch?upstream?master??#?拉取遠程代碼到本地但不應用在當前分支
$?git?pull?upstream?master???#?拉取遠程代碼到本地但應用在當前分支
$?git?pull?--rebase?upstream?master??#?如果平時使用rebase合并代碼則加上
#?工作區?<-?本地倉庫
$?git?reset?
$?git?reset?--mixed?
$?git?reset?--soft?
$?git?reset?--hard?
更多關于Git的使用技巧介紹請查閱：學會這 11 條，你離 Git 大神就不遠了！
Git 知識體系動態更新看這里：Git 技術學習
推薦閱讀?點擊標題可跳轉
Ngnix 之父突然離職，程序員巔峰一代落幕
分享幾款好用到爆的 Chrome 插件！！
2021 互聯網公司時薪排行榜出爐！微軟美團很強！
超牛逼！這款輕量級、低侵入式監控系統真強大~
神器 Nginx 的學習手冊 ( 建議 )
逃離一線！從上海舉家回成都七年，現在怎么樣了？
再見！全球第四大手機 OS
基于SpringBoot+MyBatis前后端分離的在線辦公系統
PS：因為公眾號平臺更改了推送規則，如果不想錯過內容，記得讀完點一下“在看”，加個“星標”，這樣每次新文章推送才會第一時間出現在你的訂閱列表里。
隨手在看、轉發是最大的支持！
5G游戲 Git GitHub
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
