1．初始化Git倉庫 　　Git倉庫分為兩種類型：一種是存放在服務器上面的裸倉庫，里面沒有保存文件，只是存放.git的內容；一種是標準倉庫，會在項目根目錄下創建一個.git目錄。 　　 $ git init # 創建標準倉庫，在項目根目錄下創建一個隱藏的.git 文件夾 　　 $ git init –bare # 創建一個裸倉庫，裸倉庫只有.git目錄內容， 而沒有工作區域，一般用于在共享服務器上面創建。 2．查看當前Git配置 　　Git配置信息分成三個級別，分別存放在三個不同的地方。 　　一個是系統級別的配置文件，系統基本配置文件存放在Git的安裝目錄中。 　　一個是用戶級別配置文件，用戶級別配置文件存放在當前用戶目錄下的.gitconfig文件內。 　　一個是項目級別配置文件，項目級別的配置文件會存放在.git目錄的config文件中。使用git config –list顯示的Git配置信息，是從系統級配置?用戶級配置?項目級配置一層層疊加顯示出來的，當遇到同項不同內容時以低級的配置為準，如圖1至圖3所示。 　　$ git config –list # 顯示當前Git配置信息 　　$ git config –system –list # 顯示系統級別Git配置信息 　　$ cat .git/config # 顯示項目配置文件 　　$ cat ~/.gitconfig # 顯示用戶級別配置信息  圖1  圖2  圖3 3．配置當前用戶名和郵箱 　　前面我們說過，用Git進行版本控制與集中式版本控制不同，集中版本控制需要驗證用戶信息后才能提交代碼，這樣可以識別出誰提交了代碼；而分布式版本控制的所有文件都保存在本地磁盤中，當提交代碼的時候，需要配置一個用戶信息才能被Git執行，在團體合作開發的時候用于識別文件是誰提交的，但這個識別并沒有驗證用戶的真偽，如圖4所示。  圖4 　　$ git config –global user.name “用戶名” # 在用戶級配置上設置用戶名 　　$ git config –global user.email “用戶郵箱” # 在用戶級配置上設置郵箱 　　如圖5所示。  圖5 　　注意：在用戶級別配置上設置用戶名和郵箱信息，應避免如下情形，假設開發用的電腦為多人使用，并且有一個用戶忘記給項目設置用戶信息，這時Git會把用戶信息默認設置為系統級別的信息，而不給出任何提示。 4．克隆倉庫 　　克隆倉庫是從遠程服務器上拉取一個完整的倉庫到本地磁盤，這樣做的好處在于每個人都有一個完整的代碼庫，避免把雞蛋放在同一個籃子里。但相對的，每個人都有一個完整倉庫，對代碼的防泄露又是一個問題。 　　$ git clone # 從一個遠程Git倉庫中克隆到本地磁盤 　　注意：Git支持URL傳輸協議：本地協議（Local）、HTTP 協議、SSH（Secure Shell）協議、FTP協議、Git 協議。 （1）本地協議。 　　本地協議（Local protocol），使用的是File Protocol（本地文件傳輸協議），主要用于訪問本地計算機中的文件，使用file://<文件路徑>訪問。所以遠程版本庫就是硬盤內的另一個目錄。 　　優點： 　　基于文件系統的版本庫的優點是簡單，并且直接使用了現有的文件權限和網絡訪問權限。 如果你的團隊已經有共享文件系統，那么建立版本庫會十分容易。只需像設置其他共享目錄一樣，把一個裸版本庫的副本放到大家都可以訪問的路徑，并設置好讀/寫權限就可以了。這也是快速從別人的工作目錄中拉取更新的方法。如果你和別人一起合作一個項目，他想讓你從版本庫中拉取更新時，運行類似git pull /home/john/project的命令比推送到服務再取回要簡單得多。 　　缺點： 　　這種方法的缺點是，通常共享文件系統比較難配置，并且不方便從多個位置訪問。如果你想從家里推送內容，則必須先掛載一個遠程磁盤，與網絡連接的訪問方式相比，配置不方便，速度也慢。值得一提的是，如果你使用的是類似于共享掛載的文件系統，那么這個方法也不一定是最快的。訪問本地版本庫的速度與訪問數據的速度是一樣的。在同一個服務器上，如果允許Git訪問本地硬盤，則一般來說，通過NFS訪問版本庫的速度要慢于通過SSH訪問。 　　這個協議并不能使倉庫避免意外的損壞。每一個用戶都有“遠程”目錄的完整shell權限，我們無法阻止他們修改或刪除Git內部文件或損壞倉庫。 （2）HTTP協議。 　　Git通過HTTP通信有兩種模式。在Git 1.6.6版本之前只有一個方式可用，十分簡單并且通常是只讀模式的。Git 1.6.6版本引入了一種新的更智能的協議，讓Git可以像通過SSH那樣智能地協商和傳輸數據。之后幾年，這個新的HTTP協議因為其簡單、智能變得十分流行。新版本的HTTP協議一般被稱為“智能”HTTP協議，舊版本的一般被稱為“啞”HTTP協議。我們先了解一下“智能”HTTP協議。 　　智能（Smart）HTTP協議。 　　智能HTTP協議的運行方式和SSH協議及Git協議類似，只是運行在標準的HTTP/S端口上，并且可以使用各種HTTP驗證機制，這意味著使用起來要比SSH協議簡單得多。比如可以使用HTTP協議的用戶名／密碼的基礎授權，免去設置SSH公鑰。 　　智能HTTP協議或許已經是最流行的使用Git的方式了，它既支持像git://協議一樣設置匿名服務，也可以像SSH協議一樣提供傳輸時的授權和加密。而且只用一個URL就可以做到，不必為不同的需求設置不同的URL。如果你要推送到一個需要授權的服務器上（一般來講都需要），那么服務器會提示你輸入用戶名和密碼。從服務器獲取數據時也是如此。 　　啞（Dumb）HTTP協議。 　　如果服務器沒有提供智能HTTP協議的服務，則Git客戶端會嘗試使用更簡單的啞HTTP協議。在啞HTTP協議里，Web服務器僅把裸版本庫當作普通文件來對待，提供文件服務。啞HTTP協議的優美之處在于設置起來簡單。基本只需把一個裸版本庫放在HTTP根目錄上，設置一個叫作post-update的掛鉤就可以了。此時，只要能訪問Web服務器上你的版本庫，就可以克隆你的版本庫。下面是設置從HTTP訪問版本庫的方法。 　　$ cd /var/www/htdocs/ 　　$ git clone –bare /path/to/git_project gitproject.git 　　$ cd gitproject.git 　　$ mv hooks/post-update.sample hooks/post-update # 將示例腳本重命名，需要去 掉.sample腳本才能被識別運行 　　$ chmod a+x hooks/post-update 　　這樣就可以了。Git自帶的post-update掛鉤會默認執行合適的命令（git update-server-info），來確保通過HTTP的獲取和克隆操作正常工作。這條命令會在你通過SSH向版本庫推送之后被執行，然后別人就可以通過類似下面的命令來克隆了： 　　$ git clone https://example.com/gitproject.git 　　這里我們使用了Apache里設置時常用的路徑 /var/www/htdocs，不過你可以使用任何靜態Web服務器——只需把裸版本庫放到正確的目錄下即可。Git的數據是以基本的靜態文件形式提供的。通常會在可以提供讀／寫的智能HTTP服務和簡單的只讀的啞HTTP服務之間選一個。極少會將二者混合起來提供服務。 　　優點： 　　我們將只關注智能HTTP協議的優點。 　　不同的訪問方式只需一個URL，且服務器只需在授權時提示輸入授權信息，這兩個簡便性讓終端用戶使用Git變得非常簡單。相比SSH協議，可以使用用戶名／密碼授權是一個很大的優勢，這樣用戶就不必在使用Git之前先在本地生成SSH密鑰對再把公鑰上傳到服務器。對非資深的使用者，或者系統上缺少SSH相關程序的使用者而言，HTTP協議的可用性是主要的優勢。與SSH協議類似，HTTP協議也非常快速和高效。 　　你也可以在HTTPS協議上提供只讀版本庫的服務，這樣你在傳輸數據的時候就可以加密數據；或者，你甚至可以讓客戶端使用指定的SSL證書。 　　另一個好處是HTTPS協議被廣泛使用，一般的企業防火墻都允許這些端口的數據通過。 　　缺點： 　　在一些服務器上，架設HTTPS協議的服務端會比架設SSH協議的服務端棘手一些。除了這一點，用其他協議提供Git服務與智能HTTP協議相比就幾乎沒有優勢了。 　　如果你在HTTP上使用需授權的推送，那么管理憑證會比使用SSH密鑰認證麻煩一些。然而，你可以使用憑證存儲工具，比如OSX的Keychain或者Windows的憑證管理器。 （3）SSH協議。 　　架設Git服務器時常用SSH協議作為傳輸協議。因為大多數環境下已經支持通過SSH訪問——即使沒有也比較容易架設。SSH協議是一個驗證授權的網絡協議，并且，因為其普遍性，架設和使用都很容易。 　　通過SSH協議克隆版本庫，你可以指定一個ssh://的URL： 　　$ git clone ssh://user@server/project.git 　　或者使用一個簡短的scp式的寫法： 　　$ git clone user@server:project.git 　　也可以不指定用戶，Git會使用當前登錄的用戶名。 　　優點： 　　用SSH協議的優勢很多。首先，SSH架設相對簡單——SSH守護進程很常見，多數管理員都有使用經驗，并且多數操作系統都包含了它及相關的管理工具。其次，通過SSH訪問是安全的——所有傳輸數據都要經過授權和加密。最后，與HTTP/S協議、Git協議及本地協議一樣，SSH協議很高效，在傳輸前也會盡量壓縮數據。 　　缺點： 　　SSH協議的缺點在于你不能通過它實現匿名訪問。即便只是讀取數據，使用者也要有通過SSH訪問你的主機的權限，這使得SSH協議不利于開源的項目。如果只在公司網絡使用，那么SSH協議可能是你唯一要用到的協議。如果要同時提供匿名只讀訪問和SSH協議，那么除了為自己推送架設SSH服務外，還要架設一個可以讓其他人訪問的服務。 （4）Git協議。 　　接下來是Git協議。這是包含在Git里的一個特殊的守護進程；它監聽在一個特定的端口（9418），類似于SSH服務，但是訪問無須任何授權。要想讓版本庫支持Git協議，則需要先創建一個git-daemon-export-ok文件——它是Git協議守護進程為這個版本庫提供服務的必要條件——但是除此之外，沒有任何安全措施。要么誰都可以克隆這個版本庫，要么誰都不能。這意味著，通常不能通過Git協議推送。由于沒有授權機制，一旦你開放推送操作，就意味著網絡上知道這個項目URL的人都可以向項目推送數據。不用說，極少會有人這么做。 　　優點： 　　目前，Git協議是Git使用的網絡傳輸協議里速度最快的。如果你的項目有很大的訪問量，或者你的項目很龐大并且不需要為寫進行用戶授權，那么架設Git守護進程來提供服務是不錯的選擇。它使用與SSH相同的數據傳輸機制，但是省去了加密和授權的開銷。 　　缺點： 　　Git協議的缺點是缺乏授權機制。把Git協議作為訪問項目版本庫的唯一手段是不可取的。一般的做法是，同時提供SSH或者HTTPS協議的訪問服務，只讓少數幾個開發者有推送（寫）權限，其他人通過git://訪問只有讀權限。Git協議許也是最難架設的。它要求有自己的守護進程，這就要配置xinetd或者其他程序，這些工作并不簡單。它還要求防火墻開放9418端口，但是企業防火墻一般不會開放這個非標準端口。而大型的企業防火墻通常會封鎖這個端口。 　　說明：clone和checkout的區別如下。 　　git clone命令是將版本庫完整克隆到本地新目錄中，在創建好本地庫后會自動檢出當前活動分支或初始化分支。 　　git checkout命令是創建分支或切換分支，使用該命令后會自動更新HEAD文件，將其改寫成當前分支。 5．查看文件狀態 　　使用git status可以查看當前工作區域內文件的狀態，沒被跟蹤內容會在Untracked files中顯示，可以通過git add 添加被跟蹤，如圖6所示。 　　$ git status  圖6 6．添加文件追蹤 　　使用git add 命令將文件添加到index（索引）文件中，這些文件列表將在下一次提交時記錄到倉庫，如圖7所示。 　　$ git add app/ # 將app目錄添加到index文件中 ! 圖7 7．提交代碼 　　使用git commit命令將index文件中的更改記錄提交到本地版本庫。使用參數-m可以直接將要添加的備注信息寫入，如圖8所示。 　　$ git commit -m “add app folder” # 提交到版本庫，并寫入提交信息 [](images/screenshot_1511234282065.png) 圖8 8．查看遠程倉庫 　　使用git remote命令可以顯示當前版本庫的遠程倉庫服務器信息。參數-v顯示遠程倉庫簡寫名稱和URL地址，如圖9所示。 　　$ git remote -v # 顯示版本庫連接的遠程倉庫和URL  圖9 9．添加遠程倉庫 　　使用git remote add <遠程倉庫別名> 為本地版本庫添加一個遠程倉庫，如圖10所示。 　　$ git remote add origin https://github.com/lanmaokafei/python_fullstack.git # 添加一個遠程倉庫  圖10 10．推送代碼 　　使用git push <遠程倉庫別名> <本地分支>將本地版本庫推送到遠程倉庫，如圖11所示。 　　$ git push origin master # 將本地master分支提交到別名為origin的遠程倉庫  圖11 11．從遠程倉庫更新代碼到本地 　　將代碼推送到遠程倉庫后，其他非最新版本的用戶需要更新最新代碼，可以使用git fetch或git pull命令來更新。區別在于fetch獲取最新的代碼到本地倉庫，但不會自動合并分支，需要比較分支差異后合并，而pull則直接將遠程倉庫的版本合并到本地master上，所以git fetch相對安全些，如圖12和圖13所示。 　　$ git fetch origin master # 下載origin最新的代碼  圖12 　　$ git merge origin/master # 將origin/master分支合并到本地master中  圖13 12．版本標記 　　很多書或網上會把版本標記翻譯成里程碑，即給當前提交定義一個標簽，標記出當前提交內容有別于其他提交。例如，在開發完一個新功能后，可以將其標記一個v1.1，代表這個功能開發完成，方便以后歷史中定位這次提交。 　　Git有兩種標簽類型：一種是lightweight輕量級標簽，只有版本號無其他信息；另一種是annotated附注標簽，標簽附帶一條信息，可以讓別人快速識別標簽作用，建議使用這種標簽。 　　使用git tag -n[數字] 顯示當前分支下的標簽信息，參數-n代表顯示備注信息行數，如圖14所示。  圖14 　　使用git tag -a <版本號> -m“備注”為最新提交打上標簽，如圖15所示。  圖15 　　使用git show <版本號>顯示對應標簽的版本信息和提交差異，如圖16所示。  圖16 13．添加忽略文件 　　在當前項目根目錄下創建一個.gitignore文件，用于保存忽略列表，如圖17所示。  圖17 　　配置語法如下： 　　“/”代表目錄； 　　“*”代表通配任意字符； 　　“？”代表通配單個字符； 　　“[]”代表單個字符的匹配列表； 　　“！”表示不忽略，一定要跟蹤。 14．查看當前處在的分支 　　使用命令 git branch可以查看當前工作目錄所在的分支 15．創建分支 　　在家里開發使用的是PostgreSQL數據庫，到公司后沒有在線的數據就切換到SQLite，這樣我們就創建一個新的分支以便在公司開發。使用命令git checkout -b jsb創建并切換到jsb分支，命令git checkout -b等同于同時執行了命令git branch jsb 創建分支和命令git checkout jsb切換到jsb分支 16．合并分支 　　當回到家時再把在公司開發的代碼和家里的版本庫合并分支，切換回master分支，使用命令git merge合并兩個分支，如圖20所示。  圖20 17．解決沖突 　　之前使用了不同的忽略語句，兩個分支間沒有沖突，但是如果兩個分支同時修改了同一個文件相同位置的不同參數時，在合并的時候就會產生沖突 　　在master版本中，SQLALCHEMY_DATABASE_URI 是連接PostgreSQL的數據連接’postgresql://xyj:lanmaokafei@192.168.1.137/postgres’。 　　在jsb版本中，SQLALCHEMY_DATABASE_URI是指向SQLite的數據文件 ‘sqlite:///./db/ data.db’ 。 　　當這兩個分支合并的時候就會產生沖突，需要人工修改才能合并 　　說明：人工修改沖突部分，需要將自動生成的<<<<<<< HEAD、=======、>>>>>>> jsb全部刪除，自行判斷沖突部分需要保留什么內容或者將兩者融合，修改完成后保存文件，重新使用命令git add添加文件，后再提交一次，即可解決沖突問題。