DVCS (git atau hg) mana yang lebih mudah bagi siswa pemrograman? [Tutup]


25

Sedikit konteks: Saya tahun ke-3 kuliah. siswa dibagi menjadi beberapa tim yang terdiri dari 4. Hampir semua orang akan bekerja di bawah windows (kecuali beberapa seperti saya yang ada di linux). Sebagai bagian dari kurikulum sekolah, kami akan segera mulai mengerjakan proyek untuk klien nyata, tetapi saya dan tim lain bertanya-tanya cara mana yang terbaik untuk berbagi kode kami satu sama lain.

Saya telah bekerja paruh waktu selama 3 tahun dan memiliki banyak pengalaman menggunakan git dan lincah pada proyek yang berbeda, jadi saya tidak punya masalah menggunakan satu sistem atau yang lain. Namun, tidak ada rekan tim saya yang pernah menggunakan sistem kontrol versi sebelumnya. Ada juga tim lain yang telah mencoba menggunakan SVN tetapi memiliki masalah besar dan lebih suka mencoba sesuatu yang lain, jadi mereka meminta pendapat saya.

Pikiran saya: Saya pernah mendengar bahwa Mercurial + TortoiseHg memiliki integrasi yang lebih baik di bawah windows, tetapi saya bertanya-tanya apakah konsep kepala anonim dapat membingungkan mereka bahkan jika saya menjelaskannya. Di sisi lain, saya menemukan bahwa git branch lebih mudah dipahami oleh pemula (pemisahan pekerjaan yang jelas untuk setiap programmer) tetapi tidak berfungsi dengan baik di bawah windows.


2
git memiliki banyak kekuatan yang diaktifkan secara default, tetapi semua orang yang saya ajak bicara mengatakan lincah lebih mudah dipelajari, dan saya cenderung setuju berdasarkan pengalaman saya menggunakan keduanya. Dan ya, alat lincah lebih mudah untuk menginstal di Windows vs setara git mereka. Yang mengatakan, berharap untuk memandu orang dan mengarahkan mereka di tutorial untuk minggu pertama (atau lebih ...).
wkl

1
Menggunakan DVCS dari awal mungkin merupakan cara paling sederhana untuk mengelola kontribusi penggabungan dari banyak kontributor yang bekerja secara paralel. Jika Anda menemukan kepala anonim membingungkan, jangan gunakan mereka (dukungan lincah bernama cabang).
Stephen C. Steel

2
Waktu lagi untuk menautkan ke posting blog ini? Git adalah Harrier Jump Jet .
sbi

1
Saya tidak pernah mengerti mengapa keseluruhan "terlalu sulit untuk dipelajari" penting. Oke, jadi butuh 20 menit untuk belajar bagaimana melakukan dan bercabang dan seperti menentang 10 ... Masalah besar?
alternatif

1
Tonton (salah satu dari mereka) melalui hginit.com dan mengambil tindakan berdasarkan reaksi mereka.
chelmertz

Jawaban:


49

Mercurial, tanpa keraguan.

Ini tentu saja, subyektif, dan vaires dari satu orang ke orang lain, tetapi pendapat umum adalah bahwa Mercurial lebih mudah untuk grok, terutama untuk seseorang yang baru mengenal VCS atau seseorang yang berasal dari salah satu VCS generasi lama.

