Dalam artikel ini, kami membandingkan dari sudut pandang teknis sistem kontrol versi paling terkenal (di masa depan kami berencana untuk memperluas daftar):
- Generasi pertama
- Generasi kedua
- Generasi ketiga
Sistem kontrol versi generasi pertama (VCS) melacak perubahan dalam file individual, dan pengeditan hanya didukung secara lokal dan oleh satu pengguna pada satu waktu. Sistem dibangun dengan asumsi bahwa semua pengguna akan masuk ke akun mereka pada simpul Unix yang sama.
VCS generasi kedua memperkenalkan dukungan jaringan, yang menyebabkan repositori terpusat dengan versi proyek “resmi”. Ini adalah kemajuan yang signifikan, karena beberapa pengguna dapat bekerja dengan kode pada saat yang sama, melakukan ke repositori pusat yang sama. Namun, melakukan akses yang diperlukan ke jaringan.
Generasi ketiga terdiri dari VCS terdistribusi, di mana semua salinan repositori dianggap sama, tidak ada repositori pusat. Ini membuka jalan bagi komit, cabang, dan gabungan yang dibuat secara lokal tanpa akses ke jaringan dan pindah ke repositori lain sesuai kebutuhan.
Rentang Waktu VCS
Untuk konteks, berikut adalah bagan yang menunjukkan tanggal munculnya alat-alat ini:
SCCS (Source Code Control System): generasi pertama
SCCS dianggap sebagai salah satu sistem kontrol versi pertama yang berhasil. Ini dikembangkan pada tahun 1972 oleh Mark Rochkind dari Bell Labs. Sistem ini ditulis dalam C dan dirancang untuk melacak versi file sumber. Selain itu, sangat memudahkan pencarian sumber kesalahan dalam program. Arsitektur dasar dan sintaksis SCCS memungkinkan untuk memahami akar dari alat VCS modern.
Arsitektur
Seperti kebanyakan sistem modern, SCCS memiliki seperangkat perintah untuk bekerja dengan versi file:
- File check-in untuk pelacakan riwayat di SCCS.
- Periksa versi file tertentu untuk ditinjau atau dikompilasi.
- Ekstrak versi spesifik untuk diedit.
- Memperkenalkan versi file baru bersama dengan komentar yang menjelaskan perubahan.
- Buang perubahan yang dilakukan pada file yang diekstrak.
- Perubahan percabangan dan penggabungan besar.
- File Ubah Log.
Saat menambahkan file pelacakan ke SCCS, jenis file khusus dibuat, yang disebut
s- atau
. Ini disebut sebagai file sumber, hanya dengan awalan
s. , dan disimpan di subdirektori
SCCS . Dengan demikian, untuk file
test.txt , file histori
test.txt akan dibuat di direktori
./SCCS/ . Pada saat pembuatan, file riwayat berisi konten awal dari file sumber, serta beberapa metadata yang membantu melacak versi. Checksum disimpan di sini untuk memastikan bahwa kontennya belum dimodifikasi. Isi dari file histori tidak dikompresi atau dikodekan (seperti pada VCS generasi berikutnya).
Karena isi file sumber sekarang disimpan dalam file histori, ia dapat diekstraksi ke direktori kerja untuk dilihat, dikompilasi atau diedit. Anda dapat membuat perubahan pada file histori, seperti menambahkan baris, mengubah dan menghapus, yang meningkatkan nomor versinya.
Penambahan file selanjutnya hanya menyimpan
atau perubahan, dan tidak semua isinya. Ini mengurangi ukuran file histori. Setiap delta disimpan di dalam file sejarah dalam struktur yang disebut
- . Seperti disebutkan sebelumnya, isi sebenarnya dari suatu file lebih atau kurang disalin kata demi kata, dengan urutan pelarian khusus untuk menandai awal dan akhir bagian dari konten yang ditambahkan dan dihapus. Karena file riwayat SCCS tidak menggunakan kompresi, mereka biasanya lebih besar dari file aktual di mana perubahan dilacak. SCCS menggunakan metode yang disebut
, yang menjamin waktu pengambilan yang konstan terlepas dari usia versi yang diambil, yaitu, versi yang lebih lama diambil pada kecepatan yang sama dengan yang baru.
Penting untuk dicatat bahwa semua file dilacak dan direkam secara terpisah. Tidaklah mungkin untuk memeriksa perubahan dalam banyak file sebagai blok atom tunggal, seperti komit di Git. Setiap file yang dilacak memiliki file histori sendiri, di mana histori perubahan disimpan. Dalam kasus umum, ini berarti bahwa nomor versi berbagai file dalam suatu proyek biasanya tidak cocok. Namun, versi ini dapat disepakati dengan secara bersamaan mengedit semua file dalam proyek (bahkan tanpa membuat perubahan nyata pada mereka) dan menambahkan semua file pada saat yang sama. Ini secara bersamaan akan meningkatkan nomor versi untuk semua file, menjaga mereka konsisten, tetapi perhatikan bahwa ini tidak sama dengan memasukkan beberapa file dalam satu komit, seperti pada Git. Di SCCS, riwayat individu ditambahkan ke setiap file, tidak seperti satu komit besar yang mencakup semua perubahan sekaligus.
Ketika file diekstraksi untuk diedit di SCCS, kunci ditempatkan di sana, sehingga tidak ada orang lain yang bisa mengeditnya. Ini mencegah menimpa perubahan oleh pengguna lain, tetapi juga membatasi pengembangan, karena pada waktu tertentu hanya satu pengguna dapat bekerja dengan file ini.
SCCS mendukung cabang yang menyimpan urutan perubahan dalam file tertentu. Anda bisa menggabungkan cabang dengan versi asli atau dengan cabang lain.
Tim utama
Berikut ini adalah daftar perintah SCCS yang paling umum.
sccs create <filename.ext> : tambahkan file baru ke SCCS dan buat file histori baru untuknya (secara default di direktori ./SCCS/ ).
sccs get <filename.ext> : ekstrak file dari file history yang sesuai dan letakkan di direktori kerja dalam mode read-only.
sccs edit <filename.ext> : ekstrak file dari file histori yang sesuai untuk diedit. Kunci file histori sehingga pengguna lain tidak dapat memodifikasinya.
sccs delta <filename.ext> : tambahkan perubahan ke file yang ditentukan. Sistem akan meminta komentar, menyimpan perubahan ke file histori dan melepaskan kunci.
sccs prt <filename.ext> : menampilkan log perubahan untuk file yang dipantau.
sccs diffs <filename.ext> : menunjukkan perbedaan antara copy pekerjaan file saat ini dan status file ketika diekstraksi.
Untuk informasi lebih lanjut tentang internal SCCS, lihat Panduan
Eric Allman dan Panduan Utilitas Pemrograman Oracle .
Contoh File Riwayat SCCS
^Ah20562 ^As 00001/00001/00002 ^Ad D 1.3 19/11/26 14:37:08 jack 3 2 ^Ac Here is a comment. ^Ae ^As 00002/00000/00001 ^Ad D 1.2 19/11/26 14:36:00 jack 2 1 ^Ac No. ^Ae ^As 00001/00000/00000 ^Ad D 1.1 19/11/26 14:35:27 jack 1 0 ^Ac date and time created 19/11/26 14:35:27 by jack ^Ae ^Au ^AU ^Af e 0 ^At ^AT ^AI 1 Hi there ^AE 1 ^AI 2 ^AD 3 This is a test of SCCS ^AE 2 ^AE 3 ^AI 3 A test of SCCS ^AE 3
RCS (Sistem Kontrol Revisi): generasi pertama
RCS ditulis pada tahun 1982 oleh Walter Tihey dalam bahasa C sebagai alternatif dari sistem SCCS, yang pada waktu itu bukan open source.
Arsitektur
RCS memiliki banyak kesamaan dengan pendahulunya, termasuk:
- Versi secara terpisah untuk setiap file.
- Perubahan pada banyak file tidak dapat dikelompokkan menjadi satu komit.
- File yang dilacak tidak dapat diedit oleh banyak pengguna secara bersamaan.
- Tidak ada dukungan jaringan.
- Versi setiap file yang dilacak disimpan dalam file histori yang sesuai.
- Versi percabangan dan penggabungan hanya untuk file individual.
Ketika file pertama kali ditambahkan ke RCS, file histori yang sesuai dibuat untuk itu di penyimpanan lokal di direktori lokal
./RCS/ . Ekstensi
,v , ditambahkan ke file ini, yaitu file bernama
test.txt akan dilacak oleh file bernama
test.txt,v .
RCS menggunakan skema reverse-delta untuk menyimpan perubahan. Ketika Anda menambahkan file, snapshot penuh dari isinya disimpan dalam file histori. Ketika file diubah dan dikembalikan lagi, delta dihitung berdasarkan konten yang ada dari file histori. Gambar lama dibuang, dan yang baru disimpan bersama dengan delta untuk kembali ke keadaan lama. Ini disebut
, karena untuk mengambil versi yang lebih lama, RCS mengambil versi terbaru dan secara berurutan menerapkan delta hingga mencapai versi yang diinginkan. Metode ini memungkinkan Anda untuk mengambil versi saat ini dengan sangat cepat, karena snapshot lengkap dari revisi saat ini selalu tersedia. Namun, semakin lama versi, semakin lama waktu verifikasi, karena lebih banyak delta perlu diverifikasi.
Di SCCS, ini berbeda: butuh waktu yang sama untuk mengekstraksi versi apa pun. Selain itu, checksum tidak disimpan dalam file riwayat RCS, sehingga integritas file tidak dapat dipastikan.
Tim utama
Di bawah ini adalah daftar perintah RCS yang paling umum:
<filename.ext> : tambahkan file baru ke RCS dan buat file histori baru untuknya (secara default di direktori ./RCS/ ).
co <filename.ext> : ekstrak file dari file history yang sesuai dan letakkan di direktori kerja dalam mode read-only.
co -l <filename.ext> : ekstrak file dari file histori yang sesuai untuk diedit. Kunci file histori sehingga pengguna lain tidak dapat memodifikasinya.
ci <filename.ext> : tambahkan perubahan file dan buat revisi baru untuk itu dalam file histori yang sesuai.
merge <file-to-merge-into.ext> <parent.ext> <file-to-merge-from.ext> : menggabungkan perubahan dari dua anak yang dimodifikasi dari file induk yang sama.
rcsdiff <filename.ext> : menampilkan perbedaan antara copy pekerjaan file saat ini dan status file ketika diekstraksi.
rcsclean : hapus file kerja yang tidak dikunci.
Untuk informasi lebih lanjut tentang komponen RCS internal, lihat
Manual GNU RCS .
Contoh File Riwayat RCS
head 1.2; access; symbols; locks; strict; comment @# @; 1.2 date 2019.11.25.05.51.55; author jstopak; state Exp; branches; next 1.1; 1.1 date 2019.11.25.05.49.02; author jstopak; state Exp; branches; next ; desc @This is a test. @ 1.2 log @Edited the file. @ text @hi there, you are my bud. You are so cool! The end. @ 1.1 log @Initial revision @ text @d1 5 a5 1 hi there @
CVS (Concurrent Versi System): generasi kedua
CVS dibuat oleh Dick Grun pada tahun 1986 untuk menambahkan dukungan jaringan ke kontrol versi. Ini juga ditulis dalam C dan menandai kelahiran alat VCS generasi kedua, berkat tim pengembang yang tersebar secara geografis memiliki kesempatan untuk mengerjakan proyek bersama.
Arsitektur
CVS adalah tampilan depan untuk RCS, ia memiliki serangkaian perintah baru untuk berinteraksi dengan file dalam suatu proyek, tetapi di bawah tenda format file riwayat RCS yang sama dan perintah RCS digunakan. Untuk pertama kalinya, CVS memungkinkan beberapa pengembang bekerja dengan file yang sama secara bersamaan. Ini diimplementasikan menggunakan model repositori terpusat. Langkah pertama adalah mengkonfigurasi repositori terpusat menggunakan CVS pada server jarak jauh. Proyek kemudian dapat diimpor ke dalam repositori. Ketika sebuah proyek diimpor ke CVS, setiap file dikonversi ke file histori
,v dan disimpan dalam direktori pusat:
. Repositori biasanya terletak di server jarak jauh, aksesnya adalah melalui jaringan lokal atau Internet.
Pengembang menerima salinan modul, yang disalin ke direktori kerja di komputer lokalnya. Dalam proses ini, tidak ada file yang diblokir, sehingga tidak ada batasan pada jumlah pengembang yang secara bersamaan dapat bekerja dengan modul. Pengembang dapat memodifikasi file mereka dan melakukan perubahan seperlunya (komit). Jika pengembang melakukan perubahan, pengembang lain harus memperbarui copy pekerjaan mereka menggunakan proses penggabungan otomatis (sebelum biasanya) sebelum melakukan perubahan mereka. Terkadang Anda harus menyelesaikan konflik penggabungan secara manual sebelum melakukan. CVS juga menyediakan kemampuan untuk membuat dan menggabungkan cabang.
Tim utama
export CVSROOT=<path/to/repository> : atur direktori root dari repositori CVS, jadi Anda tidak perlu menentukannya di setiap perintah.
cvs import -m 'Import module' <module-name> <vendor-tag> <release-tag> : impor direktori dengan file ke dalam modul CVS. Sebelum memulai proses ini, pergi ke direktori root proyek.
cvs checkout <module-name> : salin modul ke direktori kerja.
cvs commit <filename.ext> : mengkomit file yang dimodifikasi kembali ke modul di repositori pusat.
cvs add <filename.txt> : tambahkan file baru untuk melacak perubahan.
cvs update : perbarui copy pekerjaan dengan menggabungkan perubahan yang dilakukan yang ada di repositori pusat tetapi tidak dalam copy pekerjaan.
cvs status : tampilkan informasi umum tentang copy pekerjaan yang diekstrak dari modul.
cvs tag <tag-name> <files> : tambahkan tag ke file atau set file.
cvs tag -b <new-branch-name> : buat cabang baru di repositori (Anda perlu mengekstraknya sebelum pekerjaan lokal).
cvs checkout -r <branch-name> : ekstrak cabang yang ada ke direktori kerja.
cvs update -j <branch-to-merge> : Gabungkan cabang yang ada dengan copy pekerjaan lokal.
Untuk informasi lebih lanjut tentang komponen internal CVS, lihat
Buku Pegangan GNU CVS dan
artikel Dick Grohn .
Contoh File Riwayat CVS
head 1.1; branch 1.1.1; access ; symbols start:1.1.1.1 jack:1.1.1; locks ; strict; comment @# @; 1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches 1.1.1.1; next ; commitid zsEBhVyPc4lonoMB; 1.1.1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches ; next ; commitid zsEBhVyPc4lonoMB; desc @@ 1.1 log @Initial revision @ text @hi there @ 1.1.1.1 log @Imported sources @ text @@
SVN (Subversi): Generasi Kedua
Subversion dibuat pada tahun 2000 oleh Collabnet Inc. dan saat ini didukung oleh Apache Software Foundation. Sistem ini ditulis dalam C dan dirancang sebagai solusi terpusat yang lebih andal daripada CVS.
Arsitektur
Seperti CVS, Subversion menggunakan model repositori terpusat. Pengguna jarak jauh memerlukan koneksi jaringan untuk melakukan ke repositori pusat.
Subversion memperkenalkan fungsionalitas atom yang dilakukan dengan jaminan bahwa komit sepenuhnya berhasil atau sepenuhnya dibatalkan jika terjadi masalah. Dalam CVS, jika terjadi kegagalan fungsi di tengah komit (misalnya, karena kegagalan jaringan), repositori dapat tetap dalam keadaan rusak dan tidak konsisten. Selain itu, komit atau versi dalam Subversion dapat menyertakan beberapa file dan direktori. Ini penting karena memungkinkan Anda untuk melacak set perubahan terkait bersama sebagai blok yang dikelompokkan, dan tidak secara terpisah untuk setiap file, seperti dalam sistem masa lalu.
Subversion saat ini menggunakan sistem file FSFS (File System di atas File System). Di sini database dibuat dengan struktur file dan direktori yang sesuai dengan sistem file host. Fitur unik FSFS adalah ia dirancang untuk melacak tidak hanya file dan direktori, tetapi juga versinya. Ini adalah sistem file yang sensitif terhadap waktu. Direktori juga objek penuh dalam Subversi. Anda dapat melakukan direktori kosong ke sistem, sedangkan sisanya (bahkan Git) tidak menyadarinya.
Saat Anda membuat repositori Subversion, database file dan folder (hampir) kosong dibuat dalam komposisinya. Direktori
db/revs dibuat, yang menyimpan semua informasi pelacakan versi untuk file yang ditambahkan (berkomitmen). Setiap komit (yang dapat menyertakan perubahan dalam beberapa file) disimpan dalam file baru di direktori
revs , dan diberi nama dengan pengidentifikasi numerik berurutan dimulai dengan 1. Komit pertama menyimpan konten lengkap file. Komit di masa depan dari file yang sama hanya akan menyimpan perubahan, yang juga disebut
atau delta, untuk menghemat ruang. Selain itu, delta dikompresi menggunakan algoritma kompresi
lz4 atau
zlib untuk mengurangi ukuran.
Sistem seperti itu hanya berfungsi sampai titik tertentu. Meskipun delta menghemat ruang, tetapi jika ada banyak delta, maka banyak waktu yang diperlukan untuk operasi, karena semua delta harus diproses untuk menciptakan kembali keadaan file saat ini. Karena alasan ini, secara default, Subversion menyimpan hingga 1023 delta per file, dan kemudian membuat salinan lengkap file baru. Ini memberikan keseimbangan penyimpanan dan kecepatan yang baik.
SVN tidak menggunakan sistem percabangan dan penandaan yang biasa. Templat repositori Subversion biasa berisi tiga folder di root:
Direktori
trunk/ digunakan untuk versi produksi proyek.
branches/ direktori - untuk menyimpan subfolder yang sesuai dengan masing-masing cabang.
tags/ direktori adalah untuk menyimpan tag yang mewakili versi spesifik proyek (biasanya signifikan).
Tim utama
svn create <path-to-repository> : membuat shell repositori baru yang kosong di direktori yang ditentukan.
svn import <path-to-project> <svn-url> : impor direktori file ke dalam repositori Subversion yang ditentukan.
svn checkout <svn-path> <path-to-checkout> : salin repositori ke direktori yang berfungsi.
svn commit -m 'Commit message' : komit satu set file dan folder yang dimodifikasi bersama dengan pesan.
svn add <filename.txt> : tambahkan file baru untuk melacak perubahan.
svn update : perbarui copy pekerjaan dengan menggabungkan perubahan yang dilakukan yang ada di repositori pusat tetapi tidak di copy pekerjaan.
svn status : menampilkan daftar file yang dipantau yang telah berubah di direktori kerja (jika ada).
svn info : informasi umum tentang salinan yang diekstrak.
svn copy <branch-to-copy> <new-branch-path-and-name> : buat cabang baru dengan menyalin yang sudah ada.
svn switch <existing-branch> : alihkan direktori kerja ke cabang yang ada. Ini akan memungkinkan Anda untuk mengambil file dari sana.
svn merge <existing-branch> : menggabungkan cabang yang ditentukan dengan yang sekarang disalin ke direktori kerja. Harap perhatikan bahwa Anda harus melakukan nanti.
svn log : menunjukkan riwayat commit dan pesan terkait untuk cabang aktif.
Untuk informasi lebih lanjut tentang komponen internal SVN, lihat
Subversi Versi .
Contoh File Riwayat SVN
DELTA SVN^B^@^@ ^B ^A<89> hi there ENDREP id: 2-1.0.r1/4 type: file count: 0 text: 1 3 21 9 12f6bb1941df66b8f138a446d4e8670c 279d9035886d4c0427549863c4c2101e4a63e041 0-0/_4 cpath: /trunk/hi.txt copyroot: 0 / DELTA SVN^B^@^@$^B%^A¤$K 6 hi.txt V 15 file 2-1.0.r1/4 END ENDREP id: 0-1.0.r1/6 type: dir count: 0 text: 1 5 48 36 d84cb1c29105ee7739f3e834178e6345 - - cpath: /trunk copyroot: 0 / DELTA SVN^B^@^@'^B#^A¢'K 5 trunk V 14 dir 0-1.0.r1/6 END ENDREP id: 0.0.r1/2 type: dir pred: 0.0.r0/2 count: 1 text: 1 7 46 34 1d30e888ec9e633100992b752c2ff4c2 - - cpath: / copyroot: 0 / _0.0.t0-0 add-dir false false false /trunk _2.0.t0-0 add-file true false false /trunk/hi.txt L2P-INDEX ^A<80>@^A^A^A^M^H^@ä^H÷^Aé^FDÎ^Bzè^AP2L-INDEX ^A<91>^E<80><80>@^A?^@'2^@<8d>»Ý<90>^C§^A^X^@õ ½½^N= ^@ü<8d>Ôã^Ft^V^@<92><9a><89>Ã^E; ^@<8a>åw|I^@<88><83>Î<93>^L`^M^@ù<92>À^Eïú?^[^@^@657 6aad60ec758d121d5181ea4b81a9f5f4 688 75f59082c8b5ab687ae87708432ca406I
Git: generasi ketiga
Sistem Git dikembangkan pada 2005 oleh Linus Torvalds (pencipta Linux). Ini ditulis terutama dalam C dalam kombinasi dengan beberapa skrip baris perintah. Berbeda dari VCS dalam fungsi, fleksibilitas, dan kecepatan. Torvalds awalnya menulis sistem untuk basis kode Linux, tetapi seiring waktu cakupannya telah meluas, dan hari ini ia adalah sistem kontrol versi paling populer di dunia.
Arsitektur
Git adalah sistem terdistribusi. Tidak ada repositori pusat: semua salinan dibuat sama, yang sangat berbeda dari VCS generasi kedua, di mana pekerjaan didasarkan pada menambah dan mengekstrak file dari repositori pusat. Ini berarti bahwa pengembang dapat bertukar perubahan satu sama lain segera sebelum menggabungkan perubahan mereka ke cabang resmi.
Selain itu, pengembang dapat membuat perubahan mereka ke salinan lokal repositori tanpa sepengetahuan repositori lainnya. Ini memungkinkan komit tanpa terhubung ke jaringan atau Internet. Pengembang dapat bekerja secara offline secara lokal, sampai mereka siap untuk berbagi pekerjaan mereka dengan orang lain. Pada titik ini, perubahan dikirim ke repositori lain untuk verifikasi, pengujian, atau penyebaran.
Ketika sebuah file ditambahkan untuk pelacakan di Git, ia dikompres menggunakan algoritma kompresi
zlib . Hasilnya hash menggunakan fungsi hash SHA-1. Ini memberikan hash unik yang cocok dengan konten file ini. Git menyimpannya dalam
, yang terletak di folder tersembunyi
.git/objects . Nama file adalah hash yang dihasilkan, dan file tersebut berisi konten terkompresi. File-file ini disebut
dan dibuat setiap kali file baru (atau versi modifikasi dari file yang ada) ditambahkan ke repositori.
Git mengimplementasikan indeks pementasan, yang bertindak sebagai area perantara untuk perubahan yang sedang dipersiapkan untuk komitmen. Saat perubahan baru disiapkan, konten terkompresi mereka direferensikan dalam file indeks khusus, yang mengambil bentuk objek
.
Pohon adalah objek Git yang mengaitkan gumpalan dengan nama file aslinya, izin file, dan tautan ke pohon lain dan dengan demikian mewakili keadaan kumpulan file dan direktori tertentu. Ketika semua perubahan yang relevan disiapkan untuk komit, pohon indeks dapat dikomit ke repositori yang membuat objek (benda longgar). Tidak ada perbedaan yang digunakan di sini untuk menghemat ruang, yang membuat Git sangat cepat, karena konten lengkap dari setiap versi file tersedia sebagai objek gratis. Namun, beberapa operasi, seperti mengirim komit ke repositori jarak jauh, menyimpan sejumlah besar objek, atau secara manual menjalankan perintah pengumpulan sampah Git, menyebabkan objek tersebut dikemas ulang .packdengan konten objek dibuat , dan untuk masing-masingnya file .idx(atau indeks) dibuat dengan tautan ke objek yang dikemas dan lokasinya di file batch.Ketika cabang dipindahkan ke atau diambil dari repositori jarak jauh, file batch ini ditransfer melalui jaringan. Saat merentangkan atau mengekstraksi cabang, file paket dibongkar untuk membuat objek gratis di repositori objek.Tim utama
git init: inisialisasi direktori saat ini sebagai repositori Git (folder tersembunyi .gitdan isinya dibuat).
git clone <git-url> : Unduh salinan repositori Git di URL yang ditentukan.
git add <filename.ext> : menambahkan file yang tidak dilacak atau dimodifikasi ke area pementasan (membuat catatan terkait dalam database objek).
git commit -m 'Commit message' : komit seperangkat file dan folder yang dimodifikasi bersama dengan pesan komit.
git status : tampilkan status direktori kerja, cabang saat ini, file yang tidak dilacak, file yang dimodifikasi, dll.
git branch <new-branch> : buat cabang baru berdasarkan cabang yang diekstrak saat ini.
git checkout <branch> : ekstrak cabang yang ditentukan ke direktori kerja.
git merge <branch> : menggabungkan cabang yang ditentukan dengan yang saat ini, yang diekstraksi ke direktori kerja.
git pull : Perbarui copy pekerjaan dengan menggabungkan perubahan yang dilakukan yang ada di repositori jarak jauh, tetapi tidak di copy pekerjaan.
git push : kemas objek gratis untuk komit lokal dari cabang aktif ke dalam file paket dan transfer ke repositori jarak jauh.
git log : tampilkan riwayat commit dan pesan terkait untuk cabang aktif.
git stash : simpan semua perubahan yang tidak dikomit dari direktori kerja ke cache untuk pengambilan nanti.
Jika Anda ingin tahu cara kerja kode Git, lihat Panduan Memulai Git . Untuk informasi lebih lanjut tentang komponen internal, lihat bab terkait di buku Pro Git .Contoh gumpalan, pohon dan komit git
Gumpalan dengan hash 37d4e6c5c48ba0d245164c4e10d5f41140cab980: hi there
Objek pohon dengan hash b769f35b07fbe0076dcfc36fd80c121d747ccc04: 100644 blob 37d4e6c5c48ba0d245164c4e10d5f41140cab980hi.txt
Hash melakukan dc512627287a61f6111705151f4e53f204fbda9b: tree b769f35b07fbe0076dcfc36fd80c121d747ccc04 author Jacob Stopak 1574915303 -0800 committer Jacob Stopak 1574915303 -0800 Initial commit
Mercurial: generasi ketiga
Mercurial dibuat pada tahun 2005 oleh Matt McCall dan ditulis dalam Python. Itu juga dirancang untuk hosting basis kode Linux, tetapi Git akhirnya dipilih untuk tugas ini. Ini adalah sistem kontrol versi paling populer kedua, meskipun digunakan lebih jarang.Arsitektur
Mercurial juga merupakan sistem terdistribusi yang memungkinkan sejumlah pengembang untuk bekerja dengan salinan proyek mereka secara independen dari orang lain. Mercurial menggunakan banyak teknologi yang sama seperti Git, termasuk kompresi dan hashing SHA-1, tetapi ia melakukannya secara berbeda.Ketika file baru berkomitmen untuk dilacak di Mercurial, file yang sesuai dibuat untuk itu revlogdi direktori tersembunyi .hg/store/data/. Anda dapat mempertimbangkan file revlog(ubah log) sebagai versi yang ditingkatkan di VCS lama seperti CVS, RCS, dan SCCS. Tidak seperti Git, yang membuat gumpalan baru untuk setiap versi setiap file yang disiapkan, Mercurial hanya membuat entri revlog baru untuk file ini. Untuk menghemat ruang, setiap catatan baru hanya berisi delta dari versi sebelumnya. Ketika jumlah ambang delta tercapai, snapshot penuh file disimpan lagi. Ini mengurangi waktu pencarian ketika memproses sejumlah besar delta untuk mengembalikan versi file tertentu.Setiap revlog dinamai sesuai dengan file yang dilacak, tetapi dengan ekstensi .iatau .d. File .dberisi delta terkompresi. File .idigunakan sebagai indeks untuk dengan cepat melacak berbagai versi di dalam file.d. Untuk file kecil dengan sedikit perubahan, indeks dan konten disimpan di dalam file .i. Entri Revlog dikompresi untuk kinerja dan hash untuk identifikasi. Nilai hash ini dinamai nodeid.Di setiap komit, Mercurial melacak semua versi file dalam komit ini dalam apa yang disebut a nodeid.Akhirnya, Mercurial menggunakan jenis lain dari revlog yang disebut changelog, yaitu, log perubahan. Ini adalah daftar entri yang mengaitkan setiap komit dengan informasi berikut:- manifest nodeid: Satu set lengkap versi file yang ada pada titik waktu tertentu.
- satu atau dua nodeid untuk komitmen induk: ini memungkinkan Mercurial untuk membangun timeline atau cabang dari sejarah proyek. Satu atau dua ID induk disimpan tergantung pada jenis komit (reguler atau gabungan).
- Penulis Komit
- Tanggal komitmen
- Pesan komit
Setiap entri changelog juga menghasilkan hash yang dikenal sebagai nya nodeid.Tim utama
hg init: inisialisasi direktori saat ini sebagai repositori Mercurial (membuat folder tersembunyi .hgdan isinya).
hg clone <hg-url> : Unduh salinan repositori Mercurial di URL yang ditentukan.
hg add <filename.ext> : Tambahkan file baru untuk melacak perubahan.
hg commit -m 'Commit message' : komit set file dan folder yang diubah bersama dengan pesan komit.
hg status : menampilkan informasi yang terkait dengan status direktori kerja, file yang tidak dilacak, file yang dimodifikasi, dll.
hg update <revision> : ekstrak cabang yang ditentukan ke direktori kerja.
hg merge <branch> : menggabungkan cabang yang ditentukan dengan yang saat ini diekstraksi ke direktori kerja.
hg pull : Unduh versi baru dari repositori jarak jauh, tetapi jangan digabung menjadi direktori yang berfungsi.
hg push : Transfer versi baru ke repositori jarak jauh.
hg log : Tampilkan riwayat komit dan pesan terkait untuk cabang aktif.
Contoh File Mercurial
Manifesto: hey.txt208b6e0998e8099b16ad0e43f036ec745d58ec04 hi.txt74568dc1a5b9047c8041edd99dd6f566e78d3a42
Ubah log (changelog): b8ee947ce6f25b84c22fbefecab99ea918fc0969 Jacob Stopak 1575082451 28800 hey.txt Add hey.txt
Informasi tambahan tentang perangkat Mercurial: