Mengapa Git mendapatkan banyak hype? ... sementara yang lain tidak? [Tutup]


124

Dalam beberapa tahun terakhir, hype di sekitar Git meningkat pesat. Semua orang tahu tentang Git, tidak ada yang tahu tentang alternatif.

Yang lain seperti Mercurial tampaknya tidak diperhatikan. Keduanya telah dirilis pada tahun 2005, dan menyediakan fungsionalitas serupa. Selain itu, Mercurial umumnya dianggap lebih mudah digunakan, lebih intuitif dan memiliki UI yang lebih baik untuk waktu yang lama. Oleh karena itu, dapat diasumsikan bahwa ini akan menjadi alternatif yang populer, terutama bagi mereka yang baru untuk kontrol versi terdistribusi. Namun, tampaknya tidak diketahui oleh kebanyakan orang, tidak seperti Git yang berhasil dengan cukup baik.

Maksud dari posting ini adalah untuk mencoba memahami fenomena ini dengan lebih baik.

Bagaimana bisa Git mendapatkan semua bagian dari kue? Apakah mereka entah bagaimana menggunakan pemasaran yang lebih baik? Apakah karena komunitasnya lebih ... ahem ... "verbose"? Apakah itu karena nama "Linus"? Apakah karena gambarnya yang culun?

Apa pendapatmu?


63
Anda mungkin benar tentang Linus Torvalds menjadi satu-satunya alasan popularitasnya ...
Robert Koritnik

4
Saya tidak tahu, saya merasa mereka telah terpapar pada saya dalam jumlah yang kira-kira sama ... walaupun saya memang mendengar tentang git sebelum hg. Tapi ya, Torvalds adalah seorang selebritas, jadi apapun yang dia lakukan sepertinya akan mendapat perhatian.
pelaku

13
Saya suka GitHub ... itu saja
cnd

7
@ jrwren, saya akan mengawali komentar ini dengan mengatakan bahwa saya tidak menggunakan Git atau Mercurial. Jika saya belajar Git dan kemudian segera belajar Mercurial (atau sebaliknya), salah satu dari mereka mungkin akan membawa saya lebih sedikit waktu untuk belajar. Yang itu, yang butuh waktu lebih sedikit, adalah yang saya anggap lebih mudah digunakan. Grokking biasanya menyiratkan bahwa perlu waktu untuk memahami, yang karenanya lebih sulit untuk digunakan. Saya tidak mengatakan itu akan membuat produk lebih buruk, kadang-kadang Anda membutuhkan kurva belajar yang lebih curam untuk alat yang lebih kuat, tetapi itu tentu saja mengubah kemudahan penggunaan.
zzzzBov

8
@MarkTrapp God, Mark! Sepertinya semua orang sedang berdiskusi dengan baik dan kemudian Anda harus ikut serta mengawasi semua orang. Saya berharap saya tahu situs seperti StackOverflow yang memungkinkan diskusi.
Theodore R. Smith

Jawaban:


86

Saya percaya layanan seperti GitHub atau Gitorious adalah faktor besar. Sangat penting bagi orang-orang bahwa mereka dapat meng-host barang-barang mereka di suatu tempat dan terutama GitHub adalah layanan hebat untuk itu.

Untuk lincah, tidak ada layanan seperti itu ketika DVCS menjadi populer (setidaknya tidak ada yang saya sadari). Anda memiliki Bitbucket sekarang dan mungkin yang lain, tetapi GitHub telah ada cukup lama, itu sudah terkenal dan semakin baik.


Tambahkan ke ini bahwa beberapa proyek open source besar menggunakan git yang membuat keputusan untuk Anda. Saya telah "dipaksa" untuk menggunakan git beberapa kali (untuk android misalnya) tetapi saya belum dipaksa untuk menggunakan Mercurial atau Bazaar. Juga, saya pikir git hebat :)
FeatureCreep

11
Ada juga Google Code dan SourceForge untuk hg
konfigurator

7
Git didorong oleh Github yang menempatkan repositori lain di tempat teduh. Bitbucket memiliki beberapa kelebihan (repositori pribadi gratis) tetapi UI-nya buruk dibandingkan dengan Github
iandotkelly

2
Saya menggunakan Mercurial sendirian untuk berbicara dengan GitHub ... plugin hggit ( hg-git.github.com ) memungkinkan untuk memisahkan alat dari komunitas. Tapi mungkin bukan dari alat komunitas.
bpanulla

1
CodePlex juga mendukung Mercurial.
Grant Palin

86

Saya melihat banyak jawaban untuk ini yang bergantung pada perasaan yang penulis miliki ketika mendengar tentang satu atau lebih SCM lainnya. Yang lain mengatakan itu semua hanya keberuntungan. Saya percaya keberuntungan dapat dilacak kembali dalam sejarah.

Saya akan berbicara tentang sejarah.

Git dan Mercurial diciptakan secara bersamaan untuk menyelesaikan masalah yang sama. Pada masa itu, kernel Linux terpaksa berhenti menggunakan BitKeeper , SCM terdistribusi eksklusif yang telah digunakan selama 3 tahun. Alasannya adalah Larry McVoy, CEO BitMover, perusahaan di belakang BitKeeper, berhenti memberikan perangkat lunaknya secara gratis kepada pengembang Linux, karena seseorang di dalam komunitas Linux telah merekayasa baliknya.

