Tôi đã sử dụng git một thời gian trên Windows (với msysGit) và tôi thích ý tưởng kiểm soát nguồn phân tán. Mới gần đây tôi đã nhìn vào Mercurial (hg) và nó có vẻ thú vị. Tuy nhiên, tôi không thể che giấu sự khác biệt giữa hg và git.
Có ai đã thực hiện một so sánh song song giữa git và hg? Tôi quan tâm để biết những gì khác nhau hg và git mà không cần phải tham gia vào một cuộc thảo luận fanboy.
Câu trả lời:
Những bài viết này có thể giúp:
Chỉnh sửa : So sánh Git và Mercurial với những người nổi tiếng dường như là một xu hướng. Đây là một trong những:
Tôi làm việc trên Mercurial, nhưng về cơ bản tôi tin rằng cả hai hệ thống đều tương đương nhau. Cả hai đều hoạt động với cùng một sự trừu tượng: một loạt các ảnh chụp nhanh (bộ thay đổi) tạo nên lịch sử. Mỗi bộ thay đổi biết nó đến từ đâu (bộ thay đổi cha mẹ) và có thể có nhiều bộ thay đổi con. Phần mở rộng hg-git gần đây cung cấp một cầu nối hai chiều giữa Mercurial và Git và loại hiển thị điểm này.
Git tập trung mạnh vào việc làm thay đổi biểu đồ lịch sử này (với tất cả các hậu quả gây ra) trong khi Mercurial không khuyến khích viết lại lịch sử, nhưng dù sao cũng dễ thực hiện và hậu quả của việc đó là chính xác những gì bạn nên mong đợi (đó là , nếu tôi sửa đổi một bộ thay đổi mà bạn đã có, khách hàng của bạn sẽ thấy nó là mới nếu bạn lấy từ tôi). Vì vậy, Mercurial có sự thiên vị đối với các lệnh không phá hủy.
Đối với các nhánh trọng lượng nhẹ, thì Mercurial đã hỗ trợ các kho lưu trữ với nhiều nhánh kể từ ..., tôi luôn nghĩ vậy. Kho lưu trữ Git với nhiều nhánh chính xác là: nhiều chuỗi phát triển được phân kỳ trong một kho lưu trữ duy nhất. Git sau đó thêm tên vào các chuỗi này và cho phép bạn truy vấn các tên này từ xa. Các dấu mở rộng cho Mercurial cho biết thêm tên địa phương, và với Mercurial 1.6, bạn có thể di chuyển các bookmark xung quanh khi bạn đẩy / kéo ..
Tôi sử dụng Linux, nhưng rõ ràng TortoiseHg nhanh hơn và tốt hơn Git tương đương trên Windows (do sử dụng tốt hơn hệ thống tệp Windows kém). Cả http://github.com và http://bitbucket.org đều cung cấp dịch vụ lưu trữ trực tuyến, dịch vụ tại Bitbucket rất tuyệt vời và đáp ứng (Tôi chưa thử github).
Tôi đã chọn Mercurial vì nó cảm thấy sạch sẽ và thanh lịch - Tôi đã bị loại bỏ bởi các kịch bản shell / Perl / Ruby mà tôi có với Git. Hãy thử xem qua git-instaweb.shtệp nếu bạn muốn biết ý của tôi: đó là tập lệnh shell tạo tập lệnh Ruby , mà tôi nghĩ là chạy máy chủ web. Kịch bản shell tạo ra một kịch bản shell khác để khởi chạy tập lệnh Ruby đầu tiên. Ngoài ra còn có một chút Perl , cho biện pháp tốt.
Tôi thích bài đăng trên blog so sánh Mercurial và Git với James Bond và MacGyver - Mercurial bằng cách nào đó ít quan trọng hơn Git. Dường như với tôi, những người sử dụng Mercurial không dễ bị ấn tượng như vậy. Điều này được phản ánh trong cách mỗi hệ thống thực hiện những gì Linus mô tả là "sự hợp nhất tuyệt vời nhất!" . Trong Git, bạn có thể hợp nhất với một kho lưu trữ không liên quan bằng cách thực hiện:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
Những lệnh đó trông khá phức tạp đối với mắt tôi. Trong Mercurial, chúng tôi làm:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Lưu ý cách các lệnh Mercurial hoàn toàn đơn giản và không đặc biệt - điều khác thường duy nhất là --forcecờ hg pull, điều này là cần thiết vì Mercurial sẽ hủy bỏ nếu bạn lấy từ một kho lưu trữ không liên quan. Chính sự khác biệt như thế này khiến Mercurial có vẻ thanh lịch hơn đối với tôi.
git pull <url-of-project>. thư bạn trích dẫn là từ những ngày đầu của git (2005)
Git là một nền tảng, Mercurial là một ứng dụng. Git là một nền tảng hệ thống tập tin được phiên bản xuất hiện cùng với ứng dụng DVCS trong hộp, nhưng như bình thường đối với các ứng dụng nền tảng, nó phức tạp hơn và có các cạnh khó khăn hơn so với các ứng dụng tập trung. Nhưng điều này cũng có nghĩa là VCS của git rất linh hoạt và có một số lượng lớn những thứ không kiểm soát nguồn mà bạn có thể làm với git.
Đó là bản chất của sự khác biệt.
Git được hiểu rõ nhất từ đầu lên - từ định dạng kho lưu trữ lên. Git Talk của Scott Chacon là một mồi tuyệt vời cho việc này. Nếu bạn cố gắng sử dụng git mà không biết chuyện gì đang xảy ra dưới mui xe, đôi khi bạn sẽ bối rối (trừ khi bạn chỉ sử dụng chức năng rất cơ bản). Điều này nghe có vẻ ngu ngốc khi tất cả những gì bạn muốn là một DVCS cho thói quen lập trình hàng ngày của bạn, nhưng thiên tài của git là định dạng kho lưu trữ thực sự rất đơn giản và bạn có thể hiểu toàn bộ hoạt động của git khá dễ dàng.
Đối với một số so sánh định hướng kỹ thuật hơn, các bài viết hay nhất tôi từng thấy là Dustin Sallings ':
Anh ấy thực sự đã sử dụng cả hai DVCS và hiểu cả hai - và cuối cùng thích git hơn.
Sự khác biệt lớn là trên Windows. Mercurial được hỗ trợ nguyên bản, Git không. Bạn có thể nhận được lưu trữ rất giống với github.com với bitbucket.org (thực sự thậm chí còn tốt hơn khi bạn có một kho lưu trữ riêng miễn phí). Tôi đã sử dụng msysGit một thời gian nhưng đã chuyển sang Mercurial và rất hài lòng với nó.
Nếu bạn là nhà phát triển Windows đang tìm kiếm kiểm soát sửa đổi bị ngắt kết nối cơ bản, hãy đi với Hg. Tôi thấy Git không thể hiểu được trong khi Hg đơn giản và được tích hợp tốt với Windows shell. Tôi đã tải xuống Hg và làm theo hướng dẫn này (hginit.com) - mười phút sau tôi có một repo địa phương và đã trở lại để làm việc trong dự án của tôi.
Tôi nghĩ rằng mô tả tốt nhất về "Mercurial vs. Git" là:
Chúng gần như giống hệt nhau. Sự khác biệt quan trọng nhất, theo quan điểm của tôi (ý tôi là, lý do khiến tôi chọn một DVCS khác) là cách hai chương trình quản lý các chi nhánh.
Để bắt đầu một nhánh mới, với Mercurial, bạn chỉ cần sao chép kho lưu trữ vào một thư mục khác và bắt đầu phát triển. Sau đó, bạn kéo và hợp nhất. Với git, bạn phải đặt tên rõ ràng cho nhánh chủ đề mới mà bạn muốn sử dụng, sau đó bạn bắt đầu mã hóa bằng cùng một thư mục .
Nói tóm lại, mỗi chi nhánh trong Mercurial cần thư mục riêng; trong git bạn thường làm việc trong thư mục duy nhất. Chuyển nhánh trong Mercurial có nghĩa là thay đổi thư mục; trong git, nó có nghĩa là yêu cầu git thay đổi nội dung của thư mục bằng kiểm tra git.
Tôi thành thật: Tôi không biết liệu có thể làm điều tương tự với Mercurial hay không, nhưng vì tôi thường làm việc trên các dự án web, nên việc sử dụng cùng một thư mục với git dường như rất khó hiểu đối với tôi, vì tôi không phải làm lại -Có cấu hình Apache và khởi động lại nó và tôi không làm rối hệ thống tập tin của mình mỗi khi tôi phân nhánh.
Chỉnh sửa: Như Deestan đã lưu ý, Hg đã đặt tên các nhánh , có thể được lưu trữ trong một kho lưu trữ duy nhất và cho phép nhà phát triển chuyển đổi các nhánh trong cùng một bản sao làm việc. Các nhánh git không hoàn toàn giống với các nhánh có tên Mercurial, dù sao đi nữa: chúng là vĩnh viễn và không vứt bỏ các nhánh, như trong git. Điều đó có nghĩa là nếu bạn sử dụng một nhánh có tên cho các nhiệm vụ thử nghiệm ngay cả khi bạn quyết định không bao giờ hợp nhất thì nó sẽ được lưu trữ trong kho lưu trữ. Đó là lý do tại sao Hg khuyến khích sử dụng bản sao cho các tác vụ thử nghiệm, chạy ngắn và các nhánh được đặt tên cho các tác vụ chạy dài, như cho các nhánh phát hành.
Lý do tại sao rất nhiều người dùng Hg trước đó nhân bản trên chi nhánh được đặt tên là xã hội hoặc văn hóa hơn nhiều so với kỹ thuật. Ví dụ, với các phiên bản Hg cuối cùng, thậm chí có thể đóng một nhánh được đặt tên và loại bỏ đệ quy siêu dữ liệu khỏi các thay đổi.
Mặt khác, git mời sử dụng "các nhánh được đặt tên" không cố định và không được lưu trữ dưới dạng siêu dữ liệu trên mỗi bộ thay đổi.
Theo quan điểm cá nhân của tôi, sau đó, mô hình của git được liên kết sâu sắc với khái niệm các nhánh được đặt tên và chuyển đổi giữa một nhánh và một nhánh khác trong cùng một thư mục; hg có thể làm tương tự với các nhánh được đặt tên, nhưng nó khuyến khích việc sử dụng bản sao, mà cá nhân tôi không thích quá nhiều.
Có một sự khác biệt lớn giữa git và đồng bóng ; cách đại diện cho mỗi cam kết. git đại diện cho các cam kết như ảnh chụp nhanh, trong khi đồng bóng đại diện cho chúng là khác biệt.
Điều này có ý nghĩa gì trong thực tế? Vâng, nhiều hoạt động nhanh hơn trong git, chẳng hạn như chuyển sang một cam kết khác, so sánh các cam kết, v.v ... Đặc biệt nếu các cam kết này ở xa.
AFAIK không có lợi thế trong cách tiếp cận của đồng bóng.
Không có gì. Cả hai đều làm như vậy, cả hai thực hiện như nhau. Lý do duy nhất bạn nên chọn cái này hơn cái kia là nếu bạn giúp đỡ với một dự án đã sử dụng một ..
Lý do có thể khác để chọn một ứng dụng là một ứng dụng hoặc dịch vụ chỉ hỗ trợ một trong các hệ thống .. Ví dụ: tôi đã chọn học git vì github ..
Ngoài ra so sánh của google (mặc dù nó hơi cũ, được thực hiện vào năm 2008)
Nếu tôi hiểu họ một cách chính xác (và tôi cách xa một chuyên gia về từng người) thì về cơ bản, mỗi người có một triết lý khác nhau. Lần đầu tiên tôi sử dụng thủy ngân trong 9 tháng. Bây giờ tôi đã sử dụng git cho 6.
hg là phần mềm kiểm soát phiên bản. Mục tiêu chính của nó là theo dõi các phiên bản của một phần mềm.
git là một hệ thống tập tin dựa trên thời gian. Mục tiêu của nó là thêm một chiều khác cho một hệ thống tệp. Hầu hết có tập tin và thư mục, git thêm thời gian. Rằng nó hoạt động tuyệt vời vì một VCS là sản phẩm phụ của thiết kế.
Trong hg, có một lịch sử của toàn bộ dự án mà nó luôn cố gắng duy trì. Theo mặc định, tôi tin rằng hg muốn tất cả các thay đổi cho tất cả các đối tượng bởi tất cả người dùng khi đẩy và kéo.
Trong git chỉ có một nhóm các đối tượng và các tệp theo dõi này (các nhánh / đầu) xác định tập hợp các đối tượng đó đại diện cho cây các tệp ở trạng thái cụ thể. Khi đẩy hoặc kéo git chỉ gửi các đối tượng cần thiết cho các nhánh cụ thể mà bạn đang đẩy hoặc kéo, đó là một tập hợp nhỏ của tất cả các đối tượng.
Theo như git có liên quan thì không có "1 dự án". Bạn có thể có 50 dự án trong cùng một repo và git sẽ không quan tâm. Mỗi người có thể được quản lý riêng trong cùng một repo và sống tốt.
Khái niệm chi nhánh của Hg là các chi nhánh ngoài dự án chính hoặc các chi nhánh ngoài chi nhánh, vv Git không có khái niệm đó. Một nhánh trong git chỉ là một trạng thái của cây, mọi thứ đều là một nhánh trong git. Chi nhánh nào là chính thức, hiện tại hoặc mới nhất không có ý nghĩa gì trong git.
Tôi không biết điều đó có ý nghĩa gì không. Nếu tôi có thể vẽ hình ảnh hg có thể trông như thế này trong đó mỗi cam kết là mộto
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Một cái cây với một gốc và các nhánh mọc ra từ nó. Trong khi git có thể làm điều đó và mọi người thường sử dụng nó theo cách đó không được thi hành. Một hình ảnh git, nếu có một điều như vậy, có thể dễ dàng trông như thế này
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
Trong thực tế, theo một số cách, nó thậm chí không có ý nghĩa để hiển thị các nhánh trong git.
Một điều rất khó hiểu cho các cuộc thảo luận, cả git và đồng bóng đều có một thứ gọi là "nhánh" nhưng chúng không phải là những thứ giống nhau. Một nhánh trong đồng bóng xuất hiện khi có xung đột giữa các repos khác nhau. Một nhánh trong git rõ ràng tương tự như một bản sao trong hg. Nhưng một bản sao, trong khi nó có thể cho hành vi tương tự chắc chắn là không giống nhau. Hãy xem xét tôi thử những thứ này trong git vs hg bằng cách sử dụng repo crom khá lớn.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
Và bây giờ trong hg sử dụng bản sao
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
Cả hai đều là chạy nóng. Tức là tôi đã chạy chúng hai lần và đây là lần chạy thứ hai. hg clone thực sự giống như git-new-workdir. Cả hai đều tạo ra một thư mục làm việc hoàn toàn mới gần như thể bạn đã gõ cp -r project project-clone. Điều đó không giống như tạo ra một nhánh mới trong git. Đó là trọng lượng nặng hơn nhiều. Nếu có sự tương đương thực sự của phân nhánh git trong hg tôi không biết nó là gì.
Tôi hiểu ở một số cấp độ hg và git có thể có thể làm những điều tương tự. Nếu vậy thì vẫn có một sự khác biệt rất lớn trong quy trình làm việc mà họ dẫn bạn đến. Trong git, quy trình làm việc điển hình là tạo một nhánh cho mọi tính năng.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
Điều đó chỉ tạo ra 3 nhánh, mỗi nhánh dựa trên một nhánh gọi là master. (Tôi chắc chắn rằng có một số cách trong git để tạo 1 dòng đó mỗi dòng thay vì 2)
Bây giờ để làm việc trên một tôi chỉ cần làm
git checkout fix-game-save-bug
và bắt đầu làm việc. Cam kết mọi thứ, vv Chuyển đổi giữa các chi nhánh ngay cả trong một dự án lớn như chrome là gần như ngay lập tức. Tôi thực sự không biết làm thế nào để làm điều đó trong hg. Nó không phải là một phần của bất kỳ hướng dẫn nào tôi đã đọc.
Một sự khác biệt lớn khác. Sân khấu của Git.
Git có ý tưởng về một sân khấu. Bạn có thể nghĩ về nó như một thư mục ẩn. Khi bạn cam kết, bạn chỉ cam kết những gì trên sân khấu, không phải là những thay đổi trong cây làm việc của bạn. Nghe có vẻ lạ. Nếu bạn muốn thực hiện tất cả các thay đổi trong cây làm việc của mình, bạn sẽ git commit -athêm tất cả các tệp đã sửa đổi vào giai đoạn và sau đó cam kết chúng.
Điểm của sân khấu là gì? Bạn có thể dễ dàng tách các cam kết của bạn. Hãy tưởng tượng bạn đã chỉnh sửa joypad.cpp và gamesave.cpp và bạn muốn cam kết chúng một cách riêng biệt
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
Git thậm chí còn có các lệnh để quyết định các dòng cụ thể trong cùng một tệp mà bạn muốn sao chép vào giai đoạn để bạn cũng có thể tách riêng các cam kết đó. Tại sao bạn muốn làm điều đó? Bởi vì như những cam kết riêng biệt, những người khác chỉ có thể lấy những thứ họ muốn hoặc nếu có vấn đề, họ có thể hoàn nguyên chỉ những cam kết có vấn đề.
git add --patch, xem linux.die.net/man/1/git-add hoặc sử dụng git add -i, như trong stackoverflow.com/questions/2372583/
checkout -b <name>bạn, bạn chỉ có thể sử dụng git branch <name>để tạo một chi nhánh mới mà không cần chuyển sang nó
Có một biểu đồ so sánh động tại phiên bảncontrolblog nơi bạn có thể so sánh một số hệ thống kiểm soát phiên bản khác nhau.
dir-a/foo.cthành dir-b/foo.cvà tiếp tục làm việc dir-b/foo.c, thì công việc của bạn dir-a/foo.csẽ được kết hợp chính xác với công việc của tôi sau một lần kéo.
Có sự khác biệt khá đáng kể khi làm việc với các chi nhánh (đặc biệt là những người ngắn hạn).
Nó được giải thích trong bài viết này (BranchingExplained) so sánh Mercurial với Git.
Có bất kỳ cộng tác viên dựa trên Windows trong dự án của bạn?
Bởi vì nếu có, GUI Git-for-Windows có vẻ lúng túng, khó khăn, không thân thiện.
Ngược lại, Mercurial trên Windows là không có trí tuệ.
Thỉnh thoảng năm ngoái tôi đã đánh giá cả git và hg cho mục đích sử dụng của riêng tôi và quyết định đi với hg. Tôi cảm thấy nó giống như một giải pháp sạch hơn và hoạt động tốt hơn trên nhiều nền tảng hơn vào thời điểm đó. Nó chủ yếu là một tung lên, mặc dù.
Gần đây, tôi bắt đầu sử dụng git vì git-svn và khả năng hoạt động như một ứng dụng khách Subversion. Điều này đã thắng tôi và giờ tôi đã chuyển hoàn toàn sang git. Tôi nghĩ rằng nó có một đường cong học tập cao hơn một chút (đặc biệt là nếu bạn cần chọc vào bên trong), nhưng nó thực sự là một hệ thống tuyệt vời. Tôi sẽ đi đọc hai bài báo so sánh mà John đã đăng bây giờ.
Tôi hiện đang trong quá trình chuyển đổi từ SVN sang DVCS (trong khi viết blog về những phát hiện của tôi, nỗ lực viết blog thực sự đầu tiên của tôi ...) và tôi đã thực hiện một chút nghiên cứu (= googling). Theo như tôi có thể thấy bạn có thể làm hầu hết mọi thứ với cả hai gói. Có vẻ như git có một vài tính năng nâng cao được triển khai tốt hơn hoặc tốt hơn, tôi cảm thấy rằng việc tích hợp với các cửa sổ sẽ tốt hơn một chút đối với đồng bóng, với TortoiseHg. Tôi biết cũng có Git Cheetah (tôi đã thử cả hai), nhưng giải pháp đồng bóng chỉ cảm thấy mạnh mẽ hơn.
Xem cả hai đều là nguồn mở (phải không?) Tôi không nghĩ một trong hai sẽ thiếu các tính năng quan trọng. Nếu một cái gì đó quan trọng, mọi người sẽ yêu cầu nó, mọi người sẽ mã hóa nó.
Tôi nghĩ rằng đối với các thông lệ, Git và Mercurial là quá đủ. Cả hai đều có các dự án lớn sử dụng chúng (Git -> linux kernel, Mercurial -> Mozilla, tất cả các dự án khác), vì vậy tôi không nghĩ là thực sự thiếu thứ gì đó.
Điều đó đang được nói, tôi quan tâm đến những gì người khác nói về điều này, vì nó sẽ tạo ra một nguồn tuyệt vời cho những nỗ lực viết blog của tôi ;-)
Có một bảng và biểu đồ so sánh tuyệt vời và đầy đủ trên git, Mercurial và Bazaar tại hướng dẫn của InfoQ về DVCS .
Tôi nhận ra đây không phải là một phần của câu trả lời, nhưng trên lưu ý đó, tôi cũng nghĩ rằng sự sẵn có của các plugin ổn định cho các nền tảng như NetBeans và Eclipse đóng vai trò trong đó công cụ phù hợp hơn cho nhiệm vụ, hay đúng hơn là công cụ nào là phù hợp nhất cho "bạn". Đó là, trừ khi bạn thực sự muốn làm theo cách CLI.
Cả Eclipse (và mọi thứ dựa trên nó) và NetBeans đôi khi có vấn đề với các hệ thống tệp từ xa (như SSH) và các bản cập nhật bên ngoài của các tệp; đó là một lý do khác tại sao bạn muốn bất cứ điều gì bạn chọn để làm việc "liền mạch".
Hiện tại tôi cũng đang cố gắng tự trả lời câu hỏi này .. và tôi đã đưa ra các ứng cử viên cho Git hoặc Mercurial .. cảm ơn tất cả các bạn đã cung cấp đầu vào hữu ích cho chủ đề này mà không đi theo tôn giáo.
Một so sánh thú vị khác của mercurial và git: Mercurial vs Git . Trọng tâm chính là nội bộ và ảnh hưởng của chúng đối với quá trình phân nhánh.
Nếu bạn quan tâm đến việc so sánh hiệu suất của Mercurial và Git, hãy xem bài viết này . Kết luận là:
Cả Git và Mercurial đều có số lượng tốt nhưng tạo ra sự đánh đổi thú vị giữa tốc độ và kích thước kho lưu trữ. Mercurial nhanh chóng với cả bổ sung và sửa đổi, đồng thời kiểm soát sự phát triển của kho lưu trữ. Git cũng nhanh, nhưng kho lưu trữ của nó phát triển rất nhanh với các tệp được sửa đổi cho đến khi bạn đóng gói lại - và các gói đó có thể rất chậm. Nhưng kho lưu trữ đóng gói nhỏ hơn nhiều so với Mercurial.
Trang web đồng bóng có một mô tả tuyệt vời về sự tương đồng và khác biệt giữa hai hệ thống, giải thích sự khác biệt của từ vựng và các khái niệm cơ bản. Là một người dùng git lâu năm, nó thực sự giúp tôi hiểu được suy nghĩ của Mercurial.
Nếu bạn đang di chuyển từ SVN, hãy sử dụng Mercurial vì cú pháp của nó sẽ dễ hiểu hơn đối với người dùng SVN. Ngoài ra, bạn không thể đi sai với một trong hai. Nhưng hãy kiểm tra hướng dẫn GIT và HGinit trước khi chọn một trong số chúng.
Liên kết này có thể giúp bạn hiểu sự khác biệt http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Một số người nghĩ rằng các hệ thống VCS phải phức tạp. Họ khuyến khích phát minh các thuật ngữ và khái niệm trên lĩnh vực này. Họ có thể sẽ nghĩ rằng nhiều tiến sĩ về đề tài này sẽ rất thú vị. Trong số đó có lẽ là những người đã thiết kế Git.
Mercurial được thiết kế với một tâm lý khác nhau. Các nhà phát triển không nên quan tâm nhiều đến VCS và thay vào đó họ nên dành thời gian cho chức năng chính của họ: công nghệ phần mềm. Mercurial cho phép người dùng sử dụng và vui vẻ lạm dụng hệ thống mà không để họ mắc bất kỳ lỗi nào không thể phục hồi.
Bất kỳ công cụ chuyên nghiệp nào cũng phải đi kèm với CLI được thiết kế rõ ràng và trực quan. Người dùng Mercurial có thể thực hiện hầu hết các công việc bằng cách đưa ra các lệnh đơn giản mà không có bất kỳ tùy chọn lạ nào. Trong dấu gạch ngang kép Git, các tùy chọn điên là tiêu chuẩn. Mercurial có một lợi thế đáng kể nếu bạn là người CLI (và thành thật mà nói, bất kỳ Kỹ sư phần mềm tự trọng nào cũng nên có).
Để đưa ra một ví dụ, giả sử bạn thực hiện một cam kết do nhầm lẫn. Bạn quên chỉnh sửa một số tập tin. Để hoàn tác hành động của bạn trong Mercurial, bạn chỉ cần gõ:
$ hg rollback
Sau đó, bạn nhận được một thông báo rằng hệ thống hoàn tác giao dịch cuối cùng của bạn.
Trong Git, bạn phải gõ:
$ git reset --soft HEAD^
Vì vậy, giả sử bạn có một ý tưởng thiết lập lại là gì. Nhưng ngoài ra, bạn phải biết đặt lại "--soft" và "--hard" là gì (có dự đoán trực quan nào không?). Ồ và tất nhiên đừng quên nhân vật '^' cuối cùng! (bây giờ cái tên của Ritchie là ...)
Sự tích hợp của Mercurial với các công cụ của bên thứ 3 như kdiff3 và meld cũng tốt hơn nhiều. Tạo các bản vá của bạn hợp nhất các chi nhánh của bạn mà không có nhiều phiền phức. Mercurial cũng bao gồm một máy chủ http đơn giản mà bạn kích hoạt bằng cách nhập
hg serve
Và để người khác duyệt kho lưu trữ của bạn.
Điểm mấu chốt là, Git thực hiện những gì Mercurial làm, theo cách phức tạp hơn nhiều và với CLI kém hơn rất nhiều. Sử dụng Git nếu bạn muốn biến VCS của dự án của bạn thành một lĩnh vực nghiên cứu khoa học. Sử dụng Mercurial nếu bạn muốn hoàn thành công việc VCS mà không quan tâm nhiều đến nó và tập trung vào các nhiệm vụ thực tế của bạn.