3 配置TortoiseGit
3.1 生成公鑰
生成SSH安全密鑰，提供給GIT版本庫管理員以訪問Git 版本庫，點擊桌面上生成的圖標
然后執行執行“ssh-keygen”生成自己的公鑰：
一路回車即可完成操作，這么操作的話就是沒有給自己的私鑰設置密碼，也可以在執行過程中設置私鑰密碼的。
生成的公鑰和私鑰的目錄是：
看見沒，id_rsa就是私鑰，id_rsa.pub就是公鑰，將id_rsa.pub 復制一份，然后重命名，發送給GIT版本庫的管理員即可。
3.2 配置用戶（重要）
在桌面的空白處右鍵——TortoiseGit——setings：
選擇“Git”，然后在“Name”和“Email”中填入相關用戶信息即可：
3.3 配置msysgit
這一步就是為什么要安裝msysgit了，TortoiseGit是在它上運行的。完成了msysgit的配置我們就可以開始使用TortoiseGit進行clone、pull、create branch、push等操作了。
4 TortoiseGit的使用
本例中GIT版本庫相關信息如下：
GIT版本庫地址：“10.17.15.162”
操作GIT版本庫的用戶名：root
測試項目的名稱：project1
本地測試目錄：D：\git\test
4.1 克隆遠程的版本庫
例：服務器的project1倉庫clone到D:\git\test：
在test目錄上右鍵選擇“Git clone”：
然后URL輸入：root@10.17.15.162:project1.git，選擇“Web”，會自動生成存放倉庫的目錄： D:\git\test\project1；
最后“OK”開始clone（如果的你的私鑰設置了密碼還有下面的提示，輸入密碼即可）：
然后就看見了success的提示窗口：
這樣我們就完成了一次遠程倉庫的clone，因為我的遠程倉庫是新建的里面是空的，所以給了個警告說是我克隆了一個空倉庫，沒關系的。（看下你的D:\git\test\project1里面是不是有個.git的目錄？如果沒有就是隱藏了）
4.2 使用TortoiseGit本地建庫
選中某文件夾按右鍵,選擇Git Create repository here就可以創建庫了：
在出現的窗口中,不勾選選項,直接按OK：
在目錄中就會出現一個名為.git的隱藏文件夾,所有庫的相關內容都會存在這個文件夾中.以后不管這個項目添加多少個文件夾,整個庫只會有這一個管理文件夾,這和CVS和SVN有較大差異。
提示：這里所建的倉庫只是用說明Git的一個本地建庫的功能，與前面和后面的內容是相互獨立的，所以大家別誤解這一步到底是做什么的。
4.3 向倉庫中添加內容
這一步是在本機完成的，完全可以不需要網絡脫離服務器的。
4.1那一步我們clone了一個空的版本庫，現在為這個庫添加目錄和文件。
先給D:\git\test\project1創建三個目錄：
然后在tmp添加幾個文件：
這一步我們就需要把這些文件和目錄commit到本地的版本庫project1中生成版本快照，在D:\git\test\project1目錄的空白處右鍵選擇：Git commit->“master”
注意：我們目前只有一個分支所以只能commit到master分支，當我們創建了其他分支以后我們可以commit到別的分支。
然后把新建文件前面的鈎給打上，錄入相關操作說明點擊“OK”：
注意：這一步的操作只是commit了tmp目錄和它下面的那兩個文件，其他的兩個空目錄並沒有commit進來，要一起commit的話必須給那兩個目錄添加文件。
4.4 推到服務器
從遠程的clone到本地的commit，那么現在就可以把本地的版本庫push到服務器了。 在project1目錄的空白處右鍵——》“TortoiseGit”——》“Push”：
看下圖，可以選擇要Push的分支和要Push到服務器的哪個分支，這些都是根據實際的需要來定的，這里它會默認的推送到它clone的服務器（10.17.15.162）的project1倉庫的。 在Push時還會彈出輸入私鑰密碼的對話框，輸入即可：
提醒：master是Git默認的主要分支（主干）,適合單人獨自開發，若是多人開發強烈建議每人創建自己的分支。
推送成功！
看下log吧，右鍵選擇“Git show log“：
這個日志是隨時都能查看的，能看見版本號、提交的文件、時間、由誰提交的等信息。
14
4.5 更新版本庫
4.5.1 git pull
前一天服務器的版本庫經過若人的push以后現在是最新的了，那么今天的准備工作就是把最近的版本庫合並到本機，我們采用的是pull命令。
更新操作：在D:\git\test\project1目錄下，選中project1倉庫右鍵，然后選擇“TortoiseGit“——》”Pull“：
點擊“OK“就能把服務器的版本更新到本地的master分支，同步的結果是我發現倉庫里面多了一個文件夾和文件。然后新建一個分支在本分支開始今天工作。
4.5.2 git fetch
Git Pull能實現本機和服務器的同步，但是它不夠安全，還有一種更加安全的做法就是git fetch，我的做法是創建一個新的分支master/b_fetch，先把代碼fetch到master/b_fetch分支，然后比較master/b_fetch與master分支的區別（就是兩個版本庫的區別），最后進行merge操作。這樣具有安全性！分支的創建和比較差異后面介紹！
Git Pull=git Fetch+git merger
演示一下fetch吧！切換到b_fetch分支，然后右鍵選擇“TortoiseGit“——》”fetch“：
4.6 分支
Git分支簡介：
Git 的分支可謂是難以置信的輕量級，它的新建操作幾乎可以在瞬間完成，並且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統不同，Git 鼓勵在工作流程中頻繁使用分支與合並，哪怕一天之內進行許多次都沒有關系。
Git 中的分支實際上僅是一個包含所指對象校驗和（40 個字符長度 SHA-1 字串）的文件，所以創建和銷毀一個分支就變得非常廉價。說白了，新建一個分支就是向一個文件寫入 41 個字節（外加一個換行符）那么簡單，當然也就很快了。這和大多數版本控制系統形成了鮮明對比，它們管理分支大多采取備份所有項目文件到特定目錄的方式，所以根據項目文件數量和大小不同，可能花費的時間也會有相當大的差別，快則幾秒，慢則數分鍾。而 Git 的實現與項目復雜度無關，它永遠可以在幾毫秒的時間內完成分支的創建和切換。同時，
因為
每次提交時都記錄了祖先信息（譯注：即 parent 對象），所以以后要合並分支時，尋找恰當的合並基礎（譯注：即共同祖先）的工作其實已經完成了一大半，實現起來非常容易。Git 鼓勵開發者頻繁使用分支，正是因為有着這些特性
作保障。
4.6.1 創建分支
右鍵選擇“Git Create Branch“：
這里是我們創建的第一條分支，所以只能創建在master分支上面了。
4.6.2 分支切換
右鍵選擇“Git Branch“就能看見所有的分支，顯示的當前所在分支是master（注意前面的對勾），branch1是新建分支，這樣我們就能隨意的切換分支。
4.6.3 分支合並
在branch1上的開發完成以后我們需要合並到master分支，首先切回master分支，然后右鍵選擇“TortoiseGit“——》”merge“：
當前分支是master，所以得選擇branch1，就是把branch1合並到master分支上。
4.7 版本差異
4.7.1 兩個版本的差異
比如我現在想看一下我master分支和branch1這兩個版本的差異，該怎么看呢？
首先我們在“Git Show log”下看到所有的提交日志，然后按住shift用鼠標選擇最新的master分支和branch1分支，右鍵選擇“Compare revisions”就能看見這兩個版本的差異：
由上圖我們發現master分支相對branch1分支修改了br1.txt，增加了hoa.txt和repo文件夾以及repo下面的abcd.txt文件。
4.7.2 查看未提交的修改
當你修改了一些文件后，這時還沒有提交，你可能意識到自己的某些修改是錯誤的，那么你就想再次的審查一遍，那么怎么看你修改了哪些文件的哪些位置呢？
首先右鍵選擇“TortoiseGit”，然后選擇diff：
這時就能看見修改過的文件，如果想看修改的具體位置可以雙擊文件繼續查看詳細內容：
4.8 撤銷某次操作
revert 是撤銷某次操作，此次操作之前的commit都會被保留，比如我們發現自己修改的錯誤后就可以撤銷，右鍵選擇“TortoiseGit”，然后選擇“Revert”：
選中要撤銷的文件，點擊“OK”就能實現撤銷操作。
4.9 Git Resolve
這個命令主要是在解決沖突時才用的，具體用法看5.3中內容沖突的解決。
Git中很多命令都可能出現沖突，但從根本上來講，都是merge 和 patch（應用補丁）時產生沖突。而rebase就是重新設置基准，然后應用補丁的過程，所以也會沖突。一般產生沖突的類型有邏輯沖突、內容沖突、樹沖突。
團隊協作中沖突是不可避免的，應該盡最大努力的避免沖突發生，比如模塊的分工化，然后就是每個開發人員遵守一定的的規則，必要的溝通是解決沖突最有效最好的方法！
下面我們分別模擬三個沖突並解決。
5.1 邏輯沖突
什么事邏輯沖突？Git自動處理（合並、應用補丁）成功，但是邏輯上是有問題的。比如另外一個人修改了文件名，但我還使用老的文件名，這種情況下自動處理是能成功的，但實際上是有問題的。又比如，函數返回值含義變化，但我還使用老的含義，這種情況自動處理成功，但可能隱藏着重大BUG。我們做個實際的模擬：
一個同事在沒有告訴我的情況下把我們共同使用的一個文件xxzr_hr_emp.txt修改成xxzr_hr_emp_v1.txt，那么他已經把xxzr_hr_emp_v1.txt新文件commit到服務器了，而我依舊使用xxzr_hr_emp.txt文件名，那么在我工作完commit時會發生什么呢？
在我commit時就報錯了，說是提交失敗，這時失敗的原因就是沖突導致的，看來解決的辦法在服務器是不行了，只能在本機了，這時我就需要做一次Pull操作，把遠程庫拉下來，合並完解決沖突后再commit上去。
拉到本機：
這樣邏輯沖突自己解決了，他會把我以前的xxzr_hr_emp.txt文件名更新為xxzr_hr_emp_v1,然后這是我就可以正常的commit了。
5.2 樹沖突
文件名修改造成的沖突，稱為樹沖突。
比如，a用戶把文件改名為a.c，b用戶把同一個文件改名為b.c，那么b將這兩個commit合並時，會產生沖突。模擬一下吧：
開始我和另一個同事的版本庫是一樣的我們都有一個xxzr_hr_v1.pck的文件，但是我們兩個沒有互相溝通都是把這個文件名給改了，我改成xxzr_hr_area_person.pck,他改成xxzr_hr_tmp_v1.pck，我一個一個人改了以后是可以正常push的，那么在我完成后他再push毫無疑問他push時遇到麻煩了，遇到的錯誤和邏輯錯誤的報錯是一樣的，這時看一下該怎么解決：
首先和前面一樣的他做一次Pull操作，此時沒有顯示任何的異常：
但是到他的工作目錄一看，就不一樣了：
他就發現他重命名的文件名上多了一個嘆號，又在該目錄下面多了一個新文件，這樣的原因在於兩人同時修改了同意文件名，這時他發現了錯誤的原因，就找到我和我溝通到底該用誰的文件名，最終我們通過溝通決定使用我的xxze_hr_area_personp.pck文件名（我們的需求是關於地域人員分布的統計），把他的那個有嘆號的文件直接刪除再做一次提交就好了。 要是我們在修改文件名時做一次溝通是不是沖突直接就避免了？所以說團隊協 作中溝通真的很重要！
5.3 內容沖突
內容沖突時最常見的，也是一種不可避免的沖突現象。兩個用戶修改了同一個文件的同一塊區域，git會報告內容沖突。
模擬並解決：
我和另一同事對同一文件的同一塊做了修改，那么他提交完畢我提交時就會產生沖突，我們修改的文件是xxzr_hr_area_person.pck，先看一下報的錯誤吧：
看見錯誤沒提示我要執行一次pull操作，那么我就執行以下看看結果是什么：
提示了沖突在repo/xxzr_hr_area_person.pck文件這，解決了沖突再commit結果。
發現xxzr_hr_area_person.pck文件上面有個黃色的嘆號，這就表示文件有沖突，現在開始解決沖突，選中xxzr_hr_area_person.pck文件右鍵選擇“TortoiseGit”，然后選擇“Resolve”開始解決沖突：
這是雙擊一下那個xxzr_hr_area_person.pck文件會看到詳細的改動情況：
左上部分是別人改動的結果，右上部分是我改動的，下面是需要我手工做的最終的合並情況，這里就是我要把改動的結果寫到帶有紅色問號那行就行了，合並完成后保存退出，然后先提交到本機再push操作，這樣內容沖突的解決完畢。
提示：如果這個文件是大家共同的，那么請千萬記住當你每次有一個小的改動時，立即push到服務器，這樣的話沖突解決起來也簡單，快捷。
6 Git分支管理策略
相比同類軟件，Git有很多優點。其中很顯著的一點，就是版本的分支（branch）和合並（merge）十分方便。有些傳統的版本管理軟件，分支操作實際上會生成一份現有代碼的物理拷貝，而Git只生成一個指向當前版本（又稱”快照”）的指針，因此非常快捷易用。
但是，太方便了也會產生副作用。如果你不加注意，很可能會留下一個枝節蔓生、四處開放的版本庫，到處都是分支，完全看不出主干發展的脈絡。 提出了一個分支管理的，它可以使得版本庫的演進保持簡潔，主干清晰，各個分支各司其職、井井有條。理論上，這些策略對所有的版本管理系統都適用，Git只是用來舉例而已。
6.1 Master分支（主分支）
首先，代碼庫應該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發布。Git主分支的名字，默認叫做Master。它是自動建立的，版本庫初始化以后，默認就是在主分支在進行開發。我們可以給主分支上的每個版本庫打上tag，為了更好的管理。
6.2開發分支Develop
主分支只用來分布重大版本，日常開發應該在另一條分支上完成。我們把開發用的分支，叫做Develop。
如果想正式對外發布，就在Master分支上，對Develop分支進行”合並”（merge）。
6.3 臨時性分支
前面講到版本庫的兩條主要分支：Master和Develop。前者用於正式發布，
后者用於日常開
發。其實，常設分支只需要這兩條就夠了，不需要其他了。但是，除了常設分支以外，還有一些臨時性分支，用於應對一些特定目的的版本開發。臨時性分支主要有三種： * 功能（feature）分支
* 預發布（release）分支
* 修補bug（fixbug）分支
這三種分支都屬於臨時性需要，使用完以后，應該刪除，使得代碼庫的常設分支始終只有Master和Develop。
功能分支
第一種是功能分支，它是為了開發某種特定功能，從Develop分支上面分出來的。開發完成后，要再並入Develop。
預發布分支
第二種是預發布分支，它是指發布正式版本之前（即合並到Master分支之前），我們可能需要有一個預發布的版本進行測試。
預發布分支是從Develop分支上面分出來的，預發布結束以后，必須合並進Develop和Master分支。它的命名，可以采用release-*的形式。
修補Bug分支
最后一種是修補bug分支。軟件正式發布以后，難免會出現bug。這時就需要創建一個分支，進行bug修補。修補bug分支是從Master分支上面分出來的。修補結束以后，再合並進Master和Develop分支。它的命名，可以采用fixbug-*的形式。
合並完成以后的修補Bug分支要刪除的。
