Mengapa Git lebih baik daripada Subversi?


393

Saya telah menggunakan Subversion selama beberapa tahun dan setelah menggunakan SourceSafe , saya suka Subversion. Dikombinasikan dengan TortoiseSVN , saya tidak bisa membayangkan bagaimana bisa lebih baik.

Namun ada semakin banyak pengembang yang mengklaim bahwa Subversion memiliki masalah dan bahwa kita harus pindah ke generasi baru dari sistem kontrol versi terdistribusi, seperti Git .

Bagaimana cara Git meningkat pada Subversi?

Jawaban:


548

Git tidak lebih baik dari Subversi. Tetapi juga tidak lebih buruk. Ini berbeda.

Perbedaan utamanya adalah desentralisasi. Bayangkan Anda adalah seorang pengembang di jalan, Anda mengembangkan di laptop Anda dan Anda ingin memiliki kontrol sumber sehingga Anda dapat kembali 3 jam.

Dengan Subversion, Anda memiliki Masalah: Gudang SVN mungkin berada di lokasi yang tidak dapat Anda jangkau (di perusahaan Anda, dan saat ini Anda tidak memiliki internet), Anda tidak dapat melakukan. Jika Anda ingin membuat salinan kode Anda, Anda harus benar-benar menyalin / menempelnya.

Dengan Git, Anda tidak memiliki masalah ini. Salinan lokal Anda adalah repositori, dan Anda dapat berkomitmen padanya dan mendapatkan semua manfaat dari kontrol sumber. Saat Anda mendapatkan kembali konektivitas ke repositori utama, Anda dapat melakukan komitmen terhadapnya.

Ini terlihat bagus pada awalnya, tetapi ingatlah kompleksitas yang ditambahkan pada pendekatan ini.

Git tampaknya menjadi "baru, berkilau, keren". Ini sama sekali tidak buruk (memang ada alasan mengapa Linus menulisnya untuk pengembangan Kernel Linux), tetapi saya merasa bahwa banyak orang yang naik kereta "Distributed Source Control" hanya karena itu baru dan ditulis oleh Linus Torvalds, tanpa benar-benar mengetahui mengapa / jika itu lebih baik.

Subversi memiliki Masalah, tetapi begitu juga Git, Mercurial, CVS, TFS atau apa pun.

Sunting: Jadi jawaban ini sekarang berumur satu tahun dan masih menghasilkan banyak upvotes, jadi saya pikir saya akan menambahkan beberapa penjelasan lagi. Pada tahun terakhir sejak menulis ini, Git telah memperoleh banyak momentum dan dukungan, terutama karena situs seperti GitHub benar-benar lepas landas. Saya menggunakan Git dan Subversion saat ini dan saya ingin berbagi wawasan pribadi.

Pertama-tama, Git bisa sangat membingungkan pada awalnya ketika bekerja secara desentralisasi. Apa itu remote? dan Bagaimana cara mengatur repositori awal dengan benar? dua pertanyaan yang muncul di awal, terutama dibandingkan dengan "svnadmin create" sederhana SVN, "git init" Git dapat mengambil parameter --bare dan - shared yang tampaknya menjadi cara "tepat" untuk mengatur terpusat gudang. Ada alasan untuk ini, tetapi menambah kompleksitas. Dokumentasi perintah "checkout" sangat membingungkan bagi orang-orang yang berubah - cara yang "tepat" tampaknya adalah "git clone", sementara "git checkout" tampaknya beralih cabang.

Git BENAR-BENAR bersinar ketika Anda didesentralisasi. Saya memiliki server di rumah dan Laptop di jalan, dan SVN tidak berfungsi dengan baik di sini. Dengan SVN, saya tidak dapat memiliki kontrol sumber lokal jika saya tidak terhubung ke repositori (Ya, saya tahu tentang SVK atau tentang cara menyalin repo). Dengan Git, itu adalah mode default. Ini adalah perintah tambahan (git commit melakukan secara lokal, sedangkan git push origin master mendorong cabang master ke remote bernama "origin").

Seperti yang dikatakan di atas: Git menambah kompleksitas. Dua mode pembuatan repositori, checkout vs. clone, commit vs push ... Anda harus tahu perintah mana yang bekerja secara lokal dan yang bekerja dengan "server" (Saya berasumsi kebanyakan orang masih suka "master-repositori" sentral) ).

Juga, perkakasnya masih kurang, setidaknya di Windows. Ya, ada Visual Studio AddIn, tapi saya masih menggunakan git bash dengan msysgit.

SVN memiliki keuntungan bahwa ini JAUH lebih mudah untuk dipelajari: Ada repositori Anda, semua perubahan untuk menuju itu, jika Anda tahu cara membuat, melakukan, dan checkout dan Anda siap untuk pergi dan dapat mengambil barang-barang seperti percabangan, memperbarui dll. Nanti di.

Git memiliki keuntungan bahwa JAUH lebih cocok jika beberapa pengembang tidak selalu terhubung ke repositori master. Juga, ini jauh lebih cepat daripada SVN. Dan dari apa yang saya dengar, dukungan percabangan dan penggabungan jauh lebih baik (yang diharapkan, karena ini adalah alasan utama yang ditulis).

Ini juga menjelaskan mengapa ia mendapat banyak buzz di Internet, karena Git sangat cocok untuk proyek-proyek Open Source: Hanya Fork itu, komit perubahan Anda ke Fork Anda sendiri, dan kemudian minta pengelola proyek asli untuk menarik perubahan Anda. Dengan Git, ini hanya berfungsi. Sungguh, coba di Github, ini ajaib.

Apa yang saya juga lihat adalah Git-SVN Bridges: Repositori pusat adalah repo Subversion, tetapi pengembang lokal bekerja dengan Git dan jembatan kemudian mendorong perubahan mereka ke SVN.

Tetapi bahkan dengan tambahan panjang ini, saya masih mendukung pesan inti saya: Git tidak lebih baik atau lebih buruk, hanya saja berbeda. Jika Anda memiliki kebutuhan untuk "Kontrol Sumber Offline" dan kesediaan untuk meluangkan waktu tambahan mempelajarinya, itu fantastis. Tetapi jika Anda memiliki Kontrol Sumber yang terpusat secara ketat dan / atau berjuang untuk memperkenalkan Kontrol Sumber di tempat pertama karena rekan kerja Anda tidak tertarik, maka kesederhanaan dan perkakas yang sangat baik (setidaknya pada Windows) dari SVN bersinar.


70
Ferrari tidak lebih baik dari Hyundai. Tetapi juga tidak lebih buruk. Ini berbeda. (Apa? Jangan memandangi saya dengan cara ini ... Apakah saya mengatakan sesuatu yang salah?)
FDCastel

219
Tidak, kamu tidak. Ferrari tidak praktis, mahal, haus, dan tidak akan membuat Anda lebih baik dari A ke B jika Anda tinggal di kota seperti New York atau Paris - Saya lebih suka Hyundai untuk banyak tempat, juga karena goresan jauh lebih ringan. Tetapi untuk masing-masing sendiri - Ferrari memiliki (sangat sedikit) keuntungan serta ...
Michael Stum

