使用版本控制系統最常見的工作流程就是修改程式碼，儲存程式碼，共享程式碼。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推薦我們儘量使用分支來維護變更，那麼就必須允許我們進行合併，這樣才能最終完成團隊開發的協作。這部分會在下一篇中進行介紹。

相關文章：

原文地址:http://devopshub.cn/2018/01/13/g4e-basic-04-git-repo/ 

.NET社群新聞，深度好文，歡迎訪問公眾號文章彙總 http://www.csharpkit.com