一、概述
1. Git與SVN比較
目前用到最廣泛的版本控制軟件就是SVN和Git,那么這兩者之間有什么不同之處呢？
1) SVN（Subversion）是集中式管理的版本控制器，而Git是分布式管理的版本控制器！
2) SVN只有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這台服務器，取出最新的文件或者提交更新。
3) Git每一個終端都是一個倉庫，客戶端並不只提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。每一次的提取操作，實際上都是一次對代碼倉庫的完整備份。
4) Git具備強大的分支管理功能，SVN實際上不具備。
2. 為什么選擇Git
SVN的優點：
1) 管理方便，邏輯明確，符合一般人思維習慣。
2) 易於管理，集中式服務器更能保證安全性。
3) 代碼一致性高。
SVN的缺點：
1) 提交並非每次都能夠成功。如果有其他人先於你提交，會提示“改動基於過時的版本，先更新再提交”… 諸如此類；
2) 沖突解決是一個提交速度的競賽：手快者，先提交，平安無事；手慢者，后提交，可能遇到麻煩的沖突解決。
Git更適合分布式開發，離線工作，強調個體，任意兩個開發者之間可以很容易的解決沖突。最重要的是Git具備強大的分支管理功能，非常適合產品開發。
二、基本操作
1. 獲取幫助
通過git命令可以查看所有命令的介紹
2. 倉庫的克隆
git獲取倉庫的命令是clone而不是checkout，從這就可以看出Git和SVN的區別。
Git獲取的是整個庫的信息，可以查看所有日志信息。
3. 提交代碼
在文件夾下運行commit命令，將文件提交到本地版本庫。
由於本地倉庫只有你一個人在使用，所以請放心提交，不需要考慮BUG等因素。PUSH時就要小心了。
有些文件是不需要提交到版本管理的，比如 .vs 文件夾、bin、obj文件夾等，應該將其加入忽略列表中。
Git提交時要求輸入關於本次提交的說明，請認真填寫，這樣就不用維護額外的版本修改日志了。對於確實無關緊要的提交，可以團隊約定輸入一個字符，如“#”。
4. 同步倉庫
同步操作有兩種：
1、 PULL：將遠程服務器代碼同步到本地
2、 PUSH：將本地代碼同步到遠程服務器
具體的操作流程應該如下：
1、 commit的操作應該是頻繁進行的，和遠程庫無關；
2、 執行PULL操作獲取團隊最新代碼；
3、 本地確認編譯成功后PUSH到遠程庫，以便分享個人代碼。PUSH前應該確認個人版本是可以編譯通過的。
模擬一個操作場景：
1） A用戶早上PULL了最新版本，然后在此版本基礎上進行了一天的開發，下班時進行了PUSH操作，沒有發生任何問題；（應該先PULL再PUSH）
2） B用戶早上也PULL最新版本，開發了一天，此時B進行PUSH會報錯（本地庫版本和遠程庫不一致），必須先進行PULL獲得最新版本后才能進行PUSH。（PUSH前應保證版本可以編譯）
3） 如果兩個用戶修改了同一個文件，當B用戶在進行PULL時會進行合並，一般不會發生沖突。A用戶會在下次PULL時獲得合並后的版本。
4） 如果兩個用戶修改了同一個文件的兩個地方就會引起沖突。
5. 解決沖突
版本沖突在兩個用戶修改同一個文件的同一個位置時發生。修改同一個文件的不同的位置會自動合並，不會沖突。二進制文件沒有合並功能，任何同時修改都會沖突。
一個沖突解決的示例：
這是代碼的原始版本：
| static void Main(string[] args) { Console.WriteLine("Hello");
Console.ReadLine(); } |
A用戶修改后：
| static void Main(string[] args) { Console.WriteLine("Hello"); Console.WriteLine("Hello:I'm Good Boy!"); Console.ReadLine(); } |
B用戶修改后：
| static void Main(string[] args) { Console.WriteLine("Hello"); Console.WriteLine("Hello:I'm BAD Boy!"); Console.ReadLine(); } |
首先A用戶率先進行了commit 和 PUSH，成功。B用戶此時也准備提交，提交前，要進行一次PULL，此時發生沖突：自動合並失敗！
CONFLICT (content): Merge conflict in ConsoleApp1/ConsoleApp1/Program.cs
Automatic merge failed; fix conflicts and then commit the result.
打開沖突文件，可以看到：
| static void Main(string[] args) { Console.WriteLine("Hello"); <<<<<<< HEAD Console.WriteLine("Hello:I'm BAD Boy!"); ======= Console.WriteLine("Hello:I'm Good Boy!"); >>>>>>> 129dfb44dd2978700d82493d9fa966e598b85535 Console.ReadLine(); } } |
可以看到沖突內容包含在<<<<<<<與>>>>>>>之間，通過======隔開，前面是本地版本，后面是遠程版本。
處理辦法：直接修改這個文件，然后commit、PULL、PUSH即可。
還有一種沖突是版本庫刪除了一個文件，本地還進行了修改，這也形成沖突。
AA.txt deleted in 777b20bb5a04b3c3489318c5e7d6723d5d38d50f and modified in HEAD. Version HEAD of DOC/AA.txt left in tree.
處理辦法：先將沖突文件移開，commit后再PULL就可以成功，如果還需要這個文件，再重新commit即可。
三、進階操作
1. 版本標記
為了合並、回退等操作方便，我們會對重要版本進行標記。在log界面找到指定版本，右鍵選擇：“create tag at this version…”。
2. 恢復誤刪除的文件
如果文件（或文件夾）被誤刪除，並且已經清空回收站，可以從本地版本庫取得最新提交的文件，注意：只有提交過的版本才能恢復，沒有提交的內容是不可能找回的，所以要經常提交。
首先通過日志找到刪除之前的某個版本，在其文件上右鍵選擇“Revert to this version”即可，對於不想要的文件，如果想恢復到之前版本，也可以通過這個方法處理。
3. 獲取指定版本庫
可能近期寫的代碼一團糟，已經無法走上正軌了，希望恢復到某個穩定的版本重新開發，這就需要重置版本。首先在日志窗口找到要恢復的點，右鍵選擇：”reset XXX to this version…”
重置類型選擇“Hard”：
Hard表示強制恢復到指定版本，Mixed表示保留修改的文件。
如果在回退前沒有PUSH過版本，回退后需要PUSH的話直接PUSH就可以了，如果回退的版本早於最后一次PUSH的版本，則需要進行強制PUSH（Hard）。
需要說明的是，遠程版本回退應該是一個集體行為，不存在項目組某個人進行版本回退，但其他人繼續使用當前版本的情況，回退點之后的版本是要拋棄掉的。
四、分支管理
1. 分支管理概述
一般來說主線版本（master）是不會用來開發的，只用來進行版本發布，如果一個項目采用master單線版本進行開發，建議不要采用Git進行版本管理，采用SVN會更加方便一點。
下面介紹一下版本分支管理的主要流程與意圖：
某公司1號發布了產品版本V1.0，15號開發人員在開發V1.1過程中接到客戶反饋，發現重大BUG需要緊急修復，假設采用單分支開發，就必須在當前分支進行修復並發布，造成的問題是本次發布的版本包含未經驗證的V1.1版本的內容。
正確的做法應該是：master主分支發布V1.0版本后，創建分支V1.1進行下一個版本開發，當收到用戶BUG反饋時，創建V1.0_DEBUG分支進行修復，並發布。當V1.1版本開發完成並驗證通過后，將V1.1分支合並到master分支，同時合並V1.0_DEBUG分支修復的BUG。
版本合並后，繼續創建V1.2版本進行下一個版本開發。V1.1版本發現的BUG可以繼續在原來V1.1分支上進行修復，V1.0_DEBUG版本可以不用繼續維護了，之前發出的版本如果發現問題，可以在V1.1版本進行修改，並將客戶版本升級到V1.1 。
2. 創建分支
一般通過Git管理平台創建分支，並為分支設置權限，也可以在本地創建分支，然后Push到遠程服務器。如果要在某個時間點創建分支，在日志窗口找到指定的時間點，右鍵選擇“Create Branch at this version…”即可。本地創建分支后，需要切換到該分支並執行PUSH操作才能將分支同步到服務器。
3. 在某分支上進行開發
在固定的某個分支上進行開發，參照本文第二、第三部分的描述即可。本地克隆了版本庫之后，立即切換到開發分支，第一次切換時會在本地建立相同名稱的本地分支。
4. 分支的合並
通過Fetch命令獲取其他分支內容。Fetch命令把遠程服務器上所有版本同步到本地，但不做進一步操作。
通過Merge命令進行版本合並，合並時需要選擇對方分支的名稱。
5. Fetch與Pull的區別
Pull命令相當於 Fetch + Merge ，就是把遠程庫同步到本地並自動進行合並。如果要合並其他分支，Pull時需要選擇其他遠程分支的名稱。
采用PULL或Fetch + Merge沒有本質區別，唯一的區別就是在進行分支合並時Fetch后可以先觀察一些修改的內容在進行合並。建議在同一個分支工作時就采用Pull，在分支之間進行合並時，采用Fetch + Merge。
6. 分支沖突
合並版本后，對所有沖突進行手動修改，修改完成后Commit、PUSH即可。
需要注意幾點：
1、 永遠以master分支為發布分支；
2、 master會合並develop和fixbug版本，develop也會合並fixbug版本，不要有其他方向的合並；
3、 master版本合並其他版本后，通過新建分支的方式繼續開發，原來其他分支可以刪除掉。
4、 如果develop合並fixbug時有沖突，master在合並develop和fixbug時可能任然會沖突，如果develop版本已經合並了所有fixbug，那么master版本在合並develop后可以不用重復合並fixbug。
五、Git版本管理最佳實踐
以下是一個常見的版本管理的流程：
具體流程描述如下：
1） 首先建立版本庫，自動創建master版本，在master版本上持續開發，直到發布V1.0版本；
2） V1.0版本發布后同時面臨兩個任務：V1.1版本開發和V1.0版本的Bug修復。此時創建V1.1_develop分支和V1.0_bugfix兩個分支，相關的開發團隊應該立即Fetch庫后Switch到各自的庫上開展工作；
3） 新版本V1.1_develop研發完成並驗證后，合並到master庫，同時master庫合並V1.0_bugfix分支，經驗證后發布V1.1版本；
4） 刪除V1.1_develop和V1.0_bugfix分支；
5） 創建新分支，循環以上過程。
需要注意幾點：
1） 如果更嚴謹一些的話，應該還要具備測試分支，測試分支從develop分支創建，測試通過后合並到主分支。
2） 以上第三個過程的操作，可以更積極一點，master版本可以更頻繁地合並兩個版本以及時處理沖突，develop分支也可以積極合並fixbug分支，但fixbug分支不能合並其他分支。
3） 穩定版本發布后即可刪除所有臨時分支。