50
Distribusi bukan satu-satunya perbedaan antara Subversi dan Git. Itu juga tidak menambah kompleksitas kecuali Anda menggunakan beberapa repositori. Ada banyak keuntungan menggunakan Git daripada Subversion, tetapi hanya sedikit (kebanyakan tidak signifikan) kerugiannya. Git digunakan karena bagus, tidak mengkilap.
sebnow

6
Pengalaman saya dengan git bukanlah "wahyu yang mengubah hidup". Saya menganggapnya sebagai alat yang hebat ketika bekerja, ketika ketika tidak maka rasanya agak kasar. Saya tidak terlalu terkesan dengan debugging seperti Pertanyaan 1052882, dan meskipun itu jelas merupakan masalah RTFM: Saya menganggap git (dan vcs yang didistribusikan lainnya) lebih rumit daripada yang terpusat, dan saya akan mempertimbangkan menggunakannya di lingkungan terpusat . Tapi sekali lagi, saya terutama pengembang Windows, dan alat-alatnya masih belum matang di Windows dibandingkan dengan SVN.
Michael Stum

5
Anda hanya menganalisis aspek distribusi dalam perbandingan. Saya akan memberi tahu Anda alasannya. Karena Anda hanya ingin membagikan kode. Git dan SVN lebih dari itu, apakah Anda pernah menandai, bercabang, bergabung, menyelesaikan konflik, menyalin tambalan di antara cabang? Saya pikir analisis Anda hanya cacat. Dalam aspek-aspek tersebut, git adalah alat yang sangat kuat. Belum lagi hal-hal yang bisa git, dan SVN tidak bisa, seperti meremas, memotong, memperbaiki, rebasing, memetik ceri, dan banyak lagi hal-hal.
mschonaker

145

Dengan Git, Anda bisa melakukan apa saja secara offline, karena setiap orang memiliki repositori sendiri.

Membuat cabang dan menggabungkan antar cabang sangat mudah.

Bahkan jika Anda tidak memiliki hak komit untuk proyek, Anda masih dapat memiliki repositori online Anda sendiri, dan menerbitkan "permintaan push" untuk tambalan Anda. Setiap orang yang menyukai tambalan Anda dapat menariknya ke dalam proyek mereka, termasuk pengelola resmi.

Itu sepele untuk garpu proyek, memodifikasinya, dan masih terus menggabungkan perbaikan bug dari cabang HEAD.

Git bekerja untuk pengembang kernel Linux. Itu berarti sangat cepat (harus), dan skala ke ribuan kontributor. Git juga menggunakan lebih sedikit ruang (hingga 30 kali lebih sedikit ruang untuk repositori Mozilla).

Git sangat fleksibel, sangat TIMTOWTDI (Ada lebih dari satu cara untuk melakukannya). Anda dapat menggunakan alur kerja apa pun yang Anda inginkan, dan Git akan mendukungnya.

Akhirnya, ada GitHub , situs hebat untuk hosting repositori Git Anda.

Kerugian dari Git:

  • jauh lebih sulit untuk dipelajari, karena Git memiliki lebih banyak konsep dan lebih banyak perintah.
  • revisi tidak memiliki nomor versi seperti di subversi
  • banyak perintah Git bersifat cryptic, dan pesan kesalahan sangat tidak ramah pengguna
  • tidak memiliki GUI yang baik (seperti TortoiseSVN yang hebat )

31
Meskipun mempelajari semua Git akan jauh lebih sulit, dasar-dasarnya hampir identik. Ruang lingkup pembelajaran tidak terlalu curam sampai Anda memasuki hal-hal yang lebih maju, yang SVN tidak mampu melakukannya
sebnow

10
+1 untuk saya. Saya pikir banyak pengembang lupa bahwa git kekurangan sesuatu seperti TortoiseSVN, dan tidak hanya pengembang yang menggunakan kontrol versi. Saya ngeri memikirkan harus menjelaskan (dan mendukung) kontrol versi terdistribusi kepada non-pengembang kami menggunakan SVN | TortoiseSVN!
si618

7
Kerugian lain - Anda harus memiliki salinan lengkap dari repositori, Anda tidak dapat bekerja secara parsial (yang penting jika Anda memiliki yang besar, seperti banyak korporat)
gbjbaanb

3
Saya suka git, tetapi butuh sekitar enam bulan penggunaan sehari-hari untuk benar-benar menggunakannya secara efektif. Yang sedang berkata, saya menggunakan kombinasi git shell (command prompt) dari msysgit, git gui dan gitk dari msysgit, dan TortoiseGit. Saya pikir TortoiseGit hebat, tapi saya tidak mengerti mengapa lebih banyak orang tidak menggunakannya. Saya tahu pengelola msysgit membenci TortoiseGit karena berbagai alasan, beberapa di antaranya ideologis, dan itu mungkin ada hubungannya dengan itu. TortoiseGit adalah rahasia yang disimpan dengan baik!
Jim Raden

2
Saya setuju. Saya menggunakan SVN dan GIT (sejak sekitar 6 bulan). Jujur saya suka git lebih dari yang pernah saya lakukan SVN. Hanya butuh waktu untuk mempelajarinya. Lompatan terbesar bagi saya (saat saya melihat cahaya: P) adalah ketika saya akhirnya menyadari bahwa saya harus berhenti mencoba menggunakan GIT seperti cara kerja SVN. Kemudian semuanya jatuh pada tempatnya;)
Blizz

110

Jawaban lain telah melakukan pekerjaan yang baik untuk menjelaskan fitur inti dari Git (yang hebat). Tetapi ada juga banyak cara kecil yang membuat Git berperilaku lebih baik dan membantu menjaga hidup saya lebih waras. Inilah beberapa hal kecil:

  1. Git memiliki perintah 'bersih'. SVN sangat membutuhkan perintah ini, mengingat seberapa sering ia akan membuang file tambahan pada disk Anda.
  2. Git memiliki perintah 'membagi dua'. Itu bagus.
  3. SVN membuat direktori .svn di setiap folder tunggal (Git hanya membuat satu direktori .git). Setiap skrip yang Anda tulis, dan setiap grep yang Anda lakukan, perlu ditulis untuk mengabaikan direktori .svn ini. Anda juga memerlukan seluruh perintah ("svn export") hanya untuk mendapatkan salinan file Anda yang waras.
  4. Di SVN, setiap file & folder dapat berasal dari revisi atau cabang yang berbeda. Pada awalnya, kedengarannya menyenangkan memiliki kebebasan ini. Tetapi sebenarnya ini berarti bahwa ada jutaan cara berbeda untuk checkout lokal Anda menjadi benar-benar kacau. (misalnya, jika "svn switch" gagal setengah jalan, atau jika Anda salah memasukkan perintah). Dan bagian terburuknya adalah: jika Anda pernah masuk ke situasi di mana beberapa file Anda berasal dari satu tempat, dan beberapa di antaranya dari tempat lain, "status svn" akan memberi tahu Anda bahwa semuanya normal. Anda harus melakukan "info svn" pada setiap file / direktori untuk menemukan betapa anehnya hal-hal tersebut. Jika "git status" memberi tahu Anda bahwa semuanya normal, maka Anda dapat percaya bahwa semuanya benar-benar normal.
  5. Anda harus memberi tahu SVN setiap kali Anda memindahkan atau menghapus sesuatu. Git hanya akan mencari tahu.
  6. Abaikan semantik lebih mudah di Git. Jika Anda mengabaikan suatu pola (seperti * .pyc), itu akan diabaikan untuk semua subdirektori. (Tetapi jika Anda benar-benar ingin mengabaikan sesuatu hanya untuk satu direktori, Anda bisa). Dengan SVN, tampaknya tidak ada cara mudah untuk mengabaikan pola di semua subdirektori.
  7. Item lain yang melibatkan abaikan file. Git memungkinkan pengaturan abaikan "pribadi" (menggunakan file .git / info / exclude), yang tidak akan memengaruhi orang lain.

