Haruskah saya menggunakan SVN atau Git? [Tutup]

Saya memulai proyek terdistribusi baru. Haruskah saya menggunakan SVN atau Git, dan mengapa?

SVN adalah satu repo dan banyak klien. Git adalah repo dengan banyak repo klien, masing-masing dengan pengguna. Ini terdesentralisasi ke titik di mana orang dapat melacak pengeditan mereka sendiri secara lokal tanpa harus mendorong sesuatu ke server eksternal.

SVN dirancang untuk menjadi lebih sentral di mana Git didasarkan pada setiap pengguna yang memiliki repo Git sendiri dan repo-repo itu mendorong perubahan kembali menjadi sentral. Untuk alasan itu, Git memberi individu kontrol versi lokal yang lebih baik.

Sementara itu Anda memiliki pilihan antara TortoiseGit , GitExtensions (dan jika Anda meng-host repositori git "central" di github, klien mereka sendiri - GitHub untuk Windows ).

Jika Anda ingin keluar dari SVN, Anda mungkin ingin mengevaluasi Bazaar sebentar. Ini adalah salah satu generasi berikutnya dari sistem kontrol versi yang memiliki elemen terdistribusi ini. Itu tidak tergantung POSIX seperti git sehingga ada build Windows asli dan memiliki beberapa merek open source yang kuat mendukungnya.

Tetapi Anda bahkan mungkin belum membutuhkan fitur-fitur ini. Lihatlah fitur, kelebihan dan kekurangan VCSes yang didistribusikan . Jika Anda membutuhkan lebih dari penawaran SVN, pertimbangkan satu. Jika tidak, Anda mungkin ingin tetap dengan integrasi desktop superior SVN (saat ini).

Saya tidak pernah mengerti konsep "git tidak bagus di Windows"; Saya mengembangkan secara eksklusif di bawah Windows dan saya tidak pernah punya masalah dengan git.

Saya pasti akan merekomendasikan git atas subversi; itu hanya jauh lebih fleksibel dan memungkinkan "pengembangan offline" dengan cara yang tidak pernah benar-benar subversi. Ini tersedia di hampir setiap platform yang bisa dibayangkan dan memiliki lebih banyak fitur daripada yang mungkin pernah Anda gunakan.

Berikut adalah salinan jawaban yang saya buat dari beberapa pertanyaan duplikat sejak itu dihapus tentang Git vs SVN (September 2009).

Lebih baik? Selain dari tautan biasa WhyGitIsBetterThanX , mereka berbeda:

satu adalah VCS Pusat berdasarkan salinan murah untuk cabang dan tag yang lain (Git) adalah VCS yang didistribusikan berdasarkan grafik revisi. Lihat juga Konsep inti VCS .

Bagian pertama itu menghasilkan beberapa komentar yang salah informasi dengan berpura-pura bahwa tujuan dasar kedua program (SVN dan Git) adalah sama, tetapi mereka telah diimplementasikan dengan sangat berbeda.
Untuk mengklarifikasi perbedaan mendasar antara SVN dan Git , izinkan saya ulangi:

• SVN adalah implementasi ketiga dari kontrol revisi : RCS, lalu CVS dan akhirnya SVN mengelola direktori data berversi. SVN menawarkan fitur VCS (pelabelan dan penggabungan), tetapi tag-nya hanyalah salinan direktori (seperti cabang, kecuali Anda tidak "seharusnya" menyentuh apa pun di direktori tag), dan penggabungannya masih rumit, saat ini didasarkan pada meta -data ditambahkan untuk mengingat apa yang telah digabungkan.

• Git adalah manajemen konten file (alat yang dibuat untuk menggabungkan file), berevolusi menjadi Sistem Kontrol Versi yang benar , berdasarkan pada DAG ( Grafik Acyclic yang Diarahkan ) dari komitmen, di mana cabang-cabang adalah bagian dari sejarah data (dan bukan data itu sendiri ), dan di mana tag adalah meta-data sejati.

Mengatakan mereka tidak "berbeda secara fundamental" karena Anda dapat mencapai hal yang sama, menyelesaikan masalah yang sama, adalah ... jelas salah pada banyak tingkatan.

