Apa Perbedaan Antara Mercurial dan Git?


727

Saya telah menggunakan git untuk beberapa waktu sekarang di Windows (dengan msysGit) dan saya suka ide kontrol sumber terdistribusi. Baru-baru ini saya telah melihat Mercurial (hg) dan itu terlihat menarik. Namun, saya tidak bisa membungkus kepala saya di sekitar perbedaan antara hg dan git.

Adakah yang membuat perbandingan berdampingan antara git dan hg? Saya tertarik untuk mengetahui apa yang membedakan hg dan git tanpa harus berdiskusi dengan penggemar.

Jawaban:


345

Artikel-artikel ini dapat membantu:

Sunting : Membandingkan Git dan Mercurial dengan selebriti tampaknya menjadi tren. Ini satu lagi:


1
"Git vs Mercurial Please Relax" benar-benar ketinggalan zaman, meskipun sudah setua pertanyaan ini. Mungkin pertanyaan ini harus dihapus dan dibuka kembali sekarang karena kedua alat telah memiliki 3+ tahun fitur yang ditambahkan.
GM

238

Saya bekerja pada Mercurial, tetapi pada dasarnya saya percaya kedua sistem itu setara. Keduanya bekerja dengan abstraksi yang sama: serangkaian snapshot (perubahan) yang membentuk sejarah. Setiap changeset tahu dari mana asalnya (parentetsetet) dan dapat memiliki banyak perubahan anak. Perpanjangan hg-git baru -baru ini menyediakan jembatan dua arah antara Mercurial dan Git dan semacam menunjukkan titik ini.

Git memiliki fokus yang kuat pada mutasi grafik sejarah ini (dengan semua konsekuensi yang menyertainya) sedangkan Mercurial tidak mendorong penulisan ulang sejarah, tetapi tetap mudah untuk melakukannya dan konsekuensi dari melakukannya adalah persis seperti yang Anda harapkan dari mereka (yaitu , jika saya memodifikasi set perubahan yang sudah Anda miliki, klien Anda akan melihatnya sebagai baru jika Anda menarik dari saya). Jadi Mercurial memiliki bias terhadap perintah yang tidak merusak.

Adapun cabang ringan, maka Mercurial telah mendukung repositori dengan banyak cabang sejak ..., selalu saya pikir. Repositori Git dengan banyak cabang persis seperti itu: banyak untai pengembangan yang berbeda dalam satu repositori. Git kemudian menambahkan nama ke untaian ini dan memungkinkan Anda untuk menanyakan nama-nama ini dari jarak jauh. The Bookmarks ekstensi untuk Mercurial menambahkan nama lokal, dan dengan Mercurial 1.6, Anda dapat memindahkan bookmark di sekitar ketika Anda mendorong / tarik ..

Saya menggunakan Linux, tetapi ternyata TortoiseHg lebih cepat dan lebih baik daripada yang setara dengan Git di Windows (karena penggunaan sistem file Windows yang buruk). Baik http://github.com dan http://bitbucket.org menyediakan hosting online, layanan di Bitbucket sangat bagus dan responsif (saya belum mencoba github).

Saya memilih Mercurial karena terasa bersih dan elegan - saya tidak menyukai skrip shell / Perl / Ruby yang saya dapatkan dengan Git. Coba intip git-instaweb.shfile tersebut jika Anda ingin tahu apa yang saya maksud: itu adalah skrip shell yang menghasilkan skrip Ruby , yang saya pikir menjalankan server web. Script shell menghasilkan script shell lain untuk meluncurkan script Ruby pertama. Ada juga sedikit Perl , untuk ukuran yang baik.

Saya suka posting blog yang membandingkan Mercurial dan Git dengan James Bond dan MacGyver - Mercurial entah bagaimana lebih rendah daripada Git. Menurut saya, orang yang menggunakan Mercurial tidak mudah terkesan. Ini tercermin dalam bagaimana setiap sistem melakukan apa yang digambarkan Linus sebagai "penggabungan paling keren yang pernah ada!" . Di Git, Anda dapat bergabung dengan repositori yang tidak terkait dengan melakukan:

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

Perintah-perintah itu terlihat sangat misterius di mataku. Dalam Mercurial kita lakukan:

hg pull --force <project-to-union-merge>
hg merge
hg commit

Perhatikan bagaimana perintah Mercurial polos dan tidak spesial sama sekali - satu-satunya hal yang tidak biasa adalah --forceflag hg pull, yang diperlukan karena Mercurial akan membatalkan jika tidak ketika Anda menarik dari repositori yang tidak terkait. Perbedaan seperti ini yang membuat Mercurial tampak lebih elegan bagiku.


21
Perhatikan bahwa TortoiseHg juga bekerja sama dengan Nautilus, manajer file Gnome di Linux.
oenli

4
Script Ruby hanya dihasilkan jika httpd adalah Webrick, server web ruby.
alternatif

4
Seperti Git, Mercurial menyimpan snapshot dari file Anda ketika Anda melakukan. Saya tidak setuju bahwa penggantian nama hanya dapat dilacak dengan heuristik seperti di Git, tidak ada dalam model yang menghalangi penambahan informasi tambahan ke snapshot, misalnya, ganti nama informasi. Kami melakukannya dalam Mercurial.
Martin Geisler

63
untuk menggabungkan (tarik) proyek yang tidak berhubungan dengan git, Anda hanya dapat melakukan: git pull <url-of-project>. surat yang Anda kutip berasal dari masa-masa awal git (2005)
knittl

5
knittl: ah, bagus, aku senang mendengar bahwa Git semakin tidak misterius. Namun, saya pikir contohnya menunjukkan sedikit bagaimana sistem berbeda dalam apa yang kita anggap keren dan Git terasa lebih rendah bagi saya dibandingkan dengan Mercurial (tetapi tidak lebih kuat).
Martin Geisler

73

Git adalah sebuah platform, Mercurial adalah "hanya" aplikasi. Git adalah platform sistem file berversi yang dikirimkan bersama dengan aplikasi DVCS di dalam kotak, tetapi seperti biasa untuk aplikasi platform, Git lebih kompleks dan memiliki tepi yang lebih kasar daripada aplikasi fokus. Tetapi ini juga berarti git's VCS sangat fleksibel, dan ada banyak hal non-sumber-kontrol yang dapat Anda lakukan dengan git.

Itulah inti perbedaannya.

Git paling baik dipahami dari bawah ke atas - dari format repositori ke atas. Scott Chacon's Git Talk adalah yang utama untuk ini. Jika Anda mencoba menggunakan git tanpa mengetahui apa yang terjadi di bawah tenda, pada akhirnya Anda akan bingung (kecuali Anda tetap menggunakan fungsionalitas yang sangat mendasar). Ini mungkin terdengar bodoh ketika semua yang Anda inginkan adalah DVCS untuk rutinitas pemrograman harian Anda, tetapi genius git adalah bahwa format repositori sebenarnya sangat sederhana dan Anda dapat memahami seluruh operasi git dengan cukup mudah.

Untuk beberapa perbandingan yang lebih berorientasi teknis, artikel terbaik yang saya pribadi lihat adalah Dustin Sallings ':

Dia sebenarnya menggunakan kedua DVCS secara ekstensif dan memahami keduanya dengan baik - dan akhirnya lebih memilih git.


78
Saya sering membaca orang menyebut git sebagai "platform", tetapi itu lebih merupakan teori atau mitos umum karena tidak ada contoh utama sebagai git untuk melakukan sesuatu selain menjalankan git.
Ian Kelling

@Ian - Jika saya tidak salah, Aptana Studio 3 menggunakannya untuk sistem pembaruan internal.
mac

22
Singkatnya, Mercurial adalah sistem kendali revisi terdistribusi open-source, dan git adalah pilihan gaya hidup.
Tim Keating

51

Perbedaan besar ada pada Windows. Mercurial didukung secara native, Git tidak. Anda bisa mendapatkan hosting sangat mirip dengan github.com dengan bitbucket.org (sebenarnya lebih baik karena Anda mendapatkan repositori pribadi gratis). Saya menggunakan msysGit untuk sementara waktu tetapi pindah ke Mercurial dan sangat senang dengannya.


64
Jadi "asli" bukanlah kata yang tepat, tetapi tidak didukung dengan baik di bawah windows, itu sudah pasti.
Ian Kelling