2
Iklan. 7. Dengan git modern Anda juga dapat memiliki pengaturan abaikan "pribadi" per-pengguna dengan menggunakan variabel konfigurasi core.excludesFile di ~ .gitignore (lihat man git-config).
Jakub Narębski

3
Re # 5: Walaupun ini biasanya benar, terkadang Git mengacaukannya. Setidaknya dengan Subversion, masalah karena pindah atau hapus hampir selalu merupakan PEBKAC. Meskipun bagus untuk memiliki pelacakan pemindahan / penghapusan otomatis, saya masih setidaknya menghargai kemampuan untuk secara eksplisit menyatakan apa yang saya lakukan pada file dalam repositori, bahkan jika saya tidak perlu menggunakannya.
Chris Charabaruk

8
@ Chris: Anda dapat melakukannya dengan jelas: git mvdan git rm.
R. Martinho Fernandes

2
Saya juga ingin melihat opsi direktori .svn tunggal per copy pekerjaan, tetapi sebagai catatan: Untuk # 3: Kebanyakan alat akan (secara default) mengabaikan direktori .svn. Untuk # 6: Anda dapat mengatur properti secara rekursif.
si618

6
3: direktori ".svn" akan ada di sini dengan SVN 1.7 ketika WC-NG diimplemantasikan. 1: Untuk mendapatkan pembersihan SVN Anda 'mengekspor' di atas WC Anda. 5: ini tidak mudah, jika Anda mengganti nama file, apakah git mengenalinya dan menyimpan riwayatnya, atau memperlakukannya sebagai menambah dan menghapus dalam direktori ?. 6/7: svn memiliki pengabaian global per pengaturan klien pengguna.
gbjbaanb

56

" Mengapa Git lebih baik daripada X " menguraikan berbagai pro dan kontra dari Git vs SCM lainnya.

Secara singkat:

  • Git melacak konten daripada file
  • Cabang-cabang yang ringan dan menggabungkan itu mudah , dan maksud saya sangat mudah .
  • Ini didistribusikan, pada dasarnya setiap repositori adalah cabang. Jauh lebih mudah untuk berkembang secara bersamaan dan kolaboratif daripada dengan Subversion, menurut saya. Ini juga memungkinkan pengembangan offline .
  • Itu tidak memaksakan alur kerja apa pun , seperti yang terlihat pada situs web tertaut di atas , ada banyak alur kerja yang mungkin dengan Git. Alur kerja gaya Subversion mudah ditiru.
  • Repositori Git memiliki ukuran file yang jauh lebih kecil daripada repositori Subversion. Hanya ada satu direktori ".git", yang bertentangan dengan puluhan repositori ".svn" (note Subversion 1.7 dan yang lebih tinggi sekarang menggunakan direktori tunggal seperti Git.)
  • Area pementasan mengagumkan, ini memungkinkan Anda untuk melihat perubahan yang akan Anda lakukan, melakukan perubahan sebagian dan melakukan berbagai hal lainnya.
  • Stashing sangat berharga ketika Anda melakukan pengembangan "kacau", atau hanya ingin memperbaiki bug saat Anda masih mengerjakan sesuatu yang lain (pada cabang yang berbeda).
  • Anda dapat menulis ulang riwayat , yang bagus untuk mempersiapkan set tambalan dan memperbaiki kesalahan Anda ( sebelum Anda mempublikasikan komit)
  • ... dan banyak lagi.

Ada beberapa kelemahannya:

  • Belum banyak GUI yang bagus untuk itu. Ini baru dan Subversion sudah ada jauh lebih lama, jadi ini wajar karena ada beberapa antarmuka dalam pengembangan. Beberapa yang bagus termasuk TortoiseGit dan GitHub untuk Mac .
  • Checkout / klon repositori parsial tidak mungkin dilakukan saat ini (saya membaca sedang dalam pengembangan). Namun, ada dukungan submodule. Git 1.7+ mendukung pembayaran jarang .
  • Mungkin lebih sulit untuk belajar, meskipun saya tidak menemukan ini (sekitar setahun yang lalu). Git baru-baru ini meningkatkan antarmuka dan cukup ramah pengguna.

Dalam penggunaan yang paling sederhana, Subversion dan Git hampir sama. Tidak ada banyak perbedaan antara:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

dan

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Di mana Git benar-benar bersinar bercabang dan bekerja dengan orang lain.


8
Anda mengatakan GIT melacak konten daripada file. Saya menemukan bahwa SVN juga melakukan itu: Saya baru saja membuat perubahan pada file, dan menyimpannya. SVN menunjukkan file sebagai merah (diubah). Kemudian saya membatalkan di editor dan menyimpannya lagi. SVN kemudian memperbarui status menjadi hijau (tidak diubah) bahkan jika file diubah (mengubah tanggal lebih baru) tetapi SVN mengakui bahwa konten tidak diubah dari aslinya.
awe

svn melacak perubahan pada file?
Seun Osewa

12
@awe, itu disebut pelacakan file. coba ganti nama file, atau pindahkan ke tempat lain secara manual [konten yang sama, file baru (karena jalur / nama baru)]: akankah SVN tahu bahwa itu adalah file yang sama dan mempertahankan revisi yang tak terhitung sebelumnya yang Anda buat? tidak, saya kira tidak.
Filip Dupanovic


54

Google Tech Talk: Linus Torvalds on git

http://www.youtube.com/watch?v=4XpnKHJAok8

Halaman perbandingan Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion


12
Pembicaraan Linus menyenangkan untuk ditonton. Dia secara brutal merobek sistem kontrol versi tersentralisasi seperti Subversion dan CVS. Namun, youtube.com/watch?v=8dhZ9BXQg4 bicara Randal Schwartz lebih konstruktif, lebih informatif, dan lebih meyakinkan.
bendin

2
Yang ini juga cukup bagus. Ini dari salah satu komit git dan dia menjelaskan banyak fitur canggih seperti membagi komit besar menjadi yang lebih kecil. youtube.com/watch?v=j45cs5_nY2k
schoetbi

Saya menikmati video Linus Torvalds itu, tetapi ia menyiratkan bahwa git didistribusikan, tidak terpusat, dan ini hanya salah. Dapat digunakan dengan cara terdistribusi, atau dengan cara terpusat. Anda dapat memiliki satu repositori pusat yang dilakukan semua orang, sama seperti di SVN. Hanya saja Anda tidak harus melakukannya dengan cara itu.
MatrixFrog

