Git基本使用指南

時間 2020-05-22

標籤 git 基本使用指南欄目 Git 简体版

原文原文鏈接

1、概述git

1. Git與SVN比較

目前用到最普遍的版本控制軟件就是SVN和Git,那麼這二者之間有什麼不一樣之處呢？安全

1) SVN（Subversion）是集中式管理的版本控制器，而Git是分佈式管理的版本控制器！服務器

2) SVN只有一個單一的集中管理的服務器，保存全部文件的修訂版本，而協同工做的人們都經過客戶端連到這臺服務器，取出最新的文件或者提交更新。併發

3) Git每個終端都是一個倉庫，客戶端並不僅提取最新版本的文件快照，而是把原始的代碼倉庫完整地鏡像下來。每一次的提取操做，實際上都是一次對代碼倉庫的完整備份。分佈式

4) Git具有強大的分支管理功能，SVN實際上不具有。測試

2. 爲何選擇Git

SVN的優勢：this

1) 管理方便，邏輯明確，符合通常人思惟習慣。spa

2) 易於管理，集中式服務器更能保證安全性。3d

3) 代碼一致性高。版本控制

SVN的缺點：

1) 提交併不是每次都可以成功。若是有其餘人先於你提交，會提示「改動基於過期的版本，先更新再提交」… 諸如此類；

2) 衝突解決是一個提交速度的競賽：手快者，先提交，平安無事；手慢者，後提交，可能遇到麻煩的衝突解決。

Git更適合分佈式開發，離線工做，強調個體，任意兩個開發者之間能夠很容易的解決衝突。最重要的是Git具有強大的分支管理功能，很是適合產品開發。

2、基本操做

1. 獲取幫助

經過git命令能夠查看全部命令的介紹

2. 倉庫的克隆

git獲取倉庫的命令是clone而不是checkout，從這就能夠看出Git和SVN的區別。

Git獲取的是整個庫的信息，能夠查看全部日誌信息。

3. 提交代碼

在文件夾下運行commit命令，將文件提交到本地版本庫。

因爲本地倉庫只有你一我的在使用，因此請放心提交，不須要考慮BUG等因素。PUSH時就要當心了。

有些文件是不須要提交到版本管理的，好比 .vs 文件夾、bin、obj文件夾等，應該將其加入忽略列表中。

Git提交時要求輸入關於本次提交的說明，請認真填寫，這樣就不用維護額外的版本修改日誌了。對於確實可有可無的提交，能夠團隊約定輸入一個字符，如「#」。

4. 同步倉庫

同步操做有兩種：

一、 PULL：將遠程服務器代碼同步到本地

二、 PUSH：將本地代碼同步到遠程服務器

具體的操做流程應該以下：

一、 commit的操做應該是頻繁進行的，和遠程庫無關；

二、執行PULL操做獲取團隊最新代碼；

三、本地確認編譯成功後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便可。

3、進階操做

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）。

須要說明的是，遠程版本回退應該是一個集體行爲，不存在項目組某我的進行版本回退，但其餘人繼續使用當前版本的狀況，回退點以後的版本是要拋棄掉的。

4、分支管理

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操做才能將分支同步到服務器。