g4e基礎篇#5 建立分支和保存代碼

章節目錄

前言

1. 基礎篇：

• 爲何要使用版本控制系統
• Git 分佈式版本控制系統的優點
• Git 安裝和設置
• 瞭解Git存儲庫(Repo)
• 起步 1 – 建立分支和保存代碼
• 起步 2 – 瞭解Git歷史記錄
• 起步 3 – 拉取請求 Pull Request 工做機制

---

使用版本控制系統最多見的工做流程就是修改代碼，保存代碼，共享代碼。Git提供了一個簡單的3步工做流，讓你方便的完成這些操做。

1. 新建工做分支
2. 提交更改
3. 推送分支到中心存儲庫與團隊成員共享

Git 工做流

按照以上3步操做，咱們就能夠開始平常的編碼工做流了。下圖中展現了這個工做流的示意：

下面，咱們按照這3個步驟來完成一個典型的Git提交的建立過程：

1. 建立分支

建立分支以前你須要獲取Git存儲庫，這部分請參考以前的內容。將命令行切換到存儲庫中的任意目錄，而後執行如下命令：

>>> git branch

不帶分支名稱命令能夠查看本地已經存在的分支

>>> git branch <分支名稱>
>>> git checkout <分支名稱>

帶有分支名稱的branch和checkout命令用於建立和切換分支，你也能夠經過一個命令完成以上操做

>>> git checkout -b <分支名稱>

執行完成後你會看到命令行的提示符發生變化，表示你已經切換到一個分支上進行工做了。

2. 提交代碼到分支

首先經過cmder中的命令提示行確認你所處的分支是正確的，注意下圖中的 (my-new-branch-2 -> origin) 這表示咱們當前處於my-new-branch-2這條分支上，後面的origin是git遠程存儲庫的一個標識，表示當前咱們跟蹤的是origin這個別名的遠程存儲庫。

注：關於遠程存儲庫咱們在後面進階篇會專門進行介紹，這裏你只要知道這就是你克隆代碼的那個存儲庫就夠了。

在以上命令行狀態下鍵入如下命令打開 Visual Studio Code，編輯文件並保存退出。

>>> code .

以上咱們對2個文件進行了變動，a.txt是一個已經存在的文件，b.txt是咱們剛剛新建的文件。以上咱們保存文件並關閉vscode之後，能夠經過如下命令查看當前工做目錄中的變動

>>> git status

以上輸出的內容中有2部份內容須要理解清楚

○ Changes not staged for commit：這部分列出的文件表示已經屬於存儲庫的一部分，可是當前的改動並無被暫存。
○ Untracked files: 這部分列出的文件還不屬於存儲庫的一部分。

你會注意到在a.txt前面顯示了modified，由於a.txt已是存儲庫的一部分因此git能夠跟蹤到你對它的修改，可是對與b.txt git根本不知道你作了什麼，它只知道這裏有個文件尚未被git跟蹤。

如今，咱們須要將這兩個文件「暫存」，作好提交準備。而後執行如下命令完成暫存

>>> git add --all
>>> git status

你也可使用文件名或者通配符替換–all參數，只添加那些本身認爲須要暫存的文件。

若是暫存錯誤，使用如下命令取消暫存。

>>> git reset HEAD

這時git已經將2個文件所有放入了暫存區，準備進行提交。這時你能夠執行如下命令完成提交，git會對當前文件建立快照，造成版本記錄。請執行

>>> git commit -m "my first git commit"

git commit 命令用於提交代碼變動到git存儲庫，後面的-m參數因爲給出你的提交註釋，在git中提交註釋是必選項，不能掠過。這實際上是一個很是好的設計，我想你必定爲了在svn代碼庫中看到一堆沒有註釋的變動罵過街。

完成 git commit 命令後，你的git中就已經保存了剛纔所作的代碼改動了。如今你能夠繼續編碼，並在感受必要的時候隨時重複以上的過程保存本身的改動，就不用再擔憂會丟失代碼了。

你還能夠隨時切換回到master分支，這個操做不會要求你更改目錄，而在編輯器裏面的代碼會直接切換到master分支的代碼狀態。只要執行

>>> git checkout master

注意：當我完成切換的是時候，咱們以前建立的b.txt從vscode中消失了，同時a.txt裏面以前修改的內容也不見了。若是要找回改動，只要再切換回到剛纔的分支便可。

3. 推送分支到中心存儲庫與團隊成員共享

企業開發中推常見的場景就是團隊協同，開發人員本地完成修改後須要共享給其餘開發人員一塊兒使用，這時咱們能夠利用中心存儲庫來完成這個操做。首先確保你處於本身但願共享的分支中，而後運行：

>>> git push origin my-new-branch-2

完成操做後，你的本地分支就被推送到中心存儲庫上了，這時其餘開發人員就能夠經過如下命令獲取你的分支代碼。

>>> git fetch
>>> git checkout my-new-branch-2

