上來就亮明觀點，符合個人性格。呵呵呵。git
爲何不看好 git 呢？程序員
首先，咱們來看看 git 產生的背景。架構
git 是 Linus 開發的，最初的目的，是爲了管理 Linux 系統的源代碼。這是一個分層集中式版本控制系統，並不是網上人云亦云的分佈式版本控制系統。如下做詳細說明。分佈式
Linux 的開發習慣，與一般軟件公司的開發習慣不一樣：工具
Linus，或者加上其它少許關鍵人員，負責 Linux 核心代碼的維護，他們可能本身參與開發，也可能接受別人提供的軟件包(軟件功能加強、改進、或bug修復)，合併到已有的代碼庫裏。在接受其餘人提供的軟件包時，指望對方已進行完整測試、代碼沒有明顯的問題、代碼規範也符合相應的規定，否則，這幾個關鍵人員，有權拒絕此軟件包加入到Linux 核心代碼。而且，同一個功能，可能有多個貢獻方來提交軟件包，這幾個關鍵人員可選擇其中之一(多個貢獻方提交的軟件包裏選一個)，加入Linux 核心代碼。學習
單個軟件包自己可能也比較複雜，由另外一批少許關鍵人員、加上大量的開發人員進行開發。他們也按上述習慣，在接受其餘組織/人提供的更小級別軟件包時，指望對方已進行完整測試、代碼沒有明顯的問題、代碼規範也符合相應的規定，否則，這幾個關鍵人員，有權拒絕此更小級別軟件包加入到此軟件包。而且，同一個功能，可能有多個貢獻方來提交更小級別軟件包，這幾個關鍵人員可選擇其中之一(多個貢獻方提交的更小級別軟件包裏選一個)，加入此軟件包。測試
固然，有些狀況下，軟件包的層次會更多。spa
以上就是分層集中式的開發模式。版本控制
問題在於，大多數公司，或者臨時/長期組建的軟件項目組，都不是按 Linux 核心組的開發習慣，展開工做的。代碼規範
對於通常公司來講，任何員工的每一個小時的工做，都是人力成本，換句俗話來講，都是錢、是費用。爲避免因單個程序員電腦硬盤損壞形成的代碼丟失，形成公司的費用損失，不少公司要求，每一個程序員，天天下班前，都須要 check-in 代碼到代碼庫，那些編譯不能經過的部分代碼，註釋起來，仍要check-in 代碼到代碼庫。
極少有公司去要求：那個誰，你負責的權限模塊，所有開發、測試完成後，再放到公司級版本庫；那個誰，你負責的訂單模塊，所有開發、測試完成後，再放到公司級版本庫...
所以，Linux 核心代碼的管理模式，不具備通用性。
基於 Linux 核心代碼的管理模式而開發出來的源代碼版本管理工具 git ，也不具備通用性。不適合於大多數公司。
請注意，"分佈式"、或"分層集中式"這些詞，是時髦的詞彙，但絕大部分場合，不須要。
在無需"分佈式"的狀況下，硬要套用"分佈式"的作事方式，只會帶來更多的不方便、付出更多的人力成本。
EJB 就是一個很好例子。
單從概念、技術角度，相比以前/同期的同類軟件技術/產品/架構， EJB 均是優秀的。被普遍濫用以後，你們都發現，這玩意兒太難用了，不管是開發論壇、員工考勤、企業信息管理、電子商務，仍是其餘的軟件系統/軟件工具，絕大多數狀況下，EJB 都只會帶來技術難度及增長開發工做量。
這仍是由於，「分佈式」的技術，只適合用於「分佈式」的場景下。不具備通用性。
知乎網上，也有不少對比討論(git vs SVN)。
最明顯的一點差異，在於 git 的平常兩次提交習慣(第一次提交到本地我的電腦版本庫、第二次提交到公司集中版本庫)，相比 SVN 的一次提交習慣，須要更多的培訓、學習、適應時間。
且平常操做，更顯麻煩(操做步驟多一倍)。
固然了，對於單個員工來講，學了不合適的時髦技術，能夠加強找工做的我的競爭力；對於公司、團隊來講，使用了不合適的時髦技術，增大了整體成本、變相下降了公司的競爭力。
值得不值得用，就看站在哪一個角度來判斷了。
================================================================================================
========================轉發請註明來源:https://www.cnblogs.com/jacklondon/ ===========================
================================================================================================