Saat melihat perbandingan, menurut saya mungkin ada pemetaan 1: 1 antara set fitur mereka. Namun, pernyataan yang sering dikutip adalah bahwa "Mercurial lebih mudah". Apa dasar dari pernyataan ini? (jika ada)
Saat melihat perbandingan, menurut saya mungkin ada pemetaan 1: 1 antara set fitur mereka. Namun, pernyataan yang sering dikutip adalah bahwa "Mercurial lebih mudah". Apa dasar dari pernyataan ini? (jika ada)
Jawaban:
Contoh kasus: Katakanlah Anda ingin mengubah nama pengguna pada semua komitmen Anda sebelumnya. Saya perlu melakukan ini beberapa kali karena berbagai alasan.
Versi 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
Versi Mercurial:
file author.convert.list:
<oldname>=<newname>
Garis komando:
hg convert --authors authors.convert.list SOURCE DEST
Sekarang, mana yang terlihat lebih mudah digunakan?
Catatan: Saya menghabiskan 2 tahun bekerja hanya dengan Git, jadi ini bukan "Aku benci itu, saya tidak mendapatkannya dalam 2 detik" kata-kata kasar.
Bagi saya, ini kegunaannya. Git sangat berorientasi pada linux dengan cara linux dalam melakukan sesuatu. Itu berarti baris perintah, halaman manual, dan mencari tahu sendiri. Itu GUI yang sangat buruk (catatan: Saya mendasarkan ini dari msysGit dari sekitar setahun yang lalu), yang sepertinya hanya menghalangi saya. Saya hampir tidak bisa menggunakannya
Baris perintah lebih buruk. Menjadi program yang berorientasi Linux, pada Windows itu sangat sulit digunakan. Alih-alih port asli mereka hanya membungkus git dengan MinGW (Think cygwin), yang membuatnya bekerja jauh lebih sulit. MinGW bukan Windows Command Prompt, dan hanya bertindak berbeda. Sangat gila bahwa ini adalah satu-satunya cara untuk bekerja dengan Git. Bahkan di Linux sepertinya satu-satunya cara adalah bekerja dengan baris perintah lurus. Proyek seperti RabbitVCS membantu beberapa, tetapi tidak terlalu kuat.
Pendekatan berorientasi baris perintah dan menjadi program linux berarti bahwa hampir semua panduan howto, dokumentasi bantuan, dan pertanyaan forum / QA bergantung pada menjalankan perintah mengerikan seperti di atas. Perintah-perintah SCM dasar (komit, tarik, dorong) tidak serumit itu, tetapi kompleksitas dan kompleksitas tumbuh secara eksponensial.
Saya juga membenci satu tempat yang banyak pengguna OSS git nongkrong: Github. Ketika Anda pertama kali pergi ke halaman github, itu membanting Anda dengan semua yang Anda bisa lakukan. Bagi saya, halaman proyek git terlihat kacau, menyeramkan, dan terlalu kuat. Bahkan penjelasan tentang apa proyek itu, didorong ke bawah. Github benar-benar menyakiti orang yang tidak memiliki situs web lengkap yang sudah disiapkan. Pelacak masalahnya juga mengerikan dan membingungkan. Kelebihan fitur.
Pengguna Git juga sepertinya sangat pemuja. Pengguna Git tampaknya selalu menjadi orang-orang yang memulai "perang suci" di mana DVCS lebih baik, yang kemudian memaksa pengguna Mercurial untuk mempertahankan diri. Situs- situs seperti http://whygitisbetterthanx.com/ menunjukkan arogansi dan mentalitas "Gunakan perangkat lunak atau mati" saya hampir. Banyak kali saya pergi ke berbagai tempat bantuan hanya untuk dinyalakan karena tidak mengetahui X, menggunakan X sebelumnya, menggunakan Windows, dll. Ini gila.
Di sisi lain, lincah tampaknya mengarah pada pendekatan yang lebih baik. Halaman beranda mereka sendiri tampaknya jauh lebih ramah bagi pengguna baru daripada Git . Dalam pencarian Google sederhana hasil ke-5 adalah TortoiseHg, GUI yang sangat bagus untuk Mercurial. Seluruh pendekatan mereka tampaknya kesederhanaan dulu, kekuatan kemudian.
Dengan Mercurial, saya tidak memiliki omong kosong SSH (SSH adalah neraka di Windows), saya tidak memiliki perintah yang rumit, saya tidak memiliki pengikut yang mengikuti, saya tidak memiliki kegilaan. Mercurial hanya berfungsi.
TortoiseHg menyediakan antarmuka yang sebenarnya dapat digunakan (meskipun belakangan ini tampaknya semakin berkembang) yang menyediakan fitur yang sebenarnya berguna. Opsi terbatas pada apa yang Anda butuhkan, menghilangkan kekacauan dan opsi yang jarang digunakan. Ini juga menyediakan banyak default yang layak
Mercurial, karena sangat bersahabat dengan pendatang baru, sangat mudah dijemput. Bahkan beberapa topik yang lebih kompleks seperti model percabangan yang berbeda dan pengeditan sejarah sangat mudah diikuti. Saya mengambil Mercurial dengan cepat dan tanpa rasa sakit.
Mercurial juga hanya berfungsi pertama kali dengan sedikit pengaturan. Pada OS APA PUN saya hanya bisa menginstal TortoiseHg dan mendapatkan semua fitur yang saya inginkan (terutama perintah menu konteks) tanpa harus mencari Guis yang berbeda. Yang juga hilang adalah pengaturan SSH (separuh dari panduan di luar sana mengatakan untuk menggunakan Putty, Plink, dan Pagent sementara separuh lainnya mengatakan menggunakan ssh-keygen). Untuk pengguna baru, TortoiseHg membutuhkan waktu beberapa menit untuk mensetup sementara Git membutuhkan waktu 30 menit hingga satu jam dengan banyak googling.
Terakhir Anda memiliki repo online. Setara dengan Githubs adalah BitBucket, yang memiliki beberapa masalah yang saya uraikan di atas. Namun ada juga Google Code. Ketika saya pergi ke proyek Google Code , saya tidak mendapatkan kelebihan fitur, saya mendapatkan antarmuka yang bagus dan bersih. Google Code lebih merupakan kombo repo / situs web online, yang sangat membantu proyek OSS yang tidak memiliki pengaturan situs yang ada. Saya akan merasa sangat nyaman menggunakan Google Code sebagai situs web proyek saya selama beberapa waktu, hanya membangun situs web ketika benar-benar diperlukan. Pelacak masalahnya juga sangat kuat, cocok dengan baik di antara Pelacak Isu Github yang hampir tidak berguna dan keburukan Bugzilla .
Mercurial hanya berfungsi, pertama kali, setiap kali. Git menghalangi saya dan hanya membuat saya marah semakin saya menggunakannya.
Mercurial umumnya diyakini lebih sederhana dan lebih mudah dipelajari daripada Git. Pada gilirannya, sering kali ada persepsi bahwa Git lebih fleksibel dan kuat. Hal ini disebabkan, sebagian, karena Git cenderung memberikan lebih banyak perintah tingkat rendah, tetapi juga sebagian karena Mercurial default cenderung menyembunyikan fitur-fitur canggih , membiarkannya bagi pengguna untuk mengedit file konfigurasi mercurial untuk mengaktifkan fitur-fitur canggih yang mereka sukai. Ini sering mengarah pada persepsi bahwa fitur-fitur canggih tidak tersedia di Mercurial.
Mercurial selalu lebih fokus pada aspek antarmuka, yang membuatnya lebih mudah dipelajari. Dibandingkan dengan Git, pemahaman yang lebih dangkal diperlukan untuk beroperasi dengan Mercurial dengan cara yang bermanfaat. Dalam jangka panjang, enkapsulasi semacam itu telah membuat Mercurial memiliki penampilan yang salah karena kurang kuat dan penuh fitur daripada sebenarnya.
hg push --branch BRANCH
) atau ke revisi tertentu ( hg push --rev REV
). Silakan lihat hg help push
opsi lainnya.
Konteks: Saya menggunakan Mercurial (untuk pekerjaan) dan Git (untuk proyek sampingan dan open source) setiap hari. Saya terutama menggunakan alat berbasis teks dengan keduanya (bukan IDE) dan saya menggunakan Mac.
Secara umum, saya menemukan Mercurial lebih mudah untuk dikerjakan. Beberapa hal yang saya temukan membuat Mercurial lebih mudah:
hg
setara dengan git
cabang-cabang yang benar-benar disebut bookmarks
. Sejauh yang saya tahu, hg
cabang tidak memiliki yang setara di git
.
git
percabangan adalah bagian dari hg
percabangan. Di dalam hg
Anda dapat memiliki cabang bernama dan tanpa nama (topologi), dan bahkan dapat mengelola cabang tanpa nama dengan cara yang sama seperti git
menggunakan bookmark. Saya belum pernah benar-benar melihat titik di area pementasan. Saya lebih suka menyimpan perubahan yang tidak diinginkan dan kemudian memastikan bahwa kode saya mengkompilasi & menyelesaikan tes saya sebelum melakukan itu. Saya kemudian bisa mengesampingkan dan melanjutkan. Juga, "Massaging Hunks" Charles Bailey (p90 +) membuatku takut * 8 '): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
hg bookmark keyo-stuff
,, lakukan sesuatu hg commit
,, kemudian pada akhirnya hg push -B keyo-stuff
. Jika Anda tidak suka angka revisi, jangan gunakan; Mercurial akan menerima hash di mana saja ia akan menerima nomor revisi, saya pikir. Saya harus mengatakan, komentar Anda bashing Mercurial karena kurangnya fitur yang sebenarnya dianggap sebagai bodoh dan sedikit agresif; Anda tidak melakukan banyak hal baik untuk stereotip pengguna Git!
Ini sangat subyektif dan tergantung dari satu orang ke orang lain, tetapi ya, saya akan mengatakan bahwa kepada seseorang yang sama sekali baru untuk VCS atau seseorang yang berasal dari salah satu VCS "sekolah lama", Mercurial akan tampak lebih mudah.
Misalnya, menambahkan file, tidak adanya indeks dalam Hg, kemudahan untuk kembali ke beberapa revisi lama dan bercabang dari sana (cukup perbarui dan komit) sebagai beberapa contoh yang paling "jelas". Sekarang sebagian besar fitur dari satu sistem dapat ditiru di sistem lain dan sebaliknya, tetapi itu membutuhkan pengetahuan di Git, sementara di Mercurial default-nya (jika Anda mengizinkan saya memanggilnya) agak "ramah pengguna". Hal-hal kecil itu - sakelar di sana-sini, perilaku yang tidak jelas dalam satu perintah dan seterusnya ... hal-hal ini bertambah, dan pada akhirnya, satu sistem tampaknya lebih mudah digunakan daripada yang lain.
Hanya untuk membuat jawabannya lengkap; Saya menggunakan git, tetapi ketika merekomendasikan VCS untuk seseorang yang "baru bagi mereka", saya hampir selalu merekomendasikan Mercurial. Saya ingat, ketika pertama kali masuk ke tangan saya, rasanya sangat intuitif. Ini adalah pengalaman saya bahwa Mercurial menghasilkan lebih sedikit wtf / menit dari Git.
Saya pikir ini sesederhana ini: Mercurial memiliki sintaks yang lebih akrab (terutama untuk pengguna SVN) dan didokumentasikan dengan cukup baik. Setelah Anda terbiasa dengan sintaks Git, Anda akan merasa mudah digunakan seperti yang lainnya.
Persepsi mungkin berubah seiring waktu, dalam hal ini. Mercurial dirancang dengan sangat baik, dan begitu pula Git. Mercurial tampaknya lebih mudah dipelajari (setidaknya bagi saya), dan ada kesulitan yang saya temui di Git, yang tidak saya miliki paralelnya dengan Mercurial. Saya mencoba mempelajari Python, dan Ruby, dan semakin jauh, lebih cepat dengan Python. Itu tidak berarti Python selalu dan di mana-mana lebih baik daripada Ruby, atau bahkan lebih baik bagi saya. Hanya apa yang saya pelajari dan tempati. Pemrogram sering membuat perang suci karena pilihan pribadi. Manusia lain juga melakukannya.
Saya adalah pengguna lincah yang mencoba untuk tetap berpikiran terbuka tentang Git, dan saya dengan bebas mengakui bahwa itu tidak "menjadi hal favorit saya yang baru" dengan tingkat yang sama seperti yang dimiliki Mercurial. Saya pikir Git benar-benar sangat baik.
Contoh balasan untuk GIT / kompleksitas lincah: Dukungan Nice GIT dibangun ke dalam XCode, di Mac. Kurang mudah menggunakan XCode dengan Mercurial dari GIT.
Pengalaman saya dengan GIT sejauh ini adalah saya menjadi bingung dan tersesat dan perlu lebih banyak membaca dokumentasi saat menggunakannya. Saya percaya bahwa banyak dokumentasi telah ditulis, tetapi tidak ada yang memungkinkan saya untuk "grok" itu. Kedua, saya dapat memodifikasi dan memperluas Mercurial dengan mudah di Python, dan seperti saya mahir dalam Python, dan siapa pun yang benar-benar bisa belajar python dengan cepat, sepertinya ini merupakan keuntungan bagi saya. Saya juga tahu C, dan menulis ekstensi Python di C, jadi saya kira suatu hari, jika saya membutuhkannya, saya bisa dengan mudah menulis ekstensi Git di C.
Kemudahan penggunaan bukanlah sesuatu yang mudah untuk diukur. Itu ada di sana, dan saya pikir itu tidak sepenuhnya subjektif, tetapi kami tidak memiliki teknik pengukuran objektif yang baik. Akan seperti apa unit untuk kemudahan penggunaan? Milli-iPod?
Saya tidak begitu partisan untuk menjadi 100% pro-mercurial, dan 100% anti-git. Saya lebih nyaman menggunakan Mercurial sekarang, di Windows dan di Linux, dan ketika saya mulai melakukan lebih banyak pekerjaan Mac, saya berharap bahwa saya akan mencoba untuk tetap menggunakan XCode + GIT.
Update 2013: Saya telah sekarang digunakan Mercurial DAN GIT cukup lama untuk menemukan beberapa fitur yang saya berharap itu yang Git memiliki, seperti ini pertanyaan tentang strategi gabungan. Benar-benar Git luar biasa, jika sulit dipelajari, dan terkadang rumit.
Ada beberapa hal yang IMO kemungkinan akan membuat pengguna baru keluar dari Git:
Budaya Git lebih sentris baris perintah. Walaupun kedua alat cenderung terlalu fokus pada baris perintah (seperti yang telah saya katakan beberapa kali, instruksi baris perintah mungkin lebih kuat dan lebih lancar, tetapi itu bukan strategi pemasaran yang baik ), ini jauh lebih banyak terjadi pada Git. Sedangkan Mercurial memiliki alat GUI standar de facto di TortoiseHg, yang bahkan merupakan opsi unduhan default untuk pengguna Windows di beranda Mercurial, Git memiliki beberapa ujung depan GUI yang bersaing (TortoiseGit, Git Extensions, gitk, dll) yang tidak diiklankan dengan baik di situs web Git, dan yang semuanya sangat merusak pemandangan. (Teks hitam pada label merah? Ayo, TortoiseGit, Anda bisa melakukan lebih baik dari itu!) Ada juga sikap yang jauh lebih luas di komunitas Git bahwa orang yang menggunakan alat GUI bukanlah pengembang perangkat lunak yang tepat.
Git memiliki beberapa standar out-of-the-box yang masuk akal bagi pengguna tingkat lanjut, tetapi cenderung mengejutkan jika tidak mengintimidasi pengguna baru. Sebagai contoh, itu jauh lebih agresif tentang mengotomatisasi tugas-tugas seperti penggabungan (misalnya, git pull secara otomatis menggabungkan dan melakukan jika memungkinkan). Ada kasus untuk penggabungan sepenuhnya otomatis , tetapi sebagian besar pengguna yang tidak berpengalaman takut penggabungan, dan perlu diberi kesempatan untuk mendapatkan kepercayaan pada alat mereka sebelum melepaskan kekuatan penuh mereka pada kode sumber mereka.
Dokumentasi dan kompleksitas yang melekat:
$ hg help log | wc -l
64
$ git help log | wc -l
912
Satu hal yang bisa saya pikirkan adalah
git add .
git commit -am "message"
vs.
hg ci -Am "message"
git commit -a
tidak menambahkan file yang baru dibuat, hg ci -A
tidak, yang berarti bahwa sesuatu yang membutuhkan dua perintah dengan git dapat dilakukan dengan satu perintah di Mercurial. Kemudian lagi, "kurang mengetik" tidak berarti "lebih ramah pengguna".
git commit -a
kerjanya hanya karena membuatnya lebih mudah untuk mengontrol apa yang dilakukan dan tidak ditambahkan untuk komit yang diberikan. (Sebenarnya bukan tidak biasa bagi saya untuk menentukan nama path individual untuk setiap orang svn ci
agar tidak menambahkan materi yang tidak terkait ke komit.)
hg ci
tanpa -A
bendera itu setara dengan git commit -a
. Saya telah menggunakan git jauh lebih banyak daripada hg, jadi saya tidak 100% yakin.
hg ci
== git commit -a
.
Karena.
Git memaparkan jauh lebih banyak dari nyali daripada mercurial. Anda dapat dengan senang hati menggunakan lincah dalam beberapa menit setelah mengambilnya, tetapi saya menemukan git masih sangat sulit untuk diatasi setelah beberapa bulan bergulat dengannya (saya telah melakukan sangat sedikit selama beberapa bulan terakhir selain mencoba belajar git ). Saya menggunakan keduanya dari baris perintah dan sebagian besar di Linux jadi ini bukan hanya keengganan untuk antarmuka baris perintah.
Salah satu contoh sederhana adalah flag dan argumen command line yang relatif sedikit diperlukan untuk mercurial dibandingkan dengan git. Area staging dan perilaku perintah add di git juga menambahkan lebih banyak kompleksitas daripada yang diperlukan. Trio reset, checkout, dan revert serta berbagai permutasi mereka menambah kompleksitas yang sangat besar, yang sebenarnya tidak perlu ketika Anda menyaksikan sifat sederhana dari revert dan pembaruan pada mercurial.
Saya setuju dengan komentar di atas juga tentang Hginit , itu pasti membuat lincah jauh lebih mudah untuk dipahami. Ditulis dengan baik dan sangat mudah dimengerti. Tidak ada dokumentasi yang ditulis untuk git yang mendekati. Pertama-tama, temukan sebagian besar dari apa yang ditulis oleh Scott Chacone (yang telah menulis sebagian besar dokumentasi / buku tentang git) secara membingungkan.