Tôi nên sử dụng SVN hay Git? [đóng cửa]

Tôi đang bắt đầu một dự án phân phối mới. Tôi nên sử dụng SVN hay Git, và tại sao?

SVN là một repo và rất nhiều khách hàng. Git là một repo với rất nhiều repos khách hàng, mỗi repos có một người dùng. Nó được phân cấp đến một điểm mà mọi người có thể theo dõi các chỉnh sửa của riêng họ mà không cần phải đẩy mọi thứ sang một máy chủ bên ngoài.

SVN được thiết kế để tập trung hơn, trong đó Git dựa trên mỗi người dùng có repo Git của riêng họ và những repos đó đẩy các thay đổi trở lại thành trung tâm. Vì lý do đó, Git cung cấp cho cá nhân kiểm soát phiên bản địa phương tốt hơn.

Trong khi đó, bạn có sự lựa chọn giữa TortoiseGit , GitExtensions (và nếu bạn lưu trữ kho git "trung tâm" của mình trên github, ứng dụng khách của riêng họ - GitHub cho Windows ).

Nếu bạn đang tìm cách thoát khỏi SVN, bạn có thể muốn đánh giá Bazaar một chút. Đây là một trong những thế hệ hệ thống kiểm soát phiên bản tiếp theo có yếu tố phân tán này. Nó không phụ thuộc POSIX như git nên có các bản dựng Windows gốc và nó có một số thương hiệu nguồn mở mạnh mẽ ủng hộ nó.

Nhưng bạn thậm chí có thể không cần các loại tính năng này. Có một cái nhìn về các tính năng, ưu điểm và nhược điểm của các VCS phân tán . Nếu bạn cần nhiều hơn SVN cung cấp, hãy xem xét một. Nếu bạn không, bạn có thể muốn gắn bó với tích hợp máy tính để bàn vượt trội (hiện tại) của SVN.

Tôi chưa bao giờ hiểu khái niệm "git không tốt trên Windows"; Tôi phát triển độc quyền trong Windows và tôi chưa bao giờ có bất kỳ vấn đề nào với git.

Tôi chắc chắn sẽ đề nghị git trên lật đổ; nó chỉ đơn giản là linh hoạt hơn rất nhiều và cho phép "phát triển ngoại tuyến" theo cách lật đổ không bao giờ thực sự có thể. Nó có sẵn trên hầu hết mọi nền tảng có thể tưởng tượng và có nhiều tính năng hơn bạn có thể sử dụng.

Đây là bản sao câu trả lời tôi đã tạo từ một số câu hỏi trùng lặp kể từ đó đã bị xóa về Git so với SVN (tháng 9 năm 2009).

Tốt hơn? Ngoài liên kết thông thường WhyGitIsBetterThanX , chúng khác nhau:

một là một VCS trung tâm dựa trên bản sao giá rẻ cho các chi nhánh và thẻ còn lại (Git) là một VCS phân tán dựa trên biểu đồ sửa đổi. Xem thêm các khái niệm cốt lõi của VCS .

Phần đầu tiên đó đã tạo ra một số ý kiến ​​thông tin sai lệch giả vờ rằng mục đích cơ bản của hai chương trình (SVN và Git) là như nhau, nhưng chúng đã được thực hiện hoàn toàn khác nhau.
Để làm rõ sự khác biệt cơ bản giữa SVN và Git , hãy để tôi nói lại:

• SVN là triển khai thứ ba của kiểm soát sửa đổi : RCS, sau đó là CVS và cuối cùng là SVN quản lý các thư mục của dữ liệu được phiên bản. SVN cung cấp các tính năng VCS (ghi nhãn và hợp nhất), nhưng thẻ của nó chỉ là một bản sao thư mục (như một nhánh, ngoại trừ bạn không "được cho là" chạm vào bất cứ thứ gì trong thư mục thẻ) và hiện tại việc hợp nhất của nó vẫn phức tạp, dựa trên meta -data thêm vào để nhớ những gì đã được hợp nhất.

