Tại sao Mercurial được coi là dễ dàng hơn Git?

Khi nhìn vào các so sánh, đối với tôi, dường như có thể có ánh xạ 1: 1 giữa các bộ tính năng của chúng. Tuy nhiên, một tuyên bố thường được trích dẫn là "Mercurial dễ dàng hơn". Cơ sở của tuyên bố này là gì? (nếu có)

Case in point: Hãy nói rằng bạn muốn thay đổi tên người dùng trên tất cả các cam kết trước đó của bạn. Tôi cần phải làm điều này nhiều lần vì nhiều lý do.

Phiên bản Git

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

Phiên bản Mercurial:

tập tin tác giả.convert.list:

<oldname>=<newname>

Dòng lệnh:

hg convert --authors authors.convert.list SOURCE DEST

Bây giờ, cái nào trông dễ sử dụng hơn?

Lưu ý: Tôi đã dành 2 năm chỉ làm việc với Git, vì vậy đây không phải là câu nói "Tôi ghét nó, tôi đã không nhận được nó trong 2 giây".

Đối với tôi, đó là khả năng sử dụng. Git rất định hướng linux với cách làm linux. Điều đó có nghĩa là dòng lệnh, trang người đàn ông và tự mình tìm ra nó. Nó có một GUI rất kém (lưu ý: Tôi dựa trên msysGit từ khoảng một năm trước), điều đó dường như chỉ cản trở tôi. Tôi chỉ có thể sử dụng nó

Dòng lệnh tệ hơn. Là một chương trình định hướng Linux, trên Windows rất khó sử dụng. Thay vì một cổng bản địa, họ chỉ đơn giản là git với MinGW (Think cygwin), khiến việc làm việc với nó trở nên khó khăn hơn nhiều. MinGW không phải là Windows Command Prompt và chỉ hoạt động khác nhau. Thật điên rồ khi đây là cách duy nhất để làm việc với Git. Ngay cả trong Linux, dường như cách duy nhất là làm việc với dòng lệnh thẳng. Các dự án như RabbitVCS đã giúp một số, nhưng không mạnh mẽ lắm.

Cách tiếp cận hướng dòng lệnh và là một chương trình linux có nghĩa là hầu hết tất cả các hướng dẫn cách làm, tài liệu trợ giúp và các câu hỏi diễn đàn / QA đều dựa vào việc chạy các lệnh quái dị như trên. Các lệnh SCM cơ bản (cam kết, kéo, đẩy) không phức tạp, nhưng bất kỳ sự phức tạp nào cũng tăng theo cấp số nhân.

Tôi cũng ghét một nơi mà rất nhiều người dùng OSS git dường như quanh quẩn: Github. Khi bạn lần đầu tiên vào một trang github, nó sẽ đánh sập bạn với mọi thứ bạn có thể làm. Đối với tôi, một trang git dự án trông hỗn loạn, đáng sợ và quá mạnh mẽ. Ngay cả lời giải thích về những gì dự án là, được đẩy xuống dưới cùng. Github thực sự gây tổn thương cho những người chưa thiết lập trang web đầy đủ. Theo dõi vấn đề của nó cũng là khủng khiếp và khó hiểu. Tính năng quá tải.

Người dùng Git dường như cũng rất sùng bái. Người dùng Git dường như luôn là những người bắt đầu "thánh chiến" về việc DVCS nào tốt hơn, sau đó buộc người dùng Mercurial phải tự vệ. Các trang web như http://whygitisbetterthanx.com/ thể hiện sự kiêu ngạo và tâm lý gần như "Sử dụng phần mềm của tôi hoặc chết". Nhiều lần tôi đã đi đến nhiều nơi giúp đỡ chỉ để được biết đến vì không biết X, sử dụng X trước, sử dụng Windows, v.v. Thật điên rồ.

Mặt khác, Mercurial dường như đi theo hướng tiếp cận tử tế hơn. Trang chủ của riêng họ có vẻ thân thiện hơn với người dùng mới so với Git . Trong một tìm kiếm đơn giản của Google, kết quả thứ 5 là TortoiseHg, một GUI rất đẹp cho Mercurial. Toàn bộ cách tiếp cận của họ dường như là sự đơn giản trước, sức mạnh sau.

Với Mercurial tôi không có SSH vô nghĩa (SSH là địa ngục trên Windows), tôi không có các lệnh phức tạp ngu ngốc, tôi không có người dùng sùng bái, tôi không có sự điên rồ. Mercurial chỉ hoạt động.

TortoiseHg cung cấp một giao diện thực sự có thể sử dụng được (mặc dù gần đây nó dường như đang phát triển) cung cấp các tính năng thực sự hữu ích. Các tùy chọn được giới hạn ở những gì bạn cần, loại bỏ sự lộn xộn và các tùy chọn hiếm khi được sử dụng. Nó cũng cung cấp nhiều mặc định tốt

