Bekerja Dengan Git

Bagian 1: Konsep Fundamental Git (The "Why")

Sebelum kita menyentuh perintah-perintahnya, sangat penting untuk memahami mengapa Git ada dan bagaimana cara kerjanya.

Apa itu Version Control System (VCS)?

Bayangkan Anda sedang menulis skripsi. Anda menyimpan file sebagai skripsi_v1.doc, skripsi_v2_final.doc, skripsi_final_banget.doc. Ini adalah sistem kontrol versi manual yang sangat berantakan.

Version Control System (VCS) adalah sistem yang merekam perubahan pada sebuah file atau set file dari waktu ke waktu sehingga Anda dapat kembali ke versi tertentu di masa depan.

Kenapa Git Spesial?

Git adalah Distributed Version Control System (DVCS). Artinya, setiap developer tidak hanya memiliki salinan file kerja, tetapi juga memiliki salinan seluruh riwayat (history) proyek di komputernya. Jika server utama rusak, repositori dari developer manapun dapat digunakan untuk memulihkannya.

Tiga Area Kerja Git

Ini adalah konsep paling fundamental. Setiap file di dalam proyek Anda berada di salah satu dari tiga keadaan ini:

Working Directory: Folder proyek Anda di komputer. File di sini bisa dalam keadaan modified (sudah diubah) tetapi belum disimpan ke dalam database Git.
Staging Area (Index): Ini seperti area "draf" atau "antrean". Anda memilih perubahan mana dari Working Directory yang ingin Anda simpan dalam commit berikutnya. Ini memungkinkan Anda untuk merapikan commit hanya dengan perubahan yang relevan.
Repository (.git directory): Di sinilah Git menyimpan seluruh riwayat perubahan proyek Anda secara permanen. Setelah Anda melakukan commit, snapshot dari Staging Area akan disimpan di sini.

Analogi Sederhana: Bayangkan Anda seorang koki yang sedang menyiapkan masakan (proyek).

Working Directory adalah semua bahan mentah di dapur Anda. Anda bisa memotong-motong (mengubah file).
Staging Area adalah piring saji. Anda memilih bahan-bahan yang sudah siap (perubahan yang sudah final) dan menatanya di piring tersebut.
Commit adalah saat Anda menyajikan hidangan itu ke pelanggan. Hidangan itu sudah final dan tercatat sebagai satu sajian utuh.

Git untuk Penggunaan Sehari-hari (The Basics)

Ini adalah perintah yang akan Anda gunakan 90% setiap harinya.

Inisialisasi & Kloning

git init: Mengubah direktori saat ini menjadi sebuah repositori Git. (Untuk proyek yang benar-benar baru).
git clone [url]: Membuat salinan repositori yang sudah ada dari sebuah server (seperti GitHub, GitLab) ke komputer lokal Anda.

Siklus Kerja Dasar

Ini adalah siklus yang akan selalu berulang: Modify -> Stage -> Commit.

git status Perintah terpenting. Gunakan ini setiap saat untuk melihat status file Anda (mana yang sudah diubah, mana yang ada di staging, dll).
git add [nama_file] Memindahkan perubahan dari Working Directory ke Staging Area.
- git add .: Menambahkan semua perubahan di direktori saat ini ke Staging Area.
git commit -m "Pesan commit yang jelas" Menyimpan snapshot dari Staging Area ke Repository secara permanen.
- Penting: Pesan commit harus jelas dan deskriptif. Standar umumnya adalah menulis dalam bentuk imperatif, misal: "Add login feature" bukan "Added login feature" atau "Adding login feature".

Melihat Riwayat

git log: Menampilkan seluruh riwayat commit dari yang terbaru.
git log --oneline --graph --decorate: Versi git log yang lebih ringkas dan visual.

Bekerja dengan Remote Repository

git pull: Mengambil perubahan dari repositori remote (server) dan langsung menggabungkannya (merge) ke branch lokal Anda.
git push: Mengirim commit dari repositori lokal Anda ke remote.

Simulasi Dasar:

Anda baru bergabung di sebuah proyek. Mari kita mulai bekerja.

# 1. Ambil proyek dari GitHub
git clone https://github.com/perusahaan/proyek-keren.git

# 2. Masuk ke direktori proyek
cd proyek-keren

# 3. Buat file baru untuk fitur Anda
echo "<html><body><h1>Fitur Baru!</h1></body></html>" > fitur-baru.html

