Saya seorang pecandu Subversion, mengapa saya harus mempertimbangkan Mercurial atau Git atau DVCS lainnya?


300

Saya mencoba memahami manfaat sistem kontrol versi terdistribusi (DVCS).

Saya menemukan pendidikan ulang Subversion dan artikel ini oleh Martin Fowler sangat berguna.

DVCS Mercurial dan yang lainnya mempromosikan cara baru untuk mengerjakan kode dengan perubahan dan komitmen lokal. Ini mencegah penggabungan neraka dan masalah kolaborasi lainnya

Kami tidak terpengaruh oleh hal ini karena saya mempraktikkan integrasi berkelanjutan dan bekerja sendirian di cabang pribadi bukanlah suatu pilihan, kecuali jika kami sedang bereksperimen. Kami menggunakan cabang untuk setiap versi utama, di mana kami memperbaiki bug yang digabungkan dari bagasi.

Mercurial memungkinkan Anda untuk memiliki letnan

Saya mengerti ini bisa berguna untuk proyek yang sangat besar seperti Linux, tetapi saya tidak melihat nilainya dalam tim kecil dan sangat kolaboratif (5 hingga 7 orang).

Mercurial lebih cepat, membutuhkan lebih sedikit ruang disk dan salinan lokal lengkap memungkinkan operasi log & diff yang lebih cepat.

Saya juga tidak khawatir dengan ini, karena saya tidak melihat masalah kecepatan atau ruang dengan SVN bahkan dengan proyek yang sangat besar yang saya kerjakan.

Saya mencari pengalaman dan / atau pendapat pribadi Anda dari mantan Geeks SVN. Terutama mengenai konsep perubahan dan peningkatan kinerja keseluruhan yang Anda ukur.

UPDATE (12 Januari) : Saya sekarang yakin bahwa itu patut dicoba.

UPDATE (12 Juni) : Saya mencium Mercurial dan saya menyukainya. Rasa ceri lokalnya dilakukan. Saya mencium Mercurial hanya untuk mencobanya. Saya harap Server SVN saya tidak keberatan. Rasanya sangat salah. Rasanya benar. Jangan berarti aku jatuh cinta malam ini .

FINAL UPDATE (29 Jul) : Saya mendapat hak istimewa untuk mengulas buku Eric Sink berikutnya yang disebut Version Control by Example . Dia selesai meyakinkan saya. Saya akan pergi untuk Mercurial.


8
Saya juga sangat tertarik dengan ini. Subversion cocok dengan cara saya diajarkan untuk berpikir tentang kontrol versi (berasal dari CVS dan sejenisnya). Namun demikian, sementara saya harus menggunakan Mercurial dan Git untuk mencoba beberapa perbaikan bug untuk proyek open source saya belum dikonversi.
Berin Loritsch

29
+1 untuk pertanyaan. Saat ini telah menjadi kultus kargo yang didistribusikan hanya lebih baik, lebih cepat, lebih sederhana, lebih alami dan bebas masalah dan lebih bersinar 90% dibandingkan dengan terpusat. Kecuali itu tidak harus. Mereka adalah alat yang berbeda , dan masing-masing mungkin memiliki kelebihan dalam beberapa konteks dan kelemahan dalam konteks lain.
Joonas Pulakka

17
@Sharpie: Setelah menggunakan keduanya svn, gitdan hgselama bertahun-tahun, saya cukup menyadari pro dan kontra mereka. Meskipun gittentu saja yang paling kuat dari ini, penting untuk mengakui bahwa lebih kuat tidak secara otomatis menyiratkan lebih baik . Emacs tentu saja lebih kuat daripada editor teks javascript yang berjalan di browser web, tetapi, anehnya, saya menulis komentar ini menjadi editor teks browser javascript sekarang! Kesederhanaan , bahkan kebodohan, memiliki nilai dalam banyak konteks. Menggunakan terpusat svndan sesuatu seperti git-svnlokal menawarkan yang terbaik dari kedua dunia.
Joonas Pulakka

9
@Sharpie: Ini baik untuk Anda bahwa Anda menyukainya. Tapi pro satu orang adalah penipu pria lain. Beberapa orang menganggap kejelasan dari repositori terpusat tunggal dengan satu kanonik tunggal sangat berharga. Berikut adalah presentasi tentang bagaimana Google menyimpan kode sumber semua proyeknya, lebih dari 2000, dalam satu batang kode yang berisi ratusan juta baris kode, dengan lebih dari 5000 pengembang mengakses repositori yang sama. Apakah Anda lebih suka 5000 server dan sejarah 2000 proyek di meja semua orang? -)
Joonas Pulakka

21
-1 untuk referensi Katy Perry. ;)
Amadiere

Jawaban:


331

Catatan: Lihat "EDIT" untuk jawaban pertanyaan saat ini


Pertama-tama, baca Subversion Re-education oleh Joel Spolsky. Saya pikir sebagian besar pertanyaan Anda akan dijawab di sana.

Rekomendasi lain, pembicaraan Linus Torvalds di Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Yang lain ini mungkin juga menjawab sebagian besar pertanyaan Anda, dan itu cukup menghibur.

BTW, sesuatu yang saya temukan cukup lucu: bahkan Brian Fitzpatrick & Ben Collins-Sussman, dua pencipta subversi asli mengatakan dalam satu google talk "maaf tentang itu" merujuk pada subversi yang lebih rendah daripada lincah (dan DVCS pada umumnya).

Sekarang, IMO dan secara umum, dinamika tim berkembang lebih alami dengan DVCS apa pun, dan manfaat yang luar biasa adalah Anda dapat melakukan offline karena itu menyiratkan hal-hal berikut:

  • Anda tidak bergantung pada server dan koneksi, yang berarti waktu lebih cepat.
  • Tidak menjadi budak ke tempat-tempat di mana Anda bisa mendapatkan akses internet (atau VPN) hanya untuk dapat melakukan.
  • Setiap orang memiliki cadangan segalanya (file, riwayat), bukan hanya server. Berarti siapa pun bisa menjadi server .
  • Anda dapat melakukan secara kompulsif jika perlu tanpa mengacaukan kode orang lain . Komit bersifat lokal. Anda tidak menginjak kaki satu sama lain saat melakukan. Anda tidak merusak bangunan atau lingkungan orang lain hanya dengan melakukan.
  • Orang-orang tanpa "akses komit" dapat melakukan (karena melakukan dalam DVCS tidak berarti mengunggah kode), menurunkan penghalang untuk kontribusi, Anda dapat memutuskan untuk menarik perubahan mereka atau tidak sebagai integrator.
  • Ini dapat memperkuat komunikasi alami karena DVCS menjadikan ini penting ... dalam subversi yang Anda miliki adalah balapan komit, yang memaksa komunikasi, tetapi dengan menghalangi pekerjaan Anda.
  • Kontributor dapat bergabung dan menangani penggabungan mereka sendiri, yang berarti lebih sedikit pekerjaan untuk integrator pada akhirnya.
  • Kontributor dapat memiliki cabang sendiri tanpa mempengaruhi orang lain (tetapi bisa membaginya jika perlu).

Tentang poin Anda:

  • Penggabungan neraka tidak ada di DVCSland; tidak perlu ditangani. Lihat poin selanjutnya .
  • Dalam DVCS, semua orang mewakili "cabang", artinya ada penggabungan setiap kali perubahan ditarik. Cabang bernama adalah hal lain.
  • Anda dapat terus menggunakan integrasi berkelanjutan jika Anda mau. Tidak perlu IMHO, mengapa menambah kompleksitas ?, terus pengujian Anda sebagai bagian dari budaya / kebijakan Anda.
  • Mercurial lebih cepat dalam beberapa hal, git lebih cepat dalam hal lain. Tidak benar-benar hingga DVCS secara umum, tetapi untuk implementasi khusus mereka AFAIK.
  • Setiap orang akan selalu memiliki proyek penuh, bukan hanya Anda. Hal terdistribusi berkaitan dengan bahwa Anda dapat melakukan / memperbarui secara lokal, berbagi / mengambil dari luar komputer Anda disebut mendorong / menarik.
  • Sekali lagi, baca Pendidikan Ulang Subversion. DVCS lebih mudah dan lebih alami, tetapi mereka berbeda, jangan mencoba untuk berpikir bahwa cvs / svn === dasar dari semua versi.

Saya berkontribusi beberapa dokumentasi untuk proyek Joomla untuk membantu mengkhotbahkan migrasi ke DVCS, dan di sini saya membuat beberapa diagram untuk menggambarkan terpusat vs didistribusikan.

Terpusat

teks alternatif

Didistribusikan dalam praktik umum

teks alternatif

Didistribusikan secara maksimal

teks alternatif

Anda lihat di diagram masih ada "repositori terpusat", dan ini adalah salah satu argumen favorit penggemar versi terpusat: "Anda masih terpusat", dan tidak, Anda tidak, karena repositori "terpusat" hanyalah repositori Anda semua setuju (mis. repo github resmi), tetapi ini dapat berubah kapan saja Anda butuhkan.

Sekarang, ini adalah alur kerja khas untuk proyek sumber terbuka (misalnya proyek dengan kolaborasi besar-besaran) menggunakan DVCS:

teks alternatif

Bitbucket.org agak setara dengan github untuk mercurial, ketahuilah bahwa mereka memiliki repositori pribadi tanpa batas dengan ruang tak terbatas, jika tim Anda lebih kecil dari lima, Anda dapat menggunakannya secara gratis.

Cara terbaik Anda dapat meyakinkan diri Anda untuk menggunakan DVCS adalah dengan mencoba DVCS, setiap pengembang DVCS berpengalaman yang telah menggunakan svn / cvs akan memberi tahu Anda bahwa itu sepadan dan bahwa mereka tidak tahu bagaimana mereka bertahan sepanjang waktu tanpa itu.


EDIT : Untuk menjawab mengedit kedua saya hanya bisa menegaskan kembali bahwa dengan DVCS Anda memiliki alur kerja yang berbeda, saya akan menyarankan Anda untuk tidak mencari alasan untuk tidak mencobanya karena praktik terbaik , rasanya seperti ketika orang berpendapat bahwa OOP tidak diperlukan karena mereka dapat menyiasati pola desain yang kompleks dengan apa yang selalu mereka lakukan dengan paradigma XYZ; Anda bisa mendapatkan keuntungan.

Cobalah, Anda akan melihat bagaimana bekerja di "cabang pribadi" sebenarnya merupakan pilihan yang lebih baik. Salah satu alasan saya dapat mengatakan tentang mengapa yang terakhir adalah benar adalah karena Anda kehilangan rasa takut untuk berkomitmen , memungkinkan Anda untuk melakukan kapan saja Anda mau dan bekerja dengan cara yang lebih alami.

Mengenai "penggabungan neraka", Anda mengatakan "kecuali kami sedang bereksperimen", saya katakan "bahkan jika Anda bereksperimen + memelihara + bekerja di v2.0 yang dirubah pada saat yang sama ". Seperti yang saya katakan sebelumnya, menggabungkan neraka tidak ada, karena:

  • Setiap kali Anda berkomitmen Anda menghasilkan cabang yang tidak disebutkan namanya, dan setiap kali perubahan Anda memenuhi perubahan orang lain, terjadi penggabungan alami.
  • Karena DVCS mengumpulkan lebih banyak metadata untuk setiap komit, lebih sedikit konflik terjadi selama penggabungan ... sehingga Anda bahkan dapat menyebutnya sebagai "penggabungan cerdas".
  • Saat Anda bertemu konflik gabungan, inilah yang bisa Anda gunakan:

teks alternatif

Juga, ukuran proyek tidak masalah, ketika saya beralih dari subversi saya sebenarnya sudah melihat manfaatnya saat bekerja sendiri, semuanya terasa benar. The changesets (tidak persis revisi, tapi serangkaian tertentu perubahan untuk file tertentu Anda termasuk komit, terisolasi dari negara bagian basis kode) membiarkan Anda memvisualisasikan apa yang Anda maksud dengan melakukan apa yang Anda lakukan untuk kelompok tertentu file, bukan seluruh basis kode.

Mengenai cara kerja perubahan dan peningkatan kinerja. Saya akan mencoba mengilustrasikannya dengan contoh yang ingin saya berikan: proyek mootools beralih dari svn diilustrasikan dalam grafik jaringan github mereka .

Sebelum

teks alternatif

Setelah

teks alternatif

Apa yang Anda lihat adalah pengembang dapat fokus pada pekerjaan mereka sendiri saat melakukan, tanpa takut melanggar kode orang lain, mereka khawatir akan melanggar kode orang lain setelah mendorong / menarik (DVCS: komit pertama, kemudian tekan / tarik, kemudian perbarui ) tetapi karena penggabungan lebih cerdas di sini, mereka sering tidak pernah melakukan ... bahkan ketika ada konflik penggabungan (yang jarang terjadi), Anda hanya menghabiskan 5 menit atau kurang memperbaikinya.

Rekomendasi saya kepada Anda adalah untuk mencari seseorang yang tahu cara menggunakan mercurial / git dan mengatakan kepadanya untuk menjelaskannya kepada Anda secara langsung. Dengan menghabiskan sekitar setengah jam dengan beberapa teman di baris perintah saat menggunakan lincah dengan desktop kami dan akun bitbucket menunjukkan kepada mereka bagaimana untuk menggabungkan, bahkan membuat konflik bagi mereka untuk melihat bagaimana cara memperbaikinya dalam jumlah waktu yang konyol, saya dapat menunjukkan mereka kekuatan sebenarnya dari sebuah DVCS.

Akhirnya, saya akan merekomendasikan Anda untuk menggunakan bitbucket + mercurial daripada git + github jika Anda bekerja dengan windows guys. Mercurial juga sedikit lebih sederhana, tetapi git lebih kuat untuk manajemen repositori yang lebih kompleks (misalnya git rebase ).

Beberapa bacaan tambahan yang disarankan:


18
Jawaban yang bagus, tetapi hanya satu pertanyaan untuk kita yang berada di kapal yang sama dengan OP: dapatkah Anda menjelaskan bagaimana menggabungkan neraka tidak ada? Apakah integrator atau kontributor tidak perlu melalui tindakan yang sama ketika garpu mereka sudah ketinggalan zaman?
Nicole

17
Jawaban yang bagus. Hanya sebuah catatan: sementara Spolsky mungkin memiliki beberapa poin bagus, ingatlah bahwa ia juga mencoba menjual produk menggunakan poin-poin tersebut sebagai bahan penjualan, yang membuat mereka sedikit bias.
Martin Wickman

5
Saya membaca halaman pendidikan ulang itu, dan tidak menemukannya relevan karena berbagai alasan. Saya akan mengedit pertanyaan saya dengan pandangan pribadi saya tentang masalah ini.

15
Penting juga menunjukkan bahwa Git dapat bertindak sebagai klien Subversion, artinya Anda tidak perlu mengubah semua orang menjadi Git sekaligus; beberapa anggota tim hanya dapat menggunakan Git jika mereka suka, dan alur kerja individu mereka meningkat (terutama karena penggabungan jauh lebih mudah).
greyfade

6
@Pierre, DVCS berupaya menggabungkan perubahan perangkat lunak dari masing-masing programmer, tetapi tidak benar-benar membuat perangkat lunak mengkompilasi atau lulus tes unit yang ada. Anda masih memerlukan perangkat lunak lain untuk melakukan ini kapan pun sumbernya berubah, dan taruhan terbaik yang kami miliki saat ini adalah menggunakan mesin-CI (dan melakukannya dengan benar)

59

Apa yang Anda katakan adalah antara lain bahwa jika Anda pada dasarnya tetap di satu cabang, maka Anda tidak perlu kontrol versi terdistribusi.

Itu benar, tetapi bukankah itu pembatasan kuat yang tidak perlu untuk cara Anda bekerja, dan yang tidak skala baik ke beberapa lokasi di beberapa zona waktu? Di mana server pusat subversi berada, dan haruskah semua orang pulang jika server itu karena suatu alasan turun?

DVCSes adalah untuk Subversion, apa Bittorrent adalah untuk ftp

(secara teknis, tidak secara hukum). Mungkin jika Anda memikirkan hal itu, Anda mungkin mengerti mengapa itu adalah lompatan besar ke depan?

