公司最開始決定是使用GIT作為版本控制 , 也都使用了4,5個月了 , 開發人員也都是20多歲年輕力壯的年輕人 , 每個組的組長也一直在做git使用的培訓 , 即使是這樣 , 還是遇到了非常大的阻礙 , 主要是如下幾點 :
1.代碼合並導致代碼丟失
2.很多人對代碼commit到本地后還要push到remote表示很不解
3.個別同事經常反饋commit的記錄丟失
因為很多同事都遇到這3個問題 , 所以普偏反饋建議改為SVN作為版本控制 , 特別是接連好幾次有同事反饋了第三個問題 , 我和運維都表示很吃驚 , 表示絕對不會出現丟失的情況 ; 但是公司的領導看到這樣的反饋 , 還是建議采納開發的建議 , 改為SVN , 然后運維就將GIT 改為了SVN 。則關鍵是公司使用svn的傳統。
1.代碼合並導致代碼丟失
2.很多人對代碼commit到本地后還要push到remote表示很不解
3.個別同事經常反饋commit的記錄丟失
因為很多同事都遇到這3個問題 , 所以普偏反饋建議改為SVN作為版本控制 , 特別是接連好幾次有同事反饋了第三個問題 , 我和運維都表示很吃驚 , 表示絕對不會出現丟失的情況 ; 但是公司的領導看到這樣的反饋 , 還是建議采納開發的建議 , 改為SVN , 然后運維就將GIT 改為了SVN 。則關鍵是公司使用svn的傳統。
個人的一點看法:
對於第一點 , 我覺得完全是開發人員自己的問題造成的 , 如果開發人員不找到自己的原因 , SVN也會出現合並造成代碼丟失的問題
第3點問題 , 當時有人說這樣的問題 , 我表示也是非常的詫異的 , 我自己也是剛用git , 但是也覺得並不會出現這樣的問題 , 之道有一次自己做了這樣一個操作 , 在一個branch上checkout了一個commit,然后在這個commit的基礎上做了一下修改,然后commit了,最后checkout 原有branch時發現 , 這個commit在branch的log上是不存在的 , 由此我猜測是不是當時那位遇到commit丟失的同事是否也是像我這樣操作了 ;
總之用了一個多月的git , 覺得git在需要頻繁修改bug的場景下 , 發揮巨大優勢的branch比svn還是要好用很多的 ; 發表這個帖子並不是想說git 比svn好用 (LZ在一個公司使用過2年的Microsoft sourcesafe , 那種惡心的版本控制簡直不想再提) , 而是提一下自己以及同事在使用git確實會遇到一些影響開發的問題 .
第 1 條附言
看了大家的回復 , 統一回復幾點 :
1. 我指的提交丟失並不是物理上的丟失 , 也不是git的問題 , 而是在checkout某個版本之后基於這個版本做了修改然后提交 , 回到master之后在log中找不到這個歷史版本上提交的版本了 , 根據剛才的回復我試了一下 , 再次checkout之前修改的版本 , 可以看到HEAD detached at xxx的提示 , 我沒有注意到這點是我的疏忽
2.根據回復中提到的強制提交造成提交丟失 , 我覺得是有這種可能的 , 但是當時公司也沒有人站出來查證這個問題 , 在出現過幾次這個問題之后沒有解決領導才決定切換到svn
3.在這里我們不是討論svn和git誰好用 , 只是討論一下實踐中遇到的一些問題 , 那些說用不好git的同事應該開除 , 我並不這樣認為 , 我認為不論是svn還是git , 那些合並不好代碼導致其他人代碼丟失的同事才是有問題的 , 他們有他們的不足 , 但是並不在我們的討論范圍之內 , 因為我們沒有那么多理想的環境 , 那些大公司的混子 , 我也不是沒見過
4.那些說我git基礎知識差的我也認了, 但是各位 : 作為一個版本控制系統 , 做的最多的不就是提交,合並,更新嗎?有多少人會為了這幾個基本的操作去系統的研究學習gitpro ? 作為初學者 , 我也不信你有那么強的學習能力把git pro中的每一種場景都結合到日常的操作之中 , 就像開始回復的那些朋友 , 一口咬定git絕對不會丟失提交的占多數 , 能說出強制提交確實會造成提交丟失的也就只有那幾個人 , 開始回復的那些朋友 , 你們精通git嗎?
5.git確實有git的優點 , 但是那些把svn說的一文不值的人 , 還抨擊使用svn的用戶 , 你們未免太自大了 ? 請記住 : 存在即為合理 ;
1. 我指的提交丟失並不是物理上的丟失 , 也不是git的問題 , 而是在checkout某個版本之后基於這個版本做了修改然后提交 , 回到master之后在log中找不到這個歷史版本上提交的版本了 , 根據剛才的回復我試了一下 , 再次checkout之前修改的版本 , 可以看到HEAD detached at xxx的提示 , 我沒有注意到這點是我的疏忽
2.根據回復中提到的強制提交造成提交丟失 , 我覺得是有這種可能的 , 但是當時公司也沒有人站出來查證這個問題 , 在出現過幾次這個問題之后沒有解決領導才決定切換到svn
3.在這里我們不是討論svn和git誰好用 , 只是討論一下實踐中遇到的一些問題 , 那些說用不好git的同事應該開除 , 我並不這樣認為 , 我認為不論是svn還是git , 那些合並不好代碼導致其他人代碼丟失的同事才是有問題的 , 他們有他們的不足 , 但是並不在我們的討論范圍之內 , 因為我們沒有那么多理想的環境 , 那些大公司的混子 , 我也不是沒見過
4.那些說我git基礎知識差的我也認了, 但是各位 : 作為一個版本控制系統 , 做的最多的不就是提交,合並,更新嗎?有多少人會為了這幾個基本的操作去系統的研究學習gitpro ? 作為初學者 , 我也不信你有那么強的學習能力把git pro中的每一種場景都結合到日常的操作之中 , 就像開始回復的那些朋友 , 一口咬定git絕對不會丟失提交的占多數 , 能說出強制提交確實會造成提交丟失的也就只有那幾個人 , 開始回復的那些朋友 , 你們精通git嗎?
5.git確實有git的優點 , 但是那些把svn說的一文不值的人 , 還抨擊使用svn的用戶 , 你們未免太自大了 ? 請記住 : 存在即為合理 ;
第 2 條附言
並不是在爭論GIT SVN誰比誰更好 , 而是討論團隊中使用git的現狀 ;
我相信大多數團隊都在git的推廣過程中都踩過坑 , 就如同@realpg 一樣 , 作為git磚家的他也不敢在項目中首選git .
你們有經驗就分享經驗 , 我作為初學者來學習你們 , 其他初學者也能學到很多東西 ; 但是回復就是一個結論 : svn垃圾 ; git屌炸天 ; 這樣真的有意思嗎 ?
我相信大多數團隊都在git的推廣過程中都踩過坑 , 就如同@realpg 一樣 , 作為git磚家的他也不敢在項目中首選git .
你們有經驗就分享經驗 , 我作為初學者來學習你們 , 其他初學者也能學到很多東西 ; 但是回復就是一個結論 : svn垃圾 ; git屌炸天 ; 這樣真的有意思嗎 ?