# 4. Cek status repositori
git status
# Output akan menunjukkan 'untracked files: fitur-baru.html'

# 5. Tambahkan file baru ke Staging Area
git add fitur-baru.html

# 6. Cek status lagi
git status
# Output akan menunjukkan 'changes to be committed: new file: fitur-baru.html'

# 7. Simpan perubahan ke riwayat Git
git commit -m "Feat: Add initial file for the new feature"

# 8. Kirim pekerjaan Anda ke server GitHub
# 'origin' adalah nama default untuk remote server Anda
# 'main' adalah nama branch utama
git push origin main

Branching & Merging

Ini adalah inti dari kolaborasi di Git. Branch adalah sebuah "garis waktu" pengembangan yang independen.

Kenapa Branching Penting?

Bayangkan main branch sebagai versi stabil dari aplikasi Anda. Anda tidak ingin mengerjakan fitur baru yang belum selesai langsung di main. Jadi, Anda membuat branch baru bernama fitur-login. Di branch ini, Anda bisa bebas bereksperimen, membuat bug, dan memperbaikinya tanpa mengganggu main branch yang stabil.

Perintah-perintah Branching

git branch: Melihat semua branch yang ada.
git branch [nama-branch]: Membuat branch baru.
git checkout [nama-branch] (atau git switch [nama-branch] di Git versi baru): Berpindah ke branch lain.
git checkout -b [nama-branch]: Membuat branch baru dan langsung berpindah ke branch tersebut (ini yang paling sering dipakai).
git merge [nama-branch]: Menggabungkan riwayat dari [nama-branch] ke branch Anda saat ini.

Simulasi Branching:

Anda ditugaskan membuat fitur login.

# 1. Pastikan Anda berada di branch utama dan sudah update
git checkout main
git pull origin main

# 2. Buat branch baru untuk fitur login
git checkout -b feature/login

# 3. Kerjakan fitur Anda (buat file, edit kode, dll)
echo "Login form" > login.html
git add login.html
git commit -m "Feat: Create login form structure"

# ... Anda melanjutkan pekerjaan dengan beberapa commit lagi ...

# 4. Fitur selesai! Saatnya menggabungkan kembali ke main
# Pertama, kembali ke branch main
git checkout main

# 5. Gabungkan branch fitur Anda
git merge feature/login

# 6. Hapus branch fitur yang sudah tidak terpakai (opsional)
git branch -d feature/login

# 7. Kirim hasil penggabungan ke server
git push origin main

Problem: Merge Conflict!

Ini terjadi ketika dua orang mengubah baris yang sama di file yang sama pada branch yang berbeda. Git tidak tahu versi mana yang benar.

Cara Menanganinya:

Git akan menghentikan proses merge dan memberitahu Anda file mana yang konflik.

Buka file tersebut. Anda akan melihat penanda seperti ini:

<<<<<<< HEAD
Teks dari branch Anda saat ini (misal: main)
=======
Teks dari branch yang ingin digabungkan (misal: feature/login)
>>>>>>> feature/login

Tugas Anda: Hapus penanda <<<<<<<, =======, >>>>>>> dan edit kode untuk memilih versi yang benar, atau gabungkan keduanya secara manual.

Setelah file diperbaiki, simpan, lalu:

git add [file_yang_konflik]
git commit # Tidak perlu pesan, Git sudah menyiapkannya

Proses merge selesai!

Git Tingkat Lanjut (Sering Dipakai di Perusahaan Besar)

Di sinilah perbedaan antara pengguna biasa dan pengguna ahli terlihat. Teknik ini berfokus pada menjaga riwayat commit tetap bersih, mudah dibaca, dan profesional.

1. Interactive Rebase (git rebase -i)

Ini adalah alat super untuk membersihkan riwayat commit sebelum Anda membagikannya ke tim. Bayangkan Anda punya 5 commit untuk satu fitur: "WIP", "fix typo", "add button", "oops another fix", "final". Ini terlihat berantakan. Dengan Interactive Rebase, Anda bisa:

Squash: Menggabungkan beberapa commit menjadi satu commit yang utuh.
Reword: Mengubah pesan commit.
Edit: Mengubah isi dari commit.
Reorder: Mengubah urutan commit.

Simulasi rebase: Riwayat commit di branch feature/profile Anda terlihat seperti ini:

f3A01b: "fix: correct typo in profile title"
a2Bcd3: "WIP"
e4D5f6: "feat: add user profile picture"

Ini berantakan. Mari kita rapikan sebelum digabung ke main.

# 1. Mulai interactive rebase dari 3 commit terakhir
git rebase -i HEAD~3

Editor teks akan terbuka dengan isi seperti ini:

pick e4D5f6 feat: add user profile picture
pick a2Bcd3 WIP
pick f3A01b fix: correct typo in profile title

Untuk menggabungkan semuanya menjadi satu, ubah pick menjadi squash (atau s) untuk commit kedua dan ketiga.

pick e4D5f6 feat: add user profile picture
s a2Bcd3 WIP
s f3A01b fix: correct typo in profile title

Simpan dan tutup editor. Editor lain akan terbuka, meminta Anda menulis pesan commit baru untuk gabungan commit tadi. Tulis pesan yang bagus: "Feat: Implement user profile page with picture".

Hasilnya: Riwayat commit Anda sekarang bersih dan hanya berisi satu commit yang deskriptif.

Aturan Emas Rebase: JANGAN PERNAH me-rebase branch yang sudah di-push dan digunakan oleh orang lain (seperti main atau develop). Rebase mengubah sejarah, dan ini akan menyebabkan kekacauan besar bagi kolaborator Anda. Gunakan hanya pada branch lokal Anda.

2. Cherry-Picking (git cherry-pick)

cherry-pick digunakan untuk mengambil satu commit spesifik dari satu branch dan menerapkannya ke branch lain.

Kasus Penggunaan: Bayangkan ada bug kritis di branch main. Tim A memperbaikinya di branch hotfix-123. Namun, Anda yang sedang mengerjakan feature/long-running-task juga membutuhkan perbaikan bug tersebut sekarang, tanpa harus me-merge seluruh branch hotfix-123.

Simulasi cherry-pick:

# 1. Di branch hotfix-123, temukan hash commit perbaikan bugnya
git log
# Misal hash-nya adalah a1b2c3d

# 2. Pindah ke branch Anda
git checkout feature/long-running-task

# 3. Ambil commit tersebut
git cherry-pick a1b2c3d

# Selesai! Perbaikan bug sekarang ada di branch Anda.

3. Reflog: Jaring Pengaman Anda (git reflog)

Pernahkah Anda tidak sengaja menghapus branch atau me-reset commit dan merasa panik? git reflog adalah penyelamatnya. Git mencatat hampir semua pergerakan yang Anda lakukan (checkout, commit, reset, merge) di sebuah log referensi.

Kasus Penggunaan: Anda tidak sengaja melakukan git reset --hard dan kehilangan 2 commit terakhir.

Cara Menanganinya:

# 1. Tampilkan log referensi
git reflog
# Outputnya akan terlihat seperti ini:
# 7c5f2a1 HEAD@{0}: reset: moving to HEAD~2
# a1b2c3d HEAD@{1}: commit: add new important feature
# d4e5f6g HEAD@{2}: commit: initial setup

# 2. Anda lihat bahwa commit yang hilang adalah a1b2c3d.
# Kembalikan branch Anda ke titik tersebut
git reset --hard a1b2c3d

Voila! Commit Anda yang hilang telah kembali.

4. Bisect: Pencari Bug Otomatis (git bisect)

Jika ada bug di aplikasi dan Anda tidak tahu commit mana yang menyebabkannya, git bisect adalah pahlawannya. Ia menggunakan pencarian biner (binary search) untuk menemukan commit "jahat" tersebut dengan sangat cepat.

Cara Kerjanya:

Anda memberitahu Git sebuah commit "baik" (dimana bug belum ada) dan sebuah commit "buruk" (dimana bug sudah ada).
Git akan otomatis memindahkan Anda ke commit di tengah-tengah.
Anda tes aplikasinya. Jika bug masih ada, Anda bilang ke Git git bisect bad. Jika tidak ada, Anda bilang git bisect good.
Git akan mengulangi proses ini, memotong setengah dari sisa commit setiap kalinya, sampai menemukan commit pertama yang menyebabkan bug.

Simulasi:

# 1. Mulai sesi bisect
# HEAD adalah commit buruk, v1.2 adalah tag commit baik terakhir
git bisect start HEAD v1.2

# 2. Git akan checkout ke sebuah commit. Tes aplikasi Anda.
# Misal, bugnya masih ada.
git bisect bad