Bagi saya, beralih ke git, segera menghasilkan

  • Cadangan kami lebih mudah dilakukan (cukup "git remote update" dan Anda selesai)
  • Lebih mudah untuk melakukan langkah-langkah kecil ketika bekerja tanpa akses ke repositori pusat. Anda hanya bekerja, dan menyinkronkan ketika Anda kembali ke jaringan hosting repositori pusat.
  • Hudson lebih cepat membangun. Jauh lebih cepat menggunakan git pull daripada memperbarui.

Jadi, pertimbangkan mengapa bittorrent lebih baik daripada ftp, dan pertimbangkan kembali posisi Anda :)


Catatan: Telah disebutkan bahwa ada kasus penggunaan di mana ftp lebih cepat dan daripada bittorrent. Ini berlaku seperti halnya file cadangan yang dikelola editor favorit Anda lebih cepat digunakan daripada sistem kontrol versi.


Saya hampir memutuskan untuk mencobanya dengan proyek nyata.

Ide bagus. Ingatlah untuk masuk ke dalamnya dengan pola pikir "Saya sangat suka ini!" bukannya "Saya tidak ingin MELAKUKAN ini!". Ada banyak yang harus dipelajari. Jika Anda memilih git, github memiliki banyak bantuan online yang bagus. Jika Anda memilih hg, Joel telah menulis beberapa materi online yang bagus. Jika Anda memilih bzr, Canonical kemungkinan besar memiliki banyak materi online yang bagus. Lainnya?

3
Hmm itu mengasumsikan bahwa Anda berpikir bahwa bittorrent lebih baik daripada FTP ...
Murph

2
@Murph, saya tahu, dan begitu juga Blizzard (yang saya yakin kita bisa setujui tahu cara menangani sinkronisasi online besar-besaran?). wowwiki.com/Blizzard_Downloader

2
@ Murph, Anda memulai server torrent di server dan klien torrent di klien. Tidak sulit. Seharusnya segera membeli Anda bahwa hanya file yang telah berubah perlu diperbarui. JUGA, sudahkah Anda mempertimbangkan rsync dan bukannya ftp yang dapat membeli Anda untuk pembaruan tambahan?

46

Fitur pembunuh dari sistem kontrol versi terdistribusi adalah bagian terdistribusi. Anda tidak checkout "copy pekerjaan" dari repositori, Anda mengkloning seluruh salinan repositori. Ini sangat besar, karena memberikan manfaat kuat:

  • Anda dapat menikmati manfaat dari kontrol versi, bahkan ketika Anda tidak memiliki akses internet seperti ... Yang ini sayangnya terlalu sering digunakan dan overhyped sebagai alasan DVCS luar biasa --- itu bukan titik penjualan yang kuat karena banyak kami menemukan diri kami coding tanpa akses internet sesering mulai hujan katak.

  • Alasan sebenarnya memiliki repositori lokal adalah killer adalah bahwa Anda memiliki kendali penuh atas sejarah komit Anda sebelum didorong ke repositori master .

Pernah memperbaiki bug dan berakhir dengan sesuatu seperti:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Dan seterusnya. Sejarah seperti itu berantakan --- hanya ada satu perbaikan, tetapi sekarang implementasinya tersebar di antara banyak komit yang berisi artefak yang tidak diinginkan seperti penambahan dan penghapusan pernyataan debugging. Dengan sistem seperti SVN, alternatifnya adalah tidak melakukan (!!!) sampai semuanya berfungsi untuk menjaga sejarah tetap bersih. Meski begitu, kesalahan lewat dan Hukum Murphy sedang menunggu untuk membuat Anda brutal ketika sejumlah besar pekerjaan tidak dilindungi oleh kontrol versi.

Memiliki klon lokal repositori, yang Anda miliki , memperbaikinya karena Anda dapat menulis ulang sejarah dengan terus-menerus menggulirkan "memperbaikinya" dan "oops" berkomitmen pada komit "perbaikan bug". Pada akhirnya, satu komit bersih akan dikirim ke repositori master yang terlihat seperti:

r321 Fixed annoying bug.

Begitulah seharusnya.

Kemampuan untuk menulis ulang sejarah bahkan lebih kuat ketika dikombinasikan dengan model percabangan. Seorang pengembang dapat melakukan pekerjaan yang sepenuhnya terisolasi dalam cabang dan kemudian ketika saatnya untuk membawa cabang itu ke bagasi, Anda memiliki segala macam opsi menarik:

  • Lakukan penggabungan vanila biasa . Membawa semuanya dalam kutil dan semuanya.

  • Lakukan rebase . Memungkinkan Anda untuk memilah-milah sejarah cabang, mengatur ulang urutan komit, membuang komit, bergabung komit bersama, menulis ulang pesan komit --- bahkan mengedit komit atau menambahkan yang baru! Sistem kontrol versi terdistribusi memiliki dukungan mendalam untuk tinjauan kode.

Setelah saya mengetahui bagaimana repositori lokal memungkinkan saya untuk mengedit sejarah saya demi kewarasan sesama programmer dan masa depan saya sendiri, saya menutup SVN untuk selamanya. Klien Subversion saya sekarang git svn.