Linus Torvalds, tidak puas dengan apa yang sudah ada, kemudian mulai bekerja pada SCM baru yang ia akan segera hubungi Git. Segera setelah itu, Matt Mackall memulai proyek Mercurial dengan alasan yang sama.

Setelah beberapa waktu mengembangkan proyek-proyek ini secara terpisah, Matt Mackall menyajikan versi lanjutan dari SCM-nya dan membandingkannya dengan cara tertentu, membandingkannya dengan Git (yang baru berumur beberapa minggu). Linus mempertimbangkan untuk menggunakannya sebagai ganti Git untuk pengembangan Kernel, tetapi membatalkan ide ketika ia menyadari bahwa Mercurial menggunakan Changesets untuk mencatat modifikasi revisi . Dia takut itu terlalu dekat dengan cara kerja BitKeeper, dan dia tentu tidak ingin apa pun yang bisa membuat seseorang berkata, "Mereka membangun kloning BitKeeper".

Karena itu Git digunakan untuk pengembangan Kernel alih-alih Mercurial, tetapi keduanya secara teknis relevan. Hasil akhirnya adalah, Git memulai dengan menjadi benar-benar digunakan di mana ia dirancang untuk digunakan, sementara Mercurial tidak secepat untuk menemukan penggunaan FOSS besar pertama. Karena dianugerahi dengan desain yang sangat bagus, dan berkat ketekunan Matt Mackall, akhirnya menjadi terkenal dan digunakan untuk proyek-proyek besar, dunia nyata.

Hari ini, keduanya terkenal. Mana yang paling terkenal tidak mungkin dikatakan. Google Code baru-baru ini mengintegrasikan Git, sementara itu memiliki Mercurial untuk waktu yang lama. Banyak proyek yang sangat besar dan terkenal digunakan.

Saya kira apa yang saya maksudkan adalah, ketika alasan mengapa Anda memulai sebuah proyek hilang, lebih sulit untuk mendapatkan popularitas, tetapi masih layak.

Bazaar adalah SCM lain yang sangat terkenal di dunia GNU, tetapi tidak begitu banyak di luar itu, karena ia dibangun dengan tujuan memuaskan komunitas GNU. Perangkat lunak seringkali pergi ke tempat yang diinginkan oleh pembuatnya, dan tidak lebih jauh.

Di sisi lain, SCM yang didistribusikan adalah pemenang yang jelas. Saya tidak melihat banyak SCM non-distribusi yang banyak digunakan di luar sana.


5
Saya sangat menghargai sejarah ini.
jrwren

4
@ TMN Anda benar! Faktanya, ketika reverse-engineering Andrew Tridgell menjadi jelas, dan ketika Larry McVoy mengubah lisensi BitKeeper, ada begitu banyak perang api sehingga Linus Torvalds memutuskan untuk menjatuhkannya, dan memberi waktu satu minggu bagi dirinya untuk mencari pengganti. Pada saat itu, pesaing sebenarnya adalah Monoton, tetapi sangat lambat. Banyak orang membangun penggantian pada saat yang sama, dan semua orang senang menggunakan alat baru. Saya pikir Git mencapai 1,0 dulu, lalu Mercurial; Bazaar memakan waktu hampir dua tahun.
Thaddee Tyl

7
"Saya tidak melihat banyak SCM non-distribusi yang banyak digunakan di luar sana." Itu tergantung di mana Anda berada di industri. Perforce, ClearCase, dan svn masih sangat banyak digunakan, hanya saja tidak begitu banyak (kecuali untuk svn) di dunia open source. Oh, ya, dan Visual Source Safe dan MS Team apa pun itu di toko Windows.
Bob Murphy

13
Dengan "rekayasa balik", maksud Anda telneting ke server dan mengetik "bantuan"
alternatif

3
Saya akan mengatakan ini secara umum tentang DVCS dan CVCS: "Semua perangkat lunak mengambil bagian dalam Tao dan tidak boleh dihina." "Termasuk perangkat lunak dari Redmond?" "Oh, astaga, lihat jamnya. Kelas dibubarkan."
Bob Murphy

77

Linus Torvalds

Linus adalah penganjur besar Git dan mempromosikannya secara besar-besaran ke kelompok inti linux selama bertahun-tahun dan berkembang dari sana. Saya yakin itu sepenuhnya karena pengaruh Linus terhadap komunitas * nix.

Secara pribadi saya masih menggunakan Subversion, tapi itu dari preferensi daripada utilitas.


12
Saya tidak berpikir itu Linus secara pribadi sebanyak visibilitas besar Linux - Ada beberapa hal yang dapat Anda katakan kepada seseorang tanpa pengetahuan sebelumnya tentang DVCS (atau bahkan pengembangan perangkat lunak pada umumnya) lebih mungkin untuk memberikan kredibilitas daripada "itu digunakan untuk Kernel Linux ".
Michael Borgwardt

