選擇程式碼流程策略
請務必選擇適合您小組工作方式的程式碼流程策略。 您需要考慮幾個策略。 在本課程模組結束時，您可以探索選項。 Tailspin Web 小組決定開發以 Git 與 GitHub 為基礎的程式碼流程策略。
當 Mara 設定 Azure Boards 時，她和小組發現了一些需要解決的初始工作。 其中一個工作是建立以 Git 為基礎的工作流程。
讓我們在一旁聽聽小組成員如何想出更好的共同作業方式。 目前，他們使用集中式版本控制系統，但計劃要移至 Git 這種分散式系統。
Andy 進來時，Mara 正聚精會神地處理指派給她的功能。
Andy：嗨，Mara。 在早上的主管會議中，有人說我們這個小組與遊戲開發小組使用的是不同的版本控制系統。 為了簡化小組之間共用資源的方式，主管要求我們改用分散式版本控制系統，以提升共同作業能力。
Mara：這樣很好啊。 你記不記得，我們有在白板上寫下這點。 目前，我們使用的是集中式版本控制系統。 雖然我們目前使用得很順利，但我同意如果要開始在小組之間共用，而且我們的小組規模變大的話，選擇使用分散式版本控制系統會更好。 這也是我們寫在白板上要用來提升可見度的一項工作，這樣所有專案關係人才會知道大家手上正在做些什麼。 我認為像 Git 這樣的分散式原始檔控制系統也會有所幫助。
Andy：我一直想要嘗試 Git。 但總是找不出時間。 學習或設定難不難？ 理由充分的話，或許我們可以立即著手處理。 我受夠了一再拖延。 而且能夠看到大家正在做什麼，以及能夠存取整個存放庫會是件好事。 那麼，說說這個系統吧？
Mara：我先解釋一下這個系統，然後你再決定我們是否要立即實作。
Mara 和 Andy 走到白板前討論版本控制的事。
Git 和分散式版本控制是什麼？
Mara：左邊畫的是集中式版本控制，和我們現在用的一樣。 在 Team Foundation 版本控制 (TFVC) 中，我們有每個人都在使用的中央版本程式碼基底 
。 我們各自處理需要變更的檔案，然後在完成時將其合併回主要存放庫。
Andy：沒錯，我們使用得很順利。 不過，那次在中斷性變更合併到中央存放庫時，我遭到封鎖的情況除外。
Mara：沒錯！ 你那時遭到封鎖 
。 我們可以搭配 TFVC 使用分支策略來解決封鎖的問題，但在我們目前的設定中，合併可能會變得更複雜。 我們以前曾發生中斷性變更 
，當時在問題解決之前，沒有人可以完成任何工作。 這個問題會一直潛伏著，因為我們全都使用相同的程式碼複本。
右邊畫的是分散式版本控制。 我們還是有一個中央存放庫 
，這是穩定版本的程式碼基底，但是每個開發人員都有自己的複本 
，可從中進行工作。 如此一來，我們就可以在不影響中央存放庫的情況下，試驗並嘗試各種方法。
分散式版本控制也可以確保只有作用中的程式碼 
會合併至中央存放庫。 我們甚至可以將其設定為要經過檢閱後才能合併程式碼。
Azure DevOps 的好處是，其可與集中式版本控制系統和分散式版本控制系統良好地搭配運作。
Andy：如果多個人變更同一個檔案會怎樣？
Mara：Git 通常可以自動合併多個變更。 當然，我們一定要確保變更組合在一起後會產生可運作的程式碼。 當 Git 無法自動合併變更時，其會直接在檔案中標示出衝突，以便人為選擇要接受的變更。
Andy：現在，我們的程式碼儲存在我們自己的伺服器上。 如果我們改用分散式版本控制的話，程式碼會儲存在哪裡？
Mara：這個問題問得很好。 這時就需要裝載功能了。
我可以在哪裡裝載存放庫？
Mara：在決定要用來裝載存放庫的位置時，有幾個選項可供選擇。 例如，我們可以將存放庫裝載在本機伺服器、在 Bitbucket 或在 GitHub 中。 Bitbucket 和 GitHub 是以 Web 為基礎的裝載解決方案。 我們可以從任何地方進行存取。
Andy：你有用過任何一種嗎？
Mara：我曾經使用過 GitHub。 其包含對開發人員來說很重要的功能，像是從命令列或線上入口網站輕鬆存取變更記錄和版本控制功能。
Andy：那麼，Git 的運作方式為何？
我要如何使用 Git？
Mara：如同我之前說的，使用分散式系統時，開發人員可以自由地存取所需的檔案，而不會影響其他開發人員的工作，因為開發人員有自己的存放庫複本。 複製品是存放庫的本機複本。
當我們處理某項功能或錯誤修正時，通常會想要試用不同的方法，直到我們找到最佳解決方案。 但在主要程式碼基底的複本上試用程式碼不是個好主意，因為您通常不會想保留前幾次嘗試的結果。
為了提供更好的選擇，Git 有一個稱為分支的功能，您可以保留任意數量的複本，並只將您想要保留的複本合併回來。 這會使主分支保持穩定。
Andy：到目前為止我都聽得懂。 我要如何簽入程式碼？
如何將本機變更傳送到主要程式碼基底？
Mara：在 Git 中，預設分支 (或主幹) 通常會稱為 main。
當您覺得程式碼已準備好合併到所有開發人員共用中央存放庫中的 main 分支時，就可以建立所謂的「提取要求」。 當您建立提取要求時，就是在告訴其他開發人員，您的程式碼已經準備好接受檢閱，並想要將其合併至 main 分支。 當您的提取要求通過核准並接著合併之後，就會成為中央程式碼基底的一部分。
分支工作流程是什麼情況？
步驟 1：當您開始處理新的功能或 Bug 修正時，要做的第一件事就是確定您是從最新的穩定程式碼基底開始著手的。 為了這樣做，你可以同步處理 main 分支的本機複本與伺服器的複本。 這會將自上次同步後推送至伺服器上 main 分支的所有其他開發人員變更提取至您的本機複本中。
步驟 2：若要確定您只在程式碼「複本」上工作，請針對該功能或 Bug 修正建立新的分支。 如您所見，如果您為所有處理中的工作建立了許多分支，要記住這些分支並不容易，因此使用妥善的命名慣例非常重要。
變更檔案之前，請簽出新的分支，這樣您才會知道您正在處理來自該分支的檔案，而不是來自不同分支的檔案。 您隨時都可以切換分支，只要簽出該分支即可。
步驟 3：您現在可以安全地進行任何您想要的變更，因為這些變更只存在於您的分支中。 在工作時，您可以將變更「認可」至您的分支，以確保您不會遺失任何工作，以及有辦法將您所做的任何變更復原到舊版。 在認可變更之前，您需要暫存檔案，讓 Git 知道您準備要認可的檔案。
步驟 4：下一步是將您的本機分支推送 (或上傳) 至遠端存放庫 (例如 GitHub)，讓其他人可以查看您正在處理的工作。 別擔心，這個步驟還不會合併您的變更。 您可以根據自己的需要，頻繁地推送您的工作。 事實上，這是將工作備份起來，或讓自己能在多部電腦上工作的好方法。
步驟 5：這個步驟很常見，但非必要。 當您對程式碼的運作方式感到滿意時，就可以將遠端 main 分支提取 (或合併) 回到您的本機 main 分支。 遠端分支一直發生變更，但您的本機 main 分支尚未變更。 在您同步處理遠端 main 分支與您的分支之後，請將您的本機 main 分支合併至您的工作中分支，然後再次測試您的組建。
此程序可協助確保您的功能可與最新的程式碼搭配運作。 此外，還可協助確保您的工作將在您提交提取要求時順暢地整合。
步驟 6：您的本機程式碼現在必須認可並推送至裝載的存放庫。 這與步驟 3 和步驟 4 相同。
步驟 7：您終於準備好建議您對遠端 main 分支的變更。 若要這樣做，請開始提取要求。 如果是在 Azure Pipelines 或其他 CI/CD 系統中設定的，此步驟會觸發建置流程，而您可以看著變更在管線中移動。 組建成功且其他人核准您的提取要求之後，您的程式碼就可以合併到遠端 main 分支中。 (仍是人工決定是否合併變更)。
Andy：這些步驟很複雜，很難學會。
Mara：Git 功能很強大，因此乍看之下似乎很嚇人，但在您熟習整個流程後，就會覺得沒什麼了。
每天只會使用幾個命令。 摘要如下：
| 類別 | 如何執行這項工作 | 使用此命令 |
|---|---|---|
| 存放庫管理 | 建立 Git 存放庫 | git init |
| 下載遠端存放庫 | git clone |
|
| 分行 | 建立分支 | git checkout |
| 暫存並認可變更 | 查看哪些檔案已變更 | git status |
| 暫存要認可的檔案 | git add |
|
| 將檔案認可至您的分支 | git commit |
|
| 遠端同步處理 | 從遠端存放庫下載分支 | git pull |
| 將分支上傳至遠端存放庫 | git push |
Andy：看來這是很合適的起點。 我一定可以應付得來。 需要更進階的命令時再學就好。