公司規定切換就切換，不願意遵守公司規定走人！現在從SVN切換到Git已經不是一個個人喜好的問題，是必要性的問題，別人都進步了，就你固步自封嗎？！

啥叫C位程式設計師？如果他是老闆，那無話可說，svn也是種選擇，我當初也是用svn，老闆要求的，因為我所在的體系非常保守，PM習慣集中式管理模式，但後來也過渡到git了，這是大勢所趨

有的人不玩遊戲還不知道C位的意思，C位就是carry位的意思，也就是公司的核心位置程式設計師不願意從svn切換到git怎麼辦？

這在研發團隊中是很常見的事情，比如：

團隊擴大了，需要更標準的程式碼規範和研發流程來規約大家之前游擊戰、野戰軍的開發，但是有些同學覺得自己是老員工，是核心位置，覺得開發規範、流程限制了他的發揮，降低了開發效率，便牴觸甚至是不遵守這些規範，導致團隊領導落地執行受到阻礙。

還有一種常見的，團隊統一決定使用idea編輯器，但是就有那種個別人非得使用eclipse，導致程式碼格式做不到統一標準。

這些都是不願意接受新技術、新事物的現象。

那麼當團隊遇到這種員工怎麼辦呢？

不管他了，任其使用？

害群之馬乾掉？

這些都不是好方法，個人認為應該按如下步驟進行：

能做到c為的程式設計師，一定是可以溝通的，哪怕只在技術上可以溝通。相信他也會認可git比svn要先進，但是你不能說svn垃圾，畢竟人家使用沒問題，我們可以換個方向說：svn太難了，大家學習成本高，現在團隊大家都比較熟悉git，能不能大家統一使用git，照顧一下大家？

如果該c位員工還是敬酒不吃吃罰酒，那麼這個時候就得認真的聊一聊了，為什麼你就不能換到git？大家是一個團隊，為什麼就你非得獨具一格？就這麼一個版本工具的事情就這麼難溝通？已經給你面子了，就著臺階下來就行了！

還不接受？OK，其他人的專案直接換git，直接招人熟悉他負責的功能模組，逐步替代他。公司離開任何人都行，何況你還只是一個程式設計師呢？

不願意用就不用唄。。遇到問題了C位大佬要解決吧。人家既然是大佬。那只有你跟著大佬。而不是大佬跟著你。即使大佬錯了。還是要跟著走。不服就自己做大佬

我覺得先明確問題，再說怎麼辦。1.公司的專案是否支援多個版本控制軟體？不支援，那管你c位不c位，通通給我給改，要不就gun，正常公司離開誰都行。

2. 一般公司專案都是統一的。個人覺得再位也不好太特立獨行吧，早說了，c位已經不僅僅是技術nb了，處理這樣的問題應該遊刃有餘，再說學個git，像這種c位大神不是很容易嗎。

如果無法解決，建議直接辭退，招來是幹活，解決問題創造收益的，不是來當大爺的

不願意也沒事 svn都可以 想讓別人改變習慣 最好讓別人先看差異 很多人用git和svn的效果差不多

C位連個學習Git的能力都沒有？Git常用的命令不超過10個，如果真的是大佬級別，最多半小時。這種C位最多是業務熟練而且喜歡墨守成規的人，另外一個公司產品的好壞不取決技術而取決於運營。所以沒有人不能被代替。

不過這種情況，先私下找其溝通，希望其以團隊協作為重。Git作為分散式版本控制工具第一很容易入門，第二也是大勢所趨。曉之以情動之以理說服他服從團隊安排。

再不行只能行政命令干涉了，這個相信他不能不服從，如果靠行政命令、制度也壓不住，那這個人最好邊緣化，因為這種人早晚都是團隊毒瘤。

重要的是技術而不是版本管理！產品成敗絕不是因為使用了什麼版本管理工具！張小龍不用打卡上班！有能耐的人可以自由選擇自己喜好的工具！你不給他選工具那他就有可能選工作咯！

你要用git是基於技術角度，覺得新技術肯定更好，老程式設計師不願意推新技術是基於成本收益考慮，新技術的收益無法抵消技術遷移的成本，遷移各種歷史資料和版本，成本多少？收益多少？考慮新技術的只看到增量，但是存量也很重要啊

其實我覺得git不適合公司使用，公司裡面還是應該使用集中式管理的版本管理工具軟體，git適合鬆散耦合的組織，比如開源專案。簡單點可以用svn，大公司可以用perforce。