一、概述
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） 穩定版本發布后即可洗掉所有臨時分支，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/4067.html
標籤：其他
上一篇：sonar安裝和使用