• Git là một quản lý nội dung tệp (một công cụ được tạo để hợp nhất các tệp), được phát triển thành Hệ thống kiểm soát phiên bản thực , dựa trên một cam kết DAG ( Biểu đồ chu kỳ được điều hướng ), trong đó các nhánh là một phần của lịch sử dữ liệu (chứ không phải là dữ liệu ) và trong đó các thẻ là một siêu dữ liệu thực sự.

Để nói rằng chúng không "khác biệt" về cơ bản bởi vì bạn có thể đạt được cùng một điều, giải quyết cùng một vấn đề, là ... hoàn toàn sai trên nhiều cấp độ.

• nếu bạn có nhiều sự hợp nhất phức tạp, thực hiện chúng với SVN sẽ lâu hơn và dễ bị lỗi hơn. nếu bạn phải tạo nhiều nhánh, bạn sẽ cần quản lý chúng và hợp nhất chúng, một lần nữa dễ dàng hơn với Git so với SVN, đặc biệt là nếu có nhiều tệp có liên quan (tốc độ trở nên quan trọng)
• nếu bạn đã hợp nhất một phần cho một tác phẩm đang diễn ra, bạn sẽ tận dụng khu vực (chỉ mục) của Git để chỉ cam kết những gì bạn cần, bỏ phần còn lại và chuyển sang một nhánh khác.
• nếu bạn cần phát triển ngoại tuyến ... tốt với Git, bạn luôn "trực tuyến", với kho lưu trữ cục bộ của riêng bạn, bất kể quy trình công việc bạn muốn theo với các kho lưu trữ khác.

Vẫn còn những bình luận về câu trả lời cũ (đã xóa) nhấn mạnh:

VonC: Bạn đang nhầm lẫn sự khác biệt cơ bản trong việc thực hiện (sự khác biệt là rất cơ bản, cả hai chúng tôi đều đồng ý rõ ràng về điều này) với sự khác biệt về mục đích.
Cả hai đều là các công cụ được sử dụng cho cùng một mục đích: đây là lý do tại sao nhiều nhóm trước đây đã sử dụng SVN đã khá thành công có thể kết xuất nó theo hướng có lợi cho Git.
Nếu họ không giải quyết vấn đề tương tự, sự thay thế này sẽ không tồn tại.

, mà tôi đã trả lời:

"thay thế" ... thuật ngữ thú vị ( được sử dụng trong lập trình máy tính ).
Dĩ nhiên, Git hầu như không phải là một kiểu con của SVN.

Bạn có thể đạt được các tính năng kỹ thuật giống nhau (thẻ, nhánh, hợp nhất) với cả hai, nhưng Git không cản trở bạn và cho phép bạn tập trung vào nội dung của các tệp mà không cần suy nghĩ về chính công cụ.

Bạn chắc chắn không thể (luôn luôn) chỉ thay thế SVN bằng Git "mà không thay đổi bất kỳ thuộc tính mong muốn nào của chương trình đó (tính chính xác, nhiệm vụ được thực hiện, ...)" (tham chiếu đến định nghĩa thay thế đã nói ở trên ):

• Một là một công cụ sửa đổi mở rộng, cái còn lại là một hệ thống kiểm soát phiên bản thực sự.
• Một là phù hợp với dự án nguyên khối từ nhỏ đến trung bình với quy trình hợp nhất đơn giản và các phiên bản song song (không quá nhiều). SVN là đủ cho mục đích đó và bạn có thể không cần tất cả các tính năng Git.
• Cái còn lại cho phép các dự án từ trung bình đến lớn dựa trên nhiều thành phần ( một repo cho mỗi thành phần ), với số lượng lớn tệp để hợp nhất giữa nhiều nhánh trong một quy trình hợp nhất phức tạp, các phiên bản song song trong các nhánh, hợp nhất trang bị thêm, v.v. Bạn có thể làm điều đó với SVN, nhưng bạn tốt hơn nhiều với Git.
  SVN đơn giản là không thể quản lý bất kỳ dự án nào với bất kỳ quy trình hợp nhất nào. Git có thể.