• jika Anda memiliki banyak penggabungan yang rumit, melakukannya dengan SVN akan lebih lama dan lebih rentan kesalahan. jika Anda harus membuat banyak cabang, Anda perlu mengelolanya dan menggabungkannya, sekali lagi jauh lebih mudah dengan Git daripada dengan SVN, terutama jika sejumlah besar file terlibat (kecepatan kemudian menjadi penting)
• jika Anda memiliki penggabungan parsial untuk pekerjaan yang sedang berjalan, Anda akan mengambil keuntungan dari area pementasan Git (indeks) untuk melakukan hanya apa yang Anda butuhkan, menyimpan sisanya, dan melanjutkan cabang lainnya.
• jika Anda membutuhkan pengembangan offline ... baik dengan Git Anda selalu "online", dengan repositori lokal Anda sendiri, apa pun alur kerja yang ingin Anda ikuti dengan repositori lain.

Tetap saja komentar pada jawaban lama (yang dihapus) itu bersikeras:

VonC: Anda mengacaukan perbedaan mendasar dalam implementasi (perbedaannya sangat mendasar, kami berdua dengan jelas menyetujui hal ini) dengan perbedaan tujuan.
Keduanya adalah alat yang digunakan untuk tujuan yang sama: inilah mengapa banyak tim yang sebelumnya menggunakan SVN cukup berhasil membuangnya demi Git.
Jika mereka tidak memecahkan masalah yang sama, substitusi ini tidak akan ada.

, yang saya jawab:

"substitusi" ... istilah menarik ( digunakan dalam pemrograman komputer ).
Tentu saja, Git bukan subtipe dari SVN.

Anda dapat mencapai fitur teknis yang sama (tag, cabang, menggabungkan) dengan keduanya, tetapi Git tidak menghalangi Anda dan memungkinkan Anda untuk fokus pada konten file , tanpa memikirkan alat itu sendiri.

Anda tentu tidak dapat (selalu) hanya mengganti SVN dengan Git "tanpa mengubah sifat yang diinginkan dari program itu (kebenaran, tugas yang dilakukan, ...)" (yang merupakan referensi untuk definisi penggantian yang disebutkan di atas ):

• Salah satunya adalah alat revisi yang diperluas, yang lain merupakan sistem kontrol versi yang benar.
• Satu cocok untuk proyek monolitik kecil hingga sedang dengan alur kerja menggabungkan sederhana dan (tidak terlalu banyak) versi paralel. SVN sudah cukup untuk tujuan itu, dan Anda mungkin tidak memerlukan semua fitur Git.
• Yang lain memungkinkan untuk proyek-proyek menengah ke besar berdasarkan beberapa komponen ( satu repo per komponen ), dengan sejumlah besar file untuk menggabungkan antara beberapa cabang dalam alur kerja gabungan yang kompleks, versi paralel di cabang, gabungan retrofit, dan sebagainya. Anda bisa melakukannya dengan SVN, tetapi Anda jauh lebih baik dengan Git.
  SVN tidak bisa mengelola proyek apa pun dengan ukuran apa pun dengan alur kerja gabungan. Git bisa.

Sekali lagi, sifat mereka secara fundamental berbeda (yang kemudian mengarah pada implementasi yang berbeda tetapi bukan itu intinya).
Satu melihat kontrol revisi sebagai direktori dan file, yang lain hanya melihat konten file (begitu banyak sehingga direktori kosong bahkan tidak akan mendaftar di Git!).

Tujuan akhir umum mungkin sama, tetapi Anda tidak dapat menggunakannya dengan cara yang sama, Anda juga tidak dapat menyelesaikan kelas masalah yang sama (dalam cakupan atau kompleksitas).

2 keunggulan utama SVN yang jarang dikutip:

1. Dukungan file besar. Selain kode, saya menggunakan SVN untuk mengelola direktori home saya. SVN adalah satu-satunya VCS (didistribusikan atau tidak) yang tidak tercekik pada file TrueCrypt saya (tolong perbaiki saya jika ada VCS lain yang menangani file 500MB + secara efektif). Ini karena perbandingan diff dialirkan (ini adalah poin yang sangat penting). Rsync tidak dapat diterima karena ini bukan 2 arah.

2. Checkout / checkin sebagian repositori (subdir). Mercurial dan bzr tidak mendukung ini, dan dukungan git terbatas. Ini buruk di lingkungan tim, tetapi sangat berharga jika saya ingin memeriksa sesuatu di komputer lain dari dir home saya.

Hanya pengalaman saya saja.

Setelah melakukan penelitian lebih lanjut, dan meninjau tautan ini: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Beberapa ekstrak di bawah):

• Ini sangat cepat. Tidak ada SCM lain yang telah saya gunakan yang mampu mengikutinya, dan saya telah menggunakan banyak hal, termasuk Subversion, Perforce, darcs, BitKeeper, ClearCase dan CVS.
• Ini sepenuhnya didistribusikan. Pemilik repositori tidak dapat menentukan cara saya bekerja. Saya dapat membuat cabang dan melakukan perubahan saat terputus di laptop saya, kemudian menyinkronkannya dengan sejumlah repositori lainnya.
• Sinkronisasi dapat terjadi pada banyak media. Saluran SSH, melalui HTTP melalui WebDAV, melalui FTP, atau dengan mengirim email berisi tambalan untuk diterapkan oleh penerima pesan. Repositori pusat tidak diperlukan, tetapi dapat digunakan.
• Cabang bahkan lebih murah daripada di Subversion. Membuat cabang adalah sesederhana menulis file 41 byte ke disk. Menghapus cabang sama mudahnya dengan menghapus file itu.
• Tidak seperti cabang Subversion membawa sejarah lengkap mereka. tanpa harus melakukan salinan aneh dan berjalan melalui salinan. Saat menggunakan Subversion, saya selalu merasa canggung untuk melihat riwayat file pada cabang yang terjadi sebelum cabang dibuat. from #git: spearce: Saya tidak mengerti satu hal tentang SVN di halaman. Saya membuat cabang di SVN dan menelusuri riwayat menunjukkan seluruh sejarah file di cabang
• Penggabungan cabang lebih sederhana dan lebih otomatis di Git. Di Subversion Anda perlu mengingat apa revisi terakhir yang Anda gabungkan sehingga Anda dapat menghasilkan perintah gabungan yang benar. Git melakukan ini secara otomatis, dan selalu melakukannya dengan benar. Yang berarti ada sedikit peluang untuk melakukan kesalahan ketika menggabungkan dua cabang bersama.
• Penggabungan cabang dicatat sebagai bagian dari sejarah repositori yang tepat. Jika saya menggabungkan dua cabang bersama-sama, atau jika saya menggabungkan cabang kembali ke bagasi asalnya, operasi gabungan dicatat sebagai bagian dari sejarah repostory yang telah dilakukan oleh saya, dan kapan. Sulit untuk membantah siapa yang melakukan penggabungan saat itu ada di log.
• Membuat repositori adalah operasi sepele: mkdir foo; cd foo; git init Itu dia. Yang berarti saya membuat repositori Git untuk semuanya hari ini. Saya cenderung menggunakan satu repositori per kelas. Sebagian besar repositori tersebut di bawah 1 MB dalam disk karena mereka hanya menyimpan catatan kuliah, tugas pekerjaan rumah, dan jawaban LaTeX saya.
• Format file internal repositori sangat sederhana. Ini berarti perbaikan sangat mudah dilakukan, tetapi bahkan lebih baik karena sangat sederhana sangat sulit untuk rusak. Saya tidak berpikir ada orang yang pernah memiliki repositori Git yang rusak. Saya telah melihat Subversion dengan fsfs korup sendiri. Dan saya telah melihat Berkley DB merusak dirinya sendiri terlalu banyak untuk mempercayai kode saya ke backend bdb dari Subversion.
• Format file Git sangat bagus dalam mengompresi data, meskipun formatnya sangat sederhana. Repositori proyek Mozilla sekitar 3 GB; sekitar 12 GB dalam format fsfs Subversion. Di Git sekitar 300 MB.

Setelah membaca semua ini, saya yakin bahwa Git adalah jalan yang harus ditempuh (walaupun ada sedikit kurva pembelajaran). Saya telah menggunakan Git dan SVN pada platform Windows juga.

Saya ingin mendengar apa yang orang lain katakan setelah membaca di atas?

Saya akan mengatur repositori Subversion. Dengan melakukannya dengan cara ini, setiap pengembang dapat memilih apakah akan menggunakan klien Subversion atau klien Git (with git-svn). Menggunakan git-svntidak memberi Anda semua manfaat dari solusi Git penuh, tetapi itu memberikan pengembang individu banyak kontrol atas alur kerja mereka sendiri.

