Mengenal Git: Sistem Kontrol Versi Perangkat Lunak

Permasalahan

Bagi pengembang atau programmer yang bekerja bersama-sama dalam sebuah tim mungkin pernah merubah atau membuat blok kode program dalam sebuah projek, blok yang sama dengan yang di rubah oleh anggota tim yang lain. Akibatnya perubahan yang kita lakukan tidak kompatibel dengan perubahan yang dibuat oleh anggota tim lain pada saat yang sama. Hal ini tentu dapat menghambat proses pengembangan perangkat lunak.

Solusi

Version Control System (VCS) atau Sistem kontrol versi membantu pengembang untuk berkerja bersama dan memelihara history pekerjaan kita secara lengkap. VCS menyediakan beberapa fitur berikut :

1. Riwayat lengkap setiap berkas (file) yang memungkinkan kita untuk kembali ke versi sebelumnya untuk menganalisa sumber bug dan memperbaiki masalah di versi yang lebih lama
2. Kemampuan untuk bekerja pada setiap perubahan secara independen, sehingga memungkinkan kita untuk menggabungkan pekerjaan itu kembali dan memverifikasi setiap perubahan yang menyebabkan konflik
3. Kemampuan melacak setiap perubahan dengan pesan yang menjelaskan tujuan dan maksud perubahan dan menghubungkannya dengan manajemen projek dan sistem pelacak bug

Terdapat dua tipe version control :
1. Centralized Version Control (Kontrol Versi Terpusat)
2. Decentralized/Distributed Version Kontrol System (Kontrol Versi terdistribusi)

Centralized Version Kontrol

Dengan sistem kontrol versi terpusat, kita memiliki satu salinan "pusat" proyek di server dan melakukan perubahan pada salinan pusat ini. kita menarik file yang kita butuhkan, tetapi kita tidak pernah memiliki salinan lengkap proyek di komputer lokal. Beberapa sistem kontrol versi yang paling umum menerapkan sistem ini, termasuk Subversion (SVN) dan Perforce.

Distributed Version Kontrol

Dengan sistem kontrol versi terdistribusi (DVCS), kita tidak bergantung pada server pusat untuk menyimpan semua versi file proyek. Sebagai gantinya, kita mengkloning repositori secara lokal sehingga kita memiliki sejarang (history) lengkap proyek. Dua sistem kontrol versi terdistribusi yang umum adalah Git dan Mercurial.

Dalam bahasan berikutnya, kita akan memfokuskan pada pembahasan kontrol versi terdistribusi khususnya Git.

Sistem kontrol versi terpusat menggunakan server pusat untuk menyimpan semua file dan memungkinkan kolaborasi tim. Tetapi kelemahan utama tipe ini adalahkegagalan server pusat. Jika server pusat down selama satu jam, maka selama satu jam itu, tidak ada yang bisa berkolaborasi sama sekali. Dan bahkan dalam kasus terburuk, jika disk server rusak dan backup yang tepat belum diambil, maka kita akan kehilangan seluruh sejarah proyek. Di sini, sistem kontrol versi terdistribusi (DVCS) ditampilkan.

Klien git tidak hanya memeriksa snapshot terbaru dari direktori tetapi juga sepenuhnya mencerminkan repositori. Jika server down, maka repositori dari klien apa pun dapat disalin kembali ke server untuk memulihkannya. Git tidak bergantung pada server pusat dan itulah sebabnya kita dapat melakukan banyak operasi saat offline. kita dapat melakukan perubahan, membuat branch, melihat log, dan melakukan operasi lain saat kita offline. kita hanya memerlukan koneksi jaringan untuk mempublikasikan perubahan kita dan mengambil perubahan terbaru.

Terminologi

Local Repository
Setiap tool version control menyediakan tempat kerja pribadi sebagai salinan proyek. Kita lakukan perubahan di tempat kerja pribadi (komputer lokal) dan setelah melakukan perubahan, ini akan menjadi bagian dari repositori. Git mengambil satu langkah lebih jauh dengan membuat salinan pribadi dari seluruh repositori. Pengguna dapat melakukan banyak operasi dengan repositori ini seperti menambah file, menghapus file, mengganti nama file, memindahkan file, melakukan perubahan, dan banyak lagi.