14
git didukung ke suatu titik di Windows. Tapi coba gunakan cross-platform nama file Unicode dan lihat rasa sakit yang Anda dapatkan.
Craig McQueen

@Craig: Itu lebih dari kekurangan platform. Platform yang kompeten akan memungkinkan Anda untuk beralih ke lokal yang cocok. Jika Anda tetap menggunakan utf-8, Anda akan lebih baik kecuali bahwa Mac OS X memiliki normalisasi utf-8 yang sedikit berbeda, namun, saya tidak yakin apakah windows bahkan memungkinkan Anda menggunakan utf-8 ...
Arafangion

23
Windows mendukung Unicode, meskipun MS memilih untuk menggunakan UTF-16 dalam API-nya daripada UTF-8. Meskipun begitu, git sangat mungkin untuk mendukung Unicode cross-platform. SVN telah memecahkan masalah itu dengan cukup baik. Tapi itu bukan prioritas tinggi untuk pengembangan msysGit saat ini. code.google.com/p/msysgit/issues/detail?id=80
Craig McQueen

38

Jika Anda adalah pengembang Windows yang mencari kontrol revisi terputus dasar, ikuti Hg. Saya menemukan Git tidak bisa dimengerti sementara Hg sederhana dan terintegrasi dengan baik dengan shell Windows. Saya mengunduh Hg dan mengikuti tutorial ini (hginit.com) - sepuluh menit kemudian saya memiliki repo lokal dan kembali bekerja pada proyek saya.


1
Saya mengikuti tutorial yang sama. Itu pasti.
Nathan


20

Mereka hampir identik. Perbedaan paling penting, dari sudut pandang saya (maksud saya, alasan yang membuat saya memilih satu DVCS daripada yang lain) adalah bagaimana kedua program mengelola cabang.

Untuk memulai cabang baru, dengan Mercurial, Anda cukup menyalin repositori ke direktori lain dan mulai mengembangkan. Lalu, Anda tarik dan gabungkan. Dengan git, Anda harus secara eksplisit memberikan nama ke cabang topik baru yang ingin Anda gunakan, lalu mulai coding menggunakan direktori yang sama .

Singkatnya, setiap cabang di Mercurial membutuhkan direktori sendiri; di git Anda biasanya bekerja di direktori tunggal. Berpindah cabang di Mercurial berarti mengubah direktori; di git, itu berarti meminta git untuk mengubah konten direktori dengan checkout git.

Saya jujur: Saya tidak tahu apakah mungkin untuk melakukan hal yang sama dengan Mercurial, tetapi karena saya biasanya bekerja pada proyek web, menggunakan selalu direktori yang sama dengan git tampaknya jauh lebih nyaman bagi saya, karena saya tidak perlu kembali -configurasikan Apache dan mulai kembali dan saya tidak mengacaukan sistem file saya setiap kali saya bercabang.

Sunting: Seperti yang dicatat Deestan, Hg telah menamai cabang , yang dapat disimpan dalam satu repositori dan memungkinkan pengembang untuk berganti cabang dalam copy pekerjaan yang sama. cabang git tidak persis sama dengan cabang bernama Mercurial, pokoknya: mereka permanen dan tidak membuang cabang, seperti di git. Itu berarti bahwa jika Anda menggunakan cabang bernama untuk tugas eksperimental bahkan jika Anda memutuskan untuk tidak pernah menggabungkannya, itu akan disimpan dalam repositori. Itulah alasan mengapa Hg menganjurkan untuk menggunakan klon untuk tugas eksperimental, jangka pendek dan menamai cabang untuk tugas jangka panjang, seperti untuk cabang rilis.

Alasan mengapa banyak pengguna Hg lebih memilih klon daripada cabang bernama jauh lebih sosial atau budaya daripada teknis. Misalnya, dengan versi terakhir Hg, bahkan mungkin untuk menutup cabang bernama dan menghapus metadata dari perubahan secara rekursif.

Di sisi lain, git mengundang untuk menggunakan "cabang bernama" yang tidak permanen dan tidak disimpan sebagai metadata pada setiap perubahan.