Saya percaya ini akan menjadi waktu yang relatif singkat sebelum Git bekerja dengan baik pada Windows seperti halnya pada Unix dan Mac OS X (sejak Anda bertanya).

Subversion memiliki alat yang luar biasa untuk Windows, seperti TortoiseSVN untuk integrasi Explorer dan AnkhSVN untuk integrasi Visual Studio.

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

Tidak benar-benar menjawab pertanyaan Anda, tetapi jika Anda ingin manfaat dari Kontrol Revisi Terdistribusi - sepertinya Anda lakukan - dan Anda menggunakan Windows, saya pikir Anda akan lebih baik menggunakan Mercurial daripada Git karena Mercurial memiliki dukungan Windows yang jauh lebih baik. Mercurial memang memiliki port Mac juga.

Jika tim Anda sudah terbiasa dengan perangkat lunak versi dan sumber kontrol seperti cvs atau svn, maka, untuk proyek sederhana dan kecil (seperti yang Anda klaim), saya sarankan Anda tetap menggunakan SVN. Saya benar-benar nyaman dengan svn, tetapi untuk proyek e-commerce saat ini yang saya lakukan pada Django, saya memutuskan untuk bekerja pada git (saya menggunakan git dalam svn-mode, yaitu, dengan repo terpusat yang saya dorong dan tarik dari untuk berkolaborasi dengan setidaknya satu pengembang lain). Pengembang lain merasa nyaman dengan SVN, dan sementara pengalaman orang lain mungkin berbeda, kami berdua memiliki waktu yang sangat buruk merangkul git untuk proyek kecil ini. (Kami berdua pengguna Linux hardcore, jika itu penting sama sekali.)

Jarak tempuh Anda mungkin berbeda, tentu saja.