注意：git容許你在本地和遠程使用不一樣的分支名稱，這給予開發人員更多的自由度，可是有時候也會形成麻煩，好比可能你忘記了你本地分支已經在跟蹤一條遠程分支，不當心改錯了代碼。

爲了可以更加清晰的標識分支的全部人，通常咱們在創建分支的時候會經過前綴的方式來標識，使用特定格式的前綴可讓VSTS/TFS將你的前綴變成分支文件夾形式顯示，便於管理。以下圖，在建立分支的時候使用了 leixu/ 做爲前綴，推送到服務器上之後就變成文件夾顯示

你甚至能夠設置多級文件夾，這樣在團隊比較大的時候管理起來就容易多了。

爲什麼必定要使用分支？

爲何改動必定要放在分支中實現。這個與軟件開發自己的特性有關係，軟件開發過程自己是一個不肯定的過程，沒有人能夠在代碼寫完以前預測出到底應該怎樣寫。這個與產品生產製造不一樣，產品生產製造以前，全部的工序，操做和零件都是肯定的，所以咱們能夠清晰的規劃如何完成製造過程，也能夠將這個過程組織成流水線順序執行（注意：這裏的流水線特指製造業工廠中的生產流水線，與咱們後面說的軟件交付流水線不一樣）。軟件的開發過程則徹底是一個探索過程，開發人員須要通過屢次失敗的嘗試才能最終找到正確的實現方式，這個過程須要屢次修改代碼，有時還可能會推翻歷來。這種循環往復的過程越接近開發人員的平常編碼，越接近最小的功能實現就愈加頻繁。所以，開發人員必須可以在不影響主幹代碼的狀況下，自助的建立代碼副本，在這個副本上完成以上嘗試；同時，也須要兼顧代碼主幹上的變動，確保本身的改動的基準永遠與整個團隊對齊，不然就算寫好了也沒法與整個團隊的工做集成。這個矛盾是全部配置管理策略要處理的核心矛盾，全部咱們所遇到問題，各類複雜的分支策略以及後續的持續交付流水線的設計都是基於這個問題延展出來的，只不過在更加複雜的團隊/產品/項目中，這個矛盾被乘各類複雜度被放大，於是須要咱們提供更爲複雜的配置管理流程來進行適應。

從這一點上稍微擴展一下，你就能夠理解其實全部的配置管理流程的設計原則應該是「適應」而不是「控制」，找出最適合團隊的流程，讓流程爲人服務是全部配置管理流程目標。也由於此，咱們須要將配置管理流程視爲一個變化的規則，它必須根據團隊的狀況適時改變，才能確保可用。

理解了以上2點內容，咱們就知道爲何Git的工做必定要放入分支，而不是在主幹上直接操做。若是代碼變動直接進入master或者團隊成員共享的分支，則會直接對生產環境或者團隊成員共享的環境形成影響，在變動還未成熟穩定以前，最保險的作法就是儘可能隔離的進行修改直到代碼能夠被其餘成員或者某一環境接受的時候再合併進去。

雖然任何的配置管理工具都容許你建立分支，可是Git的如下2個特性決定了它超越其餘任何配置管理工具成爲團隊的首選：

1. 輕量級分支：Git的分支很是輕，能夠在瞬間完成建立，也能夠隨時被銷燬；拉分支不會增長Git存儲庫的存儲開銷，只有當你提交修改的時候纔會增量的增長相應的存儲內容。
2. 同文件夾內切換分支：Git分支切換不須要切換文件夾，這樣能夠和開發工具更好的集成，開發人員能夠快速的在不一樣分支間進行切換，甚至都不須要中止IDE裏面的Debug進程。這讓開發人員更加敏捷的進行嘗試，更加快速的解決問題。
3. 本地分支：由於分佈式的特色，Git分支不須要依賴服務器就能夠完成。給予開發人員獨立的，不依賴其餘人就能夠進行嘗試的可能性。而在集中式配置管理工具中，任何分支的建立都必須是由配置管理員才能完成的工做，這大大下降了單個開發人員的效率。

採用集中式版本控制(CVCS)的系統並非不能建立分支，可是因爲分支過於沉重，開銷太大，團隊每每會選擇只容許配置管理員才能執行這個操做，這就讓開發人很受束縛。

注：固然，也正是由於以上這些優點，才讓不少企業的大規模團隊管理者對Git敬而遠之，以爲它太過靈活。其實Git徹底兼顧了大規模團隊的管控要求，只是實現的方式與傳統的配置管理工具不一樣而已，這一點咱們會在第3部分中專門討論。

小結

在這一篇中咱們介紹了基本的Git編碼工做流程，瞭解了這些你就能夠開始使用Git進行平常的編碼工做了。固然，既然Git推薦咱們儘可能使用分支來維護變動，那麼就必須容許咱們進行合併，這樣才能最終完成團隊開發的協做。這部分會在下一篇中進行介紹