Git adalah salahsatu version-control system yang berguna untuk melakukan versioning terhadap suatu berkas. Git bukan satu-satunya tools yang ada untuk melakukan "versioning", ada alternatif lain seperti subversion dan mercurial misalnya. Namun, git lebih populer dan lebih banyak digunakan oleh kalangan developers—khususnya developer baru—karena salah dua alasannya adalah "interface" nya yang sederhana dan mudah digunakan.

Dan ya, salah satu project yang sangat popular (yakni Kernel) menggunakan git dalam proses development nya.

Tell me git like I'm taking skripsi

Git adalah "version-control system", yang artinya git berguna untuk mengatur "revisi" pada suatu berkas.

Ada yang familiar dengan kasus ini?

Iya, revisi. Git membuat melakukan revisi lebih mudah dan rapih. Pada dasarnya kita melakukan revisi dengan cara "copy berkas asli ke berkas baru berdasarkan berkas terakhir", jadi bila suatu saat kita ingin "kembali" ke versi–misalnya sebelum revisi ke 3–kita bisa dengan mudah menggunakan revisi tersebut.

Mengapa menggunakan Version-control system?

Pertama, kita bukan sedang membuat skripsi ataupun proposal. Melainkan sebuah software. Kita bisa saja menggunakan versioning "cara lama" dengan menjadikannya artifak–entah berkas zip, iso, ataupun docker images–dan melakukan tagging yang merepresentasikan versi yang dimaksud, misal: my_software_v1.0.0.zip.

Tapi itu tidak efektif.

Kenapa? Singkatnya, susah di track.

Kedua, kita membuat sesuatu dan berjalan disisi orang lain. Beda dengan skripsi (umumnya berkas dokumen) yang secara teknis tidak memiliki runtime. Kita tidak bisa memprediksi hadirnya bug terhadap software yang kita buat, terlebih bug yang fatal. Tapi kita bisa menyelesaikan masalah tersebut dengan melakukan rollback ke versi yang sebelumnya stabil.

Misal, bila versi v1.2.0 adalah versi stabil dan di versi v1.3.0 terdapat bug yang fatal dan mengganggu, yang mana butuh waktu yang tidak sebentar untuk menyelesaikan bug tersebut, kita bisa melakukan rollback ke versi sebelumnya (v1.2.0) sehingga user bisa menggunakan software kita dengan stabil.

Ketiga, untuk kolaborasi. Bagaimana cara untuk bisa bekerja bersama-sama tanpa khawatir akan terjadi konflik? Meskipun menggunakan VCS pun bukan berarti akan bebas dari konflik, namun dengan menggunakannya kita membuat proses konflik tersebut menjadi sulit terjadi.

Keempat, sudah menjadi standar industri bila kamu membuat sebuah software. Setiap orang yang membuat software, pasti & memang harus menggunakan VCS. Jika kamu tidak menggunakan VCS, kamu tidak mengikuti standar industri.

And you can thank me later because discovering this post.

Saya tidak akan membahas git secara fundamental, melainkan secara praktikal (praktis) dan hanya akan membahas yang sering digunakan saja, the main surface. Untuk penggunaan git yang lebih kompleks, kamu bisa baca-baca di dokumentasi resminya langsung disini.

Memulai

Kamu harus memiliki program git terlebih dahulu, jika kamu menggunakan linux/mac os biasanya sudah ter-install. Jika belum, silahkan install program tersebut. Pelajari disini.

Lalu kamu harus memiliki project yang ingin menggunakan VCS, anggap project tersebut adalah skripsi.

git init

Maka kita bisa mengeksekusi git init untuk memberitahu git bahwa project tersebut kita ingin menggunakan git untuk VCS.

git status

Project skripsi kita sekarang sudah menggunakan git untuk melakukan versioning. Kita tidak akan langsung bahas master terlebih dahulu. Sekarang mari kita buat file skripsi kita dengan minimal konten.

Sekarang indikator master menjadi merah. Apa maksudnya?

Artinya, terdapat perubahan yang terjadi yang belum di track oleh git. Kamu bisa menggunakan perintah git status untuk mengetahui perubahan apa yang ada di project tersebut.

Disitu dijelaskan bahwa ada berkas yang belum di track oleh git bernama skripsi. Sebelum berjalan lebih jauh, kita akan bahas terlebih dahulu tentang branch.

branch

Setiap project yang menggunakan git, by default akan memiliki 1 branch yang bernama master. Branch ini bisa dianggap sebagai branch utama, branch yang paling valid, branch yang menjadi acuan bila ingin membuat "revisi" terhadap project kita.

Ingat gambar desktop diatas? Branch master bisa dianggap sebagai file project_a.zip. Kamu bisa membuat sebanyak-banyaknya branch di project kamu yang mengacu ke berbagai branch, tapi disini kita akan fokus di 2 branch saja terlebih dahulu agar lebih mudah.

working & staging area

Dalam workflow git, ada 3 area:

  1. Working directory area, project yang ada di mesinmu (local)
  2. Stage area, project yang sudah di track oleh git
  3. Repository area, project yang ada di git repository (remote).