6
Bukan hanya dia penganjur besar - dia adalah orang yang menciptakan versi asli sebelum dia menyerahkannya kepada Junio ​​Hamano
Marco Ceppi

44
Apa? Mengapa Anda lebih suka Subversi?
konfigurator

11
Bukankah maksud Anda bahwa Anda masih menggunakan Subversi karena kebiasaan dan kelembaman, alih-alih preferensi atau kegunaan? Itu sebabnya saya masih menggunakannya, dan saya curiga sebagian besar dari kita juga ...
Cody Gray

7
@deadalnix: Karena Linux, dan Linux, memiliki gerombolan fanboys berteriak yang tak tertandingi oleh proyek open source lainnya. Mereka berfungsi sebagai tim jalanan yang cukup efektif untuk Git.
Tom Anderson

34

Titik sakit yang biasa dengan sistem kontrol versi adalah penggabungan cabang .

Anda harus mencobanya ketika tidak berhasil untuk memahami betapa menyakitkannya hal itu dan betapa pentingnya bekerja, agar dapat bekerja secara bebas dengan cabang-cabang.

Mengetahui bahwa Linus Torvalds menulis git untuk melakukan hal ini dengan benar, dan bahwa dalam satu situasi ia menggunakan git untuk menggabungkan dua belas cabang sekaligus, ini adalah argumen yang sangat meyakinkan agar git menjadi menarik.

Saya berada dalam situasi sekitar setahun yang lalu di mana saya harus memilih antara hg dan git, dan penggabungan di atas adalah salah satu faktor penting dalam memilih git. Yang kedua adalah bahwa organisasi Eclipse beralih ke git, sehingga tooling Eclipse diharapkan baik untuk proyek-proyek Java. Dengan dirilisnya Eclipse 3.7 ini telah terjadi. Kami mungkin 6-9 bulan lebih awal dalam hal ini.

Untuk kebutuhan yang berbeda, hg mungkin sama bermanfaatnya. Sun memilihnya untuk VCS mereka berdasarkan investigasi yang sangat hati-hati. Anda mungkin ingin menemukan kertas putih dan melihat apa alasannya.


EDIT: Catatan, saya tidak mengatakan bahwa ada sesuatu yang Mercurial tidak dapat lakukan, hanya saja untuk Java dengan Eclipse - yang merupakan fokus utama kami - kekuatan pasar saat ini terkuat untuk git, bahkan di bawah Windows, dan kami harus berdiri di bahu orang lain, bukan kaki mereka.


5
+1 Semuanya ada di cabang. Analisis ini membahas kekuatan penggabungan git dibandingkan dengan mercurial.
Amelio Vazquez-Reina

19
@AmV: Tolong jangan memposting URL yang dikaburkan.
Cody Grey


4
Saya tidak yakin saya mengerti maksud Anda di sini. Anda mengatakan bahwa mereka sama-sama pandai bercabang (Git tidak melakukan apa pun yang Mercurial tidak bisa lakukan), tetapi karena Anda membutuhkan percabangan yang baik, Anda memilih Git?
Jalf

8
Saya belum pernah melihat contoh meyakinkan tentang bagaimana Git lebih baik dalam menggabungkan daripada Mercurial, dan tentu saja tidak dalam jawaban ini. Ini hampir seperti Anda membingungkan Hg dengan SVN atau CVS.
Aaronaught

23

Alih-alih mengatakan mengapa git atau lincah lebih baik dan mengatakan itu satu-satunya alasan populer, saya akan fokus pada komunitas.

Seperti yang saya tekankan sebelumnya , komunitas Git sangat keras dan sombong. Sebagian besar akan dengan kuat mempertahankan program berharga mereka. Sebagian besar perang Git vs Mercurial yang saya lihat dimulai oleh orang-orang git yang bertanya-tanya mengapa semua orang di Bumi tidak menggunakan git suci. Situs- situs seperti whygitisbetterthanx.com bahkan menunjukkan kesombongan ini dalam pendahuluan, yang ditulis untuk menyulut umpan orang lain.

Saya tidak mengatakan semua orang seperti ini, tetapi sebagian besar waktu ketika saya bertemu orang git, situs web pro-git, dan blog pro-git saya merasa seperti git didorong ke tenggorokan saya alih-alih ditawarkan sebagai DVCS yang layak sistem.


Sebaliknya, komunitas DVCS lainnya tidak sekeras itu. Saya tidak tahu Mercurial ada sampai saya melihat "Apa DVCS terbaik?" pertanyaan di SO. Ketika git muncul di mana-mana, DVCS lain membutuhkan waktu untuk menemukannya.


16
Bukankah menyebut orang lain sombong sedikit arogan?

21
@ Thorbjørn: Ya. Kecuali ketika saya melakukannya; maka itu benar.
Tom Anderson

6
Saya pikir Anda sudah cukup alergi terhadap git. Saya telah membaca pengantar whygitisbetterthanx dan beberapa kontennya. Saya tidak melihat sesuatu yang sombong atau provokatif. Itu hanya memiliki bias normal, bahwa apa pun yang dimaksudkan untuk mempromosikan sesuatu memiliki.
back2dos