@ MatrixForog: Saya pikir dalam hal ini, "desentralisasi" bukan kebalikan dari "terpusat" tetapi benar-benar superset. Ini seperti "mobile" dan "immobile" - hanya karena ada sesuatu yang "mobile" bukan berarti saya tidak bisa diam.
Tikhon Jelvis

26

Yah, sudah didistribusikan. Benchmark menunjukkan bahwa itu jauh lebih cepat (mengingat sifatnya yang terdistribusi, operasi seperti diffs dan log semuanya lokal jadi tentu saja lebih cepat dalam hal ini), dan folder yang bekerja lebih kecil (yang masih membuat saya berpikir).

Saat Anda mengerjakan subversi, atau sistem kontrol revisi klien / server lain, Anda pada dasarnya membuat copy pekerjaan di mesin Anda dengan memeriksa revisi. Ini mewakili snapshot dalam waktu seperti apa repositori itu. Anda memperbarui copy pekerjaan Anda melalui pembaruan, dan Anda memperbarui repositori melalui komit.

Dengan kontrol versi terdistribusi, Anda tidak memiliki snapshot, melainkan seluruh basis kode. Ingin melakukan perbedaan dengan versi lama 3 bulan? Tidak masalah, versi lama 3 bulan masih ada di komputer Anda. Ini tidak hanya berarti segala sesuatunya jauh lebih cepat, tetapi jika Anda terputus dari server pusat Anda, Anda masih dapat melakukan banyak operasi yang biasa Anda lakukan. Dengan kata lain, Anda tidak hanya memiliki snapshot dari revisi yang diberikan, tetapi seluruh basis kode.

Anda akan berpikir bahwa Git akan menghabiskan banyak ruang pada harddisk Anda, tetapi dari beberapa tolok ukur yang saya lihat, sebenarnya dibutuhkan waktu lebih sedikit. Jangan tanya saya bagaimana. Maksudku, itu dibangun oleh Linus, dia tahu satu atau dua hal tentang sistem file, kurasa.


1
Penyebab mengapa Git dapat mengambil lebih sedikit ruang disk untuk repositori penuh daripada Subversion hanya untuk checkout adalah bahwa Subversion menyimpan "salinan asli" untuk membuat 'svn diff' (perbandingan dengan versi terakhir) berfungsi ... dan repositori git dikompresi (dan deltaified) ).
Jakub Narębski

3
Saya tidak heran git "folder kerja" (yaitu, repo) lebih kecil dari svn copy pekerjaan karena bahkan svn repo lebih kecil dari svn copy yang bekerja.
R. Martinho Fernandes

22

Poin utama yang saya sukai tentang DVCS adalah:

  1. Anda dapat melakukan hal-hal yang rusak. Tidak masalah karena orang lain tidak akan melihatnya sampai Anda menerbitkan. Waktu penerbitan berbeda dengan waktu komit.
  2. Karena ini, Anda dapat melakukan lebih sering.
  3. Anda dapat menggabungkan fungsi lengkap. Fungsi ini akan memiliki cabang sendiri. Semua komitmen cabang ini akan terkait dengan fungsi ini. Anda dapat melakukannya dengan CVCS namun dengan DVCS default-nya.
  4. Anda dapat mencari riwayat Anda (temukan ketika suatu fungsi berubah)
  5. Anda dapat membatalkan tarikan jika seseorang mengacaukan repositori utama, Anda tidak perlu memperbaiki kesalahan. Hapus saja penggabungannya.
  6. Ketika Anda membutuhkan kontrol sumber di direktori apa pun, lakukan: git init. dan Anda dapat melakukan, membatalkan perubahan, dll ...
  7. Cepat (bahkan di Windows)

Alasan utama untuk proyek yang relatif besar adalah peningkatan komunikasi yang diciptakan oleh poin 3. Lainnya adalah bonus yang bagus.


Saya pikir poin # 1 bermaksud untuk mengatakan "orang lain tidak akan melihatnya sampai Anda menerbitkan " (atau "push").
Jackr

+1 "Anda dapat melakukan hal-hal yang rusak." adalah alasan utama mengapa saya mempertimbangkan untuk beralih ke git dari svn. Saya selalu benci ketika saya tengah mengembangkan blok kode yang berat, dan saya tidak memiliki jaring pengaman VCS (hanya karena modifikasi saya belum berfungsi, jadi saya tidak diizinkan untuk melakukan).
András Szepesházi

15

Lucunya, saya meng-host proyek di Subversion Repos, tetapi mengaksesnya melalui perintah Git Clone.

Silakan baca Pengembangan dengan Git di Proyek Google Code

Meskipun Google Code secara alami berbicara Subversion, Anda dapat dengan mudah menggunakan Git selama pengembangan. Mencari "git svn" menunjukkan praktik ini tersebar luas, dan kami juga mendorong Anda untuk bereksperimen dengannya.

Menggunakan Git di Repositori Svn memberi saya manfaat:

  1. Saya dapat bekerja didistribusikan pada beberapa mesin, melakukan dan menarik dari dan ke mereka
  2. Saya memiliki repositori svn pusat backup/public untuk diperiksa orang lain
  3. Dan mereka bebas menggunakan Git untuk mereka sendiri

3
ini agak ketinggalan zaman, kode google tidak lincah sehingga tidak perlu untuk hack ini lagi
Sam Saffron

@ Sam kecuali Anda kebetulan suka git dan / atau tidak suka lincah.
MatrixFrog

11

Semua jawaban di sini seperti yang diharapkan, programmer sentris, namun apa yang terjadi jika perusahaan Anda menggunakan kontrol revisi di luar kode sumber? Ada banyak dokumen yang bukan kode sumber yang mendapat manfaat dari kontrol versi, dan harus hidup dekat dengan kode dan bukan di CMS lain. Sebagian besar programmer tidak bekerja secara terpisah - kami bekerja untuk perusahaan sebagai bagian dari tim.

Dengan mempertimbangkan hal itu, bandingkan kemudahan penggunaan, baik dalam tooling klien dan pelatihan, antara Subversion dan git. Saya tidak bisa melihat skenario di mana pun sistem terdistribusi kontrol revisi akan menjadi lebih mudah untuk menggunakan atau menjelaskan kepada non-programmer. Saya ingin terbukti salah, karena dengan begitu saya bisa mengevaluasi git dan benar-benar berharap itu diterima oleh orang-orang yang membutuhkan kontrol versi yang bukan programmer.

Meskipun begitu, jika ditanya oleh manajemen mengapa kita harus beralih dari sistem kontrol revisi yang tersentralisasi ke terdistribusi, saya akan sulit sekali memberikan jawaban yang jujur, karena kita tidak membutuhkannya.

Penafian: Saya menjadi tertarik pada Subversion sejak awal (sekitar v0.29) jadi jelas saya bias, tetapi perusahaan tempat saya bekerja sejak saat itu mendapat manfaat dari antusiasme saya karena saya telah mendorong dan mendukung penggunaannya. Saya menduga inilah yang terjadi pada sebagian besar perusahaan perangkat lunak. Dengan begitu banyak programmer melompat pada git ikut-ikutan, saya bertanya-tanya berapa banyak perusahaan akan kehilangan manfaat dari menggunakan kontrol versi di luar kode sumber? Bahkan jika Anda memiliki sistem terpisah untuk tim yang berbeda, Anda kehilangan beberapa manfaat, seperti integrasi pelacakan masalah (terpadu), sambil meningkatkan pemeliharaan, perangkat keras, dan persyaratan pelatihan.