Mengizinkan pengembang dan manajer untuk melakukan kontrol editorial atas hasil sejarah komit dalam sejarah proyek yang lebih baik dan memiliki riwayat bersih untuk bekerja dengan benar-benar membantu produktivitas saya sebagai seorang programmer. Jika semua pembicaraan tentang "menulis ulang sejarah" ini membuat Anda takut, jangan khawatir karena itulah untuk repositori sentral, publik, atau master. Sejarah dapat (dan seharusnya!) Ditulis ulang sampai pada titik di mana seseorang membawanya ke cabang dalam repositori yang menarik orang lain. Pada saat itu sejarah harus diperlakukan seolah-olah diukir di atas loh batu.


6
Menulis ulang sejarah: apakah itu hanya masalah Git? Atau mungkinkah Mercurial juga mudah? (Jika ya, saya benar-benar harus mulai melakukannya.)
Paul D. Waite

3
Orang harus menyadari disiplin Kernel Linux ketika melakukan ini - yaitu, jangan pernah rebase (atau menulis ulang sejarah) cabang yang telah Anda publikasikan. Jika Anda memiliki cabang yang umum untuk penggunaan jangka pendek (untuk penggabungan ke cabang yang sering dibuang seperti linux-next, atau bagi seseorang untuk meninjau dan membuang salinan lokal mereka) maka Anda dapat rebase cabang-cabang itu - tetapi Anda pengguna lain harus jelas bahwa konvensi untuk cabang itu adalah bahwa ia dapat diubah kembali dan tidak boleh digabung menjadi cabang jangka panjang orang lain.
Ken Bloom

4
Anda mungkin memiliki akses Internet tanpa memiliki akses jaringan internal penuh. Itu sering terjadi pada saya saat bepergian.

5
Tidak memerlukan akses internet adalah masalah yang sangat besar, karena dari sanalah kecepatan DVCS berasal. Segera setelah Anda harus mengirim paket melalui jaringan, Anda memperlambat proses dengan urutan besarnya atau tidak peduli seberapa baik koneksi Anda.
Adam Lassek

6
@ Paul, pemahaman saya bahwa di Mercurial itu bisa dilakukan, tetapi itu bukan fungsi dasar atau filosofi.
Benjol

18

Jawaban dukofgamings mungkin sekitar sebaik yang bisa didapat, tapi saya ingin mendekati ini dari arah yang berbeda.

Mari kita asumsikan bahwa apa yang Anda katakan benar-benar benar, dan bahwa dengan menerapkan praktik-praktik yang baik Anda dapat menghindari masalah yang DVCS dirancang untuk diperbaiki. Apakah ini berarti bahwa DVCS tidak menawarkan keuntungan bagi Anda? Orang bau di mengikuti praktik terbaik. Orang-orang akan kacau. Jadi mengapa Anda menghindari perangkat lunak yang dirancang untuk memperbaiki serangkaian masalah, memilih untuk mengandalkan orang untuk melakukan sesuatu yang dapat Anda prediksi sebelumnya yang tidak akan mereka lakukan?


2
Sebenarnya saya akan mengajukan argumen ini sebagai melawan DCVS. Perusahaan saya baru-baru ini beralih ke Mercurial dari CVS. Orang-orang menghapus perubahan orang lain selama penggabungan jauh lebih sering ketika di CVS.
Juozas Kontvainis

@JuozasKontvainis: Saya tidak tahu lincah dengan sangat baik, tetapi di git Anda dapat melarang dorongan yang menyertakan gabungan yang tidak memiliki HEAD sebagai orangtua, yang mencegah pengguna mendorong perubahan yang tidak menyertakan perubahan terbaru dari master. Saya yakin ada sesuatu yang serupa dalam lincah.
naught101

@ naught101: sebenarnya, perusahaan saya mengaktifkan pengaturan itu. Apa yang terjadi adalah programmer melakukan perubahannya secara lokal, lalu mencoba mendorong. Dia mendapat respons dari server bahwa dia perlu bergabung sebelum dia bisa mendorong. Dia mendapat pembaruan dari server dan mencoba membuat komit gabungan. Pada titik ini saya tidak tahu persis bagaimana orang-orang membuat komit gabungan tetapi pada beberapa kesempatan yang menggabungkan komit pada dasarnya menghapus perubahan yang mereka dapatkan dari server.
Juozas Kontvainis

1
Sepertinya orang menarik perubahan, lalu benar-benar menghapus perubahan yang mereka dapatkan dari server saat penggabungan (yang dimungkinkan). Tentu saja, set perubahan dari server masih ada, sehingga Anda dapat mengatur ulang repositori ke keadaan sebelum perubahannya.
philosodad

1
sebenarnya, ini terdengar seperti ini: randyfay.com/content/avoiding-git-disasters-gory-story bagus, artikel tidak kritis tentang apa yang bisa salah dengan git repo jika Anda tidak tahu apa yang Anda lakukan.
gbjbaanb

9

Ya, itu menyakitkan ketika Anda harus menggabungkan komit besar dalam subversi. Tetapi ini juga merupakan pengalaman belajar yang hebat, membuat Anda melakukan segala yang mungkin untuk menghindari penggabungan konflik. Dengan kata lain, Anda sering belajar check-in . Integrasi awal adalah hal yang sangat baik untuk proyek yang berlokasi bersama. Selama semua orang melakukan itu, menggunakan subversi seharusnya tidak menjadi masalah.

Git, misalnya, dirancang untuk pekerjaan terdistribusi dan mendorong orang untuk mengerjakan proyek mereka sendiri dan membuat garpu sendiri untuk penggabungan (akhirnya) nanti. Itu tidak secara khusus dirancang untuk integrasi berkelanjutan dalam "tim kecil dan sangat kolaboratif" yang merupakan apa yang diminta OP. Justru sebaliknya, kalau dipikir-pikir itu. Anda tidak akan menggunakan fitur terdistribusi mewah jika semua yang Anda lakukan adalah duduk di ruangan yang sama bekerja sama pada kode yang sama.

