章節目錄

前言

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推薦我們盡量使用分支來維護變更，那麽就必須允許我們進行合並，這樣才能最終完成團隊開發的協作。這部分會在下一篇中進行介紹

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