Một lần nữa, bản chất của chúng là khác nhau về cơ bản (sau đó dẫn đến việc thực hiện khác nhau nhưng đó không phải là vấn đề).
Một người xem kiểm soát sửa đổi dưới dạng thư mục và tệp, người còn lại chỉ xem nội dung của tệp (nhiều đến mức các thư mục trống thậm chí sẽ không đăng ký trong Git!).

Mục tiêu chung chung có thể giống nhau, nhưng bạn không thể sử dụng chúng theo cùng một cách, cũng như bạn không thể giải quyết cùng một loại vấn đề (về phạm vi hoặc độ phức tạp).

2 ưu điểm chính của SVN hiếm khi được trích dẫn:

1. Hỗ trợ tập tin lớn. Ngoài mã, tôi sử dụng SVN để quản lý thư mục nhà của tôi. SVN là VCS duy nhất (được phân phối hoặc không) không bị sặc trên các tệp TrueCrypt của tôi (vui lòng sửa lại cho tôi nếu có một VCS khác xử lý các tệp 500MB + hiệu quả). Điều này là do các so sánh khác nhau được truyền phát (đây là một điểm rất cần thiết). Không thể chấp nhận Rupync vì đây không phải là 2 chiều.

2. Kho lưu trữ một phần (subir) kiểm tra / checkin. Mercurial và bzr không hỗ trợ điều này và hỗ trợ của git bị hạn chế. Điều này là xấu trong môi trường nhóm, nhưng vô giá nếu tôi muốn kiểm tra một cái gì đó trên một máy tính khác từ thư mục nhà của tôi.

Chỉ là kinh nghiệm của tôi.

Sau khi nghiên cứu thêm và xem xét liên kết này: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Một số trích đoạn dưới đây):

• Nó cực kỳ nhanh. Không có SCM nào khác mà tôi đã sử dụng có thể theo kịp nó và tôi đã sử dụng rất nhiều, bao gồm Subversion, Perforce, darcs, BitKeeper, ClearCase và CVS.
• Nó được phân phối đầy đủ. Chủ sở hữu kho lưu trữ không thể ra lệnh cho cách tôi làm việc. Tôi có thể tạo các nhánh và cam kết thay đổi trong khi ngắt kết nối trên máy tính xách tay của mình, sau đó đồng bộ hóa nó với bất kỳ số lượng kho lưu trữ nào khác.
• Đồng bộ hóa có thể xảy ra trên nhiều phương tiện truyền thông. Một kênh SSH, qua HTTP thông qua WebDAV, bằng FTP hoặc bằng cách gửi email giữ các bản vá để người nhận thư áp dụng. Một kho lưu trữ trung tâm không cần thiết, nhưng có thể được sử dụng.
• Chi nhánh thậm chí còn rẻ hơn so với Subversion. Tạo một nhánh đơn giản như viết một tệp 41 byte vào đĩa. Xóa một nhánh cũng đơn giản như xóa tệp đó.
• Không giống như các nhánh Subversion mang theo lịch sử hoàn chỉnh của họ. mà không phải thực hiện một bản sao lạ và đi qua bản sao. Khi sử dụng Subversion tôi luôn thấy khó xử khi nhìn vào lịch sử của một tệp trên nhánh xảy ra trước khi nhánh được tạo. từ #git: spearce: Tôi không hiểu một điều về SVN trong trang. Tôi đã tạo một nhánh i SVN và duyệt lịch sử cho thấy toàn bộ lịch sử một tệp trong nhánh
• Hợp nhất chi nhánh đơn giản hơn và tự động hơn trong Git. Trong Subversion, bạn cần nhớ bản sửa đổi cuối cùng mà bạn đã hợp nhất là gì để bạn có thể tạo lệnh hợp nhất chính xác. Git làm điều này tự động, và luôn luôn làm đúng. Điều đó có nghĩa là ít có cơ hội phạm sai lầm khi hợp nhất hai nhánh lại với nhau.
• Sự hợp nhất chi nhánh được ghi lại như một phần của lịch sử thích hợp của kho lưu trữ. Nếu tôi hợp nhất hai nhánh lại với nhau hoặc nếu tôi hợp nhất một nhánh lại vào thân cây, thì hoạt động hợp nhất đó được ghi lại như một phần của lịch sử đăng lại như đã được tôi thực hiện và khi nào. Thật khó để tranh cãi ai đã thực hiện hợp nhất khi nó ở ngay trong nhật ký.
• Tạo một kho lưu trữ là một hoạt động tầm thường: mkdir foo; cd foo; git init Đó là nó. Điều đó có nghĩa là tôi tạo một kho lưu trữ Git cho mọi thứ hiện nay. Tôi có xu hướng sử dụng một kho lưu trữ cho mỗi lớp. Hầu hết các kho lưu trữ đó đều dưới 1 MB trong đĩa vì chúng chỉ lưu trữ các bài giảng, bài tập về nhà và câu trả lời LaTeX của tôi.
• Các định dạng tập tin nội bộ của kho lưu trữ là đơn giản đáng kinh ngạc. Điều này có nghĩa là sửa chữa rất dễ thực hiện, nhưng thậm chí còn tốt hơn bởi vì nó rất đơn giản, rất khó để bị hỏng. Tôi không nghĩ ai đã từng có kho Git bị hỏng. Tôi đã thấy Subversion với fsfs tham nhũng chính nó. Và tôi đã thấy Berkley DB đã tự làm hỏng quá nhiều lần để tin tưởng mã của tôi vào phần phụ trợ bdb của Subversion.
• Định dạng tệp của Git rất tốt trong việc nén dữ liệu, mặc dù đó là định dạng rất đơn giản. Kho lưu trữ CVS của dự án Mozilla có dung lượng khoảng 3 GB; đó là khoảng 12 GB ở định dạng fsfs của Subversion. Trong Git, nó có dung lượng khoảng 300 MB.