# 3. Git checkout lagi ke commit lain. Tes lagi.
# Misal, bugnya tidak ada.
git bisect good

# ... Ulangi terus sampai Git memberitahu:
# 'a1b2c3d is the first bad commit'

Bagian 5: Studi Kasus & Penanganan Masalah Umum

Kasus 1: "Saya salah commit ke branch main!"

Problem: Anda seharusnya bekerja di branch feature/new-button, tapi tidak sengaja melakukan commit langsung ke main.

Solusi (jika belum di-push):

# 1. Buat branch fitur dari posisi main saat ini (yang sudah berisi commit salah)
git branch feature/new-button

# 2. Kembalikan branch main ke posisi sebelum commit salah
# --hard akan menghapus perubahan di working directory juga
git checkout main
git reset --hard HEAD~1

# 3. Pindah ke branch fitur yang benar, pekerjaan Anda aman di sana
git checkout feature/new-button

Kasus 2: "Pesan commit saya ada typo"

Problem: Anda baru saja commit, tapi pesannya salah.

Solusi (jika belum di-push):

git commit --amend -m "Pesan baru yang sudah diperbaiki"

Ini akan menggantikan commit terakhir dengan commit baru yang pesannya sudah benar.

Kasus 3: "Bagaimana cara menjaga branch fitur saya tetap update dengan main?"

Problem: Anda bekerja di branch fitur selama seminggu. Sementara itu, 20 commit baru masuk ke main. Branch Anda menjadi "tertinggal".

Solusi 1: Menggunakan merge

git fetch origin # Ambil perubahan terbaru dari server
git merge origin/main

Pro: Mudah dan tidak mengubah sejarah branch Anda.
Kontra: Menciptakan "merge commit" tambahan di riwayat Anda, yang bisa membuatnya terlihat seperti rel kereta api yang rumit.

Solusi 2: Menggunakan rebase (Direkomendasikan)

git fetch origin
git rebase origin/main

Cara Kerja: Alih-alih membuat merge commit, rebase mengambil semua commit Anda, memindahkannya sementara, lalu memutar ulang satu per satu di atas versi terbaru main.
Pro: Menghasilkan riwayat yang linear dan bersih. Seolah-olah Anda baru mulai mengerjakan fitur Anda di atas versi main yang paling baru.
Kontra: Sedikit lebih kompleks dan (ingat aturan emas) tidak boleh digunakan pada branch publik.

Menyimpan Pekerjaan Sementara: git stash

Problem: Anda sedang mengerjakan fitur A, tiba-tiba ada permintaan mendesak untuk memperbaiki bug di branch lain. Pekerjaan Anda di fitur A belum siap untuk di-commit.

Solusi: git stash akan menyimpan semua perubahan Anda (yang sudah dilacak) ke dalam sebuah "tumpukan" sementara, dan mengembalikan Working Directory Anda ke kondisi bersih seperti commit terakhir.

# 1. Anda sedang bekerja, lalu ada interupsi...
git stash save "Kerjaan fitur A, belum selesai"

# 2. Sekarang Working Directory bersih. Pindah branch, perbaiki bug, commit, push.
git checkout hotfix-123
# ... perbaiki bug ...
git commit -m "Fix: Critical login bug"
git push

# 3. Kembali ke branch fitur A
git checkout fitur-A

# 4. Terapkan kembali pekerjaan Anda yang tadi disimpan
git stash pop

# Anda bisa melanjutkan pekerjaan persis dari titik terakhir.

Membatalkan & Memperbaiki (Undo & Reset)

Ini adalah bagian krusial yang membedakan pemula dan ahli.

4.1. Cara Aman Membatalkan

Memperbaiki Commit Terakhir (Belum di-push):

# Lakukan perubahan tambahan...
git add file_yang_diperbaiki.js
# Gabungkan ke commit sebelumnya
git commit --amend --no-edit

Membatalkan Perubahan di Working Directory:

# Membatalkan semua perubahan di file_ini.js sejak commit terakhir
git restore file_ini.js

Melepas File dari Staging Area:

# File sudah di 'git add', tapi ingin dibatalkan dari staging
git restore --staged file_ini.js