Sederhananya, staging area adalah area yang berada diantara lokal dan remote, yang mana berisi perubahan terhadap berkas-berkas yang sudah di track oleh git.

git add

Dari contoh git status diatas, ada berkas yang belum di track oleh git, yakni file skripsi.txt. Git mengetahui itu karena file tersebut belum ada di staging area, area yang ditrack oleh git. Untuk memasukkan file tersebut ke staging area, sesuai perintah yang ada: gunakan perintah git add <file>.

Sekarang file skripsi.txt sudah ada di staging area, namun belum di record oleh kita. Analoginya, kamu sudah memesan makanan (memilih menu, dsb) namun belum memberitahu pesanan kamu ke waiter.

git commit

Untuk me-record nya, kita bisa gunakan perintah git commit dan mulai menulis "pesan" commit yang terkait dengan perubahan tersebut.

Silahkan eksekusi perintah tersebut, nanti git akan membuka editor bawaan untuk menulis pesan commit.

Dari gambar diatas, kita membuat perubahan tersebut dengan pesan "versi pertama file skripsi", dan juga diberikan data terhadap perubahan yang terjadi (1 file, 4 (baris) penambahan).

Sekarang file tersebut sudah di stage area, dan git akan me-record setiap perubahan yang terjadi terhadap file tersebut. Mari kita coba lakukan perubahan terhadap file tersebut.

git diff

Ternyata ada typo di file skripsi.txt setelah dosen nanya maksud "Tentangga" di bagian "Tentangga git". Yang sebenarnya maksud kita adalah "Tentang Git". Mari kita ubah file tersebut, lalu simpan.

Untuk melihat perubahan yang terjadi pada file tersebut, kita bisa gunakan perintah git diff <file>, maka git akan memberitau perubahan mana saja yang terjadi.

Kita anggap perubahan ini sudah ok. Sekarang kita bisa ulang workflow git add & git commit kita. Karena saya malas–dan biasanya semua programmer malas–kita bisa persingkat flow tersebut dengan langsung ke git commit dengan parameter -a.

Dan ya, karena malas juga harus buka editor, kita bisa membawa parameter -m dilanjutkan dengan pesan commit.

Dan lagi-lagi git memberitahu kita tentang perubahan apa yang terjadi, yang pada kasus kita adalah:

  • 1 file
  • Penambahan di 1 baris: Tentantangga menjadi Tentang
  • Penghapusan di 1 baris: Tentangga menjadi Tentang

Setiap perubahan akan dianggap sebagai "insertion" kecuali perubahan tersebut  murni menghapus baris, maka tidak akan dianggap sebagai "insertion" juga.

Revisi lagi!

Kata dosen, kata-kata yang menggunakan bahasa inggris harus dibuat italic. Oke deh kita ubah yuk.

Dosen belum bales, sedangkan kita harus menulis bab 2 misalnya. Meskipun belum dikoreksi, kita harus tetap melanjutkan menulis bab 2 tanpa harus menunggu dosen mengoreksi perubahan kita.

git branch

Lalu kita menulis BAB 2, isinya seperti ini (lihat yang ada indikator + nya):

Terus ada pesan dari dosen bahwa katanya kata-kata yang menyangkut brand harus di kapital.

Sedangkan, kita sedang menulis bab 2!

Nah untuk membuat perubahan lebih rapih, kita buat branch baru untuk bab 2 ini. Karena "revisi" yang diberikan oleh dosen berdasarkan perubahan sebelumnya yang sudah di commit (c18bff8), bukan perubahan sekarang (yang belum di commit).

Kita bisa membuat branch baru dengan perintah git branch <nama_branch>, yang dalam kasus ini berarti namanya bab-2 misalnya.

Kita bisa melihat branch yang tersedia dengan perintah git branch, atau bisa membawa parameter -a untuk menghindari ambiguitas -a berarti "all".

git checkout

Untuk pindah branch, kita bisa gunakan perintah git branch <nama_branch> alias dalam kasus ini adalah git branch bab-2. Setelah itu kita akan melihat konten-konten yang "sumber" nya adalah dari branch master.

Mari kita lakukan commit terhadap perubahan tersebut dengan pesan "mulai bab 2".

Sekarang kita balik lagi ke branch master dan kita fix revisi yang didapat dari dosen tersebut.

Yap, perubahan terhadap BAB 2 kita tidak ada! Sekarang kita commit perubahan tersebut dengan pesan "kapitalisasi kata terhadap brand".

git merge

Dosen udah ok, sekarang kita terapkan perubahan kita (yang ada di branch bab-2) ke branch utama (master). Caranya, kita bisa melakukan "merging" dengan perintah git merge <nama_branch_yang_ingin_di_merge> dalam kasus ini berarti git merge bab-2.

Nantinya kamu akan diberikan layar seperti ini, kita harus membuat pesan commit kenapa kita harus melakukan merge ke branch tersebut.