Sau khi đọc tất cả những điều này, tôi tin rằng Git là con đường để đi (mặc dù có một chút đường cong học tập tồn tại). Tôi cũng đã sử dụng Git và SVN trên các nền tảng Windows.

Tôi muốn nghe những gì người khác nói sau khi đọc những điều trên?

Tôi sẽ thiết lập một kho lưu trữ Subversion. Bằng cách thực hiện theo cách này, các nhà phát triển cá nhân có thể chọn sử dụng máy khách Subversion hoặc máy khách Git (có git-svn). Việc sử dụng git-svnkhông mang lại cho bạn tất cả lợi ích của giải pháp Git đầy đủ, nhưng nó mang lại cho các nhà phát triển cá nhân rất nhiều quyền kiểm soát đối với quy trình làm việc của riêng họ.

Tôi tin rằng sẽ mất một thời gian tương đối ngắn trước khi Git hoạt động tốt như trên Windows cũng như trên Unix và Mac OS X (kể từ khi bạn hỏi).

Subversion có các công cụ tuyệt vời cho Windows, chẳng hạn như tích hợp TortoiseSVN cho Explorer và AnkhSVN cho tích hợp Visual Studio.

Đ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:

1. Tôi có thể làm việc phân phối trên một số máy, cam kết và kéo từ và đến chúng
2. Tôi có một kho svn trung tâm backup/public để người khác kiểm tra
3. Và họ được tự do sử dụng Git cho riêng mình

Không thực sự trả lời câu hỏi của bạn nhưng nếu bạn muốn những lợi ích của Kiểm soát sửa đổi phân tán - có vẻ như bạn làm - và bạn đang sử dụng Windows Tôi nghĩ rằng bạn nên sử dụng Mercurial thay vì Git vì Mercurial hỗ trợ Windows tốt hơn nhiều. Mercurial cũng có cổng Mac.

