Halo kawan, saya tidak habis pikir dengan cara development secara team untuk project yang besar. Bayangkan jika kita harus copy-paste source code – bayangkan untuk mencari dari ribuan baris apa yang saya ubah dan apa yang orang lain ubah dalam file yang sama. Dan bagaimana saya menjadikan perubahan dari semua orang tersebut menjadi satu ?
Beberapa orang tetap senang dengan konsep ini, dia garap sendiri sampai project tasknya jalan dengan baik di laptop nya – lalu saat ingin dijadikan satu dengan project yang digarap team menjadi kacau dan bingung bagaimana menggabungkan project tersebut agar source code tersebut berjalan normal kembali. Atau bahasa enaknya kerjaan saya udah ok dan jalan dengan baik di local laptop saya, saat mau di gabung dengan kerjaan temen itu menjadi problem dan problem itu bukan menjadi tanggung jawab saya – konsep ini bukan team work kawan – karena team work akan bekerja dan menjadi satu saat ada masalah. Terutama masalah soal penggabungan source code yang ditulis bersama. Jadi dalam tulisan kali ini, kita akan bahas GIT yang menjadi tools untuk team work developtment. GIT menjadi momok bagi sebagian orang karena dianggap sebagai kerjaan tambahan – Sebagai tools yang gak berguna.
VCS – Version Control System
Version Control System (VCS) adalah perangkat lunak yang membantu developer untuk bekerja sama dan menjaga history perubahan. Tehnology ini yang pertama kali dipakai oleh programer untuk berkolaborasi dalam mengembangkan software.
Ini adalah tools pertama yang menjembatani masalah versioning di team development. beberapa fungsi dari VCS :
- Memungkinkan pengembang untuk bekerja secara bersamaan.
- VCS Tidak memungkinkan adanya perubahan secara bersama. Yang terbaru yang akan dipakai.
- Mempertahankan history dari setiap versi.
Berikut ini adalah jenis VCS:
- sistem kontrol versi terpusat (CVCS).
- Didistribusikan / Desentralisasi sistem kontrol versi (DVCS).
Dalam bab ini, kita akan berkonsentrasi hanya pada sistem kontrol versi didistribusikan dan terutama pada Git. Git berada di bawah sistem kontrol versi terdistribusi.
Distributed Sistem Kontrol Versi
sistem kontrol versi terpusat (CVCS) menggunakan server pusat untuk menyimpan semua file dan memungkinkan kolaborasi tim. Tapi kelemahan utama dari CVCS adalah titik tunggal kegagalan, yaitu, kegagalan server pusat.Sayangnya, jika server pusat turun down selama satu jam, kemudian pada jam itu, tidak ada yang bisa berkolaborasi sama sekali. Dan bahkan dalam kasus terburuk, jika disk server pusat akan rusak dan file backup belum ada yang berbaru, maka Anda akan kehilangan seluruh hitory perubahan pada proyek. Di sini, sistem terdistribusi kontrol versi (DVCS) datang untuk perbaikan ini.
DVCS klien tidak hanya memeriksa snapshot terbaru dari direktori tetapi mereka juga penuh dari repositori tersebut. Jika server down, maka repositori dari klien dapat disalin kembali ke server untuk mengembalikannya. Setiap checkout adalah salinan lengkap dari repositori. Git tidak bergantung pada server pusat dan itulah sebabnya Anda dapat melakukan banyak operasi ketika Anda sedang offline. Anda dapat melakukan perubahan, membuat branch, lihat log, dan melakukan operasi lain ketika Anda sedang offline. Anda memerlukan koneksi jaringan hanya untuk mempublikasikan perubahan dan mengambil perubahan terbaru.
Keuntungan dari Git
free dan open source
Git dirilis di bawah lisensi open source GPL ini. Anda dapat menggunakan Git untuk mengelola proyek properti tanpa membayar satu sen dolar. Karena merupakan open source, Anda dapat men-download source code dan juga melakukan perubahan sesuai dengan kebutuhan Anda.
Cepat dan kecil
Karena sebagian besar operasi dilakukan secara lokal, memberikan manfaat yang sangat besar dalam hal kecepatan. Git tidak bergantung pada server pusat; itu sebabnya, tidak ada kebutuhan untuk berinteraksi dengan server remote untuk setiap operasi. Bagian inti dari Git ditulis dalam C, yang menghindari overhead runtime yang terkait dengan bahasa tingkat tinggi lainnya. Meskipun Git klien merupakan cermin seluruh repositori, ukuran data di sisi client kecil. Ini menggambarkan efisiensi Git saat mengompresi dan menyimpan data di sisi client.
Backup implisit
Kemungkinan kehilangan data sangat jarang ketika ada beberapa salinan dari itu.Data hadir di setiap sisi klien, karena itu dapat digunakan dalam hal terjadi kerusakan atau korupsi disk.
Keamanan
Git menggunakan fungsi hash kriptografi umum yang disebut fungsi hash aman (SHA1), untuk nama dan mengidentifikasi objek dalam database. Setiap file dan commit check-dijumlahkan dan diambil oleh checksum-nya pada saat checkout. Ini menyiratkan bahwa, tidak mungkin untuk mengubah file, tanggal, dan pesan komit dan data lainnya dari database Git tanpa mengetahui melalui Git.
Tidak perlu server yang uhuiii
Dalam kasus CVCS, server pusat harus cukup kuat untuk melayani permintaan dari seluruh tim. Untuk tim yang lebih kecil, itu tidak masalah, tetapi sebagai ukuran tim tumbuh, keterbatasan hardware server dapat menjadi hambatan kinerja.Dalam kasus DVCS, pengembang tidak berinteraksi dengan server kecuali mereka butuhkan untuk mendorong atau menarik perubahan. Semua angkat berat terjadi pada sisi klien, sehingga hardware server bisa dengan spek yang cupuuu :P.
Membuat branch gampang bro …
CVCS menggunakan mekanisme copy murah, Jika kita membuat cabang baru, itu akan menyalin semua kode ke cabang baru, sehingga memakan waktu dan tidak efisien. Juga, penghapusan dan penggabungan cabang di CVCS rumit dan memakan waktu. Tapi manajemen branch dengan Git sangat sederhana. Dibutuhkan hanya beberapa detik untuk membuat, menghapus, dan menggabungkan branch.
DVCS Terminologi
Repository lokal
Setiap alat VCS menyediakan copy temporary file. Saat developer melakukan perubahan di laptop pribadi mereka dan setelah perubahan ok, dan di commit maka akan menjadi bagian dari repositori. Git mengambil satu langkah lebih lanjut dengan memberikan mereka salinan pribadi dari seluruh repositori. Developer dapat melakukan banyak operasi dengan repositori ini seperti file add, menghapus file yang, mengubah nama file, memindahkan file, melakukan perubahan, dan banyak lagi.
Direktori kerja dan Staging Area atau Indeks
Direktori kerja adalah tempat di mana file repository diperiksa. Berbeda dengan CVCS, pengembang biasanya melakukan modifikasi dan melakukan perubahan secara langsung ke repositori. Tapi Git menggunakan strategi yang berbeda. Git tidak melacak setiap file yang diubah. Setiap kali Anda melakukan perubahan, Git mencari file yang ada di area stage. Hanya file yang ada di area stage dipertimbangkan untuk di tandai dan tidak semua file yang dimodifikasi.
Mari kita lihat alur kerja dasar Git.
Langkah 1 : Anda memodifikasi file dari direktori lokal.
Langkah 2 : Anda menambahkan file ke area stage.
Langkah 3 : Anda melakukan operasi komit yang bergerak dari area stage. Setelah anda push, maka perubahan permanen tersimpan di repositori Git server.
Misalkan Anda mengubah dua file, yaitu “sort.js” dan “search.js” dan Anda ingin dua file tersebut di commit dengan history perubahan yang berbeda. Anda dapat menambahkan satu file di area stage lalu di commit. Setelah anda commit, ulangi prosedur yang sama untuk file kedua.
# Commit Pertama
[bash]$ git add sort.js
# adds file to the staging area
[bash]$ git commit –m “Penjelasan perubahan”
# Second commit
[bash]$ git add search.js
# adds file to the staging area
[bash]$ git commit –m “penjelasan perubahan pada sarch.js”
Blobs
Blob singkatan Binary Large Object. Setiap versi dari file diwakili oleh blob. Sebuah blob memegang file data tetapi tidak berisi metadata tentang file. Ini adalah file biner dalam database Git, hal ini dinamakan sebagai SHA1 hash dari file itu. Dalam Git, file tidak ditangani oleh nama. Semua konten-ditangani.
Trees
Trees adalah obyek, yang mewakili sebuah direktori. Trees Ini memegang blob serta sub-direktori lain. Sebuah trees adalah file biner yang menyimpan referensi ke blob yang juga dinamakan sebagai SHA1 hash dari objek trees.
Commit
Setiap komit objek memiliki pointer ke parrent commit objek. Mudahnya saat anda commit git, maka anda meng-ok kan perubahan di client. Anda dapat melihat keseluruhan commit di local anda sebelum di push. Setelah di push maka history commit akan ada di client dan server.
Branch
Branch digunakan untuk membuat cabang lain development. Secara default, Git memiliki cabang master, yang sama dengan bagasi di Subversion. Biasanya, sebuah cabang dibuat untuk bekerja pada fitur baru. Setelah fitur selesai, itu bergabung kembali dengan cabang master dan kita menghapus cabang. Setiap cabang direferensikan oleh HEAD, yang menunjuk ke commit terbaru dalam cabang.Setiap kali Anda membuat komit, HEAD diperbarui dengan terbaru komit.
Tags
Tag memberikan nama yang bermakna dengan versi tertentu dalam repositori.Tag sangat mirip dengan cabang, tetapi perbedaannya adalah bahwa tag yang berubah. Artinya, tag adalah cabang, yang tak seorang pun berniat untuk memodifikasi. Setelah tag yang dibuat untuk komit tertentu, bahkan jika Anda membuat komitmen baru, itu tidak akan diperbarui. Biasanya, pengembang membuat tag untuk rilis produk.
Clone
Operasi clone diginakan untuk mengambil keseluruhan dari server git. operasi clone tidak hanya mengcopy pekerjaan, tetapi juga mencerminkan kondisi di repositori.Pengguna dapat melakukan banyak operasi dengan repositori lokal ini.
Pull
Pull digunakan untuk menyalin perubahan dari repositori remote ke lokal. Operasi pull digunakan untuk sinkronisasi antara dua contoh repositori. Ini sama dengan update di Subversion – update client dari server.
Push
Push digunakan untuk mengirimkan perubahan di lokal ke repository remote. Ini digunakan untuk menyimpan perubahan permanen ke dalam repositori Git.
Head
Head adalah pointer, yang selalu menunjuk ke commit terbaru dalam cabang. Setiap kali Anda membuat komit, Head diperbarui dengan commit terbaru. Head branch disimpan dalam folder git / ref / head /.
Revisi
Revisi merupakan versi dari kode sumber. Revisi Git diwakili oleh commit. commit ini diidentifikasi oleh SHA1 hash.
Disini dulu kawan, tulisan berikutnya akan dijelaskan mengenai Installasi dan penggunaan git. Sampai ketemu di tulisan berikutnya 🙂