Dari sudut pandang pribadi saya, kemudian, model git sangat terkait dengan konsep cabang bernama dan beralih antara cabang dan yang lain dengan direktori yang sama; hg dapat melakukan hal yang sama dengan cabang bernama, tetapi belum mendorong penggunaan klon, yang secara pribadi saya tidak suka terlalu banyak.


6
Ini bukan perbedaan; Hg telah menamai cabang juga. Kami menggunakannya sepanjang waktu selama perkembangan normal alih-alih cabang klon.
Deestan

2
AFAIK, cabang bernama di Hg diperoleh menyimpan metadata di setiap komit; Saya mungkin salah, tetapi saya membaca bahwa setelah Anda membuat cabang, metadata-nya akan tertanam di setiap perubahan dan menjadi bagian dari sejarah. Ini perbedaan besar dengan git. "Klon sangat bagus untuk eksperimen cepat di mana Anda tidak ingin merekam nama cabang, dan cabang bernama bagus untuk cabang jangka panjang" tinyurl.com/2wz39qx Apa yang saya coba katakan dengan posting saya adalah bahwa alur kerja standar git mengundang Anda untuk menggunakan satu copy pekerjaan; Alur kerja standar Hg termasuk klon, yang tidak sesuai dengan kebutuhan pribadi saya.
Arialdo Martini

Untuk penjelasan yang baik tentang persamaan / perbedaan: bercabang di Git & Hg, lihat: mercurial.selenic.com/wiki/GitConcepts#Branch_model
sampablokuper

2
Cabang bernama di hg tidak seperti cabang di git. Di hg, ada satu jalan yang benar . Semua cabang adalah cabang dari jalur itu. Di git tidak ada satu jalan yang benar. Hanya ada berbagai kondisi repo dan petunjuk ke keadaan itu. Setiap cabang hanyalah sebuah penunjuk yang berbeda. Pointer mana yang paling utama untuk digunakan. Cabang adalah teman sebaya.
GM

17

Ada satu perbedaan besar antara git dan lincah ; cara masing-masing mewakili komit. git merepresentasikan commit sebagai snapshot, sementara mercurial merepresentasikannya sebagai diffs.

Apa artinya ini dalam praktik? Yah, banyak operasi yang lebih cepat di git, seperti beralih ke komit lain, membandingkan komit, dll. Khususnya jika komit ini jauh.

AFAIK tidak ada keuntungan dari pendekatan lincah.


29
Keuntungan (perbedaan) keuntungan adalah dalam mengambil lebih sedikit ruang. Git memulihkan ruang yang digunakan untuk komit dengan menggunakan kompresi, tetapi ini membutuhkan langkah kompres eksplisit sesekali ("paket git").
quark

8
Sekarang disebut 'git gc', tetapi ada berbagai tingkat pengumpulan sampah, dan beberapa tingkat dijalankan secara otomatis di versi terbaru git.
FelipeC

6
sebenarnya lincah juga menggunakan snapshot
Ronny

13
Saya gagal memahami perbedaan yang Anda gambar antara 'snapshots' dan 'diffs'. Baik hg dan git store berkomitmen sebagai (grup) delta file . Delta-delta itu didasarkan pada revisi apa pun yang sebelumnya dipilih masing-masing SCM. Sudahkah Anda mendapatkan angka yang menunjukkan bahwa git sebenarnya lebih cepat untuk operasi yang Anda sebutkan? Memutakhirkan ke komit lain menghabiskan sebagian besar waktunya menulis ke dir, tidak membaca repo, sih.
Kevin

2
'Snapshot's vs.' diff's - sama sekali tidak relevan. Namun repo yang disimpan secara internal tidak ada hubungannya dengan apa yang dilihat pengguna. Baik git dan mercurial memberi pengguna 'snapshot'. Tidak ada alasan mengapa format repositori diimplementasikan dengan cara yang sama seperti git tidak dapat ditambahkan ke mercurial, seperti yang saya yakini Bazaar lakukan.
Mark Booth

11

Tidak ada. Mereka berdua melakukan hal yang sama, keduanya melakukan hal yang sama. Satu-satunya alasan Anda harus memilih satu di antara yang lain adalah jika Anda membantu proyek yang sudah menggunakan satu ..

Alasan lain yang mungkin untuk memilih satu adalah aplikasi atau layanan yang hanya mendukung salah satu sistem .. Misalnya, saya cukup banyak memilih untuk belajar git karena github ..