Membatalkan Commit yang Sudah di-push (Cara Profesional): git revert git revert tidak menghapus sejarah. Ia membuat sebuah commit baru yang isinya adalah kebalikan dari commit yang ingin dibatalkan. Ini adalah cara yang aman untuk membatalkan perubahan di branch publik.
```
# Temukan hash dari commit yang bermasalah
git log --oneline
# a1b2c3d Feat: Add unstable feature

# Buat commit baru yang membatalkan commit a1b2c3d
git revert a1b2c3d

# Sekarang Anda bisa push revert commit ini dengan aman
git push
```

Contoh revert, misalkan branch main punya history seperti ini:

A → B → C → D (HEAD)

Isi file data.txt di tiap commit:

A:
```
1
```
B:
```
1
2
```
C:
```
1
2
3
```
D:
```
1
2
3
4
```

Case 1: Revert commit terakhir (D)

git revert D

History:

A → B → C → D → D' (HEAD)

Isi file:

1
2
3

👉 Efeknya persis commit C.

Case 2: Revert commit B (bukan yang terakhir)

git revert B

History:

A → B → C → D → B' (HEAD)

Apa yang terjadi?

Commit B menambahkan 2.
Jadi git revert B akan bikin commit B' yang menghapus baris "2", walaupun setelah B sudah ada commit C dan D.

Isi file setelah B':

1
3
4

Lihat bedanya: baris 2 hilang, tapi 3 dan 4 (dari commit C dan D) tetap ada. Jadi revert commit tengah tidak “balik” ke snapshot lama, tapi benar-benar membatalkan perubahan spesifik commit itu.

Case 3: Revert lebih dari satu commit

Misalnya revert C dan D sekaligus:

git revert C D

History:

A → B → C → D → C' → D' (HEAD)

Isi file akhir:

1
2

karena commit C menambah 3, commit D menambah 4. Setelah direvert, keduanya hilang, tapi 2 (dari B) tetap ada.

Case 4: Urutan revert penting

Kalau kamu revert commit merge atau commit yang mengubah banyak file, kadang bisa muncul conflict. Misalnya:

git revert C

Kalau C mengubah baris yang sudah diubah lagi di D, Git bisa bingung → kamu harus resolve manual sebelum lanjut git revert --continue.

git revert commit terakhir → hasil akhir sering sama dengan commit sebelumnya.
git revert commit tengah → hanya membatalkan perubahan spesifik commit itu, tanpa menghapus perubahan commit setelahnya.
Bisa revert banyak commit → Git bikin commit baru untuk masing-masing revert.
Bisa muncul conflict kalau perubahan commit yang direvert sudah disentuh lagi di commit lain.

Deep Dive: git reset (The Powerful & Dangerous Tool)

git reset digunakan untuk memundurkan kepala (HEAD) branch ke commit sebelumnya, seolah-olah commit setelahnya tidak pernah terjadi. Ini mengubah sejarah dan sangat berbahaya jika digunakan pada branch publik.

Ada tiga mode utama:

--soft: Paling ringan.
- Repository: HEAD mundur ke commit yang dituju.
- Staging Area: Tetap sama (berisi perubahan dari commit yang "dihapus").
- Working Directory: Tetap sama.
- Kegunaan: Menggabungkan beberapa commit terakhir menjadi satu (squash) secara manual.
--mixed (Ini adalah mode default):
- Repository: HEAD mundur.
- Staging Area: Dikosongkan. Perubahan dari commit yang "dihapus" dipindahkan ke Working Directory.
- Working Directory: Tetap sama.
- Kegunaan: Membatalkan commit terakhir tapi ingin mengerjakan ulang perubahannya.
--hard: Paling berbahaya.
- Repository: HEAD mundur.
- Staging Area: Dikosongkan.
- Working Directory: Semua perubahan sejak commit tujuan akan DIHAPUS PERMANEN.
- Kegunaan: Membuang total beberapa commit terakhir beserta semua perubahannya. Hati-hati!

Simulasi reset:

Bayangkan git log Anda:

C (HEAD -> main): "Add button styles"
B: "Add button HTML"
A: "Initial setup"

Sekarang kita akan reset ke commit A.

Perintah git reset --mode HEAD~2

Repository (HEAD)

Staging Area

Working Directory

--soft

Mundur ke A

Berisi file dari B & C

--mixed

Mundur ke A

Kosong

Berisi file dari B & C

--hard

Mundur ke A

Kosong

Kembali ke state A (file B & C hilang)

PreviousPaging dan Segmentation NextKafka Fundamental

Last updated 4 months ago