Nếu nhóm của bạn đã quen thuộc với các phần mềm kiểm soát nguồn và phiên bản như cvs hoặc svn, thì, đối với một dự án đơn giản và nhỏ (như bạn khẳng định là như vậy), tôi khuyên bạn nên sử dụng SVN. Tôi thực sự thoải mái với svn, nhưng đối với dự án thương mại điện tử hiện tại tôi đang làm trên django, tôi đã quyết định làm việc trên git (tôi đang sử dụng git trong chế độ svn, nghĩa là với một repo tập trung mà tôi đẩy tới và kéo từ để cộng tác với ít nhất một nhà phát triển khác). Nhà phát triển khác cảm thấy thoải mái với SVN và trong khi trải nghiệm của những người khác có thể khác nhau, cả hai chúng tôi đang có khoảng thời gian thực sự tồi tệ khi ôm lấy git cho dự án nhỏ này. (Chúng tôi đều là những người dùng Linux khó tính, nếu có vấn đề gì cả.)

Mileage của bạn có thể thay đổi, tất nhiên.

Chắc chắn svn, vì Windows là người giỏi nhất, một công dân hạng hai trong thế giới git(xem http://en.wikipedia.org/wiki/Git_(software)#Portability để biết thêm chi tiết).

CẬP NHẬT: Xin lỗi vì liên kết bị hỏng, nhưng tôi đã từ bỏ việc cố gắng để SO hoạt động với các URI có chứa dấu ngoặc đơn. [liên kết cố định ngay bây giờ. -ed]

Điểm chính là, Git là một VCS phân tán và Subversion là một tập trung. Các VCS phân tán khó hiểu hơn một chút, nhưng có nhiều ưu điểm. Nếu bạn không cần lợi thế này, Subversion có thể là sự lựa chọn tốt hơn.

Một câu hỏi khác là hỗ trợ công cụ. VCS nào được hỗ trợ tốt hơn bởi các công cụ bạn dự định sử dụng?

EDIT: Ba năm trước tôi đã trả lời theo cách này:

Và Git hoạt động trên Windows tại thời điểm này chỉ thông qua Cygwin hoặc MSYS . Subversion hỗ trợ Windows ngay từ đầu. Vì các giải pháp git cho windows có thể phù hợp với bạn, có thể có vấn đề, vì hầu hết các nhà phát triển Git đều làm việc với Linux và không có tính di động ngay từ đầu. Hiện tại tôi muốn Subversion để phát triển trong Windows. Trong một vài năm điều này có thể không liên quan.

Bây giờ thế giới đã thay đổi một chút. Git đã thực hiện tốt trên các cửa sổ bây giờ. Mặc dù tôi đã thử nghiệm không đầy đủ trên các cửa sổ (vì tôi không còn sử dụng hệ thống này nữa), tôi khá tự tin, rằng tất cả các VCS chính (SVN, Git, Mercurial, Bazaar) đều có triển khai Windows đúng cách. Lợi thế này cho SVN không còn nữa. Các điểm khác (Tập trung so với Phân phối và kiểm tra hỗ trợ công cụ) vẫn hợp lệ.

Tôi sẽ chọn SVN vì nó được phổ biến rộng rãi hơn và được biết đến nhiều hơn.

Tôi đoán, Git sẽ tốt hơn cho người dùng Linux.

Git chưa được hỗ trợ nguyên bản trong Windows. Nó được tối ưu hóa cho các hệ thống Posix. Tuy nhiên, việc chạy Cygwin hoặc MinGW cho phép bạn chạy Git thành công.

Ngày nay tôi thích Git hơn SVN, nhưng phải mất một thời gian để vượt qua ngưỡng nếu bạn đến từ CVS, đất SVN.

Tôi có lẽ sẽ chọn Git vì tôi cảm thấy nó mạnh hơn SVN rất nhiều. Có những dịch vụ Code Hosting giá rẻ có sẵn, rất phù hợp với tôi - bạn không phải thực hiện sao lưu hoặc bất kỳ công việc bảo trì nào - GitHub là ứng cử viên rõ ràng nhất.

Điều đó nói rằng, tôi không biết gì về việc tích hợp Visual Studio và các hệ thống SCM khác nhau. Tôi tưởng tượng sự tích hợp với SVN để tốt hơn đáng kể.

Tôi đã sử dụng SVN trong một thời gian dài, nhưng bất cứ khi nào tôi sử dụng Git, tôi cảm thấy rằng Git rất mạnh mẽ, nhẹ, và mặc dù có một chút đường cong học tập liên quan nhưng tốt hơn SVN.

Điều tôi đã lưu ý là mỗi dự án SVN, khi nó phát triển, sẽ trở thành một dự án có quy mô rất lớn trừ khi nó được xuất khẩu. Trong đó, dự án GIT (cùng với dữ liệu Git) có kích thước rất nhẹ.

Ở SVN, tôi đã giao dịch với các nhà phát triển từ người mới đến chuyên gia và người mới và người trung gian dường như đưa ra xung đột Tệp nếu họ sao chép một thư mục từ dự án SVN khác để sử dụng lại. Trong khi đó, tôi nghĩ trong Git, bạn chỉ cần sao chép thư mục và nó hoạt động, bởi vì Git không giới thiệu các thư mục .git trong tất cả các thư mục con của nó (như SVN làm).

Sau khi giao dịch rất nhiều với SVN từ lâu, cuối cùng tôi cũng nghĩ sẽ chuyển các nhà phát triển của tôi và tôi sang Git, vì nó dễ dàng hợp tác và hợp nhất công việc, cũng như một lợi thế lớn là các thay đổi của bản sao cục bộ có thể được cam kết nhiều mong muốn, và cuối cùng được đẩy đến chi nhánh trên máy chủ trong một lần, không giống như SVN (nơi chúng ta phải thực hiện các thay đổi theo thời gian trong kho lưu trữ trên máy chủ).

Bất cứ ai có thể giúp tôi quyết định xem tôi có thực sự nên đi với Git không?

Nó đi xuống này:

Sự phát triển của bạn sẽ là tuyến tính? Nếu vậy, bạn nên gắn bó với Subversion.

Mặt khác, sự phát triển của bạn sẽ không tuyến tính, điều đó có nghĩa là bạn sẽ cần tạo phân nhánh cho các thay đổi khác nhau và sau đó hợp nhất các thay đổi đó trở lại dòng phát triển chính (được gọi là Git là nhánh chính), Git sẽ làm NHIỀU hơn cho bạn.

bạn đã thử Bzr chưa?

Nó khá tốt, theo nghĩa bóng (những người tạo ra Ubuntu) đã tạo ra nó bởi vì họ không thích bất cứ thứ gì khác trên thị trường ...

Tôi có thể mở rộng câu hỏi và hỏi liệu Git có hoạt động tốt trên MacOS không?

Trả lời Nhận xét: Cảm ơn tin tức, tôi đã mong chờ được dùng thử. Tôi sẽ cài đặt nó ở nhà trên máy Mac của tôi.

Có một video thú vị trên YouTube về điều này. Đó là từ chính Linus Torwalds: Goolge Tech Talk: Linus Torvalds trên git

SVN có vẻ như là một lựa chọn tốt trong Windows, như được chỉ ra bởi những người khác.

Nếu một số nhà phát triển của bạn muốn thử GIT, nó có thể luôn sử dụng GIT-SVN nơi kho lưu trữ SVN được tạo lại trong kho lưu trữ GIT. Sau đó, anh ta có thể làm việc cục bộ với GIT và sau đó sử dụng SVN để xuất bản các thay đổi của nó lên kho lưu trữ chính.

Bạn phải đi với một DVCS, nó giống như một bước nhảy vọt trong quản lý nguồn. Cá nhân tôi sử dụng Monotone và thời gian phát triển của nó không tăng. Chúng tôi đang sử dụng nó cho Windows, Linux và Mac và nó đã rất ổn định. Tôi thậm chí có buildbot thực hiện các bản dựng hàng đêm của dự án trên mỗi nền tảng.

DVCS trong khi được phân phối thường có nghĩa là bạn sẽ tạo một máy chủ trung tâm chỉ để mọi người đẩy các thay đổi đến và đi.