Perbedaan utama adalah bahwa (seperti yang sudah dikatakan dalam tanggapan lain) CVS adalah (lama) sistem kontrol versi terpusat, sementara Git didistribusikan.
Tetapi bahkan jika Anda menggunakan kontrol versi untuk pengembang tunggal, pada mesin tunggal (akun tunggal), ada beberapa perbedaan antara Git dan CVS:
Menyiapkan repositori . Git menyimpan repositori dalam .gitdirektori di direktori teratas proyek Anda; CVS memerlukan pengaturan CVSROOT, tempat sentral untuk menyimpan info kontrol versi untuk berbagai proyek (modul). Konsekuensi dari desain tersebut bagi pengguna adalah bahwa mengimpor sumber yang ada ke kontrol versi sesederhana "git init && git add. && git commit" di Git, sementara itu lebih rumit di CVS.
Operasi atom . Karena CVS pada awalnya adalah serangkaian skrip di sekitar sistem kontrol versi RCS per-file, komit (dan operasi lainnya) bukan atom dalam CVS; jika operasi pada repositori terputus di tengah, repositori dapat dibiarkan dalam keadaan tidak konsisten. Di Git semua operasi bersifat atom: apakah mereka berhasil secara keseluruhan, atau mereka gagal tanpa perubahan.
Kumpulan perubahan . Perubahan CVS adalah per file, sementara perubahan (komit) di Git selalu merujuk ke keseluruhan proyek. Ini adalah pergeseran paradigma yang sangat penting . Salah satu konsekuensi dari ini adalah sangat mudah dalam Git untuk mengembalikan (membuat perubahan yang merusak) atau membatalkan perubahan keseluruhan ; konsekuensi lain adalah bahwa dalam CVS mudah untuk melakukan checkout sebagian, sementara saat ini hampir tidak mungkin di Git. Fakta bahwa perubahan adalah per file, dikelompokkan bersama menyebabkan penemuan format GNU Changelog untuk pesan komit di CVS; Pengguna Git menggunakan (dan beberapa alat Git mengharapkan) konvensi yang berbeda, dengan satu baris yang menjelaskan (meringkas) perubahan, diikuti oleh baris kosong, diikuti oleh deskripsi perubahan yang lebih terperinci.
Penamaan revisi / nomor versi . Ada masalah lain yang terkait dengan fakta bahwa dalam perubahan CVS adalah per file: nomor versi (seperti yang kadang-kadang Anda lihat dalam perluasan kata kunci , lihat di bawah) seperti 1.4 mencerminkan berapa banyak waktu yang diberikan file telah diubah. Di Git, setiap versi proyek secara keseluruhan (setiap komit) memiliki nama unik yang diberikan oleh SHA-1 id; biasanya 7-8 karakter pertama sudah cukup untuk mengidentifikasi komit (Anda tidak dapat menggunakan skema penomoran sederhana untuk versi dalam sistem kontrol versi terdistribusi - yang membutuhkan otoritas penomoran pusat). Dalam CVS untuk memiliki nomor versi atau nama simbolis yang merujuk pada keadaan proyek secara keseluruhan Anda menggunakan tag; hal yang sama berlaku di Git jika Anda ingin menggunakan nama seperti 'v1.5.6-rc2' untuk beberapa versi proyek ... tetapi tag di Git lebih mudah digunakan.
Percabangan mudah . Cabang di CVS menurut saya terlalu rumit, dan sulit untuk ditangani. Anda harus menandai cabang untuk memiliki nama untuk seluruh cabang repositori (dan bahkan itu bisa gagal dalam beberapa kasus, jika saya ingat dengan benar, karena penanganan per file). Tambahkan fakta bahwa CVS tidak memiliki pelacakan gabungan , jadi Anda harus ingat, atau secara manual menandai gabungan dan titik percabangan, dan secara manual memberikan info yang benar untuk "pembaruan cvs-j" untuk menggabungkan cabang, dan itu membuat percabangan menjadi tidak perlu sulit digunakan. Dalam Git membuat dan menggabungkan cabang sangat mudah; Git mengingat semua info yang diperlukan dengan sendirinya (jadi menggabungkan cabang semudah "git merge branchname ") ... harus, karena pengembangan yang didistribusikan secara alami mengarah ke banyak cabang.
Ini berarti bahwa Anda dapat menggunakan cabang topik , yaitu mengembangkan fitur terpisah dalam beberapa langkah dalam cabang fitur terpisah.
Ganti nama (dan salin) pelacakan . Pengubahan nama file tidak didukung dalam CVS, dan pengubahan nama secara manual dapat memecah sejarah menjadi dua, atau menyebabkan sejarah yang tidak valid di mana Anda tidak dapat memulihkan keadaan proyek dengan benar sebelum mengganti nama. Git menggunakan deteksi ganti nama heuristik, berdasarkan kesamaan isi dan nama file (Solusi ini bekerja dengan baik dalam praktiknya). Anda juga dapat meminta deteksi penyalinan file. Ini berarti:
- ketika memeriksa komit yang ditentukan Anda akan mendapatkan informasi bahwa beberapa file diubah namanya,
- menggabungkan dengan benar akan memasukkan nama baru ke dalam akun (misalnya jika file diubah namanya hanya dalam satu cabang)
- "git menyalahkan", setara (lebih baik) dari "cvs annotate", alat untuk menunjukkan sejarah garis-bijaksana dari isi file, dapat mengikuti pergerakan kode juga di seluruh nama
File biner . CVS hanya memiliki dukungan yang sangat terbatas untuk file biner (misalnya gambar), yang mengharuskan pengguna untuk menandai file biner secara eksplisit saat menambahkan (atau yang lebih baru menggunakan "cvs admin", atau melalui pembungkus untuk melakukannya secara otomatis berdasarkan nama file), untuk menghindari campur aduk file biner melalui konversi end-of-line dan perluasan kata kunci. Git secara otomatis mendeteksi file biner berdasarkan konten dengan cara yang sama dengan CNU dan alat-alat lain melakukannya; Anda dapat mengganti deteksi ini menggunakan mekanisme gitattributes. Terlebih lagi file biner aman terhadap kerusakan yang tidak dapat dipulihkan berkat default pada 'safecrlf' (dan fakta bahwa Anda harus meminta konversi end-of-line, meskipun ini mungkin diaktifkan secara default tergantung pada distribusi), dan kata kunci (terbatas) ekspansi adalah 'opt-in' ketat di Git.
Ekspansi kata kunci . Git menawarkan serangkaian kata kunci yang sangat, sangat terbatas dibandingkan dengan CVS (secara default). Ini karena dua fakta: perubahan dalam Git adalah per repositori dan bukan per file, dan Git menghindari memodifikasi file yang tidak berubah ketika beralih ke cabang lain atau memutar ke titik lain dalam sejarah. Jika Anda ingin menyematkan nomor revisi menggunakan Git, Anda harus melakukan ini dengan menggunakan sistem build Anda, misalnya contoh skrip GIT-VERSION-GEN berikut dalam sumber kernel Linux dan sumber Git.
Mengubah komitmen . Karena dalam VCS terdistribusi seperti tindakan penerbitan Git terpisah dari membuat komit, orang dapat mengubah (mengedit, menulis ulang) bagian sejarah yang tidak dipublikasikan tanpa mengganggu pengguna lain. Khususnya jika Anda melihat kesalahan ketik (atau kesalahan lainnya) dalam pesan komit, atau bug dalam komit, Anda cukup menggunakan "git commit --amend". Ini tidak mungkin (setidaknya bukan tanpa peretasan berat) di CVS.
Lebih banyak alat . Git menawarkan lebih banyak alat daripada CVS. Salah satu yang lebih penting adalah " git bisect " yang dapat digunakan untuk menemukan komit (revisi) yang memperkenalkan bug; jika komit Anda kecil dan mandiri itu harus cukup mudah maka untuk menemukan di mana bug itu.
Jika Anda berkolaborasi dengan setidaknya satu pengembang lain, Anda juga akan menemukan perbedaan berikut antara Git dan CVS:
Berkomit sebelum bergabung Git menggunakan komit-sebelum-gabungan daripada, seperti CVS, gabungan-sebelum-komit (atau perbarui-kemudian-komit ). Jika saat Anda mengedit file, bersiap untuk membuat komit baru (revisi baru) orang lain yang membuat komit baru di cabang yang sama dan sekarang dalam repositori, CVS memaksa Anda untuk terlebih dahulu memperbarui direktori kerja Anda dan menyelesaikan konflik sebelum mengizinkan Anda untuk melakukan. Ini tidak terjadi dengan Git. Anda pertama kali melakukan, menyimpan status Anda di kontrol versi, kemudian Anda menggabungkan perubahan pengembang lainnya. Anda juga dapat meminta pengembang lain untuk melakukan penggabungan dan menyelesaikan konflik.
Jika Anda lebih suka memiliki riwayat linier dan menghindari penggabungan, Anda selalu dapat menggunakan alur kerja commit-merge-recommit melalui "git rebase" (dan "git pull --rebase"), yang mirip dengan CVS di mana Anda memutar ulang perubahan di atas keadaan yang diperbarui. Tapi Anda selalu berkomitmen dulu.
Tidak perlu repositori pusat Dengan Git tidak perlu memiliki satu tempat pusat di mana Anda melakukan perubahan Anda. Setiap pengembang dapat memiliki repositori sendiri (atau repositori yang lebih baik: privat di mana ia melakukan pengembangan, dan publik membuka satu di mana ia menerbitkan bagian yang siap), dan mereka dapat menarik / mengambil dari masing-masing repositori lainnya, di mode simetris. Di sisi lain adalah umum untuk proyek yang lebih besar untuk memiliki repositori pusat yang ditentukan / dinominasikan secara sosial dari mana semua orang menarik (dapatkan perubahan dari).
Akhirnya Git menawarkan lebih banyak kemungkinan ketika diperlukan kolaborasi dengan sejumlah besar pengembang. Di bawah ini ada perbedaan antara CVS di Git untuk berbagai tahapan minat dan posisi dalam suatu proyek (di bawah kontrol versi menggunakan CVS atau Git):
lurker . Jika Anda hanya tertarik untuk mendapatkan perubahan terbaru dari suatu proyek, ( tidak ada penyebaran perubahan Anda ), atau melakukan pengembangan pribadi (tanpa berkontribusi kembali ke proyek asli); atau Anda menggunakan proyek asing sebagai dasar proyek Anda sendiri (perubahan bersifat lokal dan tidak masuk akal untuk mempublikasikannya).
Git mendukung di sini akses read-only anonim yang tidak diautentikasi melalui git://protokol efisien kustom , atau jika Anda berada di belakang pemblokiran firewall DEFAULT_GIT_PORT(9418) Anda dapat menggunakan HTTP biasa.
Untuk CVS solusi paling umum (seperti yang saya mengerti) untuk akses read-only adalah akun tamu untuk protokol 'pserver' pada CVS_AUTH_PORT(2401), biasanya disebut "anonim" dan dengan kata sandi kosong. Kredensial disimpan secara default dalam $HOME/.cvspassfile, jadi Anda harus menyediakannya hanya sekali; tetap saja, ini sedikit penghalang (Anda harus tahu nama akun tamu, atau memperhatikan pesan server CVS) dan jengkel.
pengembang pinggiran (kontributor daun) . Salah satu cara menyebarkan perubahan Anda di OSS adalah mengirim tambalan melalui email . Ini adalah solusi paling umum jika Anda (kurang lebih) pengembang tidak disengaja, mengirimkan perubahan tunggal, atau perbaikan bug tunggal. BTW. mengirim tambalan mungkin melalui papan ulasan (sistem ulasan tambalan) atau cara serupa, tidak hanya melalui email.
Git menawarkan di sini alat yang membantu dalam mekanisme propagasi (penerbitan) ini untuk pengirim (klien), dan untuk pengelola (server). Bagi orang-orang yang ingin mengirim perubahan mereka melalui email ada alat " git rebase " (atau "git pull --rebase") untuk memutar ulang perubahan Anda sendiri di atas versi hulu saat ini, jadi perubahan Anda berada di atas versi saat ini (segar ), dan " git format-patch " untuk membuat email dengan pesan komit (dan kepengarangan), ubah dalam bentuk (diperluas) format diff terpadu (ditambah diffstat untuk ditinjau lebih mudah). Maintainer dapat mengubah email semacam itu menjadi komit menjaga semua informasi (termasuk pesan komit) menggunakan " git am ".
CVS tidak menawarkan alat seperti itu: Anda dapat menggunakan "cvs diff" / "cvs rdiff" untuk menghasilkan perubahan, dan menggunakan tambalan GNU untuk menerapkan perubahan, tetapi sejauh yang saya tahu tidak ada cara untuk secara otomatis menerapkan pesan komit. CVS dimaksudkan untuk digunakan dalam mode server <-> klien ...
letnan . Jika Anda mengelola bagian terpisah dari sebuah proyek (subsistem), atau jika pengembangan proyek Anda mengikuti alur kerja "jaringan kepercayaan" yang digunakan dalam pengembangan kernel Linux ... atau hanya jika Anda memiliki repositori publik Anda sendiri, dan perubahan yang Anda lakukan ingin mempublikasikan terlalu besar untuk dikirim melalui email sebagai seri tambalan , Anda dapat mengirim permintaan tarik ke (utama) pengelola proyek.
Ini adalah solusi khusus untuk sistem kontrol versi terdistribusi , jadi tentu saja CVS tidak mendukung cara kolaborasi seperti itu. Bahkan ada alat yang disebut "git request-pull" yang membantu mempersiapkan email untuk dikirim ke pengelola dengan permintaan untuk menarik dari repositori Anda. Berkat "bundel git" Anda dapat menggunakan mekanisme ini bahkan tanpa memiliki repositori publik, dengan mengirimkan bundel perubahan melalui email atau sneakernet. Beberapa situs hosting Git seperti GitHub memiliki dukungan untuk memberi tahu bahwa seseorang sedang bekerja (menerbitkan beberapa karya) pada proyek Anda (asalkan ia menggunakan situs hosting Git yang sama), dan untuk PM, semacam permintaan tarik.
pengembang utama , yaitu seseorang yang secara langsung mempublikasikan perubahannya (ke repositori utama / kanonik). Kategori ini lebih luas untuk sistem kontrol versi terdistribusi, karena memiliki banyak pengembang dengan akses tulis ke repositori pusat tidak hanya alur kerja yang mungkin (Anda dapat memiliki pengelola tunggal yang mendorong perubahan ke repositori kanonik, satu set letnan / pengelola sistem yang darinya ia tarikan, dan beragam pengembang daun yang mengirim tambalan melalui pos baik ke pengelola / mailing list proyek, atau ke salah satu letnan / pengamat).
Dengan Git Anda memiliki pilihan untuk menggunakan protokol SSH ( protokol git yang dibungkus SSH) untuk mempublikasikan perubahan, dengan alat seperti "git shell" (untuk membantu keamanan, membatasi akses akun shell) atau Gitosis (untuk mengelola akses tanpa memerlukan akun shell terpisah ), dan HTTPS dengan WebDAV, dengan otentikasi HTTP biasa.
Dengan CVS ada pilihan antara protokol pserver kustom tanpa enkripsi (teks biasa) , atau menggunakan shell jauh (di mana Anda benar-benar harus menggunakan SSH ) untuk mempublikasikan perubahan Anda, yang untuk sistem kontrol versi terpusat berarti melakukan perubahan Anda (membuat komitmen). Nah, Anda juga bisa tunnel protokol 'pserver' menggunakan SSH, dan ada alat pihak ketiga mengotomatisasi ini ... tapi saya tidak berpikir ini semudah misalnya Gitosis.
Secara umum sistem kontrol versi terdistribusi, seperti Git, menyediakan banyak pilihan alur kerja yang lebih luas. Dengan sistem kontrol versi terpusat, seperti CVS, dengan terpaksa Anda harus membedakan antara orang-orang dengan akses komit ke repositori, dan mereka yang tanpa ... dan CVS tidak menawarkan alat apa pun untuk membantu menerima kontribusi (melalui tambalan) dari orang-orang tanpa akses komit.
Karl Fogel dalam Memproduksi Perangkat Lunak Sumber Terbuka di bagian tentang kontrol versi menyatakan bahwa lebih baik tidak memberikan kontrol yang terlalu ketat, kaku, dan ketat pada area di mana seseorang diizinkan untuk membuat perubahan pada repositori publik; jauh lebih baik untuk bergantung (untuk ini) pada batasan sosial (seperti review kode) daripada pada batasan teknis; sistem kontrol versi terdistribusi mengurangi IMHO lebih jauh ...
HTH (Harapan yang Membantu)