Jelas svn, karena Windows — paling-paling — adalah warga negara kelas dua di dunia git(lihat http://en.wikipedia.org/wiki/Git_(software)#Kemampuan untuk lebih jelasnya).

UPDATE: Maaf untuk tautan yang rusak, tapi saya sudah berhenti berusaha agar SO bekerja dengan URI yang mengandung tanda kurung. [tautan diperbaiki sekarang. -ed]

Poin utamanya adalah, bahwa Git adalah VCS yang didistribusikan dan Subversion yang terpusat. VCS yang didistribusikan sedikit lebih sulit untuk dipahami, tetapi memiliki banyak keuntungan. Jika Anda tidak membutuhkan kelebihan ini, Subversion mungkin pilihan yang lebih baik.

Pertanyaan lain adalah dukungan alat. VCS mana yang lebih baik didukung oleh alat yang Anda rencanakan untuk digunakan?

EDIT: Tiga tahun lalu saya menjawab seperti ini:

Dan Git bekerja pada Windows saat ini hanya melalui Cygwin atau MSYS . Subversi mendukung Windows sejak awal. Karena solusi git untuk windows dapat bekerja untuk Anda, mungkin ada masalah, karena sebagian besar pengembang Git bekerja dengan Linux dan tidak memiliki portabilitas di pikiran sejak awal. Saat ini saya lebih suka Subversion untuk pengembangan di Windows. Dalam beberapa tahun ini mungkin tidak relevan.

Sekarang dunia telah sedikit berubah. Git memiliki implementasi yang baik di windows sekarang. Meskipun saya diuji tidak melalui windows (karena saya tidak lagi menggunakan sistem ini), saya cukup yakin, bahwa semua VCS utama (SVN, Git, Mercurial, Bazaar) memiliki implementasi Windows yang tepat sekarang. Keuntungan untuk SVN ini hilang. Poin lainnya (Terpusat vs. Terdistribusi dan cek untuk dukungan alat) tetap valid.

Saya akan memilih SVN karena lebih tersebar luas dan lebih dikenal.

Saya kira, Git akan lebih baik untuk pengguna Linux.

Git tidak didukung secara native di bawah Windows, dulu. Ini dioptimalkan untuk sistem Posix. Namun menjalankan Cygwin atau MinGW memungkinkan Anda menjalankan Git dengan sukses.

Saat ini saya lebih suka Git daripada SVN, tetapi butuh beberapa saat untuk melewati ambang batas jika Anda berasal dari CVS, tanah SVN.

Saya mungkin akan memilih Git karena saya merasa ini jauh lebih kuat daripada SVN. Ada layanan Code Hosting murah yang bekerja sangat bagus untuk saya - Anda tidak perlu melakukan backup atau pekerjaan pemeliharaan - GitHub adalah kandidat yang paling jelas.

Yang mengatakan, saya tidak tahu apa-apa mengenai integrasi Visual Studio dan sistem SCM yang berbeda. Saya membayangkan integrasi dengan SVN menjadi lebih baik.

Saya telah menggunakan SVN untuk waktu yang lama, tetapi setiap kali saya menggunakan Git, saya merasa bahwa Git jauh lebih kuat, ringan, dan meskipun sedikit melibatkan kurva belajar tetapi lebih baik daripada SVN.

Apa yang saya catat adalah bahwa setiap proyek SVN, seiring pertumbuhannya, menjadi proyek yang sangat besar kecuali diekspor. Sedangkan, proyek GIT (bersama dengan data Git) berukuran sangat ringan.

Di SVN, saya telah berurusan dengan pengembang dari pemula ke ahli, dan pemula dan perantara tampaknya memperkenalkan konflik File jika mereka menyalin satu folder dari proyek SVN lain untuk menggunakannya kembali. Padahal, saya pikir di Git, Anda cukup menyalin folder dan berfungsi, karena Git tidak memperkenalkan folder .git di semua subfoldernya (seperti halnya SVN).

Setelah berurusan dengan banyak SVN sejak lama, saya akhirnya berpikir untuk memindahkan pengembang saya dan saya ke Git, karena mudah untuk berkolaborasi dan menggabungkan pekerjaan, serta satu keuntungan besar adalah bahwa perubahan salinan lokal dapat dilakukan sebanyak diinginkan, dan akhirnya didorong ke cabang di server dalam sekali jalan, tidak seperti SVN (di mana kita harus melakukan perubahan dari waktu ke waktu di repositori di server).

Adakah yang bisa membantu saya memutuskan apakah saya harus pergi bersama Git?

Turun ke ini:

Apakah pengembangan Anda akan linier? Jika demikian, Anda harus tetap menggunakan Subversion.

Jika di sisi lain, pengembangan Anda tidak akan linier, yang berarti bahwa Anda perlu membuat percabangan untuk perubahan yang berbeda, dan kemudian menggabungkan perubahan tersebut kembali ke jalur pengembangan utama (dikenal sebagai Git sebagai cabang utama) maka Git akan melakukan BANYAK lagi untuk Anda.

Sudahkah Anda mencoba Bzr ?

Cukup bagus, kononikal (orang-orang yang membuat Ubuntu) membuatnya karena mereka tidak suka yang lain di pasaran ...

Bolehkah saya memperluas pertanyaan dan bertanya apakah Git bekerja dengan baik di MacOS?

Membalas Komentar: Terima kasih atas beritanya, saya sudah tak sabar untuk mencobanya. Saya akan menginstalnya di rumah di Mac saya.

Ada Video yang menarik di YouTube tentang ini. Ini dari Linus Torwalds sendiri: Goolge Tech Talk: Linus Torvalds on git

SVN sepertinya pilihan yang baik di bawah Windows, seperti yang ditunjukkan oleh orang lain.

Jika beberapa pengembang Anda ingin mencoba GIT, itu mungkin selalu menggunakan GIT-SVN di mana repositori SVN dibuat kembali dalam repositori GIT. Maka dia harus bisa bekerja secara lokal dengan GIT dan kemudian menggunakan SVN untuk mempublikasikan perubahannya ke repositori utama.

Anda harus menggunakan DVCS, ini seperti lompatan kuantum dalam manajemen sumber. Secara pribadi saya menggunakan Monoton dan mempercepat waktu pengembangan tanpa akhir. Kami menggunakannya untuk Windows, Linux dan Mac dan sudah sangat stabil. Saya bahkan meminta buildbot mengerjakan proyek malam hari di setiap platform.

DVCS ketika sedang didistribusikan biasanya berarti Anda akan membuat server pusat hanya untuk orang-orang untuk mendorong perubahan ke dan dari.