Mercurial, rất thân thiện với những người mới đến, rất dễ nhận. Ngay cả một số chủ đề phức tạp hơn như mô hình phân nhánh khác nhau và chỉnh sửa lịch sử cũng rất dễ theo dõi. Tôi nhặt Mercurial nhanh chóng và không đau đớn.

Mercurial cũng chỉ hoạt động lần đầu tiên với ít thiết lập. Trên BẤT K OS hệ điều hành nào, tôi chỉ có thể cài đặt TortoiseHg và nhận tất cả các tính năng tôi muốn (chủ yếu là các lệnh trình đơn ngữ cảnh) mà không cần phải tìm kiếm các Guis khác nhau. Cũng thiếu là thiết lập SSH (một nửa trong số các hướng dẫn ngoài kia nói rằng hãy sử dụng Putty, Plink và Pagent trong khi nửa còn lại nói sử dụng ssh-keygen). Đối với người dùng mới, TortoiseHg mất vài phút để thiết lập trong khi Git mất 30 phút đến một giờ với rất nhiều thông tin.

Cuối cùng, bạn có repos trực tuyến. Tương đương với Github là BitBucket, có một số vấn đề tôi đã nêu ở trên. Tuy nhiên, cũng có Google Code. Khi tôi đi đến một dự án Google Code , tôi không bị quá tải tính năng, tôi có một giao diện sạch đẹp. Google Code giống như một kết hợp repo / trang web trực tuyến, điều này thực sự giúp các dự án OSS không có thiết lập trang web hiện có. Tôi sẽ cảm thấy rất thoải mái khi sử dụng Google Code làm trang web dự án của mình trong một thời gian khá dài, chỉ xây dựng một trang web khi thực sự cần thiết. Trình theo dõi vấn đề của nó cũng rất mạnh mẽ, phù hợp độc đáo giữa Trình theo dõi vấn đề gần như vô dụng của Github và sự quái dị của Bugzilla .

Mercurial chỉ hoạt động, lần đầu tiên, mọi lúc. Git cản đường tôi và chỉ khiến tôi tức giận hơn khi sử dụng nó.

Git so với Mercurial

Mercurial thường được cho là đơn giản và dễ học hơn Git. Đổi lại, thường có nhận thức rằng Git linh hoạt và mạnh mẽ hơn. Điều này một phần là do Git có xu hướng cung cấp nhiều lệnh cấp thấp hơn, nhưng cũng một phần vì Mercurial mặc định có xu hướng ẩn các tính năng nâng cao , để người dùng chỉnh sửa tệp cấu hình đồng bóng để kích hoạt các tính năng nâng cao mà họ thích. Điều này thường dẫn đến nhận thức rằng các tính năng nâng cao không có sẵn trong Mercurial.

Khái niệm Git

Mercurial luôn tập trung nhiều hơn vào các khía cạnh giao diện, điều này làm cho nó ban đầu dễ học hơn. So với Git, cần có sự hiểu biết nông hơn để hoạt động với Mercurial một cách hữu ích. Về lâu dài, việc đóng gói như vậy đã mang lại cho Mercurial vẻ ngoài giả tạo là kém mạnh mẽ và đặc trưng hơn so với thực tế.

Bối cảnh: Tôi sử dụng cả Mercurial (cho công việc) và Git (cho các dự án phụ và nguồn mở) hàng ngày. Tôi chủ yếu sử dụng các công cụ dựa trên văn bản với cả hai (không phải IDE) và tôi đang dùng Mac.

Nói chung, tôi thấy Mercurial dễ làm việc hơn. Một vài điều mà tôi thấy làm cho Mercurial dễ dàng hơn:

1. Thiếu chỉ số. Chỉ mục là một công cụ mạnh mẽ cho phép nhiều tính năng của Git nhưng nó cũng là một lớp bổ sung thêm một bước vào nhiều việc tôi làm thường xuyên. Quy trình làm việc của Mercurial tương tự như svn.
2. Số sửa đổi thay vì shas. Đây là một điều nhỏ mà tôi thấy làm cho công việc hàng ngày trở nên dễ dàng hơn rất nhiều trong Mercurial. Cách dễ dàng hơn để đẩy một vài số sửa đổi vào đầu của bạn trong quá trình rebase, hợp nhất, v.v. trong khi viết lệnh hơn là thực hiện tương tự với các shas thậm chí rút ngắn.
3. Chi nhánh. Cách tiếp cận của Git với các chi nhánh bằng cách đặt tên cho các cam kết là mạnh mẽ và khác biệt đáng kể so với các hệ thống kiểm soát phiên bản khác. Nó làm cho một số điều dễ dàng hơn rất nhiều. Tôi thấy rằng cách tiếp cận của Mercurial phù hợp với suy nghĩ của svn tốt hơn một chút và giúp dễ hiểu trực quan hơn về lịch sử chi nhánh. Đây có thể chỉ là một sở thích.

Điều này rất chủ quan và phụ thuộc từ người này sang người khác, nhưng vâng, tôi sẽ chuyển nó cho một người hoàn toàn mới đối với VCS hoặc ai đó đến từ một trong những VCS "trường học cũ", Mercurial sẽ có vẻ dễ dàng hơn.

Ví dụ, thêm tệp, sự không tồn tại của chỉ mục trong Hg, dễ dàng quay lại một số sửa đổi cũ và phân nhánh từ đó (chỉ cần cập nhật và cam kết) như một số ví dụ "rõ ràng" nhất. Bây giờ hầu hết các tính năng của một hệ thống có thể được mô phỏng theo hệ thống khác và ngược lại, nhưng điều đó đòi hỏi một số kiến ​​thức về Git, trong khi ở Mercurial, mặc định (nếu bạn cho phép tôi gọi chúng là) khá "thân thiện với người dùng". Những điều nhỏ nhặt đó - công tắc ở đây và kia, hành vi không rõ ràng trong một lệnh và cứ thế ... những thứ này cộng lại, và cuối cùng, một hệ thống có vẻ dễ sử dụng hơn hệ thống kia.

Chỉ để làm cho câu trả lời đầy đủ; Tôi sử dụng git, nhưng khi giới thiệu một VCS cho ai đó "mới đối với họ", tôi hầu như luôn khuyên dùng Mercurial. Tôi 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 tạo ra ít wtf / phút hơn Git.

Tôi nghĩ nó đơn giản như thế này: Mercurial có một cú pháp quen thuộc hơn (đặc biệt đối với người dùng SVN) và được ghi lại khá tốt. Khi bạn đã quen với cú pháp Git, bạn sẽ thấy nó dễ sử dụng như mọi thứ khác.

Nhận thức có thể thay đổi theo thời gian, về điều này. Mercurial được thiết kế rất tốt, và Git cũng vậy. Mercurial dường như dễ học hơn (ít nhất là đối với tôi), và đã có những khó khăn mà tôi gặp phải trong Git, rằng tôi không có song song với Mercurial. Tôi đã cố gắng học Python và Ruby và ngày càng nhanh hơn với Python. Điều đó không có nghĩa là Python luôn luôn và ở mọi nơi tốt hơn Ruby, hoặc thậm chí nó tốt hơn cho tôi. Đó chỉ là những gì tôi học được và bị mắc kẹt. Các lập trình viên thường thực hiện các cuộc chiến thần thánh ngoài sở thích cá nhân. Những người khác cũng làm điều đó.

Tôi là một người dùng đồng bóng, người cố gắng giữ quan điểm cởi mở về Git và tôi tự do thừa nhận rằng nó không "trở thành thứ yêu thích mới của tôi" ở cùng mức độ với Mercurial. Tôi nghĩ rằng Git thực sự thực sự tốt đẹp mặc dù.

Một ví dụ ngược lại cho độ phức tạp của GIT / đồng bóng: Hỗ trợ GIT đẹp được tích hợp vào XCode, trên Mac. XCode ít dễ sử dụng hơn với Mercurial so với GIT.

Kinh nghiệm của tôi với GIT cho đến nay là tôi bị lẫn lộn và bị mất và cần phải tham khảo tài liệu nhiều hơn trong khi sử dụng nó. Tôi tin rằng rất nhiều tài liệu đã được viết, nhưng không có gì cho phép tôi "mò mẫm" nó. Thứ hai, tôi có thể sửa đổi và mở rộng Mercurial một cách dễ dàng trong Python và khi tôi thành thạo Python và vì bất kỳ ai thực sự có thể học được python một cách nhanh chóng, nó có vẻ là một lợi thế đối với tôi. Tôi cũng biết C và viết các phần mở rộng Python trong C, vì vậy tôi cho rằng một ngày nào đó, nếu tôi cần, tôi có thể dễ dàng viết một phần mở rộng Git bằng C.

Dễ sử dụng không phải là một cái gì đó dễ dàng để định lượng. Nó ở đó, và tôi không nghĩ nó hoàn toàn chủ quan, nhưng chúng ta không có kỹ thuật đo lường khách quan tốt. Các đơn vị để dễ sử dụng là gì? Milli-iPod?

Tôi không quá đảng phái đến mức ủng hộ 100% và chống git 100%. Tôi cảm thấy thoải mái hơn trên Mercurial ngay bây giờ, trên Windows và Linux và khi tôi bắt đầu làm nhiều công việc Mac hơn, tôi hy vọng rằng tôi sẽ cố gắng gắn bó với XCode + GIT.

Cập nhật 2013: Bây giờ tôi đã sử dụng Mercurial VÀ GIT đủ lâu để tìm thấy một số tính năng mà tôi muốn nó có Git, chẳng hạn như câu hỏi này về các chiến lược hợp nhất. Thực sự Git là tuyệt vời, nếu khó học, và đôi khi phức tạp điên cuồng.

Có một vài điều mà IMO có khả năng đưa người dùng mới ra khỏi Git:

1. Văn hóa Git là trung tâm dòng lệnh nhiều hơn. Mặc dù cả hai công cụ thường có xu hướng tập trung quá nhiều vào dòng lệnh (như tôi đã nói nhiều lần, các hướng dẫn dòng lệnh có thể mạnh mẽ và trôi chảy hơn, nhưng chúng không phải là một chiến lược tiếp thị tốt ), điều này hoàn toàn đúng với Git. Trong khi Mercurial có một công cụ GUI tiêu chuẩn thực tế trong TortoiseHg, thậm chí là tùy chọn tải xuống mặc định cho người dùng Windows trên trang chủ Mercurial, Git có một số giao diện GUI cạnh tranh (TortoiseGit, Git Tiện ích mở rộng, gitk, v.v.) không được quảng cáo tốt trên trang web Git, và tất cả đều là một đôi mắt hoàn chỉnh. (Văn bản màu đen trên nhãn màu đỏ? C'mon, TortoiseGit, bạn có thể làm tốt hơn thế!) Ngoài ra còn có một thái độ phổ biến hơn nhiều trong cộng đồng Git rằng những người sử dụng công cụ GUI không phải là nhà phát triển phần mềm thích hợp.

2. Git có một số mặc định vượt trội có ý nghĩa hoàn hảo đối với người dùng cao cấp, nhưng có thể gây ngạc nhiên nếu không khiến người dùng mới sợ hãi. Ví dụ, việc tự động hóa các tác vụ như hợp nhất sẽ mạnh hơn nhiều (ví dụ: git pull sẽ tự động hợp nhất và cam kết khi có thể). Có một trường hợp cho việc hợp nhất hoàn toàn tự động , nhưng hầu hết người dùng thiếu kinh nghiệm đều sợ việc sáp nhập và cần có cơ hội để có được niềm tin vào các công cụ của họ trước khi giải phóng toàn bộ sức mạnh của họ về mã nguồn.

3. Tài liệu và sự phức tạp vốn có:

   $ hg help log | wc -l
   64
   $ git help log | wc -l
   912
   

Một điều tôi có thể nghĩ là

git add .
git commit -am "message"

so với

hg ci -Am "message"

git commit -akhông thêm các tệp mới được tạo hg ci -A, điều đó có nghĩa là một cái gì đó yêu cầu hai lệnh với git có thể được thực hiện bằng một lệnh trong Mercurial. Sau đó, một lần nữa, "ít gõ" không nhất thiết có nghĩa là "thân thiện với người dùng hơn".

Bởi vì nó là.

Git phơi bày nhiều hơn rất nhiều so với ruột của nó. Bạn có thể vui vẻ sử dụng mercurial trong vài phút sau khi nhặt nó lên nhưng tôi thấy git vẫn rất khó khăn để vật lộn với nó sau vài tháng vật lộn với nó (tôi đã làm rất ít trong vài tháng qua ngoài việc cố gắng học git ). Tôi đang sử dụng cả hai từ dòng lệnh và chủ yếu là trên Linux vì vậy đây không chỉ là sự ác cảm với giao diện dòng lệnh.

Một ví dụ đơn giản là tương đối ít cờ và đối số dòng lệnh cần thiết cho đồng bóng so với git. Khu vực tổ chức và hành vi của lệnh add trong git cũng làm tăng thêm độ phức tạp hơn mức cần thiết. Bộ ba thiết lập lại, kiểm tra và hoàn nguyên và nhiều hoán vị của chúng làm tăng thêm sự phức tạp to lớn, điều này khá không cần thiết khi bạn chứng kiến ​​bản chất đơn giản của hoàn nguyên và cập nhật trên đồng bóng.

Tôi đồng ý với nhận xét trên cũng về Hginit , nó chắc chắn làm cho dễ hiểu hơn nhiều. Được viết tốt và rất dễ hiểu. Không có tài liệu nào viết cho git đến gần. Tôi cho một, tìm thấy hầu hết những gì được viết bởi Scott Chacone (người đã tự tay viết hầu hết các tài liệu / sách về git) đặc biệt khó hiểu.