✍️本文譯者： P2Tree
©️ 本文演繹自 Atlassian 編寫的 Why Git for your organization。頁面上所有內容採用知識共享-署名（CC BY 2.5 AU）許可協議。
Git菜單-第1篇第3章：什麼是Git，可參見我的Github倉庫：https://github.com/P2Tree/git-recipes/blob/master/sources/1.3-什麼是Git.md
從集中式版本控制系統切換到Git的決定，將會改變你所在開發團隊創造軟件的方式。如果你所在公司是一家依靠軟件來執行關鍵任務應用的公司，改變開發工作流程會影響公司的整個業務進展。
在這篇文章中，我們將會討論Git對公司各個方面的有益幫助，從開發團隊到市場團隊，以及所有其他的一切。這篇文章結束時，你就會清晰的發現Git不只適用於敏捷的軟件開發工作，它也適用於敏捷的商業活動。
Git之於開發人員
特性分支的工作流
其中最大的一個優點是Git支持分支特性（Feature Branch），不同於集中版本控制系統，Git的分支是很容易使用和合並的。這個特性分支工作流的開發機制在Git用戶中非常流行。
特性分支爲代碼庫的每一次更改提供了一個隔離的環境。當開發者希望開始工作時，不管工作內容有多複雜，他們都可以創建一個新的分支。這能確保在Master分支上總是保持具有生產質量的代碼。
使用特性分支進行開發相比於直接在生產代碼上開發更可靠保險，同時它還提供了組織上的好處。這可以保證開發工作的內容與敏捷工作清單（agile backlog）保持相同的操作粒度（譯著：大意應該是工作內容中相同粒度的工作可以建立特性分支來完成），例如，你可以實現一種策略，使得在Jira上的每一個提交都對應到相應的特性分支。
分佈式開發
在SVN中，每一個開發者都會獲取一份開發的副本，這個副本內容對應到單一的集中倉庫中的某個節點。而Git是一個分佈式的版本控制系統，它並不是複製某個節點的副本，取而代之的是，每個開發者都有一個屬於他們自己的本地倉庫，具有完整的提交歷史信息。
本地擁有完整的提交歷史可以使Git使用起來更快捷，因爲你不需要網絡連接就可以創建提交、查看某個文件之前的歷史版本信息或者是比較不同提交之間的變更差異。
分佈式的開發也可以更易於擴展你的工程團隊。在SVN上，如果某個開發者弄壞了產品分支，其他開發者將不能繼續提交他們的變更，只能等待問題修復。在Git上，這樣的問題是不存在的，每一個人可以繼續在他們自己的本地倉庫中進行工作。
同時，與特性分支類似，分佈式開發創建了一套更可靠的開發環境。即使一個開發者破壞了他自己的本地倉庫，他也可以輕鬆的克隆其他人的倉庫並重新開始工作。
拉取請求（Pull Requests）
很多源代碼管理工具設計了pull requests的功能來擴展Git核心功能。pull requests可以允許你請求其他開發者合併你的分支到他們的倉庫，這不但使得在工程中追蹤變更更爲簡單，也可以促進開發者在合併工作之前做充分的討論。
由於pull requests本質上是附加到特性分支上評註功能，所以它的用途非常廣泛。當一個開發者遇到比較困難的問題時，他們可以通過創建一個pull requests來向團隊的其他成員尋求幫助。同時，初級開發者也可以確信自己的pull requests不會作爲正式的code review，進而不會破壞整個項目進展。
社區
在許多領域，Git已經成爲新項目的預期版本控制系統。如果你的團隊使用Git，很可能你不需要在工作中去培訓新員工如何使用Git，因爲他們已經很熟悉分佈式開發的技術。
另外，Git在開源項目中非常流行，這意味着使用第三方庫變得很容易，並且更易於鼓勵其他開發者去fork你自己的開源代碼。
更快的發佈週期
前邊提到的特性分支、分佈式開發、pull requests、以及穩定的社區，他們最終的努力結果是更快的發佈週期。這些功能有助於實現敏捷的工作流程，鼓勵開發者更頻繁的共享較小的更改。反過來，和集中式版本控制系統中常見的整體發佈相比，Git的部署發佈流程可以更迅速。
正如你所期待的，Git非常易於在持續集成和持續交付環境下使用。Git hooks功能允許在倉庫中確定的事件發生時觸發運行特定的腳本，這樣可以實現自動部署的工作，甚至可以從特定的分支上構建並部署到不同的服務器上。
比如，通過配置Git，可以實現每當有人將pull request合併到開發服務器時，自動部署開發分支上最新的版本代碼到一個測試服務器上。將這種自動化構建和代碼review相結合，你將更有信心將開發內容過渡到成熟產品中。
從市場營銷角度看Git
爲了能順利理解Git如何影響公司的市場活動，可以想象開發團隊在接下來幾周內有3個獨立的日程需要完成，分別是：
- 整個團隊都正在努力完成過去6個月以來的遊戲更新特性；
- Mary正在實現一個小的，不太相關的特性，僅僅會影響部分用戶；
- Rick正在實現一些針對用戶接口上必要的更新內容；
如果公司使用的是傳統的開發工作流程，依賴於一個集中式的版本控制系統，所有這些改變都需要在同一個版本上發生。市場營銷只能發佈一個注重於遊戲更新特性的公告，故而容易忽略掉其他兩個更新的市場潛力。
Git擁有更短的開發週期機制，它可以很容易的將這些獨立的發佈版分開發布。這可以讓營銷人員可以充分的描述發佈版本的細節。在上邊這個場景中，市場營銷可以針對三個功能建立獨立的活動，從而針對更爲特定的細分市場。
例如，他們可以準備一個大的PR來推送遊戲更新特性，然後將Mary的特性公佈到公司的博客上或者是新聞簡報上，再將Rick的用戶接口的設計內容發佈到外部的設計博客上。所有這些活動可以同時在獨立的發佈流程中進行。
從產品經理角度看Git
Git在產品經理這邊的優勢和對於營銷人員的基本類似。更爲頻繁的版本發佈意味着更加頻繁的用戶反饋，從而能更爲迅速的針對反饋結果做出更新響應。可以在開發者完成代碼工作的同時，立即向用戶反饋結果，而不是等待8周後下一個版本更新。
當有更爲優先的變更時，特徵分支的工作流同樣可以提供更爲靈活的解決方案。比如說，如果正在版本發佈中途，需要推遲一項功能並替代另一項更爲緊迫的功能時，Git能夠完美解決。最初的特性可以暫時先放在它自己的分支上，直到工程師有時間繼續處理它。
這個功能同樣可以用於易於管理創新性的項目、內部測試版軟件以及需要快速迭代原型的獨立代碼庫。
從設計師角度看Git
特性分支可以快速迭代原型。無論你的UX/UI設計師是想實現一個全新的用戶交互過程，還是簡單替換一些圖標，通過檢出一個新的分支就可以得到一個可操作的安全的沙盒環境，從而，設計師可以在一個完整的工作副本上查看他們的改動效果，同時還不存在可能破壞已有設計的風險。
這樣的方式修改用戶界面，可以輕鬆的向其他成員展示更新效果。比如說，如果工程總監希望看一下設計團隊正在幹什麼，那麼只需要去查看相關的設計分支就可以了。
Pull Request能夠更進一步的提供一個正式的途徑來讓相關人員參與到新界面設計效果的討論中。設計師們可以提交相關的設計變更，這些提交都會以commit的形式展示在pull request列表中，進而讓所有相關的人員能夠參與到設計迭代的過程中。
優秀的分支結構應該易於合併到產品主線中，就像將它拋棄一樣便捷。這一點Git同樣表現優秀，這將有利於設計師和UI開發工程師在做一些實驗性的設計時，能夠確保只將最佳的設計結果展示給用戶。
從客戶支持角度看Git
客戶支持和客戶認同（譯註：原文爲customer success，意指通過我們的服務或產品讓客戶對結果滿意）工作與產品經理面對的情況不同。當客戶聯繫他們時，通常他們一定會遇到一些問題。如果這些問題是由公司的軟件導致的，那麼修復問題的工作就應該儘快開始。
Git靈活的開發週期可以避免了將問題修復的工作推遲到發佈下一個大的版本之後。開發者可以提交一個補丁並直接推送到生產線上。快速修復bug意味着可以讓客戶滿意以及讓客戶不必反饋重複的問題。這樣，你的客戶支持團隊就可以很快就能給客戶回覆說“問題已經修復了”，而不是回覆用戶“不好意思，我們正在修復中”。
從人力資源角度看Git
能夠確定的說，你的軟件開發模式決定着你要僱傭的人，因爲你總是希望去僱傭能夠熟悉你的技術和工作流程的工程師，Git除了滿足這樣的要求外，它還有其他優勢。
公司能夠通過提供職業發展機會來吸引應聘者，並且對於任何程序員來說，都會樂於去了解在大型或小型組織中如何使用Git。選擇把Git作爲公司的版本控制系統，你便能夠吸引更多有遠見的開發者。
從管理預算的任何人的角度看Git
Git是高效的。對於開發者，相比於集中式的版本控制系統，它能夠消除通過網絡提交變更所浪費的時間。也更有利於新手開發者使用，因爲它提供了一個安全的工作環境。所有這些都將會影響你的開發部門的運行。
但是，不要忘記這些高效性對於非技術團隊以外的團隊也同樣奏效。市場團隊可以防止對不受歡迎的功能投入過多精力；設計團隊可以用很小的開銷即可在真實的產品上進行新接口的試驗；客戶支持團隊又能夠更快的反饋客戶的問題。
敏捷開發意味着需要做到如何儘快的完成工作，放大成功的效果，減小失敗的影響。Git能確保每個部門的工作都更高效率，從而讓你的商業活動進展更快。
Git菜單是一套高質量的 Git 中文教程，源於國外社區的優秀文章和個人實踐。
本文原文可參見：https://github.com/P2Tree/git-recipes/blob/master/sources/1.4-爲什麼Git適合你的組織.md。
本教程全部內容可參見：https://github.com/P2Tree/git-recipes，我基於Zhongyi Tong的工作進行了重新整理和內容新增，由於作者已經關閉該項目，故重新建庫，有任何建議和疑問歡迎評論或可在Github上創建issue。再次感謝原作者的辛勤勞動。