6
Sepertinya jawaban Anda terlalu pragmatis. :)
Arafangion


11

Jika saya memahaminya dengan benar (dan saya jauh dari ahli tentang masing-masing) mereka pada dasarnya masing-masing memiliki filosofi yang berbeda. Saya pertama kali menggunakan lincah selama 9 bulan. Sekarang saya sudah menggunakan git untuk 6.

hg adalah perangkat lunak kontrol versi. Tujuan utamanya adalah melacak versi suatu perangkat lunak.

git adalah sistem file berbasis waktu. Tujuannya adalah untuk menambahkan dimensi lain ke sistem file. Sebagian besar memiliki file dan folder, git menambah waktu. Bahwa itu terjadi untuk bekerja luar biasa sebagai VCS adalah produk sampingan dari desainnya.

Dalam hg, ada sejarah seluruh proyek yang selalu berusaha untuk dipelihara. Secara default, saya yakin hg ingin semua perubahan pada semua objek oleh semua pengguna saat mendorong dan menarik.

Di git hanya ada kumpulan objek dan file pelacakan ini (cabang / kepala) yang menentukan set objek mana yang mewakili pohon file dalam keadaan tertentu. Ketika mendorong atau menarik git hanya mengirimkan objek yang dibutuhkan untuk cabang tertentu yang Anda dorong atau tarik, yang merupakan subset kecil dari semua objek.

Sejauh menyangkut git, tidak ada "1 proyek". Anda dapat memiliki 50 proyek dalam repo dan git yang sama tidak akan peduli. Masing-masing dapat dikelola secara terpisah dalam repo yang sama dan hidup dengan baik.

Konsep cabang Hg adalah cabang dari proyek utama atau cabang dari cabang dll. Git tidak memiliki konsep seperti itu. Cabang di git hanyalah keadaan pohon, semuanya adalah cabang di git. Cabang mana yang resmi, terkini, atau terbaru tidak memiliki arti dalam git.

Saya tidak tahu apakah itu masuk akal. Jika saya bisa menggambar gambar hg mungkin terlihat seperti ini di mana setiap komit adalaho

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

Sebuah pohon dengan satu akar dan ranting keluar darinya. Sementara git dapat melakukan itu dan seringkali orang menggunakannya dengan cara yang tidak diberlakukan. Sebuah gambar git, jika ada hal seperti itu, dapat dengan mudah terlihat seperti ini

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

Bahkan dalam beberapa hal bahkan tidak masuk akal untuk menunjukkan cabang di git.

Satu hal yang sangat membingungkan untuk diskusi, git dan lincah keduanya memiliki sesuatu yang disebut "cabang" tetapi mereka tidak jauh dari hal yang sama. Cabang dalam lincah muncul ketika ada konflik antara repo yang berbeda. Cabang di git tampaknya mirip dengan klon di hg. Tapi klon, sementara itu mungkin memberikan perilaku yang sama pasti tidak sama. Pertimbangkan saya mencoba ini dalam git vs hg menggunakan repo kromium yang agak besar.

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

Dan sekarang di hg menggunakan klon

$ 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

Keduanya adalah hot run. Yaitu, saya berlari mereka dua kali dan ini adalah lari kedua. klon hg sebenarnya sama dengan git-new-workdir. Keduanya membuat direktori kerja yang sama sekali baru seolah-olah Anda telah mengetikcp -r project project-clone . Itu tidak sama dengan membuat cabang baru di git. Beratnya jauh lebih berat. Jika benar ada yang setara dengan percabangan git di hg, saya tidak tahu apa itu.

Saya mengerti pada tingkat tertentu, hg dan git mungkin dapat melakukan hal serupa. Jika demikian maka masih ada perbedaan besar dalam alur kerja yang mereka arahkan ke Anda. Di git, alur kerja tipikal adalah membuat cabang untuk setiap fitur.

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

Itu baru saja membuat 3 cabang, masing-masing berdasarkan dari cabang yang disebut master. (Saya yakin ada beberapa cara di git untuk membuat masing-masing 1 baris itu bukannya 2)

Sekarang untuk mengerjakan yang saya lakukan

git checkout fix-game-save-bug

