- Kamis, 10 April 2014

Mengenal GIT

Sejarah Singkat Git
Seperti hal besar lainnya, Git dimulai dengan beberapa permasalahan dan kontroversi. Kernel Linux merupakan sebuah proyek perangkat lunak open source yang berskala cukup besar. Dalam pengelolaan perubahannya pada tahun 2002 menggunakan sistem DVCS propietary yang dikenal BitKeeper. Pada tahun 2005, hubungan antara komunitas yang mengembangkan kerlen Linux dengan perusahaan komersil yang mengembangkan BitKeeper retak dan lisensi gratisnya dicabut. 

Permasalahan yang dihadapi komunitas pengembang linux ini (terlebih Linus Torvalds, pembuat Linux) kemudian menuntut mereka untuk mengembangkan tool semacam BitKeeper  sendiri dengan berbekal pengalaman selama menggunakan BitKeeper. Tool yang dikembangkan haruslah mencakup:
  • Kecepatan
  • Desain yang sederhana
  • Dukungan penuh untuk pengembangan non-linear (ribuan cabang paralel)
  • Terdistribusi secara penuh
  • Mampu menangani proyek besar seperti Kernel Linux secara efisien (dalam kecepatan dan ukuran data)
Sejak kelahirannya pada tahun 2005, Git telah berkembang dan semakin mudah digunakan serta hingga saat ini masih mempertahankan kualitasnya tersebut. Git luar biasa cepat, sangat efisien dalam proyek besar, dan memiliki sistem pencabangan yang luar biasa untuk pengembangan non-linear.

Dasar Git
A. Snapshots, Not Differences
Agar dapat menggunakan Git secara mudah dan efektif maka Anda harus memahami Git itu sendiri. Git sangat berbeda dengan VCS lain yang mungkin telah Anda kenal sebelumnya, misalnya Subversion dan Perforce. Git sangat berbeda dengan sistem-sistem tersebut dalam hal menyimpan dan meperlakukan informasi yang digunakan, walaupun UI nya hampir mirip.


Salah satu perbedaan mencolok anatar Git dengan VCS lain (Suberversion,dll) adalah dalam cara Git memperlakukan datanya. Secara konseptual, kebanyakan sistem lain menyimpan informasi sebagai sebuah daftar perubahan file. Sistem seperti ini (CVS, Subversion, Bazaar, dll) memperlakukan informasi yang disimpannya sebagai sekumpulan file beserta perubahannya sebagaimana gambar berikut :




Git tidak berkerja seperti ini, Melainkan, Git memperlakukan datanya sebagai sebuah kumpulan snapshot dari sebuah miniatur sistem berkas. Setiap kali Anda melakukan commit atau update pada proyek Git, pada dasarya Git merekan gambaran keadaan file-file Anda pasa saat itu dan menyimpan referensi untuk gambaran tersebut. Agar efisien, jika file tidak mengalami perubahan, Git tidak akan menyimpan file tersebut - hanya menghubungkan dengan file yang identik sebelumnya yang telah tersimpan. Cara kerja Git dalam mengelola datanya sbb:

Ini adalah sebuah perbedaan penting antara Git dengan hampir semua VCS lain. Hal ini membuat Git.

Nearly Every Operation Is Local
Kebanyakan operasi pada Git hanya membutuhkan file-file dan resource lokal, tidak ada informasi yang dibutuhkan dari komputer lain pada jaringan Anda. Jika Anda terbiasan dengan VCS terpusat, dimana kebanyakan operasi memiliki overhead latensi jaringan, aspek Git yang satu ini akan membuat Anda berpikir bahwa Git adalah pilihan yang tepat. Dengan Git, Anda memiliki seluruh histori dari proyek pada lokal disk Anda, dengan seluruh operasinya.

Sebagi contoh, untuk melihat histori dari proyek, Git tidak membutuhkan data histori dari server untuk kemudian menampilkannya, namun secara sederhana Git membaca historinya langsung dari basis data lokal proyek tersebut. Ini membuat Anda dapat melihat hostori secara instan dan kapan saja. Jika Anda ingin membandingkan perubahan pada sebuah file antara versi saat ini dengan sebulan yang lalu, Git akan mencari file yang sama pada sebulan lalu dan melakukan perbandingan perubahan secara lokal, bukan dengan cara remote server melakukannya atau meminta server mengirimkan file yang lebih lama kemudian membandingkannya secara lokal.