Poin di tangan:

  1. Mercurial dikembangkan dengan mempertimbangkan Windows ; Git diangkut. Tidak peduli apa yang orang coba katakan kepada saya, Git masih warga negara kelas dua di Windows. Banyak hal telah membaik selama beberapa tahun terakhir, tetapi Anda masih melihat banyak pertengkaran tentang mengapa sesuatu bekerja / atau tidak berfungsi pada Windows seperti pada * nix box. TortoiseHg bekerja dengan sangat baik, dan implementasi Visual Studio bahkan lebih mudah digunakan tanpa memutus alur kerja Anda.

  2. Jika seseorang memulai diskusi "Git lebih kuat setelah Anda ...", maka dia cukup banyak mengatakan itu semua. Untuk 95% pengguna, Mercurial tampaknya lebih intuitif. Mulai dari kurangnya indeks, hingga opsi yang lebih intuitif (sakelar opsi koheren), ke nomor lokal untuk komit alih-alih hash SHA1 (siapa yang pernah berpikir hash SHA1 ramah pengguna ??!)

  3. Cabang-cabang Mercurial tidak kalah kuat dari Git. Posting yang menggambarkan beberapa perbedaan. Kembali ke revisi sebelumnya semudah "perbarui revisi lama". Mulai dari sana; lakukan saja komit baru. Cabang yang dinamai juga tersedia jika seseorang ingin menggunakannya.

Sekarang, saya tahu bahwa semua ini adalah perincian, dan mereka dapat dipelajari dan segalanya, tetapi masalahnya adalah ... semua ini bertambah. Dan pada akhirnya, yang satu tampak lebih sederhana dan lebih intuitif dari yang lain. Dan sistem kontrol versi seharusnya tidak menjadi sesuatu yang orang habiskan untuk belajar - Anda ada di sana untuk belajar pemrograman dan kemudian memprogram; VCS adalah alat.

Hanya untuk diperhatikan; Saya menggunakan Git dan Mercurial setiap hari. Jangan kesulitan menggunakan salah satu dari mereka. Tetapi ketika seseorang meminta rekomendasi kepada saya, saya selalu merekomendasikan Mercurial. Masih ingat, ketika pertama kali masuk ke tangan saya, rasanya sangat intuitif. Dalam pengalaman saya, Mercurial hanya menghasilkan lebih sedikit WTF / menit dari Git.


4
+ untuk "VCS adalah alat". Saya belum menganggap "hal-hal kecil" sebagai faktor, tetapi memang benar bahwa ketika Anda menjumlahkan masalah kecil di sana-sini mereka dapat menjadi gangguan nyata.
Gregory Eric Sanderson

8
"Sistem kontrol versi seharusnya bukan sesuatu yang dihabiskan seseorang untuk belajar." Ini adalah omong kosong. Anda harus selalu menghabiskan waktu mempelajari alat Anda. Anda menghabiskan waktu mempelajari kompiler Anda; tetapi VCS adalah alat yang sangat penting untuk pemrograman Anda seperti halnya kompiler Anda.
JesperE

9
+1. Terutama argumen 'warga negara kelas dua di windows' sangat penting dalam situasi ini.
tdammers

+1 untuk "WTF (s) / menit" ( osnews.com/story/19266/WTFs_m ). Anak-anak ini harus belajar skillz :-)
Ross Patterson

1
@Mark itu hanya hasil dari perbedaan terminologi ... Cabang di Git sebenarnya hanya sebuah nama.
alternatif

10

Saya telah menemukan bahwa TortoiseHg UI adalah pengalaman hebat di Windows. Ketika bereksperimen dengan Git di masa lalu, saya malah pergi ke baris perintah. Untuk pengguna biasa, UI yang baik jauh lebih mudah didekati daripada baris perintah. Jadi, saya sarankan menggunakan Mercurial. (Ini termasuk grafik cabang yang bagus di jendela meja kerja juga. Ini harus menjernihkan setiap kesulitan percabangan dasar.)

Setelah mereka memahami hal-hal dari perspektif UI, mereka mungkin akhirnya pergi ke baris perintah ke skrip atau melakukan operasi manual - tetapi mereka tidak perlu.


Menjadi "pecandu konsol" sendiri saya belum pernah menggunakan aplikasi Tortoise {Svn, Git, Hg} sebelumnya jadi saya tidak tahu TortoiseHg memiliki grafik cabang. Saya harus memeriksanya
Gregory Eric Sanderson

4