5
@ back2dos: cukup sombong karena mengklaim "Git lebih baik dari segalanya". Dan dalam potongan yang cukup besar dari argumen pendukungnya adalah salah dan tidak dikoreksi, atau dicoret, namun entah bagaimana itu tidak pernah mengubah kesimpulannya.
Jalf

5
@ Agos: Dan hampir semuanya tidak unik untuk Git. Mereka hanya memindahkan tiang gawang untuk mengecualikan produk lain.
Aaronaught

14

Saya tidak berpikir Mercurial sangat low profile. Kiln dibangun di atas Hg & telah ada dukungan yang baik dalam IDE seperti Eclipse & Netbeans untuk sementara waktu sekarang.

Sebagian besar pengembang yang saya ajak bicara tampaknya lebih suka Hg karena dukungan Windows yang lebih baik. Jika kami adalah pengembang Linux, itu mungkin cerita yang berbeda.

Anda juga kehilangan "Bazaar" yang merupakan "DVCS" yang sesungguhnya dilupakan.

Tentu saja saya setuju bahwa Linus adalah seorang pria yang sangat karismatik dan seorang nerd yang hampir tidak ada taranya sehingga banyak orang akan tertarik pada Git karena itu. Juga, "Mitos penciptaan" Git sangat menarik dengan Linus yang bekerja selama 6 hari untuk menciptakan Git dan beristirahat pada hari ketujuh - atau sesuatu seperti itu. Ketika suatu produk memiliki kisah yang mudah diingat, lebih mudah untuk mendapatkan daya tarik.


6
... sepenuhnya setuju dengan: "Bazaar" yang merupakan "DVCS" yang nyata.
dagnelies

setuju tapi paparan hg dari kiln / joel lebih baru daripada paparan git dari linus. hg sedang bermain catchup
jk.

2
Sebenarnya ada beberapa "DVCS yang terlupakan" di luar sana, meskipun banyak dari mereka mungkin akan lebih baik digambarkan sebagai "low profile", "fokus" atau "niche".
John Gaines Jr

13

Itu pendapat yang sederhana, tetapi git mungkin mendapatkan semua sensasi ini karena dua parameter:

  1. Ini sangat efisien
  2. Sangat menyenangkan untuk digunakan (dalam beberapa jenis cara ilmuwan komputer yang sangat spesifik)

Plus, git punya beberapa aplikasi pembunuh seperti github, dan beberapa proyek yang sangat populer memutuskan untuk menggunakannya, yang memberinya banyak visibilitas.


4
1. Apakah beberapa merkur tidak efisien? Sebenarnya, untuk waktu yang lama, itu lebih efisien daripada http, itulah sebabnya kode google memasukkannya sejak lebih dari 2 tahun, dibandingkan dengan dukungan git yang diumumkan minggu lalu dan menjadi baru-baru ini sama bagusnya dengan http. 2. OK 3. Ada
bitbucket.org yang

1
Apakah saya mengatakan bahwa lincah tidak efisien? Saya tidak pernah menggunakannya, jadi saya tahu.
Thibault J

4
ini sama sekali tidak menjawab pertanyaan imho, setidaknya bukan bagian "sementara yang lain tidak"
jk.

1
Mercurial tidak dapat menambahkan "folder kosong" ke repositori (tidak tahu apakah ini sudah diperbaiki sekarang) tetapi ketika saya harus memilih DVCS, saya akhirnya pergi git untuk tujuan ini. Saya perlu beberapa folder kosong.
Martin Marconcini

4
@ MartínMarconcini Apa yang Anda maksud dengan "Saya akhirnya pergi git untuk tujuan ini"? git juga tidak mendukung folder kosong.
Max Nanasy

12

Ada tiga faktor yang bekerja di sini, "beta geek media", "waktunya tepat", dan "ikuti pemimpin"

Beta Geek Media

Ada sejumlah saluran yang mendapatkan diskusi tentang "kegiatan geeky". Mereka pasti akan menutupi tampilan sistem kontrol versi baru, tetapi mereka lebih banyak membahas git. Mengapa? Karena Linus Torvalds menulisnya pada awalnya, membantahnya secara terbuka, dan menggunakannya sebagai solusi untuk masalah bitkeeper yang dipublikasikan dengan baik. Secara efektif, setiap kali ada perang api pada lkml, media beta geek akan menulis artikel tentang itu. Diskusi Git dimulai pada lkml, sehingga mendapat lebih banyak liputan daripada alternatif lain. Dan beta geeks yang membaca slashdot seperti Variety memakannya. Hasil akhir dari hal itu adalah bahwa git memiliki artikel sepuluh kali lebih banyak daripada lincah.

Waktunya tepat

Proyek open source besar dengan banyak kontributor memiliki masalah dengan kontrol sumber terpusat. Ketika sumber terbuka tumbuh, dan proyek menjadi lebih mungkin untuk memiliki banyak kontributor, masalahnya menjadi lebih buruk. Linux mungkin adalah proyek yang paling terkenal menderita dari ini, tetapi ada banyak yang lain. Dengan banyak proyek yang mencapai titik ini, beberapa jenis VCS canggih diperlukan. Git, Mercurial, dan Bazaar adalah pemenang besar di sini. Arch dan Monoton sedikit terlalu dini, dan melewatkan gelombang hype.

