DVCS nào (git hoặc hg) dễ dàng hơn cho sinh viên lập trình? [đóng cửa]

Một chút bối cảnh: Tôi đang học năm thứ 3 đại học. sinh viên được chia thành các nhóm 4. Hầu hết mọi người sẽ làm việc dưới cửa sổ (ngoại trừ một số ít như tôi trên linux). Là một phần của chương trình giảng dạy ở trường, chúng tôi sẽ sớm bắt đầu thực hiện một dự án cho một khách hàng thực sự, nhưng tôi và một nhóm khác đang tự hỏi cách nào sẽ là tốt nhất để chia sẻ mã của chúng tôi với nhau.

Tôi đã làm việc bán thời gian trong 3 năm và đã có nhiều kinh nghiệm sử dụng cả git và đồng bóng cho các dự án khác nhau, vì vậy tôi không gặp vấn đề gì khi sử dụng hệ thống này hay hệ thống khác. Tuy nhiên, không ai trong số các đồng đội của tôi đã từng sử dụng hệ thống kiểm soát phiên bản trước đây. Ngoài ra còn có một nhóm khác đã thử sử dụng SVN nhưng gặp vấn đề lớn và muốn thử một thứ khác, vì vậy họ đã hỏi ý kiến ​​của tôi.

Suy nghĩ của tôi: Tôi đã nghe nói rằng mercurial + TortoiseHg có sự tích hợp tốt hơn dưới các cửa sổ, nhưng tôi tự hỏi liệu khái niệm về những cái đầu ẩn danh có thể làm họ bối rối ngay cả khi tôi giải thích chúng. Mặt khác, tôi thấy rằng các nhánh git dễ hiểu hơn cho người mới bắt đầu (phân chia công việc rõ ràng cho mỗi lập trình viên) nhưng không hoạt động tốt dưới cửa sổ.

Không nghi ngờ gì nữa.

Điều này là tất nhiên, chủ quan và vaires từ người này sang người khác, nhưng ý kiến ​​chung là Mercurial dễ dàng hơn để tìm hiểu, đặc biệt là một người mới đến với VCS hoặc ai đó đến từ một trong những thế hệ cũ của VCS.

Điểm trong tay:

1. Mercurial được phát triển với Windows trong tâm trí ; Git đã được chuyển. Bất kể ai cố gắng nói với tôi, Git vẫn là công dân hạng hai trên Windows. Mọi thứ đã được cải thiện một cách chắc chắn trong vài năm qua, nhưng bạn vẫn thấy rất nhiều tranh cãi về lý do tại sao một cái gì đó hoạt động / hoặc không hoạt động trên Windows như nó đã làm trên hộp * nix. TortoiseHg hoạt động rất độc đáo và việc triển khai Visual Studio thậm chí còn dễ sử dụng hơn mà không phá vỡ quy trình làm việc của bạn.

2. Nếu ai đó bắt đầu cuộc thảo luận "Git mạnh hơn sau bạn ...", thì anh ta sẽ nói lên tất cả. Đối với 95% người dùng Mercurial có vẻ trực quan hơn. Bắt đầu từ việc thiếu chỉ mục, đến các tùy chọn trực quan hơn (các công tắc tùy chọn được kết hợp chặt chẽ), đến các số địa phương để xác nhận thay vì băm SHA1 (ai đã từng nghĩ băm SHA1 thân thiện với người dùng ??!)

3. Các chi nhánh của Mercurial không kém gì Git. Bài viết mô tả một số khác biệt. Quay trở lại một số sửa đổi trước đây cũng đơn giản như "cập nhật sửa đổi cũ". Bắt đầu từ đó; chỉ cần làm một cam kết mới. Chi nhánh được đặt tên cũng có sẵn nếu một người muốn sử dụng chúng.

Bây giờ, tôi biết rằng tất cả những thứ này là chi tiết, và chúng có thể được học và mọi thứ, nhưng điều là ... những thứ này cộng lại. Và cuối cùng, một cái có vẻ đơn giản và trực quan hơn cái khác. Và hệ thống kiểm soát phiên bản không nên là thứ mà người ta dành thời gian để học - bạn ở đó để học lập trình và sau đó là lập trình; VCS là một công cụ.

Chỉ cần lưu ý; Tôi sử dụng Git và Mercurial hàng ngày. Đừng gặp khó khăn khi sử dụng một trong số chúng. Nhưng khi ai đó hỏi tôi về một lời khuyên, tôi luôn đề nghị Mercurial. Vẫn còn nhớ, khi nó lần đầu tiên vào tay tôi, nó cảm thấy rất trực quan. Theo kinh nghiệm của tôi, Mercurial chỉ tạo ra ít WTF / phút hơn Git.

Tôi đã thấy rằng TortoiseHg UI là một trải nghiệm tuyệt vời trên Windows. Khi thử nghiệm với Git trong quá khứ, cuối cùng tôi đã đi đến dòng lệnh. Đối với người dùng trung bình của bạn, một giao diện người dùng tốt dễ tiếp cận hơn nhiều so với một dòng lệnh. Vì vậy, tôi khuyên bạn nên sử dụng Mercurial. (Nó cũng bao gồm một biểu đồ nhánh đẹp trong cửa sổ bàn làm việc. Nó sẽ xóa bất kỳ khó khăn phân nhánh cơ bản nào.)

Khi họ hiểu mọi thứ từ phối cảnh UI, cuối cùng họ có thể đi đến dòng lệnh để viết kịch bản hoặc thực hiện các thao tác thủ công - nhưng họ không cần phải làm vậy.

Nếu bạn quan tâm đến lựa chọn thứ ba, tôi sẽ đề xuất hóa thạch . Tôi tìm thấy khả năng đưa lên một máy chủ web tạm thời để chia sẻ mã hoạt động tuyệt vời trong các dự án nhỏ. Fossil chỉ là một tệp thực thi, vì vậy bạn có thể đặt nó và nguồn của bạn vào một ổ đĩa ngón tay cái, và sử dụng nó từ bất kỳ máy tính đại học nào.

Sử dụng fossil uiđể bắt đầu một máy chủ web tạm thời mọi lúc mọi nơi để các sinh viên của bạn đồng bộ hóa với bạn. Nó cũng cung cấp cho bạn một hệ thống vé, wiki và giao diện web dễ sử dụng để thay đổi các chi nhánh và gắn thẻ cam kết.

Chỉ cần chắc chắn rằng họ đọc hướng dẫn bắt đầu nhanh , và / hoặc cuốn sách . Cuối cùng, có một dự án gọi là winFossil để cung cấp cho họ giao diện người dùng thân thiện hơn so với web ui.

Cho rằng các đội là người mới đối với việc kiểm soát phiên bản và nhiều người đang sử dụng Windows, tôi khuyên bạn nên đồng ý với git.

Mô hình khái niệm về kiểm soát phiên bản được sử dụng bởi git và mercurial rất giống nhau, vì vậy khi bạn đã thành thạo một cái, bạn có thể dễ dàng chọn cái khác (và vì lý do tương tự, khá dễ dàng để chuyển đổi kho lưu trữ từ cái này sang cái khác) . Điều này có nghĩa là nó không phải là một vấn đề lớn nếu bạn thay đổi tâm trí của bạn sau này.

Theo tôi, người dùng mới dễ học hơn. Nó làm cho những điều đơn giản trở nên dễ dàng, và những điều nguy hiểm khó khăn. Git làm cho các hoạt động nguy hiểm trở nên dễ dàng (dễ làm, không nhất thiết phải dễ thực hiện!).

Giao diện TortoiseHg cho Winodows cũng rất đẹp và là một đối số khác có lợi cho việc sử dụng đồng bóng.

Sở thích cá nhân của tôi là cho git.

Tuy nhiên, vì một số người sẽ sử dụng windows và hướng dẫn hginit tuyệt vời tồn tại, tôi khuyên bạn nên dạy họ một cách đồng bóng.

Như nhiều người đã đề xuất, Mercurial thông qua TortoiseHg có rào cản rất thấp để vào.

Đối với những người dùng trên Windows, đó là một trình cài đặt duy nhất chứ không phải hai trình cài đặt (và toàn bộ nội dung mà họ có thể không muốn tìm hiểu) và giao diện người dùng THg bóng bẩy hơn nhiều so với TortoiseGit + Msysgit .

Người đứng đầu ẩn danh

Nếu bạn nghĩ rằng họ sẽ bị nhầm lẫn bởi những người đứng đầu ẩn danh, thì đừng khuyến khích họ sử dụng. Hầu hết các hgcuốn sách có một cách tiếp cận cân bằng và dạy cả hai nhánh tôpô và có tên, và để người đọc xác định cái nào phù hợp nhất cho việc sử dụng chúng.

Chi nhánh được đặt tên

Một điều tôi thực sự nhớ gitlà hgcác nhánh được đặt tên , vì vậy đó là một lựa chọn. gitcác nhánh vẫn ổn trong khi bạn đang làm việc với chúng, nhưng một khi bạn đã hợp nhất công việc đó vào một nhánh khác, bạn sẽ mất nhiều bối cảnh cho những thay đổi đó.

Trong hgbạn có thể tạo một nhánh được gọi Jira#1234và luôn có thể tìm thấy tất cả các sửa đổi liên quan đến sửa chữa đó . Trong git, một khi chi nhánh của bạn được hợp nhất và ref bị xóa, bạn phải suy ra bản sửa đổi nào là một phần của bản sửa lỗi từ cấu trúc liên kết của cây sửa đổi. Ngay cả khi bạn không xóa ref, bạn vẫn chỉ biết cam kết cuối cùng trên nhánh đó, chứ không phải tổ tiên của nó là một phần của chuỗi cam kết đó.

Dấu trang

Ngoài ra, nếu bạn không muốn sử dụng các nhánh được đặt tên, nhưng muốn một gitquy trình làm việc theo phong cách với các nhánh ẩn danh của mình, thì bạn có thể sử dụng dấu trang thay thế.

Điều này có thể là tốt nhất của cả hai thế giới - họ có thể học một gitquy trình công việc, nhưng có thể sử dụng các hglệnh đơn giản hơn .

Khu vực Index / Cache / Staging

Cá nhân, tôi nghĩ rằng các sinh viên có nhiều khả năng bị nhầm lẫn bởi khu vực gitchỉ mục / bộ nhớ cache / khu vực so với hgcác đầu ẩn danh. Tôi rất thích hglàm cho chức năng nâng cao này tùy chọn trên dòng lệnh, theo cách gitgiả định bạn luôn muốn / cần sử dụng nó.

Tôi cũng nghĩ rằng khu vực tổ chức khuyến khích các cam kết chưa được thử nghiệm hoặc thậm chí được biên soạn. Vì nhiều trong những nơi tôi đã làm việc đã có một không cam kết nếu nó không biên dịch quy tắc, tôi sẽ có nhiều thay xiên / stash thay đổi Tôi không muốn ngay bây giờ, kiểm tra đơn vị tái chạy và cam kết một phiên bản Tôi biết biên dịch.

Khi bạn đến sau để theo dõi một lỗi bằng cách sử dụng hg bisect hoặc git bisect , bạn sẽ cảm ơn chính mình rằng bạn có thể kiểm tra tất cả các bản sửa đổi, không chỉ các bản sửa đổi.