主要跟着https://gitee.com/progit/index.html來學習的，知識點來自這裏，添加自己的理解和想法。
首先了解什麼是Git?個人理解就是一個設計合理的版本控制系統（VCS）。
介紹本地版本控制系統、集中化版本控制系統、分佈版本控制系統。
在git出現之前，採取的多爲本地版本控制系統，許多人習慣用複製整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單。就像我們的畢業論文：初版、修訂版1、...終極版、終極不改等，有時候會混淆所在的工作目錄，一旦弄錯文件丟了數據就沒法撤銷恢復。
爲了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的數據庫來記錄文件的歷次更新差異：
接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（ Centralized Version Control Systems，簡稱 CVCS ）應運而生。這類系統，諸如 CVS，Subversion 以及 Perforce 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。多年以來，這已成爲版本控制系統的標準做法：
這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。現在，每個人都可以在一定程度上看到項目中的其他人正在做些什麼。而管理員也可以輕鬆掌控每個開發者的權限，並且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。
事分兩面，有好有壞。這麼做最顯而易見的缺點是中央服務器的單點故障。如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。要是中央服務器的磁盤發生故障，碰巧沒做備份，或者備份不夠及時，就會有丟失數據的風險。最壞的情況是徹底丟失整個項目的所有歷史更改記錄，而被客戶端偶然提取出來的保存在本地的某些快照數據就成了恢復數據的希望。但這樣的話依然是個問題，你不能保證所有的數據都已經有人事先完整提取出來過。本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。
於是分佈式版本控制系統（ Distributed Version Control System，簡稱 DVCS ）面世了。在這類系統中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客戶端並不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工作用的服務器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。因爲每一次的提取操作，實際上都是一次對代碼倉庫的完整備份。
更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協作。
你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。
git基礎
接下來就是我們的重量級嘉賓 git，git和其他相比有什麼不一樣的地方嗎？
直接記錄快照，而非差異比較
Git 和其他版本控制系統的主要差別在於，Git 只關心文件數據的整體是否發生變化，而大多數其他系統則只關心文件內容的具體差異。這類系統（CVS，Subversion，Perforce，Bazaar 等等）每次記錄有哪些文件作了更新，以及都更新了哪些行的什麼內容。
Git 並不保存這些前後變化的差異數據。實際上，Git 更像是把變化的文件作快照後，記錄在一個微型的文件系統中。每次提交更新時，它會縱覽一遍所有文件的指紋信息並對文件作一快照，然後保存一個指向這次快照的索引。爲提高性能，若文件沒有變化，Git 不會再次保存，而只對上次保存的快照作一鏈接。Git 的工作方式就像圖所示。
Git 保存每次更新時的文件快照
這是 Git 同其他系統的重要區別。它完全顛覆了傳統版本控制的套路，並對各個環節的實現方式作了新的設計。Git 更像是個小型的文件系統，但它同時還提供了許多以此爲基礎的超強工具，而不只是一個簡單的 VCS。
近乎所有操作都是本地執行
在 Git 中的絕大多數操作都只需要訪問本地文件和資源，不用連網。但如果用 CVCS 的話，差不多所有操作都需要連接網絡。因爲 Git 在本地磁盤上就保存着所有當前項目的歷史更新，所以處理起來速度飛快。
舉個例子，如果要瀏覽項目的歷史更新摘要，Git 不用跑到外面的服務器上去取數據回來，而直接從本地數據庫讀取後展示給你看。所以任何時候你都可以馬上翻閱，無需等待。如果想要看當前版本的文件和一個月前的版本之間有何差異，Git 會取出一個月前的快照和當前文件作一次差異運算，而不用請求遠程服務器來做這件事，或是把老版本的文件拉到本地來作比較。
用 CVCS 的話，沒有網絡或者斷開 VPN 你就無法做任何事情。但用 Git 的話，就算你在飛機或者火車上，都可以非常愉快地頻繁提交更新，等到了有網絡的時候再上傳到遠程倉庫。同樣，在回家的路上，不用連接 VPN 你也可以繼續工作。換作其他版本控制系統，這麼做幾乎不可能，抑或非常麻煩。比如 Perforce，如果不連到服務器，幾乎什麼都做不了（譯註：默認無法發出命令 p4 edit file 開始編輯文件，因爲 Perforce 需要聯網通知系統聲明該文件正在被誰修訂。但實際上手工修改文件權限可以繞過這個限制，只是完成後還是無法提交更新。）；如果是 Subversion 或 CVS，雖然可以編輯文件，但無法提交更新，因爲數據庫在網絡上。看上去好像這些都不是什麼大問題，但實際體驗過之後，你就會驚喜地發現，這其實是會帶來很大不同的。
時刻保持數據完整性
在保存到 Git 之前，所有數據都要進行內容的校驗和（checksum）計算，並將此結果作爲數據的唯一標識和索引。換句話說，不可能在你修改了文件或目錄之後，Git 一無所知。這項特性作爲 Git 的設計哲學，建在整體架構的最底層。所以如果文件在傳輸時變得不完整，或者磁盤損壞導致文件數據缺失，Git 都能立即察覺。
Git 使用 SHA-1 算法計算數據的校驗和，通過對文件的內容或目錄的結構計算出一個 SHA-1 哈希值，作爲指紋字符串。該字串由 40 個十六進制字符（0-9 及 a-f）組成，看起來就像是：
24b9da6552252987aa493b52f8696cd6d3b00373
Git 的工作完全依賴於這類指紋字串，所以你會經常看到這樣的哈希值。實際上，所有保存在 Git 數據庫中的東西都是用此哈希值來作索引的，而不是靠文件名。
多數操作僅添加數據
常用的 Git 操作大多僅僅是把數據添加到數據庫。因爲任何一種不可逆的操作，比如刪除數據，都會使回退或重現歷史版本變得困難重重。在別的 VCS 中，若還未提交更新，就有可能丟失或者混淆一些修改的內容，但在 Git 裏，一旦提交快照之後就完全不用擔心丟失數據，特別是養成定期推送到其他倉庫的習慣的話。
這種高可靠性令我們的開發工作安心不少，儘管去做各種試驗性的嘗試好了，再怎樣也不會弄丟數據。
文件的三種狀態
對於任何一個文件，在 Git 內都只有三種狀態：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該文件已經被安全地保存在本地數據庫中了；已修改表示修改了某個文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時要保存的清單中。
由此我們看到 Git 管理項目時，文件流轉的三個工作區域：Git 的工作目錄，暫存區域，以及本地倉庫。
工作目錄，暫存區域，以及本地倉庫
每個項目都有一個 Git 目錄（譯註：如果 git clone 出來的話，就是其中 .git 的目錄；如果 git clone --bare 的話，新建的目錄本身就是 Git 目錄。），它是 Git 用來保存元數據和對象數據庫的地方。該目錄非常重要，每次克隆鏡像倉庫的時候，實際拷貝的就是這個目錄裏面的數據。
從項目中取出某個版本的所有文件和目錄，用以開始後續工作的叫做工作目錄。這些文件實際上都是從 Git 目錄中的壓縮對象數據庫中提取出來的，接下來就可以在工作目錄中對這些文件進行編輯。
所謂的暫存區域只不過是個簡單的文件，一般都放在 Git 目錄中。有時候人們會把這個文件叫做索引文件，不過標準說法還是叫暫存區域。
基本的 Git 工作流程如下：
- 在工作目錄中修改某些文件。
- 對修改後的文件進行快照，然後保存到暫存區域。
- 提交更新，將保存在暫存區域的文件快照永久轉儲到 Git 目錄中。
所以，我們可以從文件所處的位置來判斷狀態：如果是 Git 目錄中保存着的特定版本文件，就屬於已提交狀態；如果作了修改並已放入暫存區域，就屬於已暫存狀態；如果自上次取出後，作了修改但還沒有放到暫存區域，就是已修改狀態。
安裝git
有許多種安裝方式，主要分爲兩種，一種是通過編譯源代碼來安裝；另一種是使用爲特定平臺預編譯好的安裝包。
不爲難自己，直接網頁版下載
http://msysgit.github.com/
具體安裝步驟可以參考：https://blog.csdn.net/weixin_30363263/article/details/79679802
接下來就可以點擊git-bash來操作git了O(∩_∩)O~~