⑴ 關於git和github版本管理的疑問，先謝謝大家了，80分~~
樓主 我一個問題一個問題的回答哈
1、git是分布式管理，也就是說伺服器上的和本地內的可以隨時同步容更新，當你提交不成功時，你所更改的文件會放在緩存區，別人來提交的時候會一起把所有更改的文件提交，建議代碼入庫不要多個人來操作 一個人就好了 這樣子不容易出錯。
2、git分支間的合並---是把兩個分之間不同的修改合並到一起，如果遇到沖突(比如修改到了同一個文件)，就會提示你，讓你忽略或者是手動處理。（建議手動處理）
3、不用，你就在本地客戶端克隆一個代碼庫，然後進行本地修改，到時候代碼入庫的時候注意一個先後順序就行了。
4、為什麼要在伺服器上改呢？直接在本地進行開發，然後在進行伺服器的代碼同步不就好了嗎
⑵ Git系列之底層原理篇
本章節是Git的核心知識點，主要是介紹Git底層原理與在使用Git過程中的幾個重要區域，弄懂Git的整個使用流程，以及數據的存儲過程。
工作區（Working Directory）:
工作區就是我們平時編寫文本文件的地方
暫存區（Stage/Index）:
暫存區是我們提交文本文件到本地倉庫的來源地，只有把工作區的文件添加至暫存區，才可以被提交至本地倉庫。
本地倉庫（Repository）：
本地倉庫是保存每次文件更新的記錄，包括提交人，提交時間，提交的內容等詳細信息，方便追溯歷史版本。
遠程倉庫（Remote Repository）：
遠程倉庫算是本地倉庫的一個副本，主要是方便合作夥伴之間的倉庫文件同步。
因此它的使用流程可以簡單的概括為：
1、在本地搭建一個目錄，用來創建git倉庫
$ git init gitDirectory
2、在倉庫目錄下創建文本文件（工作區）
$ cd gitDirectory
$ echo "first txt" > first.txt
3、把工作區的first.txt文件添加至git暫存區
$ git add first.txt
4、將暫存區中的文件first.txt提交至本地倉庫
$ git commit -m "first commit"
5、將文件保存至本地倉庫就已經可以記錄我們每次提交的歷史信息了，但是為了方便其他夥伴一起協作，還需要搭建一個遠程服務。（本次以GitHub為例）
在GitHub創建一個和本地一樣名稱的倉庫，創建成功後會生成一個倉庫地址：
https://github.com/mr-kings/gitDirectory.git
6、將本地倉庫和遠程倉庫關聯起來
$ git remote add origin https://github.com/mr-kings/gitDirectory.git
7、第一次將本地倉庫提交至遠程倉庫
$ git push -u origin master
第一次需要添加 -u 參數，即把本地的master分支和遠程倉庫的master分支對應上
8、此時本地倉庫和遠程倉庫就已經實現了同步，其他協作夥伴只需到遠程倉庫把倉庫克隆到自己的電腦即可進行協作編輯
$ git clone https://github.com/mr-kings/gitDirectory.git
9、克隆下來以後會在本地生成本地倉庫以及工作區，後續的操作和2步驟及以後步驟一致
需要注意的是：遠程倉庫有兩種連接方式https/ssh，上面的例子使用的https，其實ssh方式會比https快的多，它還可以通過添加密鑰的方式省去每次提交時都要輸入用戶名和密碼的問題，這里不做詳細介紹。https也是可以通過配置省去每次推送都需要輸入用戶名和密碼的問題。
Git安裝成功後，在本地新建一個Git倉庫，$ git init Gitstudy會生成一個.git文件夾，如果你創建的時候沒有發現.git目錄那應該是你的電腦默認隱藏了.git文件夾，有兩種方式可以查看它：
第一種方式：
命令行工具，在當前目錄下，在命令行里輸入 $ ll -a 即可查看
第二種方式：
在當前目錄下，點擊查看菜單，然後勾選上隱藏的項目即可
.git目錄就是暫存區和本地倉庫的位置，所以它的核心就在這里，下面看看它有哪些內容：
由上圖可知，初始化的時候.git目錄下有以下文件及文件夾：
config(文件)：存放當前倉庫的一些配置信息，比如記住用戶名和密碼，別名等
下面是它的常用選項：
[core] ignorecase 是否忽略文件大小寫
[remote "origin"] url 配置遠程倉庫地址
[remote "origin"] fetch 遠程分支映射關系
[user] name 用戶名
[user] email 郵箱
[alias] 命令別名配置 ： cmt = commit
description(文件)：創建倉庫的描述文件
HEAD(文件)：指示當前被檢出(所在)的分支，如當前在test分支，文件內容則為ref: refs/heads/test。
hooks/(文件夾)：包含客戶端或服務端的鉤子腳本(hook scripts)，如pre-commit，post-receive等
info/ (文件夾)：用以存儲一些有關git倉庫的信息，如exclude
objects/ (文件夾)：用以存儲git倉庫中的所有數據內容
refs/(文件夾)：包含 heads 文件夾，remote文件夾。heads 記錄本地相關的各 git分支操作記錄，remote 記錄遠程倉庫相關的各git分支 操作記錄
當第一次提交的時候還會生成以下文件及文件夾：
index (文件) -- （在git add file的時候生成）：是當前版本的文件索引，包含生成當前樹(唯一確定的)對象的所虛信息，可用於快速比對工作樹和其他提交樹對象的差異(各commit和HEAD之間的diff)，可用於存儲單文件的多個版本以有效的解決合並沖突。可使用git ls-files 查看index文件內容
COMMIT_EDITMSG(文件) -- （在git commit -m "first commit"的時候生成）：最近一次的 commit edit message
logs/ (文件夾) -- （在git commit -m "first commit"的時候生成）：放置git倉庫操作記錄的文件夾，包含HEAD文件 和 refs文件夾
以上簡單介紹了.git目錄下的文件及文件夾，重點則是objects文件夾：
經過第一次提交後objects文件夾下多出了3個文件夾：44/、d0/、f6/。通過提交的日誌我們發現，commit後會生成一個40位的16進制字元串（前兩位作為文件夾名稱，後38位為內容哈希值）
官方描述：這是一個 SHA-1 哈希值——一個將待存儲的數據外加一個頭部信息(header)一起做 SHA-1 校驗運算而得的校驗和（前2位作為文件夾名稱 -- 後面38位作為內容的哈希值）
通過cat-file -t sha-1 命令查看當前哈希值所屬的類型：
由圖可知它是一個commit對象
再通過命令cat-file -p sha-1查看該commit對象包含有哪些信息
由圖知一個commit對象包含了tree對象，本地倉庫信息，提交人信息及提交時的備注信息。
再通過上述命令查看tree對象又包含又哪些信息：
由圖知tree對象又包含了blob對象，在多目錄的情況下tree對象還會包含其他tree對象。
由此得出結論：剛才提交的時候生成的那個3個文件夾分別對應的是3個對象即：44/文件夾對應的是commit對象，f6/文件夾對應的是tree對象，d0/文件夾對應的是blob對象。層級關系是：commit對象對應一個tree對象，tree對象可以包含一個或多個其他tree對象和blob對象。
下面就簡單介紹git中的幾個對象：
blob：
blob對象只跟文本文件的內容有關，和文本文件的名稱及目錄無關，只要是相同的文本文件，會指向同一個blob。
tree:
tree對象記錄文本文件內容和名稱、目錄等信息，每次提交都會生成一個頂層tree對象，它可以指向其引用的tree或blob。
commit:
commit對象記錄本次提交的所有信息，包括提交人、提交時間，本次提交包含的tree及blob。
tag:
標簽引用，它指向某一個commit。
用下面的圖可以把今天的內容概括起來：上半部分描述了git的操作流程圖，下半部分描述git底層數據存儲結構圖
Git流程及底層結構圖
下面就對圖的下半部分做個詳細說明：
1、在與.git同級目錄下新建文件夾directory，再在directory目錄下新建一個文本文件first.txt，裡面的內容為1。當執行$ git add first.txt 的時候就會在.git/objects/生成一個blob對象的文件夾（前兩位為文件夾名稱 -- 後38位為文本內容的哈希值）對應上圖的第一個d00491 -- blob對象。
2、當執行$ git commit -m "first commit" 的時候就會在.git/objects/下新生成了2個tree對象和一個commit對象的文件夾（前兩位為文件夾名稱 -- 後38位為文本內容的哈希值）對應上圖的f6589b -- tree對象,4a2e3e -- tree對象,6b18a7 -- commit對象。之所以生成兩個tree對象是因為directory目錄為一個tree對象還有與commit對象一一對應的頂層tree對象。這個時候HEAD游標指向的是當前master分支的first commit。並且在這次提交的時候打個v1.0版本的標簽。
3、在與.git同級目錄下新建一個新的文本文件second.txt，內容為2。當執行$ git add second.txt 的時候就會在.git/objects/生成一個新的blob對象的文件夾（前兩位為文件夾名稱 -- 後38位為文本內容的哈希值）對應上圖的0cfbf0 -- blob對象。
4、當執行$ git commit -m "second commit" 的時候就會在.git/objects/下新生成了1個tree對象和一個commit對象的文件夾（前兩位為文件夾名稱 -- 後38位為文本內容的哈希值）對應上圖的35e40c -- tree對象,d6dca9 -- commit對象。只生成一個與commit對象一一對應的頂層tree對象。由於本次提交directory目錄下的first.txt內容沒有變化，所以上圖的35e40c -- tree對象還會指向f6589b -- tree對象。這個時候HEAD游標指向的是當前master分支的second commit(HEAD索引向前移動)，second commit 會指向上一次的提交即 parent指向first commit。
後續的操作以此類推，但需要注意的點是：
1、blob對象只對文件的內容有關，和文件名稱無關，如果不同的文件名稱，內容相同只會有一個blob對象，生成的新tree對象會指向該blob對象。例如上圖的third.txt和four.txt裡面的內容都為3。所以不會生成新的blob對象，新的tree對象只會指向同一個blob。
2、如果每次提交的時候包含的某些文件並沒有改動（更新），那麼就會直接指向它原來的索引，不會重新生成。例如上圖的directory/first.txt，second.txt
3、每次commit對象都會和頂層的tree對象一一對應。
⑶ Git底層數據結構和原理之三：存儲模型
git 區別與其他 vcs 系統的一個最主要原因之一是：git 對文件版本管理和其他 vcs 系統對文件版本的實現理念完成不一樣。這也就是 git 版本管理為什麼如此強大的最核心的地方。
SVN 等其他的 VCS 對文件版本的理念是以文件為水平維度，記錄每個文件在每個版本下的 delta 改變。
Git 對文件版本的管理理念卻是以每次提交為一次快照，提交時對所有文件做一次全量快照，然後存儲快照引用。
Git 在存儲層，如果文件數據沒有改變的文件，Git 只是存儲指向源文件的一個引用，並不會直接多次存儲文件，這一點可以在 pack 文件中看見。如下圖所示：
存儲隨著需求和功能的不斷復雜，git 版本的不斷更新，但是主要的存儲模型還是大致不變。如下圖所示：
⑷ git的文件系統與底層原理
由於工作中使用git作為版本管理，之前對git的了解不多，特別是底層方面的原理方面的知識。為了能更好的使用git，有必要學習並梳理下相關知識。
步入正題：
執行git init 初始化後，會在.git文件夾下會創建多個目錄，每個文件夾功能劃分的很清晰。
Git 是一套內容定址文件系統.通過鍵值對的方式存儲和查找。
下面操作一遍，直觀的看到整個過程，以便理解。
參考： https://git-scm.com/docs/git-hash-object
參考： http://man.linuxde.net/find
可以見到文件名稱為數字和字母組成的字元串。這個是根據文件內容和頭信息（Header），通過SHA-1演算法計算得出的40位十六進制校驗和。
SHA-1是一種加密哈希函數（cryptographic hash function）。SHA-1將文件中的內容通過其hash演算法生成一個160bit的報文摘要，即40個十六進制數字（每個十六進制數字佔4位）。它幾乎可以保證，如果兩個文件的SHA-1值是相同的，那麼它們確是完全相同的內容（類似於生活中的指紋識別）；SHA-1主要有兩種用途，一個是加密，一個是數據完整性校驗。Linux kernel開創者和Git的開發者——Linus說，Git使用了SHA-1並非是為了安全性，而是為了數據的完整性。理論上SHA-1會在2^51攻擊下實現哈希碰撞，所以也不是完全的安全。
參考： https://git-scm.com/docs/git-cat-file
模擬bolb對象存儲流程
以上，說明了git的數據存儲的基本方式。主要步驟：
下面是創建文件，修改文件，恢復文件的相關過程。
git會記錄每個版本的修改，根據校驗和可恢復到相應的版本。
小結： 這個過程中包括文件創建、文件修改、文件恢復，跟我們平時工作中使用的高級命令功能很相似。git會把整個過程轉化為底層操作，同時對用戶透明。
相關引用參考：
http://smilejay.com/2012/08/git-commit-sha-1/
https://git-scm.com/book/zh/v1/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1