從集中式版本控制系統轉換到 Git，實質上改變了你團隊的軟體開發流程。對於那些對軟體業務至關重要的公司來說，這種工作流程的轉變將在整個組織中產生深遠的影響。
這篇文章深入探討了 Git 在組織各個層面的多面優勢，從開發團隊到行銷部門等各方面。透過本文的結論，你將明白 Git 不僅僅是敏捷軟體開發的範疇，它更促進了敏捷的商業實踐。
對開發者 Developers 來說的 Git
特色分支工作流程
Git 的分支功能是它最重要的優勢之一。與集中式版本控制系統相比，Git 提供了輕量、輕鬆的分支建立和合併功能。這個簡化流程特別適合大部分 Git 使用者喜愛的特色分支工作流程。
特色分支為你的程式碼庫中每個修改提供了一個獨立的工作空間。無論開發人員開始進行任何大小的任務，他們都會啟動一個新的分支。這個做法保證了主要分支始終保持著符合生產標準的程式碼。
採用特色分支不僅相對於直接修改生產代碼而言提高了可靠性，還帶來了組織上的優勢。它們讓你能夠以與敏捷任務清單相同的細節水準來反映開發活動。例如，你可以採取一種策略，讓每個 Jira 票擁有自己的專用特色分支。
分散式開發
分散式開發
在 SVN 中，每個開發者都會收到一個工作複本，連接到中央儲存庫。相反地，Git 則是一個分散式版本控制系統。在這裡，每個開發者都有自己的本地儲存庫，包含了一個完整的提交記錄。
完整的本地歷史大幅增強了 Git 的效能，因為它消除了執行各種任務所需的網路連接，例如建立提交、檢閱檔案的先前版本或在提交之間進行比較。
此外，Git 中的分散式開發方式簡化了擴展工程團隊的過程。在 SVN 中，如果有人干擾了生產分支，會阻止其他開發者提交更改，直到問題解決。然而，Git 的運作方式不同；這樣的障礙是不存在的。每個人都可以在自己的本地儲存庫中無間斷地繼續他們的工作。
此外，與特色分支所提供的優勢相似，分散式開發建立了更可靠的環境。即使開發者意外刪除了自己的儲存庫，他們也可以輕鬆地複製另一個儲存庫並恢復他們的工作，而不會造成中斷。
Pull requests 拉取請求
許多像是 Bitbucket 這樣的原始碼管理平台透過拉取請求增強了 Git 的基本功能。拉取請求是一個開發者請求將他們的分支整合到另一個開發者的儲存庫中的方法。這不僅讓專案領導者更輕鬆地監控變更的流程，也讓開發者能夠在將其合併到主要程式碼庫之前，就他們的貢獻發起討論。
因為拉取請求本質上就像是與特色分支相關聯的評論串，所以它們展現出令人驚艷的多功能性。當開發者遇到困難問題時，他們可以啟動一個拉取請求，向團隊的其他成員尋求協助。相反地，初級開發者可以將拉取請求視為結構化的程式碼審查流程，確保他們的貢獻不會無意中危及整個專案的完整性。
社群
在許多領域中，Git 已經成為啟動新專案的標準版本控制系統。有了 Git，新團隊成員可能就不需要太多關於你的工作流程的培訓了。這是因為他們很可能已經熟悉了分散式開發方法。
再者，Git 在開源專案中享有廣泛的流行。因此，利用第三方庫並鼓勵他人分叉你的開源程式碼變得毫不費力。
更快的釋出週期
特色分支、分散式開發、拉取請求和凝聚力強大的社群的結合，使得釋出週期更加快速。這些功能促進了一種敏捷的工作流程，鼓勵在更頻繁的間隔中共享較小的更改。因此，變更可以迅速地通過部署管道進行進展，與集中式版本控制系統經常關聯的單一釋出形成對比。
當然，Git 與持續整合和持續交付（CI/CD）環境完美地整合在一起是毫不意外的。Git 鉤子提供了在儲存庫內的特定事件發生時執行腳本的能力，從而為部署提供了廣泛的自動化選項。這種靈活性使您可以根據自己的需求自定義部署流程。例如，您可以設定 Git，在將拉取請求合併到 develop 分支時，自動將最新的提交部署到指定的測試伺服器上。通過將這種建構自動化與同儕審查實踐相結合，您可以確保代碼從開發到階段到生產環境的進展，讓您對其充滿最大的信心。
Git for marketing
談到轉換到 Git 對於你公司的行銷活動的影響，可以想像一下以下的情境：你的開發團隊在未來幾周有三個明顯的變化計畫要完成：
- 整個團隊正在最後階段完成一個革命性的功能，這個功能已經開發了六個月了。
- 雅淳正在實作一個較小、與原有無關的功能，主要影響現有客戶。
- Rick 正在修改「使用者介面」的必要更新。
在依賴集中式版本控制系統（VCS）的傳統開發流程中，這些變化很可能會被捆綁成一個單一的發佈。因此，行銷將被限制在進行一次宣佈，主要集中在那個具有革命性的功能上，而其他兩個更新的行銷潛力則會被忽略。
然而，Git 帶來的較短的開發周期顯著簡化了將這些變化劃分為個別發佈的過程。這又讓行銷人員有更多的內容可以更頻繁地進行溝通。在上述的情境中，行銷可以策劃三個分開的行銷活動，每個都圍繞著一個具體的功能。結果，他們可以針對非常具體的市場區隔進行定位，最大程度地發揮每個更新的行銷潛力。
舉例來說，行銷團隊可能會計畫針對那個具有革命性的功能進行大規模的公共關係推廣，同時撰寫一篇企業部落格文章和特別強調瑪莉功能的新聞摘要。此外，他們還可以撰寫客座文章，專注於瑞克的基礎使用者體驗理論，並提交到外部設計部落格。這些行銷活動中的每一項都可以與不同的發佈同步進行，配合每個功能的部署時間和重要性。
Git 用於產品管理
Git 在產品管理上的優勢與行銷方面相似。更頻繁的釋出意味著更頻繁的客戶回饋，並且更快地對這些回饋做出更新。你不需要等待下一個可能八週後才會到來的釋出週期，只要你的開發者能夠實施解決方案，你就可以迅速地將解決方案部署給客戶。
特色分支的工作流程在適應變動的優先事項方面提供了靈活性。例如，如果在釋出週期中途，你決定推遲一個功能，以優先處理一個更具時間敏感性的功能，這並不成問題。最初的功能可以保留在其指定的分支中，直到工程部門有時間重新審視它。
此外，這個功能簡化了對創新項目、測試版和快速原型的管理，因為它們作為獨立的程式碼庫存在。
設計師的 Git
對設計師來說，特色分支非常適合快速原型設計。無論你的 UX/UI 設計師是想要引入全新的使用者流程，還是只是想要更新一些圖示，建立一個新的分支都能給他們一個受控的環境來進行實驗。這讓設計師可以在實際的工作複本中預覽他們的修改，而不用擔心破壞現有的功能。
這樣分離使用者介面的修改方式，讓向其他利害關係人展示更新變得更加簡單。例如，如果工程主管想要檢閱設計團隊的進度，他們只需指示他們檢查相應的分支即可。
拉取請求進一步強化了這個過程，提供了一個正式平台讓有興趣的人討論新的界面。設計師可以整合任何必要的調整，而相應的提交將在拉取請求中可見。這種包容性的方法邀請了每個人參與到迭代過程中。
使用分支進行原型設計最有利的一點之一是將變更合併到生產環境中或完全丟棄都變得很容易。沒有壓力必須採取其中任何一個行動。這種環境促進了設計師和UI開發者可以自由實驗的環境，同時確保最有前途的想法最終才被實施，以造福客戶。
Git 在客戶支援上的應用
客戶支援和客戶成功團隊通常會和產品經理有不同的看法。當客戶聯繫他們時，通常是因為遇到了一些問題。如果問題源自貴公司的軟體，必須立即部署修復程式。
Git 的高效開發週期避免了將錯誤修復推遲到下一個全面的發佈版本。開發人員可以立即解決問題並將修復程式直接部署到產品上。快速解決問題意味著更快樂的客戶和減少再次提問的次數。您的客戶支援團隊不必再回答「抱歉，我們會盡快處理」，而可以自信地回覆「問題已經解決了！」
Git 在人力支援上的應用
在很多方面，你的軟體開發流程會影響到你在招聘時吸引到的候選人類型。雖然吸納熟悉你的技術和工作流程的工程師對你的團隊很有益，但將 Git 納入你的流程中還能帶來額外的優勢。
潛在員工通常被吸引到提供職涯發展機會的公司。在大型和小型組織中都能熟練運用 Git 是任何程式設計師都寶貴的技能。選擇 Git 作為你的版本控制系統向潛在候選人傳達了你的公司標榜前瞻性的開發實踐，使得對未來發展有眼光的開發者更願意加入。
適合任何管理預算的人的 Git
對於任何在管理預算的人來說，Git 是效率的典範。對開發者來說，它不僅節省了在網路連線上傳遞提交的時間，還消除了在集中式版本控制系統中整合變更時的繁瑣流程。此外，它通過為初級開發者提供安全的操作環境，最大程度地發揮了他們的貢獻。這些改進直接影響了您工程部門的底線。
然而，關鍵在於要認識到這些效率不僅僅是對你的開發團隊有利的。它們也能讓行銷免於為不受歡迎的功能投入資源，讓設計師能夠在現有產品上進行新介面的測試而帶來最小的開銷，並讓你能夠迅速處理客戶的投訴。
靈活性意味著迅速判斷哪些是有效的，加強成功的努力，並丟棄那些沒有效果的。Git 在確保每個部門在各自的角色中更有效率地運作的同時，也作為你所有業務活動的放大器。