dan mulai bekerja. Berkomitmen, dll. Beralih antar cabang bahkan dalam proyek sebesar chrome hampir seketika. Sebenarnya saya tidak tahu bagaimana melakukannya di hg. Itu bukan bagian dari tutorial yang saya baca.

Satu perbedaan besar lainnya. Panggung Git.

Git memiliki ide panggung. Anda dapat menganggapnya sebagai folder tersembunyi. Ketika Anda berkomitmen Anda hanya melakukan apa yang ada di atas panggung, bukan perubahan di pohon kerja Anda. Itu mungkin terdengar aneh. Jika Anda ingin mengkomit semua perubahan di pohon kerja Anda, lakukan git commit -ayang menambahkan semua file yang dimodifikasi ke panggung dan kemudian lakukan.

Apa gunanya panggung itu? Anda dapat dengan mudah memisahkan komit Anda. Bayangkan Anda mengedit joypad.cpp dan gamesave.cpp dan Anda ingin mengkomitnya secara terpisah

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 bahkan memiliki perintah untuk memutuskan baris tertentu dalam file yang sama yang ingin Anda salin ke panggung sehingga Anda dapat membagi komit-komit tersebut secara terpisah. Mengapa Anda ingin melakukan itu? Karena sebagai komitmen terpisah, orang lain hanya dapat menarik yang mereka inginkan atau jika ada masalah, mereka dapat mengembalikan hanya komit yang memiliki masalah.


"Git bahkan memiliki perintah untuk memutuskan baris mana dalam file yang sama yang ingin Anda salin ke panggung sehingga Anda dapat membagi komit itu secara terpisah juga." Apa perintah ini?
James McMahon

1
@James: git add --patch, melihat linux.die.net/man/1/git-add atau penggunaan git add -i, seperti di stackoverflow.com/questions/2372583/...
tanascius

@ gman: alih-alih memeriksa master dan bercabang dengan checkout -b <name>Anda bisa gunakan git branch <name>untuk membuat cabang baru tanpa beralih ke itu
tanascius

8

Ada bagan perbandingan dinamis di di versioncontrolblog di mana Anda dapat membandingkan beberapa sistem kontrol versi yang berbeda.

Berikut ini adalah tabel perbandingan antara git, hg dan bzr.


1
Informasi tentang Mercurial tidak sepenuhnya akurat: Mercurial memang memiliki "gabungan cerdas setelah dipindahkan atau diganti nama". Konkretnya, ini berarti bahwa jika saya mengganti nama dir-a/foo.cmenjadi dir-b/foo.cdan terus bekerja dir-b/foo.c, maka pekerjaan Anda dir-a/foo.cakan digabung dengan benar dengan pekerjaan saya setelah menarik.
Martin Geisler

Informasi (ini berasal dari perbandingan Inisiatif SCM yang Lebih Baik , IIRC) tentang Git juga tidak akurat atau bahkan tidak terhapus di beberapa tempat.
Jakub Narębski


7

Apakah ada kolaborator berbasis Windows di proyek Anda?

Karena jika ada, GUI Git-for-Windows tampaknya canggung, sulit, tidak ramah.

Sebaliknya, Mercurial-on-Windows adalah no-brainer.


Saya suka git, tapi saya harus setuju di sini. Git memiliki baris perintah yang lebih bagus dengan panggung dan dokumentasi yang lebih baik. Saya akan dengan senang hati menggunakan perintah git dengan shell posix. Namun tortoiseHG di windows sangat bagus, bahkan terintegrasi dengan beberapa alat berbeda (tidak dapat dibandingkan) dan memiliki dukungan penuh untuk sub-repo, dan banyak plugin hg seperti strip / mq
Keyo

Setidaknya ada satu Windows (dan OS X + Linux) Git GUI yang sangat bagus.
Mot

7

Satu hal yang perlu diperhatikan antara mercurial dari bitbucket.org dan git dari github adalah, mercurial dapat memiliki repositori pribadi sebanyak yang Anda inginkan, tetapi github Anda harus meningkatkan ke akun berbayar. Jadi, itu sebabnya saya menggunakan bitbucket yang menggunakan mercurial.


5

