一. 關於Git
什麼是版本？軟件時不時彈出讓你更新到幾點幾點幾的提示，那幾點幾點幾就是一個個的版本，也就是不同的內容就是不同的版本；什麼是版本控制？就是對各種版本無論修改前還是修改後的管理；什麼是集中式版本控制？就是對於版本的管理控制集中於一箇中央服務器，每次要改動版本都需要將版本從服務器那裏拿過來，完事後在傳送過去，也就是說必須聯網；什麼是分佈式版本控制？就是對於版本的控制管理可以自給自足，也可以相互之間進行傳遞，因爲本身自己就是一個管理庫；
Git就是一個分佈式版本控制系統，由Linux開源創始人Linus編寫而成，起初是爲了保管Linux源代碼用C語言編寫而成的，但是由於其免費方便強大等優勢迅速成爲了各業界技術愛好者託管源代碼的一個很棒的平臺，而GitHub是免費爲開源項目提供Git存儲的一個網站，用戶註冊一個賬號就能將本地的Git交給遠程GitHub倉庫來保存了，只要有網，隨時隨地可以從遠程端獲取或者推送自己的文件數據，這樣就更加凸顯了安全高效的優勢。
二. Git管理過程
首先要說明的是，Git既然是一個版本控制系統，那麼其管理的就不單單是一個個的文件那麼簡單了，Git跟蹤並管理的是修改，也就是對於一個文件的增刪查改，Git都能夠給記錄下來，並且還方便恢復，這樣一來就不會有將一個文件改的面目全非而不知道誰是誰的問題了。
增
對於用戶可見的一個目錄也就是一個倉庫而言，就是用戶的工作區；Git版本庫裏本身維護了一個暫存區stage(或者叫index)，而用戶在工作區編輯好文件想要提交給Git管理需要進行兩步，首先要先將想要提交的文件交給Git，稱爲添加，終端下使用git add命令，這個步驟就是將文件從工作區拷貝添加進暫存區，之後再進行提交，git commit命令，而提交纔是將文件從暫存區放到Git分支中（分支的概念下面會討論）；
爲什麼要分爲兩步？就不能一次放好麼？這是因爲有可能一次要git add很多文件到暫存區，而提交命令git commit則是一次性將add到暫存區的文件都放到分支中；這就好比要將散落在各處的物件放到收納箱中，一次性將要收納的物件都收集拿到再放入收納箱，顯然要比一個一個地拿起再放進收納箱要簡便高效些；
既然GitHub提供了遠程庫來進行Git存儲，那麼也就同樣可以將本地的文件推送至遠程庫，當然，在這之前首先需要將自身的本地Git和遠程庫也就是用戶的GitHub關聯起來，由於GitHub使用SSH協議Secure Shell，也就是安全外殼協議，它是建立在應用層和運輸層基礎上的安全協議，專爲遠程登錄會話和其他網絡服務提供安全性的協議，可有效防止遠程管理過程中的信息泄漏問題。因此需要將一個SSH密鑰交給GitHub中的SSH配置，這樣就可以進行遠程庫和本地的一個交互了。
刪
對於文件的刪除，在工作區直接使用rm命令就可以將一個文件刪除，但這時候工作區就和Git版本庫不一樣了，如果確實想要刪除這個文件，可以使用Git命令git rm filename來進行版本庫裏對應文件的刪除，但這時候還是需要再進行一次提交以確保工作區和版本庫的一致；而如果是不小心在工作區誤刪了文件，只要這個文件被提交到Git分支管理過，使用git checkout —— filename命令仍然是可以從版本庫中恢復到工作區的，git checkout —— filename命令其實是用版本庫裏的版本替換工作區的版本；
查
這裏不得不再次說明，Git作爲一個分佈式版本控制系統，用戶的每一次增刪查改都會產生不同的版本也就是都會被管理記錄；因此，這裏的查詢可以被看做是查詢每一次的改動或者查詢每一次不同的版本，使用git log命令就可以查看由近到遠每一次提交的情況，而這個查看，主要是在當前分支的日誌情況；
對於Git來說可以關聯遠端的GitHub遠程庫來交由其管理本地的文件，同樣，當本地文件數據丟失或者需要他人協作完成某項作業的時候，可以從GitHub的遠程庫中將所需要的文件給clone到本地，完成後再同步推送至遠端管理；着同樣也可以看做是一種查詢機制；因爲Git本身就是具有開源精神的平臺，任何人都可以上傳數據同樣也可以被任何人看到或者拿到；
改
如果用戶對當前版本並不滿意，還是覺得上一個版本比較好，想要改回原來的版本怎麼辦呢？
如果只是在當前工作區做了修改但還沒有提交，可以使用git check —— filename命令，該命令上面提到過，其實也就是將工作區的修改全部撤銷，如果添加到暫存區後又做了修改，該命令可以恢復到添加到暫存區後的狀態；
如果已經將文件git add添加到了暫存區但是還沒有提交到分支，可以使用git reset HEAD filename來將暫存區的修改會退到工作區，然後再使用上述命令；
如果已經將文件添加並且提交到了本地分支版本庫管理，就可以使用版本回退git reset ——hard 版本號 來使版本回退到上一次的版本，不過前提是沒有提交到遠程庫；
如果提交併且同步到了遠程庫，那就沒辦法了，GitHub已經都給保存下來了；
既然Git管理了一系列改動的各種版本，並且上面說到可以使用查看日誌來查詢到以往所有的改動，那麼就可以使用git reset命令來進行版本回退，而回退之後還想要在恢復會退前的版本，同樣也是支持的，這是因爲Git內部有一個指向當前版本的HEAD指針，在當前分支上修改的所有版本可以看做都按照先後順序排列在了一條分支上，而HEAD指針就指向的是一個個版本，當進行版本改動的時候，其實僅僅是移動了HEAD指針；而使用git log來查詢日誌的時候，其實就是從HEAD指向的版本開始羅列；那麼既然是這樣，想要恢復到哪一個版本，其實只要知道每個版本的版本號就可以了；
Git分支
分支是Git中一個強大的地方，當創建出一個倉庫的時候，默認是有一個master，可以被稱爲主幹，每一次的版本提交其實就是將各種版本依次沿着這條master主幹排放，分支的作用是什麼呢？如果你想修改文件的某一小塊內容，但是又擔心其不合適只是想試試水怕影響文件主體內容，這樣的話就可以創建一個分支出來，剛創建的分支和主幹一毛一樣，只是在分支上的修改提交並不會影響主幹，如果覺得修改內容合適，可以將當前分支和主幹進行合併，如果真的是不合適完全可以刪除分支而一點也不影響主幹；這種模式完全可以勝任多人合作或者多模塊多任務的作業，也就是可以創建多個分支在分支上完成某一模塊的任務，完成之後就可以合併成一個，這樣的話不僅提高了效率還具有安全性；
其實每一次提交的版本，不僅有一個HEAD指針，還有一個master指針，而master指針是纔是主幹上指向當前版本的指針，HEAD指針是指向master的，每一次新添一個版本，master指針就會往前移動一個，同樣的HEAD指針也會跟着移動；當創建出一個分支比如dev，其實也就會有一個dev的指針和master一樣，隨着分支中版本的添加和更改移動，而HEAD指向哪個分支的指針，就表示當前在哪個分支和版本上；
對於分支的合併，其實是使用了快速合併的方法，也就是直接將master指針指向dev的當前版本就OK了，至於切換到哪個分支，每次的添加提交就在那個分支上，後來在合併就成了一條主幹了，至於HEAD永遠都是指向當前工作分支的當前版本。
如上操作具體命令請參照http://2627lounuo.blog.51cto.com/10696599/1790022
如有不妥當的地方，請多指教。
《完》