Jadi untuk tim yang berlokasi bersama, menggunakan CI, saya benar-benar tidak berpikir itu penting jika Anda menggunakan sistem terdistribusi atau tidak. Itu bermuara pada rasa dan pengalaman.


2
Git dirancang untuk pekerjaan yang didistribusikan di seluruh dunia dan mendorong orang untuk mengerjakan proyek mereka sendiri dan membuat garpu sendiri. Itu tidak secara khusus dirancang untuk integrasi berkelanjutan dalam "tim kecil dan sangat kolaboratif" yang merupakan apa yang diminta OP.
Martin Wickman

4
Coba tebak, Anda mendapatkan konflik yang lebih kecil / mudah diselesaikan. Tetapi jika dua ppl mengubah bagian kode yang sama, Anda memiliki masalah perencanaan di tim Anda, dan itu tidak dapat diselesaikan oleh VCS apa pun. Didistribusikan atau tidak.
Martin Wickman

4
OP berada dalam tim yang ditempatkan bersama menggunakan CI. Ini berarti mereka sering melakukan check-in kecil (beberapa kali sehari). Mengingat ini, saya tidak melihat alasan mengapa menggunakan DVD harus memberikan keuntungan tertentu dan saya tidak melihat alasan mengapa penggabungan besar harus terjadi dan dengan demikian tidak ada neraka gabungan. Saya tidak akan merekomendasikan svn untuk tim terdistribusi, tapi itu tidak terjadi di sini.
Martin Wickman

2
@ MartinWickman - Mercurial dirancang untuk melakukan, bercabang, dan menggabungkan dengan cepat dan murah. Kedengarannya sempurna untuk integrasi berkelanjutan. Secara pribadi, saya berpikir bahwa memiliki kemampuan bagi Alice untuk mengubah perubahannya dan menyarankan agar Bob menariknya dan menggabungkan perubahannya ke cabang itu untuk memeriksa masalah - semua tanpa menyentuh server pusat atau mendorong perubahan di mana saja - terdengar seperti cara yang hebat untuk tim kecil dan sangat kolaboratif untuk bekerja.
philosodad

2
$ 0,02 saya Saya telah menggunakan Subversion, Mercurial, dan Git sekarang untuk berbagai proyek. Subversi tampaknya benar-benar menjadi pilihan terbaik untuk kelompok yang sangat terintegrasi melakukan integrasi berkelanjutan. Mercurial lebih cocok untuk grup yang mungkin hanya melakukan satu build sehari dengan lebih banyak perubahan kode setiap kali (yang akan membuat masalah penggabungan di SVN). Git sepertinya cara yang harus dilakukan untuk orang-orang yang memiliki tim yang bisa pergi berhari-hari / minggu tanpa benar-benar mendorong kode bersama untuk membuat build.
Brian Knoblauch

8

Karena Anda harus terus menerus menantang pengetahuan Anda sendiri. Anda suka subversi, dan saya bisa mengerti karena saya menggunakannya selama bertahun-tahun, dan sangat senang tentang hal itu, tetapi itu tidak berarti bahwa itu masih alat yang paling cocok untuk Anda.

Saya percaya bahwa ketika saya mulai menggunakannya, itu adalah pilihan terbaik saat itu. Tetapi alat lain muncul seiring waktu, dan sekarang saya lebih suka git, bahkan untuk proyek waktu luang saya sendiri.

Dan subversi memang memiliki beberapa kekurangan. Misal, jika Anda mengganti nama direktori pada disk, maka direktori tersebut tidak diganti namanya di repositori. Pemindahan file tidak didukung, membuat file memindahkan operasi penyalinan / penghapusan, membuat penggabungan perubahan saat file telah dipindahkan / diganti namanya menjadi sulit. Dan pelacakan gabungan tidak benar-benar membangun ke dalam sistem, melainkan diimplementasikan dalam bentuk solusi.

Git memang memecahkan masalah ini (termasuk mendeteksi secara otomatis jika suatu file telah dipindahkan, Anda bahkan tidak perlu mengatakan itu adalah fakta).

Di sisi lain git tidak memungkinkan Anda untuk bercabang pada level direktori individual seperti halnya subversi.

Jadi jawaban saya adalah, Anda harus menyelidiki alternatif, melihat apakah itu sesuai dengan kebutuhan Anda lebih baik daripada apa yang Anda kenal, dan kemudian memutuskan.


Sangat benar, bereksperimen alternatif harus otomatis.

git menggunakan heuristik tertentu untuk menentukan apakah suatu file telah dipindahkan, bagus tapi tidak sempurna.
gbjbaanb

Setuju dengan itu, bahkan jika Anda membenci alat baru yang digunakan anak-anak sialan, saya pikir penting untuk memaksa diri Anda setidaknya mencoba hal-hal baru, terutama jika hal-hal ini membuat gelombang besar.
Tjaart

7

Sehubungan dengan kinerja, Git atau DVCS lainnya memiliki keuntungan besar dibandingkan SVN ketika Anda harus beralih dari satu cabang ke cabang lain, atau untuk beralih dari satu revisi ke yang lain. Karena semuanya disimpan secara lokal, banyak hal lebih cepat daripada untuk SVN.

Ini saja bisa membuat saya beralih!


Setuju, checkout git sangat cepat.