IMHO, ini adalah satu-satunya alasan yang sah untuk mendukung SVN. Singkatnya, lebih mudah dijelaskan kepada non-programmer, yaitu, seseorang yang diharapkan menggunakannya secara linier dan menghindari skenario VC yang kompleks (= nyata): konflik, 3 cara menggabungkan, cabang .. Maksud saya, Anda akan tidak pernah ingin membiarkan VCS menggabungkan file presentasi powerpoint ..
inger

2
"Sebagian besar programmer tidak bekerja secara terpisah" tampaknya menyarankan bahwa akuntan / orang pemasaran harus menggunakan repo yang sama di mana kode sumber disimpan. Saya tidak melihat manfaatnya; beberapa mantan perusahaan saya ingin melakukan standarisasi pada hal-hal seperti itu, tetapi pasti gagal. Saya pikir pendekatan sederhana bisa bagus untuk manajer tetapi penyederhanaan yang berlebihan untuk tim programmer - jadi menyatukan ini mengarah pada kompromi yang buruk.
inger

Untuk dokumen yang disertakan dengan perangkat lunak, Anda benar - mereka harus diversi bersama. Saya menemukan bahwa itu jauh lebih sedikit daripada yang dipikirkan orang pada awalnya (kami akhirnya mengeluarkan dokumen pohon besar dari sumber repo). Juga, ada banyak hal yang dapat Anda lakukan untuk menyederhanakan alur kerja para penulis teknologi, dll, seandainya itu menjadi masalah (seharusnya tidak).
inger

2
@inger Saya tidak berpikir Anda bisa mengatakan "ini adalah satu-satunya alasan yang sah", dukungan perkakas AFAIK untuk Subversion jauh lebih unggul daripada Git, misalnya TortoiseSVN dan integrasi dengan Visual Studio dan IDE Java seperti Eclipse. Itu mungkin tidak menjadi masalah bagi Anda, tapi itu pasti bagi kami. Saya tidak menyebutkannya dalam jawaban saya karena ini adalah masalah yang terpisah.
si618

1
@ Yaho, ya benar non-programmer akan membutuhkan waktu untuk mendapatkan Subversion, tapi saya pikir mereka akan membutuhkan waktu lebih lama dengan git atau Hg. Wiki sangat bagus jika dipelihara, tetapi menurut pengalaman saya, pengembang lebih cenderung memelihara dokumen yang terkait dengan kode sumber jika mereka dekat dengan kode sumber itu. Saya setuju dengan inger dalam bahwa tidak ada banyak dokumen yang sesuai dengan kategori ini, tetapi mereka pasti ada. Sangat menarik Anda mengatakan git / Hg adalah alat terbaik untuk pekerjaan itu, itu pernyataan selimut yang mungkin tidak benar untuk semua keadaan, apakah git dan Hg memiliki integrasi yang sama baiknya dengan SVN?
si618

9

Subversion masih merupakan sistem kontrol versi yang lebih banyak digunakan, yang berarti bahwa ia memiliki dukungan alat yang lebih baik. Anda akan menemukan plugin SVN matang untuk hampir semua IDE , dan ada ekstensi explorer yang baik tersedia (seperti TurtoiseSVN). Selain itu, saya harus setuju dengan Michael : Git tidak lebih baik atau lebih buruk daripada Subversion, itu berbeda.


Tapi sekarang, setelah menggunakan git secara ekstensif selama beberapa tahun, saya perlu tidak setuju dengan diri saya sendiri: Git jauh lebih baik daripada Subversion. Setidaknya sekali Anda melupakan sintaks Git yang tidak ramah.
neu242

8

Salah satu hal tentang SubVersion yang mengganggu saya adalah bahwa ia menempatkan foldernya sendiri di setiap direktori proyek, sedangkan git hanya menempatkan satu di direktori root. Ini bukan yang besar dari kesepakatan, tetapi hal-hal kecil seperti itu menambahkan.

Tentu saja, Subversi memiliki Kura-kura, yang [biasanya] sangat bagus.


5
dirs Svn akan segera pergi, mungkin dengan v1.7
gbjbaanb

8

David Richards WANdisco Blog tentang Subversion / GIT

Munculnya GIT telah membawa generasi fundamentalis DVCS - 'Gitterons' - yang berpikir bahwa selain GIT adalah omong kosong. Gitteron tampaknya berpikir rekayasa perangkat lunak terjadi di pulau mereka sendiri dan sering lupa bahwa sebagian besar organisasi tidak mempekerjakan insinyur perangkat lunak senior secara eksklusif. Tidak apa-apa tapi itu tidak seperti yang dipikirkan oleh sisa pasar, dan saya senang membuktikannya: GIT, pada tampilan terakhir memiliki kurang dari tiga persen pasar sementara Subversion memiliki di wilayah lima juta pengguna dan sekitar setengah dari pasar keseluruhan.

Masalah yang kami lihat adalah bahwa para Gitteron menembakkan tembakan (murah) ke Subversion. Tweets seperti “Subversion sangat [lambat / jelek / ketat / tidak berbau / menatapku dengan cara yang lucu] dan sekarang saya punya GIT dan [semuanya bekerja dalam hidup saya / istri saya hamil / saya punya pacar setelah 30 tahun mencoba / saya menang enam kali berlari di meja blackjack]. Anda mendapatkan fotonya.


1
Perhatikan bahwa David Richards mungkin tidak memihak: produk yang dibuatnya didasarkan pada Subversion (atau pada gagasan Subversion), jadi tentu saja ia akan pro-Subversi dan anti-Git.
Jakub Narębski

2
Ironisnya, Git diciptakan khusus karena rekayasa perangkat lunak tidak terjadi di pulau. Kutipan ini bodoh.
Ben Collins

Walaupun saya menggunakan git, saya juga akan senang bekerja dengan DVCS yang layak seperti Mercurial misalnya. Butuh waktu untuk konsep DVCS untuk mendapatkan popularitas dan sekarang saya melihat sejumlah besar proyek open source telah beralih ke git.
Keyo

Dengan melukis para pencela svn sebagai kaum fundamentalis, David mengesampingkan masalah mendasar: arsitektur subversi adalah jalan buntu. Bukan berarti git adalah VCS yang paling lengkap, ia memiliki kutil untuk memastikannya, tetapi git, lincah, darc, dan banyak VCS lainnya semuanya memiliki model repositori yang pada dasarnya lebih elegan. Subversi tidak akan pernah membuat penggabungan bekerja karena direktori == model cabang membuat kemajuan nyata menjadi tidak mungkin. Perusahaan-perusahaan seperti milik David dapat terus membuat lipstik babi semakin banyak, tetapi svn pasti akan jatuh semakin jauh di belakang keadaan seni.
gtd

7

Git juga membuat percabangan dan penggabungan sangat mudah. Subversion 1.5 baru saja menambahkan pelacakan gabungan, tetapi Git masih lebih baik. Dengan bercabang Git sangat cepat dan murah. Itu membuat membuat cabang untuk setiap fitur baru lebih layak. Repositori Oh dan Git sangat efisien dengan ruang penyimpanan dibandingkan dengan Subversion.