Ikuti sang pemimpin

Proyek besar memiliki pengikut yang memeriksa dan membuat kode secara teratur, bahkan jika mereka tidak berkontribusi. Para pengikut menjadi terbiasa dengan alat yang dibutuhkan untuk mengambil proyek yang mereka ikuti, sehingga alat-alat itu dapat digunakan lebih banyak. Mari kita lihat proyek "undian besar" untuk tiga DVCS besar:

  • Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
  • Mercurial : Java, Mozilla, Python
  • Bazaar : Ubuntu, Emacs

Git memiliki lebih banyak "proyek menarik" proyek yang menggunakannya, sehingga lebih banyak orang yang akrab dengan git, ada lebih banyak tutorial git yang ditulis.


1
Anda mungkin benar, tetapi daftar "undian besar" Anda agak menyesatkan / bias. Melihat di situs Bazaar, mereka mendaftar beberapa proyek besar lainnya: MySQL, Bugzilla, Debian, GNU semuanya tampak seperti yang sudah dikenal luas. Daftar Hg juga sedikit lebih besar.
jalf

@jalf: daftar seperti itu harus subjektif. Saya sudah mengkompilasi Linux dan Gnome saya sendiri, tetapi tidak pernah Mozilla atau Emacs. Yang lain mungkin sebaliknya. Pertanyaannya adalah "berapa banyak orang yang akan menarik proyek ini dari kontrol sumber"? Saya mencantumkan yang tampaknya paling mungkin bagi saya untuk menginspirasi orang untuk menginstal vcs untuk menarik sumber saat ini.
Sean McMillan

Cukup adil. Saya berasumsi itu adalah upaya daftar sasaran (lagipula, daftar proyek besar mana yang menggunakan setiap sistem DVCS harus cukup mudah untuk dilacak) :)
jalf

12

Ini terutama hanya sensasi yang memperkuat diri sendiri. Git adalah yang paling populer, sehingga mendapat publisitas paling banyak, yang membuatnya semakin populer.

Git, Hg, dan Bzr semuanya adalah sistem DVCS yang sangat baik, tetapi sejumlah orang yang menakutkan menyamakan DVCS dengan Git, dan berpikir bahwa semua fitur indah dari DVCS adalah unik untuk Git. Jadi mereka menggunakan Git, dan merekomendasikan Git, dan mengatakan hal-hal seperti "Git lebih baik karena bisa melakukan penggabungan gurita" (Begitu juga Bazaar), atau "Git lebih baik karena didistribusikan" (demikian pula setiap DVCS, maka namanya ), atau "Git lebih baik karena membuat percabangan dan penggabungan menjadi mudah" (sekali lagi, ini berlaku untuk setiap DVCS).

Sedihnya, karena saya merasa alternatif memiliki banyak hal untuk ditawarkan juga, dan saya lebih suka orang memilih Git karena kekuatannya yang unik, daripada hanya karena mereka berpikir DVCS == Git.

Ketika seseorang menemukan betapa cerdiknya DVCS, dengan menunjuk ke satu DVCS tertentu, mereka sering tidak pergi dan memberi tahu orang lain "hei, DVCS bagus, Anda harus menggunakannya", melainkan, "DVCS yang saya belajar tentang DVCS dari bagus, Anda harus menggunakannya ".


11

Github. Github adalah pelopor dalam pengkodean sosial. Itu mengubah kontrol versi menjadi platform sosial yang menarik banyak perhatian, dan itu jelas hanya mendukung Git. Media sosial = adopsi yang lebih besar. Bitbucket mulai mendapatkan banyak fitur baru, membuatnya menjadi saingan :)


7

Yah sebenarnya saya pikir hype adalah tentang semua pertemuan DSVC.

Tetapi para advokat git lebih vokal, seringkali lebih agresif dalam komentar mereka untuk jujur ​​dan suka membicarakannya di mana-mana.

Saya menduga Mercurial digunakan secara luas, tentu saja sesering git, mungkin lebih (Microsoft dan perusahaan besar lainnya menggunakannya sekarang), tetapi orang yang menggunakan Mercurial paling sering hanya menginginkan DSVC yang dapat mereka pahami dengan cepat, bukan sesuatu yang menjadi dasar agama. Jadi mereka paling tidak vokal dan lebih reaktif dalam diskusi daripada proaktif seperti beberapa pengguna git.

Bazaar tidak banyak dibicarakan karena hanya beberapa proyek besar yang diketahui yang menggunakannya dan tidak ada perusahaan besar selain Canonical yang menggunakannya. Bandingkan dengan Google (git, mercurial, svn) dan proyek open-source besar misalnya dan Anda dapat melihat mengapa itu tidak benar-benar dibicarakan. Fosil adalah satu lagi yang menarik untuk niche devs, jadi saya kira itu normal dan baik bagi mereka untuk didengar hanya oleh mereka yang mencari fitur yang mereka sediakan (seperti embedded wiki, pelacakan masalah dan forum).