Suatu waktu tahun lalu saya mengevaluasi git dan hg untuk saya gunakan sendiri, dan memutuskan untuk pergi dengan hg. Saya merasa itu tampak seperti solusi yang lebih bersih, dan bekerja lebih baik pada lebih banyak platform pada saat itu. Tapi sebagian besar adalah undian.

Baru-baru ini, saya mulai menggunakan git karena git-svn dan kemampuan untuk bertindak sebagai klien Subversion. Ini memenangkan saya dan saya sekarang telah beralih sepenuhnya ke git. Saya pikir itu punya kurva belajar yang sedikit lebih tinggi (terutama jika Anda perlu mencari-cari di dalam), tetapi itu benar-benar sistem yang hebat. Saya akan membaca dua artikel perbandingan yang diposting John sekarang.


4
Lihatlah hgsubversion: bitbucket.org/durin42/hgsubversion . Saat ini membutuhkan versi pengembangan Mercurial, tetapi mereka akan membuat rilis untuk Mercurial 1.3, yang jatuh tempo 1 Juli.
Martin Geisler

4

Saat ini saya sedang dalam proses migrasi dari SVN ke DVCS (saat blogging tentang temuan saya, upaya blogging nyata pertama saya ...), dan saya telah melakukan sedikit riset (= googling). Sejauh yang saya bisa lihat, Anda dapat melakukan sebagian besar hal dengan kedua paket. Sepertinya git memiliki beberapa fitur canggih yang lebih atau lebih baik diimplementasikan, saya merasa bahwa integrasi dengan windows sedikit lebih baik untuk lincah, dengan TortoiseHg. Saya tahu ada Git Cheetah juga (saya mencoba keduanya), tetapi solusi lincah hanya terasa lebih kuat.

Melihat bagaimana mereka berdua open-source (kan?) Saya tidak berpikir keduanya akan kekurangan fitur-fitur penting. Jika sesuatu itu penting, orang akan memintanya, orang akan mengkodekannya.

Saya pikir untuk praktik umum, Git dan Mercurial lebih dari cukup. Mereka berdua memiliki proyek-proyek besar yang menggunakannya (Git -> linux kernel, Mercurial -> proyek yayasan Mozilla, keduanya tentu saja antara lain), jadi saya tidak berpikir keduanya benar-benar kekurangan sesuatu.

Yang sedang berkata, saya tertarik pada apa yang orang lain katakan tentang ini, karena itu akan menjadi sumber yang bagus untuk upaya blog saya ;-)


1
Ya, keduanya adalah proyek open-source.
Martin Geisler


3

Saya menyadari ini bukan bagian dari jawaban, tetapi pada catatan itu, saya juga berpikir ketersediaan plugin stabil untuk platform seperti NetBeans dan Eclipse memainkan bagian di mana alat lebih cocok untuk tugas tersebut, atau lebih tepatnya, alat mana adalah yang paling cocok untuk "kamu". Yaitu, kecuali Anda benar - benar ingin melakukannya dengan cara CLI.

Baik Eclipse (dan semuanya berdasarkan itu) dan NetBeans terkadang memiliki masalah dengan sistem file jarak jauh (seperti SSH) dan pembaruan eksternal file; yang merupakan alasan lain mengapa Anda ingin apa pun yang Anda pilih untuk bekerja "mulus".

Saya mencoba untuk menjawab pertanyaan ini untuk diri saya sendiri sekarang juga .. dan saya sudah menurunkan kandidat untuk Git atau Mercurial .. terima kasih semua untuk memberikan masukan yang berguna pada topik ini tanpa menjadi religius.


2
+1, karena pengalaman "mulus" lebih penting daripada yang dipikirkan orang-orang yang tidak bekerja dengan hal-hal ini. Plugin yang solid untuk IDE membuat banyak perbedaan.
eksortso

2

Namun perbandingan lain yang menarik antara mercurial dan git: Mercurial vs Git . Fokus utama adalah pada internal dan pengaruhnya terhadap proses percabangan.


2

Jika Anda tertarik pada perbandingan kinerja Mercurial dan Git, lihat artikel ini . Kesimpulannya adalah:

Git dan Mercurial keduanya menghasilkan angka yang baik tetapi membuat trade-off yang menarik antara kecepatan dan ukuran repositori. Mercurial cepat dengan penambahan dan modifikasi, dan menjaga pertumbuhan repositori tetap terkendali secara bersamaan. Git juga cepat, tetapi repositori tumbuh sangat cepat dengan file yang dimodifikasi hingga Anda mengemasnya kembali - dan repack itu bisa sangat lambat. Tetapi repositori yang dikemas jauh lebih kecil daripada milik Mercurial.



2

Jika Anda bermigrasi dari SVN, gunakan Mercurial karena sintaksnya JAUH lebih mudah dipahami oleh pengguna SVN. Selain itu, Anda juga tidak bisa salah. Tetapi periksa tutorial GIT dan HGinit sebelum memilih salah satunya.



1

Beberapa orang berpikir bahwa sistem VCS harus rumit. Mereka mendorong menciptakan istilah dan konsep di lapangan. Mereka mungkin akan berpikir bahwa banyak PhD pada subjek akan menarik. Di antara mereka mungkin adalah orang-orang yang merancang Git.

Mercurial dirancang dengan mental yang berbeda. Pengembang seharusnya tidak terlalu peduli tentang VCS, dan mereka seharusnya menghabiskan waktu mereka pada fungsi utama mereka: rekayasa perangkat lunak. Mercurial memungkinkan pengguna untuk menggunakan dan dengan senang hati menyalahgunakan sistem tanpa membiarkan mereka melakukan kesalahan yang tidak dapat dipulihkan.

Alat profesional apa pun harus dilengkapi dengan CLI yang dirancang dengan jelas dan intuitif. Pengguna Mercurial dapat melakukan sebagian besar pekerjaan dengan mengeluarkan perintah sederhana tanpa opsi aneh. Di Git double dash, opsi gila adalah normanya. Mercurial memiliki keuntungan substansial jika Anda adalah orang CLI (dan sejujurnya, setiap Insinyur Perangkat Lunak yang menghargai diri sendiri seharusnya).

Untuk memberi contoh, misalkan Anda melakukan komit karena kesalahan. Anda lupa mengedit beberapa file. Untuk membatalkan tindakan Anda di Mercurial Anda cukup mengetik:

$ hg rollback

Anda kemudian mendapatkan pesan bahwa sistem membatalkan transaksi terakhir Anda.

Di Git Anda harus mengetik:

$ git reset --soft HEAD^

Jadi ok kira Anda memiliki ide tentang reset. Tetapi selain itu Anda harus tahu apa yang me-reset "--soft" dan "--hard" (ada tebakan intuitif?). Oh dan tentu saja jangan lupa karakter '^' pada akhirnya! (Sekarang apa nama Ritchie itu ...)

Integrasi Mercurial dengan alat pihak ke-3 seperti kdiff3 dan berbaur jauh lebih baik juga. Hasilkan tambalan Anda menggabungkan cabang-cabang Anda tanpa banyak rewel. Mercurial juga menyertakan server http sederhana yang Anda aktifkan dengan mengetik

hg serve

Dan biarkan orang lain menelusuri repositori Anda.

Intinya adalah, Git melakukan apa yang Mercurial lakukan, dengan cara yang jauh lebih rumit dan dengan CLI yang jauh lebih rendah. Gunakan Git jika Anda ingin mengubah VCS proyek Anda menjadi bidang penelitian ilmiah. Gunakan Mercurial jika Anda ingin menyelesaikan pekerjaan VCS tanpa peduli, dan fokus pada tugas Anda yang sebenarnya.


1
Sebenarnya Anda bisa menggunakan perintah alias di git , yang membuat CLI lebih mudah digunakan. Ada banyak dari mereka dalam pertanyaan SuperUser (StackExchange) ini .
Spoike

1
Sungguh ya, Anda juga bisa menulis skrip shell untuk menangani beberapa tugas umum. Akhirnya Anda mulai menyadari bahwa Anda sedang membangun CLI pembungkus untuk berurusan dengan VCS yang memiliki CLI yang dirancang dengan buruk dan kontra-intuitif. Dan bukan hanya itu saja. Git memperkenalkan banyak sekali konsep dengan kegunaan yang dipertanyakan sehingga pengguna pada akhirnya dipaksa untuk belajar dan memahami agar merasa nyaman dengan dokumentasi dan pesan-pesan CLI.
Kostas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.