Hal ini berarti Anda dapat melakukan apa saja meskipun dalam keadaan offline atau berada diluar VPN. Jika Anda sedang berada dalam pesawat terbang atau sebuah kereta dan ingin melakukan pekerjaan kecil, Anda dapat melakukan commit sampai Anda memperoleh koneksi internet hingga anda dapat menguploadnya. Jika Anda pulang ke rumah dan VPN klien Anda tidak bekerja dengan benar, Anda tetap dapat bekerja. Pada kebanyakan sistem lainnya, melakukan hal ini cukup sulit atau bahkan tidak mungkin sama sekali. Pada Perforce misalnya, anda tidak dapat berbuat banyak ketika anda tidak terhubung dengan server; pada Subversion dan CVS, anda dapat mengubah berkas, tapi anda tidak dapat melakukan commit pada basisdata anda (karena anda tidak terhubung dengan basisdata). Hal ini mungkin saja bukanlah masalah yang besar, namun anda akan terkejut dengan perbedaan besar yang disebabkannya.

Git Has Integrity
Segala sesuatu yang terjadi pada Git akan melalui proses checksum terlebih dahulu sebelum disimpan yang kemudian direfrensikan oleh hasil checksum tersebut. Hal ini berarti tidak mungkin melakukan perubahan terhadap file manampun tanpa diketahui oleh Git. Fungsionalitas ini dimiliki Git. Jadi Anda tidak akan kehilangan informasi atau mendapatkan file yang cacat tanpa diketahui oleh Git.

Mekanisme checksum yang digunakan oleh Git adalah hash SHA-1. Ini merupakan sebuah susunan string yang terdiri dari 40 karakter heksadesimal (0 hingga 9 dan a hingga f) dan dihitung berdasarkan isi dari sebuah berkas atau struktur direktori pada Git. Sebuah hash SHA-a berupa seperti berikut :

24b9da6552252987aa493b52f8696cd6d3b00373

Anda akan melihat nilai seperti ini pada berbagai tempat di Git. Faktanya, Git tidak menyimpan nama berkas pada basisdatanya, melainkan nilai hash dari isi berkas.

Git Generally Only Adds Data
Ketika Anda melakukan operasi pada Git, kebanyakan dari operasi tersebut hanya menambahkan data pada basisdata Git. Ini sangat sulit untuk memaksa sistem melakukan sesuatu yang tidak dapat dikembalikan (undo) atau menghapusnya. Seperti pada berbagai CVS, Anda dapat kehilangan atau mengacaukan perubahan yang belum di commit, namun jika Anda melakukan commit pada Git, akan sangat sulit kehilangannya, terutama jika Anda secara teratur melakukan PUSH basisdata Anda pada repositori lain.

The Three States
Sekarang perhatikan. Ini adalah hal utama yang harus diingat tentang Git jika anda ingin proses belajar anda berjalan lancar. Git memiliki 3 keadaan utama dimana berkas anda dapat berada: committed, modified dan staged. Committed berarti data telah tersimpan secara aman pada basisdata lokal. Modified berarti anda telah melakukan perubahan pada berkas namun anda belum melakukan commit pada basisdata. Staged berarti anda telah menandai berkas yang telah diubah pada versi yang sedang berlangsung untuk kemudian dilakukan commit.

Git Directory adalah dimana Git menyimpan metadata dan database objek untuk projek Anda. Ini adalah bagian terpenting dari Git, dan inilah yang disalin ketika anda melakukan clone sebuah repository dari komputer lain.

Working Directory adalah sebuah checkout tunggal dari satu versi dari projek. File-file ini kemudian ditarik keluar dari basisdata yang terkompresi dalam direktori Git dan disimpan pada disk untuk anda gunakan atau modifikasi.

Staging Area adalah sebuah berkas sederhana, umumnya berada dalam direktori Git Anda, yang menyimpan informasi mengenai apa yang dijadikan commit selanjutnya. Ini terkadang disebut sebagai index, tetapi semakin menjadi standard untuk menyebutnya sebagai staging area.

Alur kerja dasar Git adalah seperti ini:

  1. Anda mengubah file dalam direktori kerja anda.
  2. Anda membawa file ke stage, menambahkan snapshotnya ke staging area.
  3. Anda melakukan commit, pada file yang berada di staging area dan menyimpan snapshotnya secara permanen ke direktori Git anda.

Jika versi tertentu dari sebuah file telah ada di direktori git, ia dianggap 'committed'. Jika berkas diubah (modified) tetapi sudah ditambahkan ke staging area, maka itu adalah 'staged'. Dan jika berkas telah diubah sejak terakhir dilakukan checked out tetapi belum ditambahkan ke staging area maka itu adalah 'modified'.

Tidak ada komentar:

Posting Komentar