6

Ini semua tentang kemudahan penggunaan / langkah-langkah yang diperlukan untuk melakukan sesuatu.

Jika saya sedang mengembangkan satu proyek pada PC / laptop saya, git lebih baik, karena jauh lebih mudah untuk diatur dan digunakan. Anda tidak memerlukan server, dan Anda tidak perlu terus mengetik URL repositori ketika Anda melakukan penggabungan.

Jika hanya 2 orang, saya akan mengatakan git juga lebih mudah, karena Anda hanya bisa mendorong dan menarik dari satu sama lain.

Setelah Anda melampaui itu, saya akan melakukan subversi, karena pada saat itu Anda perlu mengatur server atau lokasi 'khusus'.

Anda dapat melakukan ini sama baiknya dengan git seperti halnya dengan SVN, tetapi manfaat dari git lebih besar daripada kebutuhan untuk melakukan langkah-langkah tambahan untuk menyinkronkan dengan server pusat. Di SVN Anda hanya melakukan. Di git Anda harus git komit, lalu git push. Langkah tambahan menjadi menjengkelkan hanya karena Anda akhirnya melakukannya begitu banyak.

SVN juga memiliki manfaat alat GUI yang lebih baik, namun ekosistem git sepertinya akan menyusul dengan cepat, jadi saya tidak akan khawatir tentang ini dalam jangka panjang.


11
Pemisahan komitmen dari penerbitan di Git lebih menguntungkan IMHO daripada merugikan.
Jakub Narębski

Oke, jadi bagaimana Anda menilai "kemudahan penggunaan / langkah-langkah yang diperlukan untuk melakukan sesuatu" untuk SVN ketika: - membuat cabang topik untuk eksperimen - menggabungkan cabang ini ke cabang lain - memecah hal-hal yang diedit dalam file ke dalam komitmen mereka yang lebih kecil - cepat memeriksa cabang utama untuk membuat perbaikan kecil IMHO Saya tidak melihat bagaimana mengatur server SVN lebih mudah daripada mengatur server git Anda. Dan mengapa Anda ingin melepaskan semua keuntungan bagus yang Anda dapatkan dari cabang yang ringan hanya agar Anda tidak "harus mendorong secara terpisah".
Sam

Argumen "cabang topik untuk eksperimen" sering diajukan untuk kebaikan git, tetapi jujur, saya tidak pernah benar-benar melihat ada orang yang melakukan hal itu dalam subversi atau sistem non-DVCS lainnya. Mungkin ini masalah besar dan kita semua kehilangan, tetapi dari apa yang saya lihat 99% pengembang (termasuk saya) tidak peduli dengan cabang topik karena mereka tidak pernah menggunakannya! - Anda tidak dapat melewatkan apa yang belum pernah Anda miliki :-). Saya pikir jika orang-orang DVCS akan mengajukan "cabang topik" sebagai fitur, pertama - tama mereka harus meyakinkan semua orang bahwa hal-hal seperti itu sebenarnya berguna.
Orion Edwards

"Memecah hal-hal yang diedit menjadi komit yang lebih kecil", sekali lagi, adalah sesuatu yang terdengar bagus secara teori. Tapi, dalam 3 tahun terakhir, saya tidak pernah berpikir "oh, saya berharap saya bisa melakukan itu", dan saya berjuang untuk bahkan datang dengan situasi hipotetis di mana saya mungkin menginginkan fitur ... Banyak git / Para pendukung DVCS hanya mengatakan "kita punya X dan X itu luar biasa" dan semua orang duduk di sana bertanya-tanya mengapa mereka membutuhkan X
Orion Edwards

6

Easy Git memiliki halaman yang bagus membandingkan penggunaan aktual Git dan SVN yang akan memberi Anda gambaran tentang hal-hal yang dapat dilakukan Git (atau melakukan lebih mudah) dibandingkan dengan SVN. (Secara teknis, ini didasarkan pada Easy Git, yang merupakan pembungkus ringan di atas Git.)


5

Git dan DVCS secara umum bagus untuk pengembang yang melakukan banyak pengkodean secara independen satu sama lain karena setiap orang memiliki cabang sendiri. Namun, jika Anda memerlukan perubahan dari orang lain, ia harus berkomitmen pada repo lokalnya dan kemudian ia harus mendorong perubahan itu kepada Anda atau Anda harus menariknya darinya.

Alasan saya sendiri juga membuat saya berpikir DVCS membuat segalanya lebih sulit untuk QA dan manajemen rilis jika Anda melakukan hal-hal seperti rilis terpusat. Seseorang harus bertanggung jawab untuk melakukan push / pull dari repositori orang lain, menyelesaikan setiap konflik yang akan diselesaikan pada waktu komit awal sebelumnya, kemudian melakukan build, dan kemudian membuat semua pengembang lain menyinkronkan ulang repo mereka.

Semua ini dapat diatasi dengan proses manusia, tentu saja; DVCS baru saja memecahkan sesuatu yang diperbaiki oleh kontrol versi terpusat untuk memberikan beberapa kenyamanan baru.


1
Sebenarnya jika Anda terlihat seperti Linux kernel atau proyek git itu sendiri dikelola, Anda akan melihat bahwa Git sangat baik untuk alur kerja 'maintainer tunggal' (atau maintainer + letnan), dengan repositori pusat dengan persetujuan pusat. Dan membuatnya mudah untuk sementara beralih ke orang lain sebagai pengelola.
Jakub Narębski

5

Saya suka Git karena sebenarnya membantu pengembang komunikasi untuk pengembang pada tim menengah ke besar. Sebagai sistem kontrol versi terdistribusi, melalui sistem dorong / tariknya, ini membantu pengembang untuk membuat sistem kode sumber yang membantu mengelola kumpulan besar pengembang yang mengerjakan satu proyek.

Misalnya, Anda mempercayai 5 pengembang dan hanya menarik kode dari repositori mereka. Masing-masing pengembang memiliki jaringan kepercayaan mereka sendiri dari mana mereka menarik kode. Dengan demikian pengembangan didasarkan pada jalinan kepercayaan pengembang di mana tanggung jawab kode dibagi di antara komunitas pengembangan.

Tentu saja ada manfaat lain yang disebutkan dalam jawaban lain di sini.


4

Beberapa jawaban telah menyinggung ini, tetapi saya ingin membuat 2 poin eksplisit:

1) Kemampuan untuk melakukan komitmen selektif (misalnya, git add --patch). Jika direktori kerja Anda berisi beberapa perubahan yang bukan bagian dari perubahan logis yang sama, Git membuatnya sangat mudah untuk membuat komit yang hanya mencakup sebagian dari perubahan. Dengan Subversion, itu sulit.

2) Kemampuan untuk berkomitmen tanpa membuat perubahan publik. Dalam Subversion, komit apa pun segera publik, dan karenanya tidak dapat dibatalkan. Ini sangat membatasi kemampuan pengembang untuk "melakukan lebih awal, melakukan sering".

Git lebih dari sekedar VCS; itu juga alat untuk mengembangkan tambalan. Subversi hanyalah sebuah VCS.