+1 untuk menunjukkan hal itu, melompat di antara cabang / perubahan cukup cepat
dukeofgaming

3

Alih-alih berpegang pada gagasan bahwa "dengan menerapkan praktik terbaik Anda tidak memerlukan DVCS", mengapa tidak mempertimbangkan bahwa alur kerja SVN adalah satu alur kerja, dengan satu set praktik terbaik, dan alur kerja GIT / Hg adalah alur kerja yang berbeda, dengan serangkaian praktik terbaik yang berbeda.

git bisect (dan semua implikasinya pada repositori utama Anda)

Di Git, prinsip yang sangat penting adalah Anda dapat menemukan bug menggunakan git bisect. Untuk melakukan ini, Anda mengambil versi terakhir yang Anda jalankan yang diketahui berfungsi, dan versi pertama yang Anda jalankan ternyata gagal, dan Anda melakukan (dengan bantuan Git) pencarian biner untuk mencari tahu komit yang menyebabkan bug. Untuk melakukan ini, seluruh riwayat revisi Anda harus relatif bebas dari bug lain yang dapat mengganggu pencarian bug Anda (percaya atau tidak, ini sebenarnya bekerja cukup baik dalam praktiknya, dan pengembang kernel Linux melakukan ini sepanjang waktu).

Untuk mencapai git bisectkapabilitas, Anda mengembangkan fitur baru di cabang fitur sendiri , rebase dan bersihkan riwayatnya (sehingga Anda tidak memiliki revisi yang tidak berfungsi dalam riwayat Anda - hanya sekelompok perubahan yang masing-masing membuat Anda mengambil jalan tengah untuk memperbaiki masalah), dan kemudian ketika fitur selesai, Anda menggabungkannya ke cabang utama dengan riwayat kerja.

Juga, untuk membuat ini berfungsi, Anda harus memiliki disiplin tentang versi cabang utama tempat Anda memulai cabang fitur Anda. Anda tidak bisa hanya memulai dari kondisi mastercabang saat ini karena mungkin ada bug yang tidak terkait - jadi saran dalam komunitas kernel adalah mulai bekerja dari versi stabil terbaru dari kernel (untuk fitur besar), atau untuk mulai bekerja dari calon rilis yang diberi tag terbaru.

Anda juga dapat mencadangkan kemajuan perantara Anda dengan mendorong cabang fitur ke server, dan Anda dapat mendorong cabang fitur ke server untuk membaginya dengan orang lain dan memperoleh umpan balik, sebelum fitur selesai, sebelum Anda harus ubah kode menjadi fitur permenant dari basis kode yang harus dihadapi semua orang * dalam proyek Anda.

The gitworkflows Halaman manusia adalah pengenalan yang baik untuk alur kerja yang Git dirancang untuk. Juga Mengapa Git Lebih Baik daripada X membahas alur kerja git.

Proyek besar dan terdistribusi

Mengapa kita membutuhkan letnan dalam tim yang sangat berkolaborasi dengan praktik yang baik dan kebiasaan desain yang baik?

Karena dalam proyek-proyek seperti Linux, ada begitu banyak orang yang terlibat yang terdistribusi secara geografis sehingga sulit untuk berkolaborasi dengan tim kecil yang berbagi ruang konferensi. (Saya menduga bahwa untuk mengembangkan produk besar seperti Microsoft Windows yang bahkan jika orang-orang semua berada di gedung yang sama, tim ini terlalu besar untuk mempertahankan tingkat kolaborasi yang membuat VCS yang terpusat bekerja tanpa penolong.)


Saya tidak mendapatkan poin pertama Anda. Apakah Anda punya referensi? Mengenai yang terakhir, saya akan membagi proyek menjadi beberapa komponen yang terpisah. Saya tidak pernah bekerja pada projet yang begitu besar, jumlah maksimum pengembang yang saya dapatkan di proyek yang sama adalah dua lusin.

@Pierre. Itu tentu masuk akal untuk membagi proyek menjadi komponen yang terpisah. Karena Linux adalah kernel monolitik, itu berarti (pada dasarnya) bahwa semua driver perangkat harus dikembangkan dalam repositori yang sama, meskipun masing-masing pada dasarnya adalah proyek yang terpisah. Pada saat yang sama, mereka menginginkan kelincahan bagi arsitek mereka yang lebih berpengalaman untuk membuat perubahan luas yang menyentuh semua driver ini, jadi memecah mereka menjadi repositori yang berbeda akan menyebalkan. Jadi git (dan letnan) cocok untuk mereka dalam mengelola masalah yang berbeda ini.
Ken Bloom

Anda mungkin juga tertarik membaca apa yang dikatakan Martin Fowler tentang alur kerja SVN versus Git dan Mercurial. martinfowler.com/bliki/VersionControlTools.html
Ken Bloom

2
Saya melakukan pembagian dua bagian pada SVN secara teratur untuk menemukan bug. Satu-satunya perbedaan dengan Git adalah tidak semuanya otomatis. Tetapi ini saja tidak akan cukup bagi kita untuk beralih.
Xavier Nodet

1
Relevansi git bisect untuk tim kecil hampir nol. Saya mendapatkannya untuk kernel di mana ratusan perubahan dari orang yang berbeda digabungkan sekaligus dan memecahkan banyak hal, tetapi ketika Anda memiliki tim 5, Anda biasanya dapat menghilangkan semua kecuali 2-3 patch pelakunya yang potensial dengan melihat sekilas pada catatan.
blucz

2