Yang sedang berkata, saya pikir kita perlahan turun siklus hype dan banyak pengembang yang menggunakan beberapa solusi yang berbeda dapat mulai melihat mana yang sesuai dengan kebutuhan mereka.

Juga, Google Code Hosting dan SourceForge sekarang memungkinkan git dan lincah sehingga menjadi lebih spesifik untuk proyek tertentu daripada sebelumnya ketika Anda memilih git karena fitur GitHub.

Tidak ada perang nyata, hanya berbagai alat yang menarik.


Saya berharap hype tentang DVCS secara umum, tetapi dari semua yang saya lihat, hype tentang Git, dan kebanyakan orang berpikir bahwa DVCS dan Git pada dasarnya adalah hal yang sama.
Jalf

6

Saya tahu sudah ada banyak jawaban untuk pertanyaan ini, tetapi saya merasa saya bisa menambahkan sedikit lebih banyak perspektif.

Saya menggunakan Bazaar cukup banyak sejak itu dibuat untuk berbagai hal. Hal terbesar yang saya gunakan untuk itu adalah proyek AllTray, di mana saya (saat ini) satu-satunya pengembang dan pengelola. Bazaar bagus. Itu hanya berfungsi, itu tetap keluar dari jalan saya, dan hampir tidak pernah saya harus melihat halaman - help atau halaman manual untuk itu. Yang mengatakan, ada beberapa kelemahannya:

  1. Banyak fungsi yang dimilikinya yang seharusnya menjadi bagian dari VCS inti, bukan. Hal-hal seperti kemampuan untuk melakukan pembelahan sejarah, untuk menjalankan keluaran panjang melalui pager, atau untuk memiliki cabang "colocated" (misalnya, repositori gaya git) disediakan sebagai plugin.
  2. Banyak plugin yang tidak stabil. Sebagai contoh, fungsi cabang colocated tampaknya tidak berfungsi dengan baik di sisi server (setidaknya, saya tidak pernah membuatnya berfungsi, itu cenderung keliru mengatakan bahwa cabang di jalur yang diberikan tidak ada ketika itu tepat di depan Anda dan Anda dapat melihat benda berdarah).
  3. Ini tidak memiliki operasi "klon", Anda menarik cabang satu per satu. Anda harus melakukan pekerjaan ekstra jika Anda ingin memiliki repositori sehingga Anda dapat menarik cabang baru secara efisien.
  4. Untuk beberapa proyek, ini sangat lambat. Coba "bzr branch lp: mysql" kapan-kapan.
  5. Tidak memiliki dukungan kuat untuk kait; Anda dapat menulis plugin bzr yang menyediakan kait, tetapi tidak ada cara standar untuk memiliki skrip kait sewenang-wenang sisi server.

Saya baru-baru ini beralih ke git untuk pengembangan AllTray, dan saya sangat cepat mempertimbangkan untuk memigrasi semua proyek saya ke git. Ada lebih banyak waktu di muka dihabiskan untuk mengenal tali, tetapi tampaknya layak. Beberapa hal yang saya perhatikan:

  1. git clone adalah operasi yang relatif cepat, dan memberi Anda informasi tentang semua cabang yang ada di repositori yang Anda kloning.
  2. Menambahkan repositori jarak jauh tambahan tidak menyakitkan, sehingga Anda dapat melacak banyak repositori berbeda yang memiliki banyak cabang jika diinginkan.
  3. The Git Pro buku yang tersedia secara online dan dalam berbagai format, termasuk untuk pembaca e-book perangkat-dan tidak membaca sulit.
  4. git tampaknya jauh lebih mudah diperluas daripada Bazaar, dan Anda tidak harus menggunakan satu API tertentu untuk melakukannya. (NB: ini adalah sisi positif dan negatifnya.)
  5. git memiliki built-in pembelahan, dan saya tidak bisa cukup menekankan utilitas fitur itu.
  6. GitHub lebih baik.
  7. The gitosisSistem ini juga cukup bagus. Saya bahkan tidak yakin bagaimana seseorang akan mengimplementasikannya selain sebagai plugin di Bazaar, dan saya tidak bisa membayangkan itu akan menjadi seefisien mungkin.

Singkat cerita: Saya sudah menggunakan bzr untuk waktu yang sangat lama, tetapi git dengan cepat membuktikan betapa megahnya saya.


5

Menggunakan git, Anda cenderung untuk selalu berada di direktori lokal yang sama ketika Anda melakukan pengembangan, dan cukup melakukan git checkout branchnameuntuk beralih antar cabang (saya menggunakan cabang fitur "ringan" sepanjang waktu, jadi ini adalah fitur yang sangat penting bagi saya).

Melihat dokumentasi dan tutorial Mercurial, tampaknya cara yang disukai untuk menangani berbagai cabang pembangunan adalah dengan membuat repositori baru dengan mengkloning. Tutorial ini adalah contohnya.

Saya percaya Anda dapat melakukan hal yang sama di Mercurial seperti di git, tetapi untuk beberapa alasan dokumentasi Mercurial (yang telah saya baca) hampir selalu menunjukkan percabangan dengan membuat klon repositori.

