Bekerja sendirian dengan Git itu relatif tenang, tetapi begitu proyek dikerjakan beramai-ramai, ketakutan terbesar pemula biasanya sama: bagaimana kalau perubahan saya merusak kode teman? Jawabannya ada pada satu fitur Git yang paling powerful, yaitu branching. Panduan git branching pemula ini akan mengajarkanmu membuat cabang kerja yang aman, menggabungkannya kembali, menyelesaikan merge conflict tanpa panik, sampai alur pull request yang dipakai tim profesional.
Kalau kamu belum familier dengan dasar Git seperti commit dan push, baca dulu Tutorial Git dan GitHub untuk Pemula: Dari Instalasi sampai Push Pertama. Artikel ini mengasumsikan kamu sudah bisa membuat repository, commit perubahan, dan push ke GitHub, lalu fokus sepenuhnya pada dunia branching.
Git Branching Pemula: Kenapa Butuh Branch
Branch adalah cabang dari riwayat commit yang memungkinkanmu bekerja secara terisolasi. Analogi paling pas: branch main adalah jalan tol yang harus selalu mulus dan bisa dipakai, sedangkan branch fitur adalah jalan kecil tempatmu bereksperimen. Bila eksperimenmu gagal, jalan tol tetap aman. Bila berhasil, kamu menggabungkannya kembali ke jalan tol dengan terkendali.
Tanpa branch, semua orang commit langsung ke main dan risiko tabrakan sangat tinggi. Dengan branch, setiap fitur atau perbaikan bug dikerjakan di cabangnya sendiri, diuji sampai yakin, baru digabung. Inilah fondasi kolaborasi modern yang dipakai dari startup kecil sampai perusahaan teknologi raksasa.
Satu hal yang perlu diluruskan: membuat branch di Git itu murah dan instan, tidak seperti membuat salinan folder secara manual. Branch hanyalah penanda yang menunjuk ke sebuah commit, jadi jangan ragu membuatnya untuk setiap pekerjaan, sekecil apa pun itu.
Membuat dan Berpindah Branch
Perintah dasarnya sederhana. Untuk melihat daftar branch yang ada, jalankan git branch. Branch yang aktif ditandai bintang. Untuk membuat branch baru sekaligus pindah ke sana, cara modernnya memakai git switch -c.
# Lihat branch yang ada
git branch
# * main
# Buat branch baru "fitur-login" dan langsung pindah ke sana
git switch -c fitur-login
# Verifikasi posisi
git branch
# main
# * fitur-login
Perintah lama git checkout -b fitur-login melakukan hal yang sama dan masih banyak dipakai di tutorial lama, jadi kenali keduanya. Namun untuk pemula, biasakan git switch karena lebih jelas maksudnya: switch untuk berpindah, sedangkan checkout versi lama punya terlalu banyak fungsi ganda yang membingungkan.
Setelah pindah branch, semua commit yang kamu buat hanya tercatat di branch tersebut. Branch main tidak tersentuh sama sekali sampai kamu memutuskan untuk merge. Untuk kembali ke main, cukup jalankan git switch main. Kamu bisa berpindah bolak-balik dengan aman selama tidak ada perubahan yang belum di-commit.
Merge: Menggabungkan Branch Kembali
Setelah pekerjaan di branch fitur selesai dan sudah di-commit, saatnya menggabungkannya ke main. Alurnya selalu sama: pindah dulu ke branch tujuan, lalu merge branch sumber ke dalamnya.
# 1. Pindah ke branch tujuan (main)
git switch main
# 2. Pastikan main dalam kondisi terbaru
git pull origin main
# 3. Gabungkan branch fitur-login ke main
git merge fitur-login
Bila tidak ada konflik, Git melakukan fast-forward merge: penanda main tinggal dimajukan ke commit terbaru dari branch fitur. Riwayatnya tetap linear dan bersih. Inilah skenario ideal yang terjadi bila tidak ada orang lain yang mengubah baris yang sama selama kamu bekerja.
Setelah merge berhasil dan sudah di-push, branch fitur yang sudah tidak dipakai sebaiknya dihapus agar daftar branch tetap rapi.
# Hapus branch lokal yang sudah di-merge
git branch -d fitur-login
# Hapus branch di remote (GitHub)
git push origin --delete fitur-login
Flag -d hanya mau menghapus branch yang sudah di-merge, sehingga aman dari kecelakaan. Bila kamu yakin ingin menghapus branch yang belum di-merge, barulah pakai -D dengan penuh kesadaran.
Simulasi Merge Conflict dan Cara Me-resolve
Merge conflict terjadi saat dua branch mengubah baris yang sama pada file yang sama, sehingga Git tidak bisa memutuskan versi mana yang benar. Ini bukan error yang harus ditakuti, melainkan Git yang meminta keputusanmu secara eksplisit. Mari simulasikan supaya kamu mengalaminya di lingkungan aman.
Pertama siapkan skenario konfliknya. Buat file catatan.txt di branch main, commit, lalu buat branch fitur-a yang mengubah baris pertama file itu dan commit. Kembali ke main, ubah baris pertama yang sama dengan isi berbeda, dan commit juga.
# Di main: buat file awal
echo "Baris pertama versi awal" > catatan.txt
git add catatan.txt
git commit -m "Tambah catatan awal"
# Buat branch fitur-a dan ubah baris pertama
git switch -c fitur-a
echo "Baris pertama versi fitur A" > catatan.txt
git add catatan.txt
git commit -m "Ubah baris pertama di fitur-a"
# Kembali ke main dan ubah baris pertama yang sama
git switch main
echo "Baris pertama versi main" > catatan.txt
git add catatan.txt
git commit -m "Ubah baris pertama di main"
# Coba merge: KONFLIK!
git merge fitur-a
Git akan melaporkan CONFLICT (content): Merge conflict in catatan.txt dan menghentikan proses merge. Buka file tersebut dan kamu akan melihat penanda konflik seperti ini.
<<<<<<< HEAD
Baris pertama versi main
=======
Baris pertama versi fitur A
>>>>>>> fitur-a
Bagian antara <<<<<<< HEAD dan ======= adalah versimu saat ini (main), sedangkan antara ======= dan >>>>>>> fitur-a adalah versi dari branch yang di-merge. Tugasmu sederhana: edit file menjadi versi final yang benar, lalu hapus semua penanda konfliknya.
# Setelah mengedit file menjadi versi final:
# "Baris pertama versi gabungan yang benar"
# Tandai konflik selesai
git add catatan.txt
# Selesaikan merge dengan commit
git commit -m "Resolve conflict: gabungkan perubahan main dan fitur-a"
Kunci menghadapi konflik adalah tetap tenang dan baca penandanya baik-baik. Konflik hampir selalu hanya soal beberapa baris, bukan seluruh file. Editor modern seperti VS Code bahkan menampilkan tombol Accept Current Change dan Accept Incoming Change sehingga kamu cukup klik. Setelah terbiasa, menyelesaikan konflik hanya butuh waktu satu dua menit.
Alur Pull Request Sederhana untuk Kolaborasi Tim
Di tim profesional, merge langsung ke main dari lokal biasanya dilarang. Sebagai gantinya dipakai pull request (PR), yaitu permintaan peninjauan sebelum kode digabung. Alurnya memberi lapisan keamanan berupa review dari rekan tim dan pengecekan otomatis.
Alur sederhananya begini. Pertama, push branch fiturmu ke GitHub dengan git push origin fitur-login. Kedua, buka halaman repository di GitHub dan klik tombol Compare and pull request yang muncul otomatis. Ketiga, tulis deskripsi perubahan dengan jelas: apa yang diubah dan kenapa. Keempat, minta rekan tim me-review. Mereka bisa memberi komentar per baris kode dan meminta perbaikan sebelum menyetujui.
Kelima, setelah disetujui, klik Merge pull request di GitHub. GitHub menawarkan tiga mode merge: Create a merge commit yang jujur mencatat riwayat, Squash and merge yang memadatkan semua commit branch menjadi satu commit rapi di main, dan Rebase and merge yang menempelkan commit satu per satu. Untuk pemula, squash and merge paling rapi karena satu fitur menjadi satu commit di main.
Keenam, hapus branch fitur dari GitHub setelah di-merge dan sinkronkan lokalmu dengan git switch main lalu git pull. Siklus ini berulang untuk setiap fitur. Mungkin terdengar panjang, tetapi setelah dua tiga kali praktik, alurnya menjadi kebiasaan yang hanya butuh beberapa menit.
Git Branching Pemula: Aturan Main yang Disarankan
Supaya branching tetap rapi saat tim membesar, ikuti beberapa konvensi sederhana. Pertama, beri nama branch yang deskriptif dengan awalan jenis pekerjaannya, misalnya fitur/login-google, perbaikan/bug-tombol-kirim, atau docs/update-readme. Hindari nama seperti branch-baru atau coba-coba yang tidak memberi informasi apa pun.
Kedua, buat branch dari main yang terbaru. Sebelum membuat branch baru, selalu git switch main lalu git pull dulu supaya titik berangkatmu mutakhir. Ketiga, jaga branch tetap pendek umur: semakin lama branch hidup terpisah, semakin besar peluang konfliknya. Usahakan satu branch selesai dan di-merge dalam hitungan hari, bukan minggu.
Keempat, commit kecil dan sering dengan pesan yang jelas di setiap branch. Riwayat commit yang granular memudahkan review dan memudahkan melacak kapan bug muncul. Kelima, jangan pernah commit langsung ke main bila sudah bekerja dalam tim. Jadikan branch dan pull request sebagai satu-satunya jalan menuju main, tanpa pengecualian.
Cheat Sheet Perintah Git Branching
Tabel berikut merangkum semua perintah penting dari artikel ini untuk ditempel di catatanmu.
| Perintah | Fungsi |
|---|---|
git branch |
Melihat daftar branch lokal |
git switch -c nama-branch |
Membuat branch baru dan pindah ke sana |
git switch main |
Pindah ke branch main |
git merge nama-branch |
Menggabungkan branch ke branch aktif |
git branch -d nama-branch |
Menghapus branch lokal yang sudah di-merge |
git log --oneline --graph --all |
Melihat riwayat branch dalam bentuk graf |
git status |
Memeriksa status file dan konflik |
git push origin nama-branch |
Mengirim branch ke GitHub |
Perintah git log --oneline --graph --all layak mendapat perhatian khusus karena menampilkan visualisasi cabang yang sangat membantu memahami apa yang terjadi. Jalankan sesekali untuk melihat bagaimana branch-branchmu bercabang dan bergabung kembali.
Langkah Selanjutnya
Kamu sekarang menguasai inti git branching pemula: membuat dan berpindah branch dengan switch, menggabungkan dengan merge, menyelesaikan merge conflict tanpa panik, sampai alur pull request yang dipakai tim profesional. Kombinasikan dengan dasar commit dan push yang sudah kamu kuasai, dan kamu siap berkolaborasi di proyek tim sungguhan.
Satu konvensi yang dipakai hampir semua tim profesional adalah pola penamaan branch yang konsisten, misalnya fitur/login-google, fix/bug-validasi, atau hotfix/crash-checkout. Nama seperti ini membuat isi branch langsung terbaca dari daftar branch tanpa harus membuka commit-nya. Biasakan juga menghapus branch lokal yang sudah di-merge dan tidak dipakai lagi agar daftar branch tetap bersih. Dua kebiasaan sederhana ini membuat kolaborasimu terlihat profesional sejak hari pertama.
Praktik terbaik berikutnya adalah membiasakan alur ini di proyek pribadimu sendiri, misalnya proyek Laravel yang sedang kamu bangun. Setiap selesai satu bab dari Tutorial Git dan GitHub untuk Pemula, buat branch baru untuk latihan bab berikutnya. Kebiasaan kecil inilah yang membedakan developer yang siap kerja tim dengan yang hanya bisa ngoding sendirian.