Jika Anda tertarik pada opsi ketiga, saya sarankan fosil . Saya menemukan kemampuan untuk membuang server web temp untuk berbagi kode bekerja dengan baik dalam proyek-proyek kecil. Fosil hanyalah sebuah executable, sehingga Anda bisa memasukkannya dan sumber Anda ke dalam thumb drive, dan menggunakannya dari komputer universitas mana pun.

Gunakan fossil uiuntuk memulai server web temp di mana pun Anda berada untuk menyinkronkan sesama siswa dengan Anda. Ini juga memberi Anda sistem tiket, wiki, dan antarmuka web yang mudah digunakan untuk mengubah cabang dan menandai komitmen.

Pastikan mereka membaca panduan mulai cepat , dan / atau buku . Akhirnya, ada sebuah proyek bernama winFossil untuk memberi mereka antarmuka pengguna yang lebih ramah daripada web ui.


Saya telah mendengar hal-hal baik tentang fosil, tetapi sayangnya saya tidak punya banyak waktu untuk mengenal DVCS baru. Saya lebih suka menggunakan sesuatu yang saya terbiasa (jika mungkin) karena saya sudah tahu cara mengatasi perangkap yang paling umum. Tapi terima kasih atas sarannya, saya pasti akan memeriksanya begitu saya punya waktu.
Gregory Eric Sanderson

+1; fosil sedikit diketahui tetapi sangat mudah untuk bekerja dan mandiri (dvsc + wiki + tiket + server web) yang merupakan alternatif nyata untuk seluruh trac atau bahkan github.
Javier

Tetapi fosil tidak akan terlihat sebagus pada CV siswa sebagai git atau hg, karena sangat sedikit orang yang sulit melakukannya.
Ian

Mercurial juga telah membangun fungsionalitas servis hg. Itu melewatkan pelacak bug dan wiki tentu saja. Tetapi kemudian ada bitbucket.com
Johannes Rudolph

3

Mengingat bahwa tim-tim tersebut baru mengenal kontrol versi, dan banyak yang menggunakan Windows, saya akan merekomendasikan mercurial over git.

Model konseptual dari kontrol versi yang digunakan oleh git dan mercurial sangat mirip, jadi setelah Anda menguasainya, mudah untuk mengambil yang lain (dan untuk alasan yang sama, sangat mudah untuk mengubah repositori dari satu ke yang lain) . Ini berarti ini bukan masalah besar jika Anda berubah pikiran nanti.

Menurut pendapat saya, lincah lebih mudah bagi pengguna baru untuk belajar. Itu membuat hal-hal sederhana menjadi mudah, dan yang berbahaya menjadi sulit. Git membuat operasi berbahaya mudah (mudah dilakukan, tidak harus mudah dilakukan dengan benar!).

Antarmuka TortoiseHg untuk Winodows juga sangat bagus, dan merupakan argumen lain yang mendukung penggunaan mercurial.


2

Preferensi pribadi saya adalah untuk git.

Namun, karena beberapa orang akan menggunakan windows dan tutorial hginit yang luar biasa ada, saya sarankan mengajar mereka lincah.


+1 untuk menyebutkan hginit. Meskipun, Pro Git juga cukup bagus.
Tamás Szelei

@ TamásSzelei, Terima kasih, saya belum pernah melihat Pro Git sebelumnya.
dan_waterworth

0

Seperti yang disarankan banyak orang, Mercurial via TortoiseHg memiliki penghalang yang sangat rendah untuk masuk.

Bagi mereka yang menggunakan Windows, ini adalah satu penginstal dan bukan dua penginstal (dan banyak hal yang mungkin tidak ingin mereka pelajari) dan antarmuka pengguna THg jauh lebih halus daripada TortoiseGit + Msysgit .

Kepala anonim

Jika Anda berpikir mereka akan bingung dengan kepala anonim, maka jangan mendorong penggunaannya. Sebagian besar hgbuku mengambil pendekatan yang seimbang dan mengajarkan cabang topologi dan bernama, dan biarkan pembaca menentukan mana yang paling tepat untuk mereka gunakan.

