git是一個版本控制工具,就要先弄清楚什麼是版本git
那一個commit又包含哪些內容,好比有一個文件裏邊的內容是:算法
京口瓜洲一水間 鐘山只隔數重山 春風又到江南岸 明月什麼時候照我還
後來改爲了服務器
京口瓜洲一水間 鐘山只隔數重山 春風又過江南岸 明月什麼時候照我還
那此次改動就是一次commit工具
能夠理解爲一個commit裏邊存的就是一個差別,好比上例就能夠表示爲:fetch
-春風又到江南岸 +春風又過江南岸
這樣咱們就能夠清楚的知道某個版本作了什麼樣的修改,同時還能知道這個時候文件的所有內容是什麼樣的設計
爲了能準肯定位到某個版本,git給每一個commit一個獨一無二的ID,好比a823b1這樣的16進制數(能夠只用前幾位,只要惟一就行)版本控制
commit-ID的生成算法:使用當前版本的全部文件內容
和父commit-ID
算一個hash值code
若是恰好有另一我的也對源文件作了修改:對象
-春風又到江南岸 +春風又綠江南岸
那這時候就會有倆條版本線(分支)教程
┌──────過(a8) 到(c3) └──────綠(b2)
括號裏是commit-ID
git實現版本線的方法很巧妙:
HEAD=a8 | ┌──────過(a8) 到(c3) └──────綠(b2) | HEAD=b2
好比:
a8
a8
的commit,查到他的父commit-ID爲c3
這樣就能夠造成一條分支線
分支原理很重要幾乎全部神乎其技的git操做都是經過它實現的
這個時候倆條版本線是孤立的,若是隻是這樣簡單的各幹各的,那我們的教程也就《全劇終》了
惋惜原做者採納了綠
的建議,但也要對過
作記錄,這時候就該版本管理工具提供的更增強大的功能協做
出馬,咱們一塊兒爲同一個項目添磚添瓦,而後統一意見(分支合併)
合併後的整個版本變動過程就變成:
到 過 綠
git合併分支有倆種辦法:merge,rebase。在git使用中不用merge是能夠的,但rebase是必須技能,因此本教程只講解rebase,merge請參見其餘教程。
整個合併的步驟:
b2
所在的分支上操做(由於他是最終的修改)b2
的變動加到a8
後邊b2
的 父commit-ID 設置爲 a8
b2
算一個新的commit-ID 1e
1e
以下所示:
HEAD=a8 | 到(c3)──────過(a8)──────綠(1e) | HEAD=1e
在git中咱們通常會使用master分支做爲主分支(成熟的分支),日常咱們會在master分支上支出來一個新的不成熟分支進行開發,以便在遇到bug或者新需求時再基於master拉一個純淨的分支,這些分支都是存儲於本地庫中,除了本地庫還有遠程庫、遠程鏡像庫
就是咱們的git服務器,他其實和咱們的本地庫是如出一轍的存在,它和每一個人的工做目錄沒有任何區別,只是咱們把這臺機器做爲中心節點彙總咱們的改動。默認名字是origin。
git是一個離線版本控制系統,它設計了不少功能以支持離線工做。遠程鏡像庫顧名思義就是遠程庫的一個本地鏡像,咱們不能夠修改它,只能讓他更新。這樣全部讀取遠程庫就變成本地操做。
git fetch
更新遠程鏡像庫
git brannch
顯示全部分支,以remote打頭的都是遠程鏡像庫裏的分支(像上邊說的咱們沒法直接查看遠程庫中分支)
git不能更新庫。操做的對象只是分支和commit,咱們只是用本地分支合併遠程分支,也就是讓本地分支包含遠程分支的全部commit,也就達到了更新本地分支的效果(是否是和合並本地分支是同樣的道理)
具體操做:git rebase origin/master
將咱們的master分支更新到和遠程master同樣後就能夠推送commit到遠程庫
git push orgin master
將本地master分支推送到遠程庫(以及遠程鏡像庫)master分支
其餘的遠程分支其實和master分支是同樣的,只是咱們使用master做爲最成熟的代碼分支。若是怕電腦硬盤壞致使未推送到遠程master的代碼丟失,咱們就能夠push到遠程其餘分支保存咱們的分支。或者是幾我的公共開發同一個功能也須要一個遠程分支來彙總你們的工做進展
本文都是一些概念用於你們對git有一個整體的理解,具體操做還需查看pro git、git help或其餘教程。