4
Re 1) Jika Anda menggunakan TortoiseSVN, AnkhSVN, dll. Maka sangat mudah (sepele) untuk memilih file mana dengan perubahan yang akan dikomit. Re 2) Jika Anda tidak ingin pengembang lain mendapatkan kode Anda, buat cabang dan gabungkan saat siap, itu tidak sulit.
si618

tidak dapat dibatalkan? Yah Anda bisa membalikkan menggabungkan komit yang salah dan repositori seperti sebelumnya. Tapi Anda benar, itu sudah didokumentasikan. Tetapi apakah ini baik atau buruk? Saya kira itu tergantung ...
schoetbi

@schoetbi Tidak, kepala repositori adalah seperti sebelumnya. Repositori itu sendiri sekarang berisi dua commit, sedangkan alangkah baiknya jika tidak ada dari mereka di sana. Ini kekacauan ekstra yang memperlambat Anda ketika Anda melihat-lihat log. Tentu saja, ini bisa terjadi dengan git juga, terutama jika beberapa pengembang terbiasa mendorong segera setelah melakukan. Tetapi jauh lebih mudah untuk menghindari di git.
MatrixFrog

4

Saya pikir Subversion baik-baik saja .. sampai Anda mulai menggabungkan .. atau melakukan sesuatu yang rumit .. atau melakukan apa pun yang menurut Subversion rumit (seperti melakukan pertanyaan untuk mencari tahu cabang mana yang kacau dengan file tertentu, di mana perubahan sebenarnya berasal, mendeteksi copy & paste , dll) ...

Saya tidak setuju dengan jawaban yang menang, mengatakan bahwa manfaat utama GIT adalah pekerjaan offline - ini tentu berguna, tetapi lebih seperti tambahan untuk kasus penggunaan saya. SVK dapat bekerja secara offline juga, masih tidak ada pertanyaan bagi saya yang menginvestasikan waktu belajar saya).

Hanya saja itu sangat kuat dan cepat dan, setelah terbiasa dengan konsep - sangat berguna (ya, dalam arti: ramah pengguna).

Untuk detail lebih lanjut tentang kisah penggabungan, lihat ini: Menggunakan git-svn (atau serupa) * hanya * untuk membantu penggabungan svn?


3

Berkat fakta itu tidak perlu berkomunikasi dengan server pusat terus-menerus, cukup banyak setiap perintah berjalan dalam waktu kurang dari satu detik (jelas git push / pull / fetch lebih lambat hanya karena mereka harus menginfeksi koneksi SSH). Bercabang jauh lebih mudah (satu perintah sederhana untuk bercabang, satu perintah sederhana untuk digabung)


3

Saya benar-benar senang bisa mengelola cabang-cabang lokal dari kode sumber saya di Git tanpa mengeruhkan air repositori pusat. Dalam banyak kasus, saya akan checkout kode dari server Subversion dan menjalankan repositori Git lokal hanya untuk dapat melakukan ini. Sangat bagus juga bahwa menginisialisasi repositori Git tidak mencemari sistem file dengan banyak folder .svn yang mengganggu di mana-mana.

Dan sejauh dukungan alat Windows, TortoiseGit menangani dasar-dasarnya dengan sangat baik, tapi saya masih lebih suka baris perintah kecuali saya ingin melihat log. Saya sangat suka cara Tortoise {Git | SVN} membantu ketika membaca log komit.


3

Ini adalah pertanyaan yang salah untuk ditanyakan. Terlalu mudah untuk berfokus pada kutil git dan merumuskan argumen tentang mengapa subversi tampak lebih baik, setidaknya untuk beberapa kasus penggunaan. Fakta bahwa git pada awalnya dirancang sebagai set konstruksi kontrol versi tingkat rendah dan memiliki antarmuka berorientasi-pengembang baroque linux memudahkan perang suci untuk mendapatkan traksi dan legitimasi yang dirasakan. Pendukung Git menggedor drum dengan jutaan keuntungan alur kerja, yang oleh semua orang dinyatakan tidak perlu. Segera seluruh perdebatan dibingkai sebagai terpusat vs terdistribusi, yang melayani kepentingan komunitas alat svn perusahaan. Perusahaan-perusahaan ini, yang biasanya mengeluarkan artikel paling meyakinkan tentang keunggulan subversi di perusahaan,

Tapi inilah masalahnya: Subversi adalah jalan buntu arsitektur .

Sedangkan Anda dapat mengambil git dan membangun penggantian subversi terpusat dengan cukup mudah, meskipun sudah ada lebih dari dua kali lipat svn tidak pernah bisa mendapatkan bahkan pelacakan penggabungan dasar yang bekerja di dekat maupun git. Salah satu alasan dasar untuk ini adalah keputusan desain untuk membuat cabang sama dengan direktori. Saya tidak tahu mengapa mereka pergi dengan cara ini pada awalnya, itu tentu saja membuat pembayaran sebagian sangat sederhana. Sayangnya itu juga membuat tidak mungkin untuk melacak sejarah dengan benar. Sekarang jelas Anda seharusnya menggunakan konvensi tata letak repositori subversi untuk memisahkan cabang dari direktori biasa, dan svn menggunakan beberapa heuristik untuk membuat sesuatu berfungsi untuk kasing harian. Tetapi semua ini hanya menutupi keputusan desain tingkat rendah yang sangat buruk dan terbatas. Mampu melakukan diff repositori-bijaksana (daripada diff direktori-bijaksana) adalah fungsi dasar dan kritis untuk sistem kontrol versi, dan sangat menyederhanakan internal, sehingga memungkinkan untuk membangun fitur yang lebih cerdas dan berguna di atasnya. Anda dapat melihat dalam jumlah upaya yang telah dilakukan untuk memperluas subversi, namun seberapa jauh di balik itu dari tanaman VCS modern saat ini dalam hal operasi mendasar seperti resolusi gabungan.

Sekarang, inilah saran saya yang menyentuh hati dan agnostik bagi siapa pun yang masih percaya bahwa Subversion cukup baik untuk masa mendatang:

Subversion tidak akan pernah mengejar keturunan VCSes yang lebih baru yang telah belajar dari kesalahan RCS dan CVS; itu adalah ketidakmungkinan teknis kecuali mereka memperlengkapi kembali model repositori dari bawah ke atas, tetapi kemudian tidak akan benar-benar menjadi svn bukan? Terlepas dari seberapa banyak Anda berpikir Anda tidak memiliki kemampuan VCS modern, ketidaktahuan Anda tidak akan melindungi Anda dari jebakan Subversion, banyak di antaranya adalah situasi yang tidak mungkin atau mudah diselesaikan dalam sistem lain.

Sangat jarang bahwa inferioritas teknis dari suatu solusi begitu jelas seperti halnya dengan svn, tentu saja saya tidak akan pernah menyatakan pendapat seperti itu tentang win-vs-linux atau emacs-vs-vi, tetapi dalam hal ini sangat tebang habis, dan kontrol sumber adalah alat mendasar dalam arsenal pengembang, sehingga saya merasa harus dinyatakan dengan tegas. Terlepas dari persyaratan untuk menggunakan svn untuk alasan organisasi, saya mohon semua pengguna svn untuk tidak membiarkan pikiran logis mereka membangun kepercayaan yang salah bahwa VCS yang lebih modern hanya berguna untuk proyek-proyek open-source besar. Terlepas dari sifat pekerjaan pengembangan Anda, jika Anda seorang programmer, Anda akan menjadi programmer yang lebih efektif jika Anda belajar cara menggunakan VCSes yang dirancang lebih baik, apakah itu Git, Mercurial, Darcs, atau banyak lainnya.


