SVN對分支當(dāng)做路徑來授權(quán)，造成管理的負(fù)擔(dān)（參見 前面的描述 ）， 因此使用SVN實(shí)現(xiàn)靈活的特性分支開發(fā)、可靠的發(fā)布控制（維護(hù)分支凍結(jié)）很難。
企業(yè)應(yīng)用Git的困惑之一是如何裁剪出適合自己的工作流。實(shí)際上Git本身已經(jīng)給出范例：
$ git help workflows
理解Git的應(yīng)用模型并選用合適的服務(wù)器端軟件（如 Gitolite），可以定制出適合自己的工作流。 例如下表是在企業(yè)中使用Git版本控制系統(tǒng)的典型角色劃分：
再來談?wù)凣it的使用，實(shí)際上Git的設(shè)計(jì)模型非常簡單，理解了其設(shè)計(jì)思想，可以很容易地掌握 git reset， git checkout， git rebase， git push， git pull 等命令。
誤解7：程序員不喜歡命令行
誰說Git沒有好的圖形工具？SVN 有 TortoriseSVN，Git 同樣有 TortoiseGit。 只不過Git的命令行太好用，使得圖形操作顯得笨拙。
至于Windows用做開發(fā)環(huán)境是否還有前途，看看火熱的iOS、Android開發(fā)、和優(yōu)雅的 MacBook 知道了。
Git能做到，而SVN難以做到的事情
Git分支功能為強(qiáng)大，分支管理能力讓SVN望塵莫及
Git可以很容易地對比兩個(gè)分支，知道一個(gè)分支中哪些提交尚未合并到另一分支，反之亦然。
● 查看當(dāng)前分支比other分支多了哪些提交：
$ git log other..
● 查看other分支比當(dāng)前分支多了哪些提交：
$ git log ..other
我不認(rèn)為SVN的分支是真正的分支，因?yàn)榉种Щ镜奶峤桓綦xSVN沒能實(shí)現(xiàn)。 在SVN中一次提交可以同時(shí)更改主線（/trunk）和分支中的內(nèi)容， 所以判斷一個(gè)分支中哪些提交未合并到另外的分支，完全不能對SVN抱有希望。
Git可以實(shí)現(xiàn)更好的發(fā)布控制
針對同一個(gè)項(xiàng)目，Git可以設(shè)置不同層級的版本庫（多版本庫）， 或者通過不同的分支（多分支）實(shí)現(xiàn)對發(fā)布的控制。
● 設(shè)置只有發(fā)布管理員才有權(quán)限推送的版本庫或者分支，用于穩(wěn)定發(fā)布版本的維護(hù)。
● 設(shè)置只有項(xiàng)目經(jīng)理、模塊管理員才有權(quán)推送的版本庫或者分支，用用于整合測試。
