接下來我們將談談如何交付與共同開發。由於本案是透過 Azure DevOps 作為主要專案與協作的平台，而程式碼的交付自然就是選擇 Git。那麼，針對不同的環境，該如何進行區分呢？我們目前已知的主要環境有：各自開發環境、測試 (UAT)、正式環境，因此我們將 Branch 分為：

• develop（測試）

• main（正式）

• Feature（功能開發）

每個開發者開始開發的起始點，皆以當下的 develop 分支為基礎，開啟新的 Branch 進行開發。開發持續至可交付時，再透過 Pull Request 合併回 develop。
develop& main 受到特定的保護策略限制，無法直接透過 Git 進行 push。任何 Branch 可以任意進行 Merge 與 Push，但 develop 必須透過發 PR 的方式進行程式碼合併，並觸發 ADO 上的 Pipeline，針對合併後的內容自動執行對應的編譯 (CI) 與部署 (CD) 作業，以確保測試與正式環境分別表示特定環境的最終版本。
圖5-1:本案的git 交付策略

要特別注意的是，在尚未上線期間，develop branch 的測試環境便成為協作開發的最新版本。
所有開發者必須基於該版本往上疊加進行自己被分派的工作，也因為 develop 有目前測試環境最新版的標籤，很多剛開始加入協作開發成員或是初入 Git 的開發者，會恐懼交付 PR，總覺得「萬一我發了壞了?怎麼辦？」或是「我的功能其實不完整，先不 PR 了」的謬思，團隊中 Tailing & Vanessa 於我動工後約 4 週才開始加入，加入前期，兩位辛勤耕耘開發好要交付的功能了，應該是要自信滿滿地交東西出去，但總是帶著幾分懷疑、溫柔地在群組發問「各位~不好意思，我想要發 PR 可以嗎」，這裡要給這樣背負包袱的開發者幾個強心劑的建議：

1. 別怕發 PR，先發再說！壞掉沒關係，Git 就是讓你可以勇敢試錯的。
2. 錯誤很正常，反正測試環境本來就是拿來「試爆」的。
3. 習慣就從多發 PR 開始，發久就順了。真的不行，那就至少每天 push 一下，讓你辛苦寫的程式有地方留痕跡

此外，針對開發者鼓勵盡量 PR 提早交付外，也要澄清一個觀念：即便你孤獨地在地端開發，也要做到盡量貼齊最新版 你可以想像打團體副本時，main 是共用進度。有人升級武器、有人打倒 BOSS，如果你一直自己練功、沒同步戰報，那等你要合流時會發現你用的版本根本打不到人家現在的怪，早點合流，才不會落單打醬油。

有些情況下，例如結構性調整、共用功能發佈、嚴重 Bug、或會造成髒亂資料的 Bug 等情況，我們在發完 PR 後會特別通知所有開發者，全體先進行 fetch 與 rebase，以達到以下效益：

1. 避免落後太多造成合併地獄（merge hell）
   如果你一直在自己的分支上開發，沒跟 main 同步，其他人 push 的新變更你都沒拿到，最後合併時就會產生大量衝突（尤其多人一起動同個區域時）。

2. 確保你在的基礎版本是最新、穩定的
   最新版本通常會持續修 bug 或更新框架，如果你沒跟上，有可能踩在已經被修過的 bug 上，浪費時間 debug。

3. 提早發現潛在衝突
   早 rebase 或 merge main 進來，越容易單點解決衝突，晚了可能會造成「堆疊式錯誤」，讓人頭大。

4. 有好的共用請盡早享用
   好的架構與共用需要盡早讓團隊「早知道」、「早享用」，不然就失去它可以發揮的價值。

5. 不用太苛求
   如果不小心用了錯誤的共用版本怎麼辦？沒關係，修就好了。過程中也請不要害怕重構，重構是為了更好的再造而存在，持續改進與交付便是 DevOps 的核心精神概念。

Ending Remark

每天開工前先拉一下最新版
分支存活週期不要太長，能快點提 PR、快點合併就快點做
定期同步是負責任的工程習慣，也是團隊合作的基本功