Cabang yang diberi nama

Satu hal yang saya benar-benar rindu di gitadalah hg's cabang bernama , jadi itu salah satu pilihan. gitcabang baik-baik saja saat Anda mengerjakannya, tetapi begitu Anda telah menggabungkan pekerjaan itu ke cabang lain, Anda kehilangan banyak konteks untuk perubahan itu.

Di dalamnya, hgAnda bisa membuat cabang bernama Jira#1234dan selalu dapat menemukan semua revisi yang terkait dengan perbaikan itu . Di git, setelah cabang Anda digabungkan dan ref dihapus, Anda harus menyimpulkan revisi mana yang merupakan bagian dari perbaikan dari topologi pohon revisi. Bahkan jika Anda tidak menghapus ref, Anda masih tahu komit terakhir pada cabang itu, bukan leluhur mana yang merupakan bagian dari rantai komit itu.

Bookmark

Atau, jika Anda tidak ingin menggunakan cabang bernama, tetapi ingin gitalur kerja gaya dengan cabang anonim Anda, maka Anda dapat menggunakan bookmark .

Ini bisa menjadi yang terbaik dari kedua dunia - mereka bisa mempelajari gitalur kerja, tetapi bisa menggunakan hgperintah yang lebih sederhana .

Indeks / Cache / Pementasan area

Secara pribadi, saya pikir siswa jauh lebih mungkin untuk bingung dengan gitindeks / cache / area pementasan daripada oleh hgkepala anonim. Saya lebih suka hgmenjadikan fungsionalitas lanjutan ini opsional di baris perintah, alih-alih gitmengasumsikan Anda selalu ingin / perlu menggunakannya.

Saya juga berpikir bahwa area pementasan mendorong komit yang belum diuji atau bahkan disusun. Karena banyak dari tempat saya bekerja memiliki tidak komit jika tidak kompilasi aturan, saya lebih suka menunda / simpanan mengubah saya tidak ingin sekarang, unit test ulang-lari dan melakukan versi yang Saya tahu kompilasi.

Ketika nanti Anda melacak bug menggunakan hg bisect atau git bisect , Anda akan berterima kasih pada diri sendiri bahwa Anda dapat menguji semua revisi, bukan hanya yang mengkompilasi.


Anda tidak harus menghapus cabang git setelah selesai; itu hanya kebiasaan. Juga -1 untuk salah mengartikan penggunaan indeks - Anda tidak menggunakannya untuk menentukan komit yang buruk, Anda menggunakannya untuk menentukan langkah parsial dari serangkaian komit yang lebih besar. Biasanya ini terjadi selama rebase ketika Anda sedang membersihkan riwayat Anda.
alternatif

@mathepic - Jika Anda tidak menghapus nama cabang, dan mendorong semua cabang 'fix' lokal Anda ke jarak jauh maka Anda akan berakhir dengan sejumlah besar referensi, sama seperti Anda berakhir dengan sejumlah besar cabang lama di svn. Dalam hgcabang-cabang ini nama-nama selalu topologi lokal, jadi Anda hanya melihatnya jika Anda mencarinya.
Mark Booth

@ mathepic - Adapun -1 Anda, saya pikir Anda salah menafsirkan apa yang saya katakan. Saya tidak bisa membayangkan mengapa ada orang yang dengan sengaja membuat komit buruk, tetapi dengan git mudah melakukannya secara tidak sengaja. Jika Anda lupa bahwa file cmengimplementasikan antarmuka yang dimodifikasi dalam file idan tanpa sengaja melakukan itanpanya cmaka jika seseorang melakukan perubahan sebelum Anda sempat melakukan ckompilasi mereka akan gagal. Jika Anda menggunakan alur kerja simpanan / kompilasi / komit sebagai gantinya, kesalahan ini tidak akan terjadi karena bangunan Anda sendiri akan rusak terlebih dahulu. Saya sudah mencoba membuat jawaban saya lebih jelas.
Mark Booth
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.