當我們能夠通過一個驗收測試後，就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同，我們是以 Trunk-based Development（主幹開發）的方式進行，也就是只有 main 一條分支，並且所有人都會提交進去。
衝突對應
在多人、多團隊的狀況下，只使用一條分支難道不會發生衝突嗎？答案是必然的，然而我們需要習慣這樣的狀態。
我們應該讓每一個 Commit 都維持足夠小，這也是 A-TDD（驗收測試驅動開發） 和 TDD（測試驅動開發）兩者技巧被應用後，我們自然而然的可以透過小步前進的方式進行開發。當我們遭遇衝突時，這就表示我們獲得了機會了解其他團隊的工作以及思考的方式，這樣會加深我們在團隊之間的交流與協作。除此之外，以主幹為基礎的開發，能夠讓開發是更加線性的，也更容易理解產品的發展過程。
觀點：對於組織內部的產品應該使用主幹分支開發，以分支為基礎的開發方式是為了對應開源專案所設計的。
建置失敗
當我們使用相同的分支開發時，總會遭遇到自動化測試、建置失敗的情況，在這樣的狀況下我們應該暫停推送 Commit 並且確認其他團隊已經發現問題，並且由遭遇問題的團隊著手處理。
如果問題持續太久，我們可以使用安燈系統來中斷所有團隊一起來排除問題，或者直接退回（Revert）失敗的 Commit 讓其他團隊可以繼續工作。我們應該要對發生問題感到高興，因為我們可能找到過去沒有注意到的問題並且在發布給使用者之前將其解決。
採取 A-TDD 或者 TDD 並不是敏捷開發的必要條件，如果團隊認為不需要的時候 Scrum Master 也可以在確保安全的前提下讓團隊進行各種嘗試。
封面圖片使用 Unsplash 上 Alexey Soucho 的作品，這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神，看關於技術的主題可以到弦而時習之找找靈感。