Karena branch tersebut berdasarkan branch master yang mengarah ke commit c18bff8, sedangkan branch master sekarang mengarah ke commit 205d2ab, jadi kita harus melakukan commit sehingga kita bisa mulai melanjutkan pekerjaan kita.

Kita ambil contoh pesan commit nya adalah "melanjutkan BAB 2".

git log

Sejauh ini kita sudah menggunakan git secara "normal", mari kita evaluasi apa yang sudah kita lakukan. Kita bisa menggunakan git log untuk itu.

Agar tidak terlalu ter-distract dengan banyaknya informasi dan agar lebih jelas "alurnya" seperti apa, kita akan menggunakan parameter --oneline dan --graph.

Itu adalah "history" dari perubahan yang terjadi terhadap project kita. Tentu melakukan "commit" di branch baru terhadap suatu pekerjaan yang statusnya masih "Work In Progress" membuat history kita kurang rapih (See that b8808db and f994212).

git stash

Untuk membuatnya lebih rapih, daripada kita:

  1. membuat branch baru
  2. commit perubahan
  3. pindah ke branch utama
  4. commit perubahan di branch utama
  5. merge branch baru ke branch utama

Kita akan menggunakan perintah yang khusus untuk meng-handle ini: git stash. Sekarang mari kita buat kasusnya, kita sedang melanjutkan bab 3, sedangkan dosen tiba-tiba memberikan revisi terhadap bab 2: Yaa nya kurang banyak a nya, tambah 3 huruf lagi.

Daripada mengulang cara sebelumnya (yang membuat history kurang rapih), mending kita menggunakan stash.

Pada dasarnya git stash adalah untuk "nge-track" perubahan kita, namun hanya sementara. Alias, tidak masuk ke stage area. Sebenarnya hampir sama dengan cara yang kita gunakan sebelumnya, bedanya, kita tidak melakukan commit terhadap perubahan tersebut–yang menyebabkan tersimpannya perubahan ke stage area.

Untuk mulai melakukan git stash, kita bisa eksekusi perintah tersebut dan nanti perubahan tersebut akan di "hilangkan" sehingga perubahan sebelumnya yang belum kita commit hilang.

Well, enggak hilang. Tapi disimpan di entah dimana itu yang penting bukan di stage area.

Lalu kita fix revisi dari dosen tersebut dan commit perubahan tersebut.

Nah kita ingin lanjut bab 3 nih, kita bisa balik lagi ke "melanjutkan bab 3" tersebut dengan melakukan git stash pop. Jika kamu masih ingin menyimpan "WIP" tersebut, kamu bisa menggunakan git stash apply maka stash untuk WIP tersebut akan tetap ada disana.

Untuk melihat daftar "WIP" yang ada di stash, kamu bisa gunakan perintah git stash list.

Sekarang kita terapkan perubahan tersebut, dan lihat perubahan apa saja yang terjadi terhadap versi yang paling terbaru.

Sesuai ekspektasi, BAB 3 kita tidak masuk. Sekarang mari kita lihat perubahan terbaru yang belum masuk ke stage area.

Perfect.

Sekarang kita commit perubahan tersebut dengan pesan "versi pertama bab 3".

Tidak ada commit mengganggu seperti yang sebelumnya :))

Sebagai tambahan, agar lebih memberikan konteks terkait WIP, kita bisa menggunakan perintah git stash save "some context" agar lebih jelas.

Misal, bandingkan stash berikut dan lihat mana yang lebih mudah dimengerti.

Yang pada dasarnya sama saja namun lebih jelas memberikan info (draft BAB 3) daripada hanya menampilkan berdasarkan commit terakhir.

Kapan harus pakai branch?

Dari tadi kita bergantung dengan branch master, setiap perubahan selalu terjadi di branch master. Ini bukan "standar" industri, karena setiap perubahan seharusnya berada di branch baru yang mengarah ke suatu branch, dan biasanya, branch master adalah branch yang paling stabil.

Branch yang dipakai di production, software yang digunakan oleh pengguna berdasarkan dari kode-kode yang ada di branch lain.

Artinya, setiap perubahan harus selalu berada di branch baru. Entah itu fix-typo, bab-3, dsb, intinya, perubahan jangan berada di branch master. Selain karena alasan diatas, juga agar mudah untuk berkolaborasi dengan developers lain dalam proses pengembangan.

Anything else?

Kita tidak membahas seputar git push, pull, rebase, bisect, blame, dsb. Yang diharapkan kamu bisa mempelajarinya sendiri.

Khusus untuk pull dan push, kita akan bahas di post kedua setelah ini.

Rangkuman dari tulisan ini, workflow menggunakan git pada dasarnya hanyalah:

  • git add
  • git commit
  • git status

Di skala yang lebih besar, workflow git kamu akan sekompleks ini misalnya

Yang memiliki banyak branch dan developers.

Referensi

  • man git

Ditulisan selanjutnya kita akan membahas seputar "menulis pesan commit". Perjalanan masih panjang, duduk yang nyaman dan ambil popcorn kalian!