Tôi làm việc trong một bộ phận mà trước đây chưa có ai sử dụng kiểm soát nguồn, kể cả bản thân tôi.

Tôi đang cố gắng đẩy khái niệm. Tôi đã dành một chút thời gian nghiên cứu SVN. Tôi một số điều cơ bản đã học. Tôi có thể Tạo / cập nhật / kiểm tra / cam kết với dòng lệnh và từ Rùa. Tôi đang bắt đầu học cách gắn thẻ và phân nhánh nhưng vẫn nhầm lẫn rất nhiều về xung đột giữa các nhánh và thân cây, v.v. Tôi vẫn đang học, nhưng tôi không có một người vật lý nào có thể chỉ cho tôi bất cứ điều gì. Tất cả từ sách / hướng dẫn và thử nghiệm và lỗi.

Từ những gì tôi đã đọc trực tuyến có vẻ như gitlà điều tốt hơn để biết, nhưng nó cũng phức tạp hơn. Tôi không muốn áp đảo bản thân. Tôi có nên tiếp tục làm chủ svn trước khi chuyển sang git hay tôi sẽ khôn ngoan hơn khi chỉ nhảy sang git bây giờ?

Có những ưu và nhược điểm cho cả hai phương pháp?

Không

Git hoàn toàn khác với SVN, nó sẽ không giúp bạn. Nếu bất cứ điều gì bạn sẽ tìm kiếm các lệnh "cập nhật" và "cam kết" và tự hỏi tại sao mọi thứ đều khác nhau.

Bắt đầu với Git từ dưới lên và đi từ đó.

Đối chiếu một hệ thống phiên bản mô hình cập nhật / cam kết tập trung tiêu chuẩn với Git giống như so sánh một chiếc xe buýt với phương tiện giao thông đại chúng. Một xe buýt sẽ đưa bạn (và mọi người khác) từ điểm A đến điểm B sử dụng cùng một tuyến đường. Vận chuyển khối lượng lớn sẽ đưa bạn từ điểm A đến điểm B bằng bất kỳ tuyến đường nào bạn muốn.

Bản thân phân phối có những nhược điểm bạn nên chú ý. Phải mất nhiều công sức hơn để giữ tất cả mọi người trên cùng một trang. Nó cung cấp một sự gia tăng lớn trong tính linh hoạt mặc dù.

Sửa đổi băm so với số

Có người đã đề cập đến Git bằng cách sử dụng băm SHA1 trong khi Hg sử dụng số.

Trước tiên, bạn hiếm khi (nếu có) cần phải xử lý trực tiếp các giá trị băm trong các lần cam kết / kéo hàng ngày. Bạn cần phải kéo lên nhật ký và kéo băm nếu bạn đang làm khác hoặc một số mục nổi loạn khó khăn hơn.

Với Git, mọi người đều có băm giống nhau. Các kho lưu trữ khác nhau không có số cam kết khác nhau và mọi người đều ở trên cùng một trang. Với Hg thì điều này là ít. Trong thực tế, nếu bạn phải thực hiện băm cam kết và làm việc với chúng (để so sánh hoặc vượt qua dòng thời gian của mã), việc đồng bộ hóa với người khác khi bạn băm thay vì số sẽ dễ dàng hơn.

Không, xin đừng bận tâm.

Nghiêm túc, bắt đầu từ một DVCS. Thực tế là SVN phổ biến không làm cho nó trở thành tiêu chuẩn. Linus Torvalds sẽ nói với bạn rằng nó có thể làm hỏng não của bạn .

Đọc bài viết / giới thiệu tuyệt vời này của Joel Spolsky có tên Subversion Re-giáo dục .

Bạn cũng có thể quan tâm đến việc đọc câu hỏi khác này: Tôi là một người đam mê Subversion, tại sao tôi nên xem xét hoặc không xem xét Mercurial hoặc Git hoặc bất kỳ DVCS nào khác?

Lựa chọn giữa các DVCS

Cá nhân, tôi sử dụng cả đồng bóng và git, và tôi nghĩ rằng điều quan trọng là phải biết cả hai. Một cách đọc khuyến nghị về điều này là Git vs. Mercurial: Hãy thư giãn (xem ví dụ git-addremove). Hai trích dẫn từ bài báo mà tôi nghĩ rằng tổng hợp nó.

Về git:

Triết lý thiết kế của Git không thể nhầm lẫn với Unix: không giống như Subversion, CVS hay Mercurial, git không phải là một nhị phân nguyên khối mà là vô số các công cụ riêng lẻ, từ các lệnh của sứ sứ cấp độ cao như git-pull, git-merge và git-checkout với các lệnh cấp độ cao của hệ thống ống nước cấp độ cao như git-áp dụng, git-hash-object và git-merge-file. Vì vậy, giống như MacGyver, bạn có thể làm bất cứ điều gì bạn cần với Git - điều này bao gồm các công cụ Wiki hoàn toàn tuyệt vời, trình theo dõi vấn đề, hệ thống tệp, công cụ sysadmin - mọi thứ đều không thể sửa chữa cầu chì.

Về đồng bóng:

Các nhà phát triển muốn giữ cho hệ thống của họ sạch sẽ có thể sẽ đánh giá cao việc hg cài đặt một nhị phân trái ngược với 144 tạo nên git và các nhà phát triển nghĩ rằng khả năng chỉnh sửa các cam kết trước đó của bạn là sai lầm, không cần thiết và nguy hiểm sẽ đánh giá cao đơn giản hg cung cấp bằng cách bỏ qua tính năng cụ thể đó.

Rất nhiều dự án có thể được tìm thấy trên github và git mạnh hơn, nhưng nó cũng có thể hơi đáng sợ đối với người mới, đặc biệt là người dùng windows. Ngoài ra còn có bitbucket (github tương đương với đồng bóng).

Đề nghị của tôi: bắt đầu với đồng bóng và ngay khi bạn cảm thấy thoải mái với nó, hãy chọn git; nó không phải là về các công cụ, nó là về những người bạn làm việc cùng .

Những gì tôi cho là sử dụng thực tế và thực tế của lật đổ là, không phải để làm việc với người khác, mà có lẽ để thực hiện một trình cập nhật cho các ứng dụng sản xuất của bạn, đây là lý do:

• Hiện tại, svn gần như được cài đặt trong hầu hết các nhà cung cấp dịch vụ lưu trữ
• Có hỗ trợ tiểu dự án tốt (mặc dù địa chỉ trong git và hg bây giờ). svn upvà dự án của bạn và các phụ thuộc của nó được cập nhật.

Trích dẫn Thorbjørn về chủ đề khác này :

DVCS là để lật đổ, Bittorrent là gì để ftp

Chỉnh sửa : Nếu có một VCS bạn nên biết trước Git, đó có thể là Mercurial (giao diện CLI thân thiện hơn và tốt để được giới thiệu về các khái niệm phân tán). Lời khuyên này đặc biệt áp dụng cho những người đến từ Subversion vì CLI cũng tương tự ở một mức độ nào đó. Kiểm soát phiên bản phân tán có thể dễ học hơn Kiểm soát phiên bản tập trung, vì bạn chỉ lo lắng về trường hợp kho lưu trữ của mình và không tách rời các phần máy khách và máy chủ .

Bạn nên học những gì bạn định sử dụng. Git là phổ biến, giống như Mercurial cũng rất thích sự phổ biến. Git / Mercurial đều là các hệ thống kiểm soát nguồn phân tán.

Điều quan trọng nhất khi giới thiệu một khái niệm mới cho một nhóm (và thật không may là kiểm soát phiên bản được coi là một chủ đề mới cho quá nhiều nhóm), nó giúp phác thảo các mục tiêu và tiêu chí đánh giá của bạn. Bạn không cần phải quá chính thức về điều đó, nhưng hãy tự hỏi mình những câu hỏi sau:

• Mục đích của kiểm soát phiên bản trong nhóm của chúng tôi là gì . Có, tất cả các hệ thống kiểm soát phiên bản có giá trị bất cứ điều gì sẽ cho phép bạn quay lại lịch sử và xem những gì đã thay đổi trong bất kỳ tệp nào. Tuy nhiên, bạn sẽ sử dụng nó để làm cơ sở cho các bản phát hành mới? (gật đầu, bạn muốn điều này). Đây là tuyên bố tầm nhìn 2-3 dòng cho những gì bạn muốn thực hiện.
• Có phải nhóm của bạn đã từng có môi trường làm việc tại địa phương của riêng mình chỉ để hợp nhất mọi thứ một cách cẩn thận sau này? Nếu vậy, tuyến DVCS có thể có ý nghĩa nhất.
• Ngược lại, nhóm của bạn có từng làm việc từ một ổ đĩa chung và mọi thứ đều được tích hợp liên tục không? Nếu vậy, VCS truyền thống hơn có thể có ý nghĩa nhất.

Khi đánh giá các lựa chọn thay thế của bạn, bạn phải xem xét những điều quan trọng mà tất cả các VCS cần làm:

• Mã cơ sở (các chi nhánh được gắn thẻ, nhãn, v.v.). Về cơ bản, làm thế nào để bạn có được mã nguồn chính xác được sử dụng trong một bản phát hành dự án của bạn.
• Nhận thay đổi cục bộ đến máy chủ trung tâm. Cần phải có một bản sao có thẩm quyền của mã - cho dù bạn sử dụng DVCS hay VCS tiêu chuẩn. Mỗi công cụ xử lý quá trình này khác nhau.
• Nhận thay đổi trong máy chủ trung tâm để sao chép địa phương của bạn.
• Làm thế nào để đối phó với những thay đổi thử nghiệm. VCS cho phép bạn táo bạo hơn với các thay đổi được đề xuất mà không vi phạm mã nguồn dự án chính. Các hệ thống DVCS và VCS tiêu chuẩn tiếp cận điều này rất khác nhau - một trong những hệ thống sẽ hoạt động tốt nhất cho nhóm của bạn.
• Làm thế nào để bạn thiết lập và cấu hình các máy chủ?
• Bạn có cần xác thực? Nếu vậy, làm thế nào để bạn chắc chắn rằng chỉ những người được phép thực hiện thay đổi thực sự có thể?

Cuối cùng, hãy đánh giá nhanh để xác định xem các hệ thống VCS hoặc DVCS tiêu chuẩn sẽ là tốt nhất cho nhóm của bạn. Bạn sẽ phải chọn công cụ cung cấp ít đau nhất hoặc có thể sẽ không được chấp nhận. Sau đó, đánh giá các lựa chọn thay thế phù hợp nhất với nhu cầu của bạn.

Cuối cùng, tìm hiểu những gì bạn định sử dụng.

Tôi nghĩ rằng rất nhiều người thấy git phức tạp hơn svn vì nó khác. Sau khi sử dụng subversion (hoặc cvs, v.v.) trong một thời gian, có thể khó chuyển đổi các chế độ thành mô hình DVCS. Dựa vào đó, tôi có thể nói rằng nó có thể khiến bạn nghiên cứu các VCS truyền thống như lật đổ song song với việc nghiên cứu một DVCS như git.

Mặc dù git là VCS ưa thích của tôi, tôi sẽ nói rằng có lẽ tốt nhất là học lật đổ. Đối với một người, vẫn còn rất nhiều kho lưu trữ lật đổ và cvs mà bạn có thể phải tương tác với một ngày, và bạn cũng sẽ hiểu rõ hơn về những lợi thế và bất lợi chính xác của DVCS so với VCS truyền thống.

Nó sẽ phản tác dụng khi học svn và sau đó git

Dưới đây là một vài lý do:

• Gits hoàn toàn khác với svn. Git bị phân tâm và svn là máy khách / máy chủ.
• Ý nghĩa khác nhau được gắn liền với cùng một từ. Ví dụ: 'git checkout ...' có nghĩa khác với 'svn checkout ...'
• Sự phân nhánh là khác nhau. Git có khái niệm về các nhánh 'chủ đề' là các nhánh địa phương giá rẻ mà svn không hỗ trợ.
• Git có một vị trí bổ sung, được gọi là chỉ mục, nằm giữa cây làm việc và kho lưu trữ của bạn. Svn không có chỉ số. Sử dụng git các thay đổi của bạn chuyển từ cây làm việc của bạn sang chỉ mục vào kho lưu trữ.

Lời khuyên của tôi là chỉ học git.

Có một số điều tương tự như nhau trong GIT và SVN và một số thì không.

Tạo / cập nhật / thanh toán / cam kết

Nhìn chung, bạn nên chọn nó một cách dễ dàng.

Cách gắn thẻ và rẽ nhánh nhưng vẫn nhầm lẫn rất nhiều về xung đột giữa các nhánh và thân cây, v.v.

Khác nhau giữa hai người.

Không nói rằng bạn nên hoặc không nên thay đổi ngay bây giờ (tôi nghĩ đó là cuộc gọi của bạn), chỉ muốn chỉ ra rằng đó là điều cần phải tính đến. Nếu bạn chắc chắn muốn thử Git, bạn có thể quyết định chuyển đổi ngay bây giờ để tiết kiệm cho mình việc học một cái gì đó trong SVN khác với Git.

Ồ; 12 câu trả lời và mọi người vẫn đang cầu xin câu hỏi ...

Không, Subversion không phải là điều kiện tiên quyết cho Git.

Không có ánh xạ rõ ràng giữa Subversion và Git - nếu bạn có kế hoạch học cả hai, bạn sẽ phải chịu đựng thông qua việc họ sử dụng cùng một thuật ngữ cho các hành động khác nhau. (Và các điều khoản khác nhau cho cùng một hành động.)