Direktori Kerja dan Staging Area atau Indeks
Direktori kerja adalah tempat di mana file diperiksa. Git tidak melacak setiap file yang dimodifikasi. Setiap kali kita melakukan operasi, Git mencari file yang ada di staging area . Hanya file-file yang ada di staging area yang dianggap untuk komit dan tidak semua file yang dimodifikasi.

Mari kita lihat alur kerja dasar Git.
1. Kita memodifikasi file dari direktori kerja.
2. Tambahkan file-file ini ke staging area.
3. Lakukan operasi komit yang memindahkan file dari staging area. Setelah operasi Push, ini akan menyimpan perubahan secara permanen ke repositori Git.

BLOBs
Blob adalah singkatan dari Binary Large Object. Setiap versi file diwakili oleh blob. blob menyimpan data file tetapi tidak berisi metadata apa pun tentang file tersebut. Ini adalah file biner, dan dalam database Git, ia dinamai sebagai hash SHA1 dari file itu. Di Git, file tidak dialamatkan dengan nama. Semuanya ditujukan pada alamat konten.

Trees
Tree adalah objek, yang merepresentasikan direktori. Ini menampung blob serta sub-direktori lainnya. Tree adalah file biner yang menyimpan referensi ke blob dan tree yang juga disebut sebagai hash SHA1 dari objek tree. Commits
Commit mencatat status repositori saat ini. Komit juga dinamai dengan hash SHA1. kita dapat mempertimbangkan objek komit sebagai simpul dari daftar tertaut. Setiap objek yang commit memiliki pointer ke objek commit induk. Dari komit yang diberikan, kita dapat mengembalikan ke sesi sebelumnya dengan melihat pointer induk untuk melihat riwayat komit. Jika komit memiliki beberapa komit induk, maka komit tersebut telah dibuat dengan menggabungkan dua branch.

Branch
Branch digunakan untuk membuat jalur pengembangan lain. Secara default, Git memiliki Branch master, yang sama dengan trunk di Subversion. Biasanya, branch dibuat untuk bekerja pada fitur baru. Setelah fitur selesai, itu digabung kembali dengan cabang master dan kita menghapus branch tersebut. Setiap branch direferensikan oleh HEAD, yang menunjuk ke komit terbaru di branch. Setiap kali kitamembuat komit, HEAD diperbarui dengan komit terbaru.

Tag
Tag memberikan nama yang bermakna dengan versi spesifik di repositori. Tag sangat mirip dengan branch, tetapi perbedaannya adalah tag tidak dapat diubah. Artinya, tag adalah branch, yang tidak akan diubah oleh siapa pun. Setelah tag dibuat untuk komit tertentu, bahkan jika kita membuat komit baru, itu tidak akan diperbarui. Biasanya, pengembang membuat tag untuk rilis produk. Clone
Operasi Clone menciptakan instance repositori. Operasi Clone tidak hanya memeriksa copy pekerjaan, tetapi juga mencerminkan repositori lengkap. Pengguna dapat melakukan banyak operasi dengan repositori lokal ini.

Pull (Tarik)
Operasi Pull menyalin perubahan dari instance repositori di server ke lokal. Operasi Pull digunakan untuk sinkronisasi antara dua instance repositori. Ini sama dengan operasi pembaruan di Subversion.

Push (Dorong)
Operasi Push menyalin perubahan dari instance repositori lokal ke yang jauh. Ini digunakan untuk menyimpan perubahan secara permanen ke dalam repositori Git. Ini sama dengan operasi komit di Subversion.

HEAD
HEAD adalah pointer, yang selalu menunjuk ke komit terbaru di branch. Setiap kali kita membuat komit, HEAD diperbarui dengan komit terbaru.

Revision/Revisi
Revision mewakili versi kode sumber. Revision di Git diwakili oleh komit. Komit ini diidentifikasi oleh pengamanan hash SHA1.

URL
URL mewakili lokasi repositori Git. URL Git disimpan dalam file konfigurasi.

Lebih lengkap lagi di Part 2 berikut ini