(Saya menggunakan git setiap hari. Saya memiliki sedikit pengalaman dengan lincah, saya telah bermain dengannya dan mengikuti beberapa tutorial)


2
Saya menggunakan cabang 'bernama' sepanjang waktu di hg. Ini mendukung mereka dengan baik. hg branch foo, kemudian hg up foonanti ... Klon-untuk-cabang memiliki beberapa kelemahan kuat untuk pengembangan biasa.
Paul Nathan

Hmm, jadi Anda mengatakan bahwa Git lebih baik daripada Hg karena sementara Hg mendukung fitur yang Anda pedulikan, komunitas Hg menganggap pendekatan alternatif lebih unggul?
Jalf

1
1: Saya bertanya-tanya: Mengapa fokus pada "cabang dengan kloning" dalam dokumentasi Hg (lihat misalnya hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html dan mercurial.selenic. com / guide )? Bagi saya, sepertinya berantakan untuk memiliki satu repositori per cabang. 2: Saya tidak mengatakan git lebih baik, jawaban saya lebih merupakan pengamatan tentang hal yang bagi saya (seorang pemula Hg) terlihat seperti perbedaan antara keduanya. Perbedaannya tampaknya lebih bersifat budaya daripada teknis, karena Hg juga mendukung "branch dalam repositori yang sama".
codeape

3
Mercurial menderita banyak informasi online yang kedaluwarsa; banyak yang dipropagasi oleh orang-orang yang menggunakan git dan tidak mengikuti perkembangan fitur-fitur lincah saat berevolusi. Sebagian besar alasan lama untuk memilih repositori hasil kloning tidak lagi berlaku dalam versi modern dari merkuri (cabang bernama dapat ditutup sekarang, dan ada sistem bookmark yang memberi Anda pola penggunaan yang mirip dengan git cabang jika Anda suka).
Stephen M. Redd

4

Saya tidak tahu berapa banyak kata-kata kasar seperti yang saya lihat beberapa minggu terakhir, tetapi mereka semua menganggapnya sebagai fakta bahwa Mercurial dan / atau Bazaar secara objektif lebih baik daripada Git. Kegunaan tampaknya menjadi tema umum. Ya, mempelajari Git ternyata sangat sulit setelah menggunakan CVS dan Subversion, tetapi pada titik ini saya tidak ingin menukarnya dengan VCS lain kecuali itu merupakan perubahan paradigma lain . Dan menunjuk ke daftar fitur akan memberi tahu saya sedikit tentang seberapa fleksibel, dapat diperluas, aman, atau mudahnya itu. Misalnya, secara default git-diff menggunakan warna dan pager. Tentu saya bisa mendapatkan yang sama dengan diff ... | colordiff | less -Ratau sesuatu, tetapi harus jelas mengapa yang satu lebih unggul dari yang lain.


Saya tidak berpikir argumennya adalah karena itu Anda harus beralih - jelas menggunakan alat yang sudah Anda ketahui lebih mudah daripada beralih ke yang lain, tidak peduli betapa mudahnya yang lain. Saya tidak berpikir setiap pendukung DVCS benar-benar dapat mengklaim Anda kehilangan sejumlah besar dengan menjadi git daripada Bazaar atau Mercurial, tidak ada banyak di antara mereka.
ZoFreX

3

Agar adil, saya pikir advokat git vs mercurial sedikit dan jauh di antara dibandingkan dengan advokat git vs terpusat. Namun, alasannya mudah diringkas:

Git adalah kontrol versi untuk programmer. Mercurial adalah kontrol versi untuk perusahaan. Terpusat adalah upaya pertama yang memadai untuk menciptakan kontrol versi, terutama mengingat itu dirancang sebelum revolusi komputer pribadi.

Apa yang saya maksud dengan kontrol versi untuk programmer adalah bahwa programmer pada umumnya lebih menyukai fleksibilitas daripada kemudahan belajar. Bagaimanapun, kami bersedia menghabiskan waktu bertahun-tahun untuk belajar bahasa esoterik agar memiliki fleksibilitas untuk membuat komputer melakukan apa yang tidak dapat dilakukan oleh orang yang tidak terlatih. Git memberi para programmer fleksibilitas untuk menggunakannya sesuka mereka, dengan mengorbankan waktu lebih lama untuk belajar bagaimana menggunakan fleksibilitas itu dengan aman. Ini memungkinkan pembatasan diberlakukan untuk menegakkan kebijakan, tetapi tidak muncul begitu saja. Catatan saya katakan kemudahan belajar daripada kemudahan penggunaan . Setelah Anda mempelajarinya, git mudah digunakan seperti VCS lainnya, dan seringkali lebih mudah karena peningkatan kecepatan dan fitur.

Beberapa programmer cukup belajar untuk melakukan apa yang mereka inginkan, kemudian menolak mempelajari cara-cara baru untuk melakukannya. Perusahaan mempekerjakan dan mempekerjakan banyak dari orang-orang ini, sehingga mereka ingin setiap perubahan dalam alat yang mereka gunakan memiliki tingkat keakraban tertentu. Perusahaan juga ingin programmer mereka memiliki fleksibilitas yang cukup untuk melakukan pekerjaan mereka, tetapi tidak terlalu mempersulit pelatihan atau migrasi awal. Di sinilah mercurial cocok. Ia memiliki sebagian besar kekuatan git, tetapi jalur migrasi agak lebih mudah.

Saya tidak berpikir adil untuk mengatakan git hanya populer karena hype, atau dukungan Linus. Itu mungkin menjelaskan bagi banyak orang yang mencobanya , tetapi mereka tetap menggunakannya dan mempromosikannya karena itu bekerja dengan baik untuk mereka, murni dan sederhana.




1

Saya baru-baru ini mencari sistem kontrol versi untuk proyek-proyek pribadi, jadi saya hanya mencoba banyak dari mereka. Saya pada dasarnya buta huruf di baris perintah, dan saya pernah mendengar bahwa meskipun GUI tersedia, Git benar-benar dimaksudkan untuk digunakan melalui baris perintah, yang membuat saya agak ragu-ragu. Jujur saja, itu sangat mudah untuk diambil, dan saya benar-benar menikmatinya. Dokumentasi adalah faktor besar dalam adopsi teknologi baru, dan Git memiliki banyak dokumentasi sederhana yang sangat jelas dan tersedia. Alternatif lain seperti SVN dan Bazaar sangat bagus, mereka tidak membuatnya semudah Git. Github juga merupakan faktor besar, karena telah menjadi sangat penting bagi pergerakan open source saat ini. Memiliki (secara ironis) lokasi terpusat untuk bertukar kode dan proyek melalui adalah pengubah permainan itu sendiri.


1

Hanya 2 ¢ saya - saya memilih git daripada alternatif karena ditulis dalam bahasa C daripada bahasa radtool atau bahasa tingkat tinggi yang terlalu akademis. Keuntungannya adalah cepat dan efisien dan saya bisa benar-benar RTFS jika saya menemukan bug atau perilaku yang tidak bisa saya jelaskan. Hal ini juga memungkinkan untuk digunakan pada lingkungan pengembangan kecil yang di-host sendiri yang tidak menyertakan interpreter / runtime raksasa, yang berarti saya dapat langsung menarik dari repo git dan mengkompilasi pada sistem seperti itu daripada harus mengambil sumber terbaru di tempat lain dan rsync.


1
Itu juga alasan mengapa saya memilih git, karena itu ditulis dalam bahasa yang dikompilasi daripada python, dan karena itu saya hanya dapat memiliki versi portabel git di pena usb saya bersama dengan beberapa alat lainnya.
Coyote21

Namun, inilah tepatnya alasan Facebook memilih untuk menggunakan merkuri: mereka tidak senang dengan kinerja keduanya, tetapi merasa lebih mudah untuk meningkatkan kinerja merkuri (yang, untuk sebagian besar operasi, hanya sebagian kecil lebih lambat daripada git keseluruhan) dengan margin yang signifikan (yang mereka lakukan dengan mengintegrasikannya dengan layanan pemantauan file sehingga dapat mengetahui apa yang bisa dan tidak bisa berubah, lihat detailnya di sini ) karena fakta bahwa python lebih mudah untuk dikerjakan daripada C.
Jules

1

Anda mungkin tertarik untuk membaca mengapa proyek desktop GNOME memilih git daripada hg dan bzr, ketika ia memutuskan untuk pindah dari svn beberapa tahun yang lalu. Ada banyak diskusi keagamaan yang hangat sepanjang jalan, tetapi halaman Wiki GNOME ini dengan baik merangkum pro dan kontra ketika mereka diterapkan pada komunitas tertentu.


0

Belum lagi Apple sekarang telah terlibat dengan mendorongnya ke komunitas c tujuan, jika Anda telah membuat aplikasi baru di Xcode 4 baru-baru ini, Anda akan memperhatikan bahwa itu secara otomatis bertanya apakah Anda ingin membuat repo Git.

Memang Xcode 4 baru ada selama beberapa bulan, dan tidak mempengaruhi kesuksesan Gits sebelumnya, tetapi kita semua tahu betapa populernya Apple dapat membuat banyak hal dalam waktu singkat.


-1

Saat ini saya beralih dari hg (kiln) ke git (github). Saya telah menggunakan kiln selama sekitar satu tahun sekarang. Bagi saya hg tidak memiliki kerugian. Saya bisa melakukan semua yang harus saya lakukan. Sangat bagus.

Mengapa saya menggunakan sekarang?

Hanya ada tiga alasan saat ini.

  1. gitHub menawarkan intisari yang hebat
  2. gitHub menawarkan fitur sosial yang luar biasa
  3. Saat melakukan presentasi dan lokakarya pengembang, saya selalu menerbitkan sampel saya di hg dan git. Di git saya sudah sekitar 10 kali lebih banyak pengunjung daripada di hg !!

Saya pikir yang ketiga adalah yang paling penting.

Thorsten


-2

Keberuntungan murni kurasa, sampai sekarang hampir mustahil untuk membuktikan mengapa sesuatu berhasil dan yang lainnya tidak. Linus dapat membangun sesuatu yang spektakuler dan tidak berhasil.

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.