• svn commitlà một điều khác biệt hơn git commit.
• các nhánh trong svn và git rất khác nhau
• một kho svn giống như một git remote (nhưng không thực sự)
• một kho git giống như một bản sao làm việc của svn (nhưng không thực sự)

Đây là hai công cụ được chia theo một ngôn ngữ chung.

Câu hỏi của bạn và hầu hết các câu trả lời khác, giả sử rằng git là một loại svn ++; Một "svn tốt hơn". Không phải vậy. Hai là những công cụ khác nhau hoạt động trong cùng một không gian, giống như ô tô và xe máy.

Tôi sẽ đề nghị bạn chọn một, làm chủ nó và bắt đầu sử dụng nó trong nhóm của bạn. Kiểm soát phiên bản học tập sẽ khó đối với những người chưa sử dụng nó trước đây. VCS của bạn sẽ là một phần quan trọng trong cơ sở hạ tầng của bạn và học cách tin tưởng nó liên quan đến việc xây dựng thói quen làm việc mới. Điều đó mất một lúc.

(Dù bằng cách nào, hãy đảm bảo rằng bạn có các hệ thống của bạn sao lưu kho lưu trữ chính - mất kiểm soát nguồn của bạn sẽ là thảm họa.)

Có lẽ là không - có đủ sự khác biệt giữa máy chủ dựa trên và phân phối mà có lẽ bạn chỉ làm bạn bối rối hơn nữa.

Đặt ra từ đầu để tuân theo thực tiễn tốt với DVCS mà bạn chọn như thể từ đầu và có lẽ bạn sẽ hạnh phúc hơn rất nhiều.

Hãy nhìn vào Mercurial (nếu bạn không muốn bị choáng ngợp).

Git chỉ phức tạp hơn một chút so với Subversion, bởi vì có một sự khác biệt trong Git giữa cam kết và đẩy vào kho lưu trữ trung tâm.

Thật đáng để học Git trong khi bạn có cơ hội để tâm trí của mình không bị lật đổ bởi Subversion.

Tôi không nghĩ hiểu Subversion là cần thiết để hiểu Git.

Sự khác biệt lớn nhất với Git và Mercurial từ Subversion, đối với tôi, ít nhất là, bạn có một kho lưu trữ cục bộ mà bạn làm việc cùng, bạn kiểm tra và ra khỏi đó cho đến khi mã của bạn hoạt động, kiểm tra từ repo trung tâm, khắc phục mọi xung đột và kiểm tra lại và đẩy đến máy chủ.

Tôi thực sự thích git trong môi trường Unix (Linux, MacOS X). Trong các cửa sổ, nó là một chút hacky. Tôi sẽ xem xét Mercurial nếu tôi có Windows trong phương trình.

Tôi bạn thích các lớp lịch sử của bạn, thử SCCS, RCS, CVS, Subversion và sau đó sử dụng một số thứ hữu ích như Git hoặc Mercurial.

Git và Mercurial là trang bị, phần thưởng lớn của Git là github . Nhưng nếu bạn không muốn thuê ngoài kiểm soát phiên bản của mình, github sẽ không còn trong phương trình.

Các hệ thống kiểm soát phiên bản chia sẻ một cái gì đó chung với các ngôn ngữ lập trình trong đó ngôn ngữ đầu tiên bạn học sẽ mất nhiều thời gian nhất. Sau đó, chọn một cái mới chỉ là vấn đề tìm hiểu làm thế nào các khái niệm cốt lõi được thể hiện bởi hệ thống mới.

Bạn có thể học Git ngay bây giờ và đầu tư thời gian vào việc học Suvbersion sau nếu bạn cần.

Không. Tải xuống Git, tạo tài khoản github và loay hoay trong vài ngày để tìm kiếm repos, v.v. Git khá tầm thường để bắt kịp tốc độ. Tìm hiểu 5 hoặc 6 lệnh bash và bạn có thể thực hiện tất cả các tác vụ thiết yếu. Tôi thường thích "tính chống đối" của GUI, nhưng Git Bash thì dễ như nó có. Ngoài ra, Git Gui là khá tốt nếu bạn thích tuyến đường đó. Tôi không thực sự thấy được lợi ích mà bạn sẽ thấy khi học SVN. Tôi đã trải qua một khoảng thời gian khi tôi đang đánh giá một vài hệ thống Kiểm soát Phiên bản khác nhau cho một dự án nguồn mở mới. Tôi đã thử SVN, Bazaar, Git, và một vài người khác và tìm hiểu những điều cơ bản của từng. YMMV, nhưng Git là xa dễ nhất. Không có gì sai khi học SVN cả, nhưng nó thực sự sẽ không giúp bạn học Git.