Tôi đã sử dụng Subversion được vài năm và sau khi sử dụng SourceSafe , tôi chỉ thích Subversion. Kết hợp với TortoiseSVN , tôi thực sự không thể tưởng tượng làm thế nào nó có thể tốt hơn nữa.
Tuy nhiên, ngày càng có nhiều nhà phát triển cho rằng Subversion có vấn đề và chúng ta nên chuyển sang loại hệ thống kiểm soát phiên bản phân tán mới, chẳng hạn như Git .
Làm thế nào để Git cải thiện khi lật đổ?
Câu trả lời:
Git không tốt hơn Subversion. Nhưng cũng không tệ hơn. Nó khác nhau.
Sự khác biệt chính là nó được phân cấp. Hãy tưởng tượng bạn là một nhà phát triển trên đường, bạn phát triển trên máy tính xách tay của mình và bạn muốn có quyền kiểm soát nguồn để bạn có thể quay lại 3 giờ.
Với Subversion, bạn có một vấn đề: Kho lưu trữ SVN có thể ở vị trí bạn không thể truy cập (trong công ty của bạn và bạn không có internet vào lúc này), bạn không thể cam kết. Nếu bạn muốn tạo một bản sao của mã của mình, bạn phải sao chép / dán mã theo nghĩa đen.
Với Git, bạn không gặp phải vấn đề này. Bản sao cục bộ của bạn là một kho lưu trữ và bạn có thể cam kết với nó và nhận được tất cả các lợi ích của kiểm soát nguồn. Khi bạn lấy lại kết nối với kho lưu trữ chính, bạn có thể cam kết chống lại nó.
Điều này thoạt nhìn có vẻ tốt, nhưng chỉ cần ghi nhớ sự phức tạp thêm vào phương pháp này.
Git dường như là điều "mới, sáng bóng, mát mẻ". Điều đó không có nghĩa là xấu (có một lý do Linus đã viết nó cho sự phát triển Hạt nhân Linux), nhưng tôi cảm thấy rằng nhiều người nhảy lên tàu "Kiểm soát nguồn phân tán" chỉ vì nó mới và được viết bởi Linus Torvalds, mà không thực sự được viết biết tại sao / nếu nó tốt hơn.
Subversion có vấn đề, nhưng Git, Mercurial, CVS, TFS hay bất cứ điều gì cũng vậy.
Chỉnh sửa: Vì vậy, câu trả lời này đã được một năm tuổi và vẫn tạo ra nhiều upvote, vì vậy tôi nghĩ rằng tôi sẽ thêm một số giải thích. Trong năm ngoái kể từ khi viết bài này, Git đã đạt được rất nhiều động lực và hỗ trợ, đặc biệt là khi các trang web như GitHub thực sự cất cánh. Hiện tại tôi đang sử dụng cả Git và Subversion và tôi muốn chia sẻ một số hiểu biết cá nhân.
Trước hết, Git có thể thực sự khó hiểu lúc đầu khi làm việc phi tập trung. Điều khiển từ xa là gì? và Làm thế nào để thiết lập đúng kho lưu trữ ban đầu? là hai câu hỏi xuất hiện ngay từ đầu, đặc biệt là so với "svnadmin tạo" đơn giản của SVN, "git init" của Git có thể lấy các tham số --bare và - shared có vẻ là cách "phù hợp" để thiết lập một tập trung kho. Có những lý do cho điều này, nhưng nó thêm phức tạp. Tài liệu của lệnh "thanh toán" rất khó hiểu đối với những người thay đổi - cách "thích hợp" dường như là "git clone", trong khi "git checkout" dường như chuyển nhánh.
Git THỰC SỰ tỏa sáng khi bạn được phân cấp. Tôi có một máy chủ ở nhà và một máy tính xách tay trên đường và SVN đơn giản là không hoạt động tốt ở đây. Với SVN, tôi không thể kiểm soát nguồn cục bộ nếu tôi không được kết nối với kho lưu trữ (Có, tôi biết về SVK hoặc về các cách để sao chép repo). Với Git, dù sao đó cũng là chế độ mặc định. Đó là một lệnh bổ sung mặc dù (git commit cam kết cục bộ, trong khi git đẩy gốc master đẩy nhánh chủ đến từ xa có tên "origin").
Như đã nói ở trên: Git thêm phức tạp. Hai chế độ tạo kho lưu trữ, thanh toán so với sao chép, cam kết so với đẩy ... Bạn phải biết lệnh nào hoạt động cục bộ và hoạt động với "máy chủ" (Tôi cho rằng hầu hết mọi người vẫn thích một "kho lưu trữ chính" trung tâm ).
Ngoài ra, công cụ vẫn chưa đủ, ít nhất là trên Windows. Vâng, có một Visual Studio AddIn, nhưng tôi vẫn sử dụng git bash với msysgit.
SVN có lợi thế là đơn giản hơn rất nhiều để tìm hiểu: Có kho lưu trữ của bạn, tất cả các thay đổi đối với nó, nếu bạn biết cách tạo, cam kết và kiểm tra và bạn đã sẵn sàng và có thể chọn các thứ như phân nhánh, cập nhật, v.v. trên.
Git có lợi thế là nó phù hợp hơn nếu một số nhà phát triển không phải lúc nào cũng được kết nối với kho lưu trữ chính. Ngoài ra, nó nhanh hơn SVN rất nhiều. Và từ những gì tôi nghe được, sự hỗ trợ phân nhánh và hợp nhất sẽ tốt hơn rất nhiều (đó là điều được mong đợi, vì đây là những lý do cốt lõi được viết ra).
Điều này cũng giải thích lý do tại sao nó thu được nhiều tiếng vang trên Internet, vì Git hoàn toàn phù hợp với các dự án Nguồn mở: Chỉ cần Fork nó, cam kết các thay đổi của bạn với Fork của riêng bạn, sau đó yêu cầu người bảo trì dự án ban đầu rút các thay đổi của bạn. Với Git, điều này chỉ hoạt động. Thực sự, hãy thử nó trên Github, đó là phép thuật.
Những gì tôi cũng thấy là Cầu Git-SVN: Kho lưu trữ trung tâm là một repo Subversion, nhưng các nhà phát triển làm việc tại địa phương với Git và cây cầu sau đó đẩy các thay đổi của họ sang SVN.
Nhưng ngay cả với sự bổ sung dài dòng này, tôi vẫn đứng trước thông điệp cốt lõi của mình: Git không tốt hơn hay tệ hơn, nó chỉ khác. Nếu bạn có nhu cầu "Kiểm soát nguồn ngoại tuyến" và sẵn sàng dành thêm thời gian để học nó, thật tuyệt vời. Nhưng nếu bạn có Kiểm soát nguồn tập trung nghiêm ngặt và / hoặc đang vật lộn để giới thiệu Kiểm soát nguồn ngay từ đầu vì đồng nghiệp của bạn không quan tâm, thì sự đơn giản và công cụ tuyệt vời (ít nhất là trên Windows) của SVN sẽ tỏa sáng.
Với Git, bạn thực tế có thể thực hiện mọi thứ ngoại tuyến, vì mọi người đều có kho lưu trữ riêng.
Làm chi nhánh và sáp nhập giữa các chi nhánh thực sự dễ dàng.
Ngay cả khi bạn không có quyền cam kết cho một dự án, bạn vẫn có thể có kho lưu trữ của riêng mình trực tuyến và xuất bản "yêu cầu đẩy" cho các bản vá của bạn. Mọi người thích bản vá của bạn có thể kéo chúng vào dự án của họ, bao gồm cả những người bảo trì chính thức.
Thật là tầm thường khi rẽ nhánh một dự án, sửa đổi nó và vẫn tiếp tục hợp nhất trong các lỗi từ nhánh CHÍNH.
Git hoạt động cho các nhà phát triển nhân Linux. Điều đó có nghĩa là nó thực sự nhanh (phải như vậy) và quy mô lên hàng ngàn người đóng góp. Git cũng sử dụng ít không gian hơn (ít hơn 30 lần dung lượng cho kho lưu trữ Mozilla).
Git rất linh hoạt, rất TIMTOWTDI (Có nhiều hơn một cách để làm điều đó). Bạn có thể sử dụng bất kỳ quy trình công việc nào bạn muốn và Git sẽ hỗ trợ nó.
Cuối cùng, có GitHub , một trang web tuyệt vời để lưu trữ kho Git của bạn.
Hạn chế của Git:
Các câu trả lời khác đã làm rất tốt khi giải thích các tính năng cốt lõi của Git (rất tuyệt). Nhưng cũng có rất nhiều cách nhỏ để Git cư xử tốt hơn và giúp cuộc sống của tôi lành mạnh hơn. Dưới đây là một số điều nhỏ:
git mvvà git rm.
" Tại sao Git tốt hơn X " phác thảo những ưu và nhược điểm khác nhau của Git so với các SCM khác.
Tóm tắt:
Có một số nhược điểm:
Trong cách sử dụng đơn giản nhất, Subversion và Git khá giống nhau. Không có nhiều sự khác biệt giữa:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
và
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Nơi Git thực sự tỏa sáng là phân nhánh và làm việc với những người khác.
Google Tech Talk: Linus Torvalds trên git
http://www.youtube.com/watch?v=4XpnKHJAok8
Trang so sánh của Git Wiki
Vâng, nó được phân phối. Điểm chuẩn cho thấy rằng nó nhanh hơn đáng kể (do tính chất phân tán của nó, các hoạt động như khác biệt và nhật ký đều là cục bộ nên tất nhiên là nhanh hơn trong trường hợp này) và các thư mục làm việc nhỏ hơn (vẫn làm tôi suy nghĩ).
Khi bạn đang làm việc trên lật đổ hoặc bất kỳ hệ thống kiểm soát sửa đổi máy khách / máy chủ nào khác, về cơ bản bạn sẽ tạo các bản sao làm việc trên máy của mình bằng cách kiểm tra các bản sửa đổi. Điều này thể hiện một ảnh chụp nhanh trong thời gian của kho lưu trữ trông như thế nào. Bạn cập nhật bản sao làm việc của mình thông qua các bản cập nhật và bạn cập nhật kho lưu trữ thông qua các cam kết.
Với kiểm soát phiên bản phân tán, bạn không có ảnh chụp nhanh mà thay vào đó là toàn bộ cơ sở mã. Bạn muốn làm khác với phiên bản 3 tháng tuổi? Không có vấn đề gì, phiên bản 3 tháng tuổi vẫn còn trên máy tính của bạn. Điều này không chỉ có nghĩa là mọi thứ nhanh hơn, nhưng nếu bạn bị ngắt kết nối với máy chủ trung tâm, bạn vẫn có thể thực hiện nhiều thao tác bạn đã sử dụng. Nói cách khác, bạn không chỉ có một ảnh chụp nhanh về một sửa đổi nhất định, mà là toàn bộ cơ sở mã.
Bạn sẽ nghĩ rằng Git sẽ chiếm một loạt dung lượng trên ổ cứng của bạn, nhưng từ một vài điểm chuẩn tôi đã thấy, nó thực sự tốn ít hơn. Đừng hỏi tôi như thế nào. Ý tôi là, nó được xây dựng bởi Linus, anh ta biết một vài điều về hệ thống tập tin mà tôi đoán.
Những điểm chính tôi thích về DVCS là:
Lý do chính cho một dự án tương đối lớn là giao tiếp được cải thiện được tạo bởi điểm 3. Những người khác là những phần thưởng tuyệt vời.
Điều buồn cười là: Tôi lưu trữ các dự án trong Subversion Repos, nhưng truy cập chúng thông qua lệnh Git Clone.
Vui lòng đọc Phát triển với Git trên Dự án Mã Google
Mặc dù Google Code thực sự nói Subversion, bạn có thể dễ dàng sử dụng Git trong quá trình phát triển. Tìm kiếm "git svn" cho thấy thực tiễn này là phổ biến và chúng tôi cũng khuyến khích bạn thử nghiệm nó.
Sử dụng Git trên Kho lưu trữ Svn mang lại cho tôi lợi ích:
backup/public để người khác kiểm traTất cả các câu trả lời ở đây là như mong đợi, trung tâm lập trình viên, tuy nhiên điều gì xảy ra nếu công ty của bạn sử dụng kiểm soát sửa đổi bên ngoài mã nguồn? Có rất nhiều tài liệu không phải là mã nguồn được hưởng lợi từ kiểm soát phiên bản và phải sống gần với mã chứ không phải trong một CMS khác. Hầu hết các lập trình viên không làm việc riêng rẽ - chúng tôi làm việc cho các công ty như là một phần của một nhóm.
Với ý nghĩ đó, hãy so sánh sự dễ sử dụng, trong cả công cụ và đào tạo của khách hàng, giữa Subversion và git. Tôi không thể thấy một kịch bản trong đó bất kỳ hệ thống kiểm soát sửa đổi phân tán nào sẽ dễ sử dụng hoặc giải thích hơn cho người không lập trình. Tôi muốn được chứng minh là sai, bởi vì sau đó tôi có thể đánh giá git và thực sự có hy vọng nó sẽ được chấp nhận bởi những người cần kiểm soát phiên bản không phải là lập trình viên.
Ngay cả sau đó, nếu được quản lý hỏi tại sao chúng ta nên chuyển từ một hệ thống kiểm soát sửa đổi tập trung sang phân tán, tôi sẽ khó lòng đưa ra một câu trả lời trung thực, bởi vì chúng ta không cần nó.
Tuyên bố miễn trừ trách nhiệm: Tôi bắt đầu quan tâm đến Subversion từ rất sớm (khoảng v0,29) nên rõ ràng tôi thiên vị, nhưng các công ty tôi làm việc từ thời điểm đó đang được hưởng lợi từ sự nhiệt tình của tôi vì tôi đã khuyến khích và hỗ trợ việc sử dụng nó. Tôi nghi ngờ đây là cách nó xảy ra với hầu hết các công ty phần mềm. Với rất nhiều lập trình viên nhảy vào nhóm git, tôi tự hỏi có bao nhiêu công ty sẽ bỏ lỡ những lợi ích của việc sử dụng kiểm soát phiên bản bên ngoài mã nguồn? Ngay cả khi bạn có các hệ thống riêng cho các nhóm khác nhau, bạn vẫn bỏ lỡ một số lợi ích, chẳng hạn như tích hợp theo dõi vấn đề (thống nhất), trong khi tăng yêu cầu bảo trì, phần cứng và đào tạo.
Subversion vẫn là một hệ thống kiểm soát phiên bản được sử dụng nhiều hơn, có nghĩa là nó có hỗ trợ công cụ tốt hơn. Bạn sẽ tìm thấy các plugin SVN trưởng thành cho hầu hết mọi IDE và có sẵn các tiện ích mở rộng thám hiểm tốt (như TurtoiseSVN). Ngoài ra, tôi phải đồng ý với Michael : Git không tốt hơn hay tệ hơn Subversion, nó khác.
Một trong những điều về SubVersion làm tôi khó chịu là nó đặt thư mục riêng của nó trong mỗi thư mục của một dự án, trong khi git chỉ đặt một trong thư mục gốc. Đó không phải là vấn đề lớn, nhưng những thứ nhỏ nhặt như thế cộng lại.
Tất nhiên, SubVersion có Rùa, [thường] rất hay.
David Richards WANdisco Blog về lật đổ / GIT
Sự xuất hiện của GIT đã mang theo một nhóm các nhà cơ bản DVCS - 'Gitterons' - nghĩ rằng bất cứ điều gì khác ngoài GIT là tào lao. Gitterons dường như nghĩ rằng công nghệ phần mềm xảy ra trên hòn đảo của chính họ và thường quên rằng hầu hết các tổ chức không sử dụng riêng các kỹ sư phần mềm cao cấp. Điều đó ổn nhưng đó không phải là cách mà phần còn lại của thị trường nghĩ, và tôi rất vui khi chứng minh điều đó: GIT, ở cái nhìn cuối cùng có ít hơn ba phần trăm thị trường trong khi Subversion có trong khu vực năm triệu người dùng và khoảng một nửa thị trường tổng thể.
Vấn đề chúng tôi thấy là Gitterons đã nổ súng (giá rẻ) tại Subversion. Những người thích Tweet như Subversion rất [chậm / nhảm nhí / hạn chế / không có mùi / nhìn tôi một cách hài hước] và bây giờ tôi có GIT và [mọi thứ trong cuộc sống của tôi / vợ tôi có thai / Tôi có bạn gái sau 30 năm cố gắng / Tôi đã thắng sáu lần chạy trên bàn blackjack]. Bạn nhận được hình ảnh.
Git cũng làm cho việc phân nhánh và hợp nhất thực sự dễ dàng. Subversion 1.5 chỉ cần thêm theo dõi hợp nhất, nhưng Git vẫn tốt hơn. Với phân nhánh Git rất nhanh và rẻ. Nó làm cho việc tạo một nhánh cho mỗi tính năng mới khả thi hơn. Kho lưu trữ Oh và Git rất hiệu quả với không gian lưu trữ so với Subversion.
Đó là tất cả về sự dễ dàng sử dụng / các bước cần thiết để làm một cái gì đó.
Nếu tôi đang phát triển một dự án duy nhất trên PC / máy tính xách tay của mình, git sẽ tốt hơn, vì việc cài đặt và sử dụng dễ dàng hơn nhiều. Bạn không cần một máy chủ và bạn không cần phải nhập URL của kho lưu trữ khi bạn hợp nhất.
Nếu chỉ có 2 người, tôi muốn nói rằng git cũng dễ dàng hơn, bởi vì bạn có thể chỉ cần đẩy và kéo từ nhau.
Khi bạn vượt qua điều đó, tôi sẽ chuyển sang lật đổ, vì tại thời điểm đó, bạn cần thiết lập một máy chủ hoặc vị trí 'chuyên dụng'.
Bạn có thể làm điều này tốt với git như với SVN, nhưng lợi ích của git trở nên lớn hơn khi cần phải thực hiện các bước bổ sung để đồng bộ với máy chủ trung tâm. Trong SVN bạn chỉ cần cam kết. Trong git bạn phải git commit, sau đó git đẩy. Bước bổ sung trở nên khó chịu chỉ đơn giản là vì bạn đã làm nó rất nhiều.
SVN cũng có lợi ích của các công cụ GUI tốt hơn, tuy nhiên hệ sinh thái git dường như đang bắt kịp nhanh chóng, vì vậy tôi sẽ không lo lắng về điều này trong dài hạn.
Easy Git có một trang đẹp so sánh việc sử dụng Git và SVN thực tế , điều này sẽ cho bạn ý tưởng về những điều Git có thể làm (hoặc làm dễ dàng hơn) so với SVN. (Về mặt kỹ thuật, điều này dựa trên Easy Git, một trình bao bọc nhẹ trên đầu Git.)
Nói chung, Git và DVCS rất tốt cho các nhà phát triển thực hiện nhiều mã hóa độc lập với nhau vì mọi người đều có chi nhánh riêng. Tuy nhiên, nếu bạn cần một sự thay đổi từ người khác, cô ấy phải cam kết với repo địa phương của mình và sau đó cô ấy phải đẩy thay đổi đó cho bạn hoặc bạn phải lấy nó từ cô ấy.
Lý luận của riêng tôi cũng khiến tôi nghĩ DVCS làm cho QA khó khăn hơn và quản lý phát hành nếu bạn làm những việc như phát hành tập trung. Ai đó phải chịu trách nhiệm thực hiện thao tác đẩy / kéo đó từ kho lưu trữ của người khác, giải quyết mọi xung đột đã được giải quyết tại thời điểm cam kết ban đầu trước đó, sau đó thực hiện quá trình xây dựng và sau đó yêu cầu tất cả các nhà phát triển khác đồng bộ lại repos của họ.
Tất cả điều này có thể được giải quyết với các quy trình của con người, tất nhiên; DVCS vừa phá vỡ một cái gì đó đã được sửa bởi kiểm soát phiên bản tập trung để cung cấp một số tiện ích mới.
Tôi thích Git vì nó thực sự giúp nhà phát triển truyền thông phát triển trên một nhóm vừa và lớn. Là một hệ thống kiểm soát phiên bản phân tán, thông qua hệ thống đẩy / kéo, nó giúp các nhà phát triển tạo ra một hệ sinh thái mã nguồn giúp quản lý một nhóm lớn các nhà phát triển làm việc trong một dự án.
Ví dụ: bạn tin tưởng 5 nhà phát triển và chỉ lấy mã từ kho lưu trữ của họ. Mỗi nhà phát triển có mạng tin cậy của riêng họ từ đó họ lấy mã. Do đó, sự phát triển dựa trên kết cấu tin cậy của các nhà phát triển nơi trách nhiệm mã được chia sẻ giữa cộng đồng phát triển.
Tất nhiên có những lợi ích khác được đề cập trong các câu trả lời khác ở đây.
Một vài câu trả lời đã ám chỉ những điều này, nhưng tôi muốn làm rõ 2 điểm:
1) Khả năng thực hiện các cam kết chọn lọc (ví dụ git add --patch:). Nếu thư mục làm việc của bạn chứa nhiều thay đổi không phải là một phần của cùng một thay đổi logic, Git sẽ giúp bạn thực hiện một cam kết chỉ bao gồm một phần của các thay đổi. Với Subversion, thật khó khăn.
2) Khả năng cam kết mà không làm thay đổi công khai. Trong Subversion, bất kỳ cam kết nào là ngay lập tức công khai, và do đó không thể hủy bỏ. Điều này hạn chế rất nhiều khả năng của nhà phát triển "cam kết sớm, cam kết thường xuyên".
Git không chỉ là một VCS; nó cũng là một công cụ để phát triển các bản vá. Lật đổ chỉ là một VCS.
Tôi nghĩ Subversion vẫn ổn .. cho đến khi bạn bắt đầu hợp nhất .. hoặc làm bất cứ điều gì phức tạp .. hoặc làm bất cứ điều gì Subversion nghĩ là phức tạp (như thực hiện các truy vấn để tìm ra nhánh nào bị rối với một tệp cụ thể, nơi thực sự thay đổi , phát hiện bản sao , Vân vân)...
Tôi không đồng ý với câu trả lời chiến thắng, nói rằng lợi ích chính của GIT là hoạt động ngoại tuyến - nó chắc chắn hữu ích, nhưng nó giống như một phần bổ sung cho trường hợp sử dụng của tôi. SVK cũng có thể hoạt động ngoại tuyến, vẫn không có câu hỏi nào cho tôi nên đầu tư thời gian học tập của mình vào đâu).
Chỉ là nó cực kỳ mạnh mẽ và nhanh chóng và, sau khi đã quen với các khái niệm - rất hữu ích (vâng, theo nghĩa đó: thân thiện với người dùng).
Để biết thêm chi tiết về một câu chuyện hợp nhất, hãy xem điều này: Sử dụng git-svn (hoặc tương tự) * chỉ * để giúp đỡ với một hợp nhất svn?
Nhờ thực tế không cần liên lạc với máy chủ trung tâm liên tục, hầu như mọi lệnh đều chạy trong chưa đầy một giây (rõ ràng git đẩy / kéo / tìm nạp chậm hơn đơn giản chỉ vì chúng phải kích hoạt các kết nối SSH). Phân nhánh dễ dàng hơn nhiều (một lệnh đơn giản để phân nhánh, một lệnh đơn giản để hợp nhất)
Tôi hoàn toàn thích có thể quản lý các nhánh địa phương của mã nguồn của mình trong Git mà không làm vấy bẩn nước của kho lưu trữ trung tâm. Trong nhiều trường hợp, tôi sẽ kiểm tra mã từ máy chủ Subversion và chạy kho Git cục bộ chỉ để có thể thực hiện việc này. Thật tuyệt khi khởi tạo một kho lưu trữ Git không gây ô nhiễm hệ thống tập tin với một loạt các thư mục .svn khó chịu ở khắp mọi nơi.
Và theo như công cụ Windows hỗ trợ, TortoiseGit xử lý các vấn đề cơ bản rất tốt, nhưng tôi vẫn thích dòng lệnh trừ khi tôi muốn xem nhật ký. Tôi thực sự thích cách Rùa {Git | SVN} giúp khi đọc nhật ký cam kết.
Đây là câu hỏi sai được hỏi. Thật quá dễ dàng để tập trung vào mụn cóc của git và đưa ra một lập luận về lý do tại sao lật đổ tốt hơn về mặt hình ảnh, ít nhất là đối với một số trường hợp sử dụng. Thực tế là git ban đầu được thiết kế như một bộ xây dựng kiểm soát phiên bản cấp thấp và có giao diện định hướng dành cho nhà phát triển linux, giúp các cuộc chiến thần thánh dễ dàng có được lực kéo và nhận thức được tính hợp pháp. Những người đề xướng Git đánh trống với hàng triệu lợi thế về quy trình làm việc, điều mà các svn tuyên bố không cần thiết. Gần như toàn bộ cuộc tranh luận được đóng khung là tập trung so với phân phối, phục vụ lợi ích của cộng đồng công cụ svn doanh nghiệp. Các công ty này, thường đưa ra các bài viết thuyết phục nhất về sự vượt trội của lật đổ trong doanh nghiệp,
Nhưng đây là vấn đề: Subversion là một ngõ cụt kiến trúc .
Trong khi đó, bạn có thể sử dụng git và xây dựng một thay thế lật đổ tập trung khá dễ dàng, mặc dù đã tồn tại hơn hai lần vì svn chưa bao giờ có thể làm cho ngay cả theo dõi hợp nhất cơ bản hoạt động ở bất cứ đâu gần như trong git. Một lý do cơ bản cho điều này là quyết định thiết kế để làm cho các nhánh giống như các thư mục. Tôi không biết tại sao ban đầu họ đi theo cách này, nó chắc chắn làm cho việc kiểm tra một phần rất đơn giản. Thật không may, nó cũng làm cho nó không thể theo dõi lịch sử đúng. Bây giờ rõ ràng bạn phải sử dụng các quy ước bố trí kho lưu trữ lật đổ để tách các nhánh khỏi các thư mục thông thường và svn sử dụng một số phương pháp phỏng đoán để làm cho mọi thứ hoạt động cho các trường hợp sử dụng hàng ngày. Nhưng tất cả điều này chỉ là vượt qua một quyết định thiết kế cấp thấp rất kém và hạn chế. Có thể thực hiện một diff-khôn ngoan kho lưu trữ (chứ không phải diff-khôn ngoan thư mục) là chức năng cơ bản và quan trọng cho hệ thống kiểm soát phiên bản, và đơn giản hóa rất nhiều nội bộ, giúp xây dựng các tính năng thông minh và hữu ích hơn trên nó. Bạn có thể thấy trong số lượng nỗ lực đã được đưa vào mở rộng lật đổ, và phía sau nó còn bao xa so với các VCS hiện đại về các hoạt động cơ bản như giải quyết hợp nhất.
Bây giờ đây là lời khuyên chân thành và bất khả tri của tôi cho bất cứ ai vẫn tin Subversion là đủ tốt cho tương lai gần:
Subversion sẽ không bao giờ bắt kịp các giống VCS mới hơn đã học được từ những sai lầm của RCS và CVS; đó là một sự bất khả thi về mặt kỹ thuật trừ khi họ trang bị lại mô hình kho lưu trữ từ đầu, nhưng sau đó nó sẽ không thực sự là svn phải không? Bất kể bạn nghĩ bạn không có khả năng của một VCS hiện đại đến mức nào, sự thiếu hiểu biết của bạn sẽ không bảo vệ bạn khỏi những cạm bẫy của Subversion, nhiều trong số đó là những tình huống không thể hoặc dễ dàng giải quyết trong các hệ thống khác.
Rất hiếm khi sự kém cỏi về mặt kỹ thuật của một giải pháp quá rõ ràng như với svn, chắc chắn tôi sẽ không bao giờ nêu ý kiến như vậy về win-vs-linux hoặc emacs-vs-vi, nhưng trong trường hợp này là như vậy Clearcut, và kiểm soát nguồn là một công cụ cơ bản như vậy trong kho vũ khí của nhà phát triển, mà tôi cảm thấy nó phải được tuyên bố một cách dứt khoát. Bất kể yêu cầu sử dụng svn là gì vì lý do tổ chức, tôi khuyên tất cả người dùng svn không để tâm trí logic của họ xây dựng một niềm tin sai lầm rằng các VCS hiện đại hơn chỉ hữu ích cho các dự án nguồn mở lớn. Bất kể bản chất của công việc phát triển của bạn là gì, nếu bạn là một lập trình viên, bạn sẽ là một lập trình viên hiệu quả hơn nếu bạn học cách sử dụng các VCS được thiết kế tốt hơn, cho dù đó là Git, Mercurial, Darcs hay nhiều người khác.
Subversion rất dễ sử dụng. Trong những năm qua tôi chưa bao giờ thấy có vấn đề gì hoặc một cái gì đó không hoạt động như mong đợi. Ngoài ra có nhiều công cụ GUI tuyệt vời và sự hỗ trợ cho tích hợp SVN là rất lớn.
Với Git, bạn có được một VCS linh hoạt hơn. Bạn có thể sử dụng nó giống như SVN với kho lưu trữ từ xa nơi bạn cam kết tất cả các thay đổi. Nhưng bạn cũng có thể sử dụng nó chủ yếu ngoại tuyến và chỉ đẩy các thay đổi theo thời gian đến kho lưu trữ từ xa. Nhưng Git phức tạp hơn và có đường cong học tập dốc hơn. Tôi thấy mình trong lần đầu tiên phạm sai lầm, tạo ra các nhánh gián tiếp hoặc nhận thông báo lỗi không có nhiều thông tin về lỗi và nơi tôi phải tìm kiếm với Google để có thông tin tốt hơn. Một số điều dễ dàng như thay thế các điểm đánh dấu ($ Id $) không hoạt động nhưng GIT có cơ chế lọc và móc rất linh hoạt để hợp nhất các tập lệnh riêng và do đó bạn có được tất cả những gì bạn cần và hơn thế nữa nhưng nó cần nhiều thời gian hơn và đọc tài liệu ;)
Nếu bạn làm việc chủ yếu ngoại tuyến với kho lưu trữ cục bộ, bạn không có bản sao lưu nếu bị mất thứ gì đó trên máy cục bộ. Với SVN, bạn chủ yếu làm việc với một kho lưu trữ từ xa, cũng là lúc sao lưu của bạn trên một máy chủ khác ... Git có thể hoạt động theo cách tương tự nhưng đây không phải là mục tiêu chính của Linus để có một cái gì đó giống như SVN2. Nó được thiết kế cho các nhà phát triển nhân Linux và nhu cầu của hệ thống kiểm soát phiên bản phân tán.
Git có tốt hơn SVN không? Các nhà phát triển chỉ cần một số lịch sử phiên bản và cơ chế sao lưu có cuộc sống tốt và dễ dàng với SVN. Các nhà phát triển làm việc thường xuyên với các chi nhánh, thử nghiệm nhiều phiên bản cùng một lúc hoặc làm việc chủ yếu ngoại tuyến có thể được hưởng lợi từ các tính năng của Git. Có một số tính năng rất hữu ích như không tìm thấy với SVN có thể giúp cuộc sống dễ dàng hơn. Nhưng mặt khác, không phải tất cả mọi người sẽ cần tất cả các tính năng. Vì vậy, tôi không thể nhìn thấy cái chết của SVN.
Git cần một số tài liệu tốt hơn và báo cáo lỗi phải hữu ích hơn. Ngoài ra các GUI hữu ích hiện có chỉ là hiếm khi. Lần này tôi chỉ tìm thấy 1 GUI cho Linux với sự hỗ trợ của hầu hết các tính năng Git (git-cola). Tích hợp Eclipse đang hoạt động nhưng nó không được phát hành chính thức và không có trang cập nhật chính thức (chỉ có một số trang cập nhật bên ngoài với các bản dựng định kỳ từ thân cây http://www.jgit.org/updates ) Vì vậy, cách ưa thích nhất để sử dụng Git ngày nay là dòng lệnh.
Eric Sink từ SourceGear đã viết một loạt bài viết về sự khác biệt giữa các hệ thống kiểm soát phiên bản phân tán và không phân phối. Ông so sánh ưu và nhược điểm của hầu hết các hệ thống kiểm soát phiên bản phổ biến. Đọc rất thú vị.
Bài viết có thể được tìm thấy trên blog của mình, www.ericsink.com :
Đối với những người tìm kiếm GUI Git tốt, Syntevo SmartGit có thể là một giải pháp tốt. Nó độc quyền, nhưng miễn phí cho sử dụng phi thương mại, chạy trên Windows / Mac / Linux và thậm chí hỗ trợ SVN bằng cách sử dụng một số loại cầu git-svn, tôi nghĩ vậy.
http://subversion.wandisco.com/component/content/article/1 / 40.html
Tôi nghĩ khá an toàn khi nói rằng trong số các nhà phát triển, SVN Vs. Đối số Git đã hoành hành một thời gian, với tất cả mọi người có quan điểm riêng của họ về cái nào tốt hơn. Điều này thậm chí đã được đưa ra trong các câu hỏi trong Hội thảo trên web của chúng tôi về Subversion năm 2010 và Beyond.
Hyrum Wright, Giám đốc Nguồn mở của chúng tôi và Chủ tịch của Subversion Corporation nói về sự khác biệt giữa Subversion và Git, cùng với các Hệ thống kiểm soát phiên bản phân tán (DVCS) khác.
Anh cũng nói về những thay đổi sắp tới trong Subversion, chẳng hạn như Work Copy Next Generation (WC-NG), mà anh tin rằng sẽ khiến một số người dùng Git chuyển đổi trở lại Subversion.
Hãy xem video của anh ấy và cho chúng tôi biết suy nghĩ của bạn bằng cách bình luận trên blog này hoặc bằng cách đăng trên diễn đàn của chúng tôi. Đăng ký rất đơn giản và sẽ chỉ mất một chút thời gian!
Git trong Windows hiện được hỗ trợ khá tốt.
Hãy xem GitExtensions = http://code.google.com.vn/p/gitextensions/
và hướng dẫn cho trải nghiệm Windows Git tốt hơn.
Gần đây tôi đã sống ở vùng đất Git và tôi thích nó cho các dự án cá nhân, nhưng tôi sẽ không thể chuyển đổi các dự án công việc sang nó từ Subversion vì sự thay đổi trong suy nghĩ cần thiết từ nhân viên, mà không có lợi ích cấp bách. Hơn nữa, dự án lớn nhất mà chúng tôi điều hành trong nhà phụ thuộc rất nhiều vào svn: externals , từ những gì tôi thấy cho đến nay, không hoạt động độc đáo và liền mạch trong Git.
Đầu tiên, kiểm soát phiên bản đồng thời có vẻ như là một vấn đề dễ giải quyết. Nó hoàn toàn không phải. Dù sao...
SVN khá không trực quan. Git thậm chí còn tồi tệ hơn. [mỉa mai-suy đoán] Điều này có thể là do các nhà phát triển, giống như các vấn đề khó khăn như kiểm soát phiên bản đồng thời, không quan tâm nhiều đến việc tạo ra một giao diện người dùng tốt. [/ mỉa mai-suy đoán]
Những người ủng hộ SVN nghĩ rằng họ không cần một hệ thống kiểm soát phiên bản phân tán. Tôi cũng nghĩ vậy. Nhưng bây giờ chúng tôi sử dụng Git độc quyền, tôi là một tín đồ. Bây giờ kiểm soát phiên bản hoạt động cho tôi VÀ nhóm / dự án thay vì chỉ làm việc cho dự án. Khi tôi cần một chi nhánh, tôi chi nhánh. Đôi khi, đó là một nhánh có một nhánh tương ứng trên máy chủ, và đôi khi không. Không đề cập đến tất cả các lợi thế khác mà tôi sẽ phải nghiên cứu (một phần nhờ vào giao diện người dùng thiếu phức tạp và vô lý đó là một hệ thống kiểm soát phiên bản hiện đại).
Tại sao tôi nghĩ Subversion tốt hơn Git (ít nhất là đối với các dự án tôi làm), chủ yếu là do tính khả dụng của nó và quy trình làm việc đơn giản hơn:
http://www.databaseandlife.com/why-subversion-is-better-than-git/