Mengapa tidak menggunakannya bersama-sama? Pada proyek saya saat ini, kami terpaksa menggunakan CVS. Namun, kami juga menyimpan repositori git lokal untuk melakukan pengembangan fitur. Ini adalah yang terbaik dari kedua dunia karena Anda dapat mencoba berbagai solusi dan menyimpan versi dari apa yang sedang Anda kerjakan, pada mesin Anda sendiri. Ini memungkinkan Anda untuk mengembalikan fitur versi sebelumnya atau mencoba beberapa pendekatan tanpa masalah saat Anda mengacaukan kode Anda. Memiliki repositori sentral kemudian memberi Anda manfaat memiliki repositori terpusat.


Tetapi Anda hanya dapat mengatur repositori pusat dengan DVCS (dan Anda dapat mengontrol izin sama
ketatnya

Benar, tetapi repositori git pusat mungkin sulit diatur jika Anda berada di lingkungan Windows. Saya kira itu satu-satunya yang bisa saya pikirkan. Kami terpaksa menggunakan CVS di tingkat perusahaan, jadi kami tidak punya banyak pilihan.
Vadim

1

Saya tidak punya pengalaman pribadi dengan DVCS, tetapi dari apa yang saya kumpulkan dari jawaban di sini dan beberapa dokumen terkait, perbedaan paling mendasar antara DVCS dan CVCS adalah model kerja yang digunakan

DVCS

Model kerja DVCS adalah Anda melakukan pengembangan yang terisolasi . Anda sedang mengembangkan fitur baru / perbaikan bug Anda secara terpisah dari semua perubahan lain sampai saat Anda memutuskan untuk merilisnya ke seluruh tim. Hingga saat itu, Anda dapat melakukan check-in apa pun yang Anda suka, karena tidak ada orang lain yang akan terganggu dengan hal itu.

CVCS

Model kerja CVCS (khususnya Subversion) adalah Anda melakukan pengembangan kolaboratif . Anda sedang mengembangkan fitur baru / perbaikan bug Anda dalam kolaborasi langsung dengan semua anggota tim lainnya dan semua perubahan segera tersedia untuk semua.

Perbedaan lainnya

Perbedaan lain antara svndan git/ hg, seperti revisi vs perubahan adalah kebetulan. Sangat mungkin untuk membuat DVCS berdasarkan revisi (seperti Subversion memilikinya) atau CVCS berdasarkan pada perubahan (seperti yang dilakukan Git / Mercurial).

Saya tidak akan merekomendasikan alat tertentu, karena sebagian besar tergantung pada model kerja yang Anda (dan tim Anda) paling nyaman dengannya.
Secara pribadi, saya tidak punya masalah dengan bekerja dengan CVCS.

  • Saya tidak takut memeriksa barang-barang, karena saya tidak punya masalah memasukkannya ke kondisi yang tidak lengkap, tetapi dapat dikompilasi.
  • Ketika saya mengalami merger-neraka, itu dalam situasi di mana itu akan terjadi pada keduanya svndan git/ hg. Sebagai contoh, V2 dari beberapa perangkat lunak dikelola oleh tim yang berbeda, menggunakan VCS yang berbeda, sementara kami mengembangkan V3. Kadang-kadang, perbaikan bug harus diimpor dari V2 VCS ​​ke V3 VCS, yang pada dasarnya berarti melakukan check-in yang sangat besar pada V3 VCS (dengan semua perbaikan bug dalam satu set perubahan). Saya tahu itu tidak ideal, tetapi itu adalah keputusan manajemen untuk menggunakan sistem VCS yang berbeda.

Saya tidak berpikir bahwa pengembangan yang terisolasi sebenarnya adalah model kerja DVCS. Satu fitur penting dari DVCS adalah anggota tim yang lain dapat menarik perubahan lokal Anda atau mengkloning repositori lokal Anda. Anda berkomitmen ketika Anda suka, perubahan Anda selalu tersedia, dan bug Anda tidak dapat menyebabkan kekacauan massal.
philosodad

@ philosodad: Jika orang lain menarik kode dari repositori saya tanpa mengetahui status kode itu, itu masih dapat menyebabkan kekacauan. Satu-satunya perbedaan adalah tanggung jawab siapa. Dan kode saya tidak selalu tersedia. Itu masih tergantung pada apakah sistem saya dikonfigurasi untuk akses luar.
Bart van Ingen Schenau

Jika orang-orang menarik kode dari repositori Anda dan bergabung dengan mereka sendiri, mereka dapat memutar kembali, independen, tanpa massa masalah. Kedua, tentu saja, jika Anda membuat keputusan untuk menolak akses ke basis kode Anda dan melumpuhkan fitur utama sistem, Anda dapat memaksakan isolasi pada diri Anda sendiri. Itu jauh berbeda dari sistem yang dimodelkan untuk pengembangan terisolasi. DVCS tidak. Pemahaman Anda tentang model kerja DVCS benar-benar salah.
philosodad

1
@ philosodad: Saya pikir saya mulai memahaminya dengan lebih baik dan lebih baik: Semua orang bisa mendapatkan kekacauan Anda, sama seperti di CVCS, tetapi ini bukan lagi kesalahan Anda, karena Anda tidak memaksakannya. :-)
Bart van Ingen Schenau

Yah ... semacam itu. Tetapi biasanya, Alice akan mengkloning atau bercabang terlebih dahulu dan kemudian menggabungkan perubahan Anda, yang membuatnya lebih mudah untuk hanya berpura-pura tidak pernah melihat kode kereta Anda di tempat pertama!
philosodad
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.