2

Subversi sangat mudah digunakan. Saya tidak pernah menemukan masalah dalam tahun-tahun terakhir ini atau ada sesuatu yang tidak berfungsi seperti yang diharapkan. Juga ada banyak alat GUI yang sangat baik dan dukungan untuk integrasi SVN besar.

Dengan Git Anda mendapatkan VCS yang lebih fleksibel. Anda bisa menggunakannya dengan cara yang sama seperti SVN dengan repositori jarak jauh di mana Anda melakukan semua perubahan. Tetapi Anda juga dapat menggunakannya sebagian besar offline dan hanya mendorong perubahan dari waktu ke waktu ke repositori jarak jauh. Tetapi Git lebih kompleks dan memiliki kurva belajar yang lebih curam. Saya menemukan diri saya pertama kali berkomitmen ke cabang yang salah, membuat cabang secara tidak langsung atau mendapatkan pesan kesalahan dengan tidak banyak informasi tentang kesalahan dan di mana saya harus mencari dengan Google untuk mendapatkan informasi yang lebih baik. Beberapa hal mudah seperti penggantian marker ($ Id $) tidak berfungsi tetapi GIT memiliki mekanisme penyaringan dan pengait yang sangat fleksibel untuk menggabungkan skrip sendiri dan sehingga Anda mendapatkan semua hal yang Anda butuhkan dan lebih banyak tetapi membutuhkan lebih banyak waktu dan membaca dokumentasi. ;)

Jika Anda sebagian besar bekerja offline dengan repositori lokal Anda, Anda tidak memiliki cadangan jika ada sesuatu yang hilang pada mesin lokal Anda. Dengan SVN Anda sebagian besar bekerja dengan repositori jarak jauh yang juga merupakan waktu yang sama dengan cadangan Anda di server lain ... Git dapat bekerja dengan cara yang sama tetapi ini bukan tujuan utama Linus untuk memiliki sesuatu seperti SVN2. Itu dirancang untuk pengembang kernel Linux dan kebutuhan sistem kontrol versi terdistribusi.

Apakah Git lebih baik daripada SVN? Pengembang yang hanya membutuhkan beberapa riwayat versi dan mekanisme cadangan memiliki kehidupan yang baik dan mudah dengan SVN. Pengembang sering bekerja dengan cabang, menguji lebih banyak versi pada saat yang sama atau bekerja sebagian besar offline dapat mengambil manfaat dari fitur Git. Ada beberapa fitur yang sangat berguna seperti menyimpan tidak ditemukan dengan SVN yang dapat membuat hidup lebih mudah. Tetapi di sisi lain tidak semua orang akan membutuhkan semua fitur. Jadi saya tidak bisa melihat kematian SVN.

Git membutuhkan dokumentasi yang lebih baik dan pelaporan kesalahan harus lebih bermanfaat. Juga GUI berguna yang ada jarang. Kali ini saya hanya menemukan 1 GUI untuk Linux dengan dukungan sebagian besar fitur Git (git-cola). Integrasi Eclipse berfungsi tetapi tidak resmi dirilis dan tidak ada situs pembaruan resmi (hanya beberapa situs pembaruan eksternal dengan versi berkala dari trunk http://www.jgit.org/updates ) Jadi cara yang paling disukai untuk menggunakan Git hari ini adalah baris perintah.


2

Eric Sink dari SourceGear menulis serangkaian artikel tentang perbedaan antara sistem kontrol versi terdistribusi dan tidak terdistribusi. Dia membandingkan pro dan kontra dari sistem kontrol versi paling populer. Bacaan yang sangat menarik.
Artikel dapat ditemukan di blog-nya, www.ericsink.com :


2

Bagi orang yang mencari Git GUI yang baik, Syntevo SmartGit mungkin menjadi solusi yang baik. Hak miliknya, tetapi gratis untuk penggunaan non-komersial, berjalan pada Windows / Mac / Linux dan bahkan mendukung SVN menggunakan semacam jembatan git-svn, saya pikir.


1

http://subversion.wandisco.com/component/content/article/1/40.html

Saya pikir cukup aman untuk mengatakan bahwa di antara pengembang, SVN Vs. Argumen Git telah berkobar selama beberapa waktu sekarang, dengan setiap orang memiliki pandangan mereka sendiri tentang mana yang lebih baik. Ini bahkan dimunculkan dalam pertanyaan-pertanyaan selama Webinar kami tentang Subversion pada tahun 2010 dan Selanjutnya.

Hyrum Wright, Direktur Open Source kami dan Presiden untuk Subversion Corporation berbicara tentang perbedaan antara Subversion dan Git, bersama dengan Sistem Kontrol Versi Terdistribusi (DVCS) lainnya.

Dia juga berbicara tentang perubahan yang akan datang dalam Subversion, seperti Working Copy Next Generation (WC-NG), yang dia yakini akan menyebabkan sejumlah pengguna Git kembali ke Subversion.

Tonton videonya dan beri tahu kami apa yang Anda pikirkan dengan berkomentar di blog ini, atau dengan memposting di forum kami. Pendaftarannya sederhana dan hanya perlu waktu sebentar!


Jelas bias, karena alatnya didasarkan pada Subversion. Hanya mengatakan.
Jakub Narębski


1

Saya telah tinggal di tanah Git akhir-akhir ini, dan saya menyukainya untuk proyek-proyek pribadi, tetapi saya belum dapat mengalihkan proyek-proyek pekerjaan ke sana dari Subversion mengingat perubahan pemikiran yang diperlukan dari staf, tanpa ada manfaat yang mendesak. Selain itu, proyek terbesar yang kami jalankan di rumah sangat tergantung pada svn: eksternal yang, dari apa yang saya lihat sejauh ini, tidak bekerja dengan baik dan mulus di Git.


1

Pertama, kontrol versi bersamaan sepertinya merupakan masalah yang mudah dipecahkan. Sama sekali tidak. Bagaimanapun...

SVN cukup non-intuitif. Git bahkan lebih buruk. [sarkastik-spekulasi] Ini mungkin karena pengembang, yang suka masalah sulit seperti kontrol versi bersamaan, tidak memiliki banyak minat dalam membuat UI yang bagus. [/ spekulasi sarkastik]

Pendukung SVN berpikir mereka tidak membutuhkan sistem kontrol versi terdistribusi. Saya juga memikirkan itu. Tapi sekarang kita menggunakan Git secara eksklusif, saya seorang yang beriman. Sekarang kontrol versi berfungsi untuk saya DAN tim / proyek alih-alih hanya bekerja untuk proyek. Ketika saya membutuhkan cabang, saya bercabang. Kadang-kadang itu adalah cabang yang memiliki cabang yang sesuai di server, dan kadang-kadang tidak. Belum lagi semua keuntungan lain yang harus saya pelajari (sebagian berkat UI yang absurd dan absurd yang merupakan sistem kontrol versi modern).


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.