DevOps••10 min read•8 views

Panduan Git Pemula : Bekerja Dengan Branch

Sering bentrok kode saat kerja tim? Pelajari perintah dasar Git Branch, alur Git Flow, dan praktik terbaik manajemen versi agar repository selalu aman.

Halo! Selamat datang di tim. Saya perhatikan kamu sudah mulai terbiasa dengan rutinitas dasar git add, git commit, dan git push. Saat kamu mengerjakan project kuliah atau side-project sendirian, mendorong kode langsung ke branch utama (biasanya main atau master) memang terasa cepat dan praktis. Tidak ada yang protes, tidak ada kode yang bertabrakan.

Tapi, mari kita bicara tentang realitas di dunia industri. Saat kamu bekerja di tim perangkat lunak profesional—baik itu membangun sistem POS skala besar, platform e-commerce, atau aplikasi enterprise—kamu tidak akan pernah bekerja sendirian. Akan ada frontend developer yang sedang mengerjakan antarmuka dengan React.js, backend engineer yang mengoptimalkan API dengan Go, dan DevOps yang menyiapkan deployment. Jika semua orang mendorong kode setengah matang langsung ke main, repository kita akan hancur dalam hitungan jam. Aplikasi di production akan penuh dengan bug, dan kita akan menghabiskan lebih banyak waktu mencari tahu kode siapa yang merusak sistem daripada membangun fitur baru.

Di sinilah Git Branching masuk sebagai penyelamat nyawa. Anggap artikel ini sebagai sesi mentoring eksklusif dari saya untuk kamu. Siapkan kopimu, buka terminalmu, dan mari kita bedah bagaimana profesional mengelola versi kode mereka.

1. Filosofi Branching: Konsep "Multiverse" dalam Kode

Sebelum kita menghafal perintah terminal, kamu harus paham mindset-nya. Bayangkan repository Git kita adalah sebuah garis waktu (timeline). Garis waktu utama kita bernama main. Aturan emas pertama dan paling suci di dunia software engineering adalah: Branch main harus selalu dalam keadaan stabil, bersih, dan siap di-deploy ke production kapan saja.

Lalu, bagaimana caranya kita membuat fitur baru tanpa mengotori main? Kita membuat branch (cabang).

Menggunakan branch itu seperti menciptakan alam semesta paralel (multiverse). Saat kamu membuat branch baru dari main, kamu menyalin seluruh kondisi source code pada detik itu ke dalam ruang kerjamu sendiri yang terisolasi. Di alam semesta paralel ini, kamu bebas melakukan eksperimen, menghapus file penting, menginstal library baru, atau merombak arsitektur basis data. Apapun yang kamu lakukan di branch kamu, tidak akan berdampak seujung kuku pun pada branch main atau branch milik rekan timmu, sampai kamu secara eksplisit menggabungkannya (merge).

Isolasi inilah yang memungkinkan tim yang terdiri dari puluhan engineer bekerja secara bersamaan (konkuren) pada satu basis kode yang sama tanpa saling membunuh.

2. Perintah Dasar Git Branch: Senjata Wajib Sehari-hari

Sebagai engineer, terminal adalah rumahmu. Mari kita bahas perintah-perintah yang akan kamu ketik ratusan kali setiap minggunya.

Melihat Branch yang Ada

Untuk melihat di branch mana kamu sedang berada, gunakan perintah:

Bash 
git branch
Git akan menampilkan daftar branch lokalmu. Branch yang sedang aktif akan ditandai dengan bintang (*) dan biasanya berwarna hijau. Jika kamu ingin melihat semua branch termasuk yang ada di remote server (seperti GitHub/GitLab), tambahkan flag -a:

Bash 
git branch -a

Membuat Branch Baru

Katakanlah kamu ditugaskan membuat halaman landing page. Kamu tidak boleh menulisnya di main. Buat branch baru:

Bash 
git branch feature/landing-page
Perintah ini hanya membuat branch baru, tetapi tidak memindahkanmu ke sana. Kamu masih berada di main.

Berpindah Dimensi (Checkout / Switch)

Untuk pindah ke branch yang baru saja kamu buat, di Git versi lama kita menggunakan checkout:

Bash 
git checkout feature/landing-page
Namun, karena checkout memiliki fungsi ganda (bisa juga dipakai untuk mengembalikan file yang diubah), Git versi terbaru memperkenalkan perintah yang lebih spesifik dan aman, yaitu switch:

Bash 
git switch feature/landing-page
Pro Tip dari Senior: Kamu bisa merangkum proses "membuat sekaligus berpindah branch" dalam satu perintah efisien. Ini yang paling sering saya gunakan:

Bash 
git checkout -b feature/landing-page
# ATAU di Git versi baru:
git switch -c feature/landing-page

Menghapus Branch

Setelah fiturmu selesai dan sudah digabungkan ke main, branch tersebut hanya akan menjadi sampah visual. Biasakan untuk rajin bersih-bersih:

Bash 
git branch -d feature/landing-page
Jika Git menolak menghapus karena menganggap ada perubahan yang belum digabungkan (tapi kamu yakin ingin membuangnya), gunakan huruf D besar untuk paksa hapus:

Bash 
git branch -D feature/landing-page

3. Skenario Dunia Nyata 1: Siklus Hidup Feature Branch

Mari kita simulasikan pekerjaan nyata. Kamu mendapat tiket tugas (misalnya di Jira atau Trello): "Tambahkan komponen tabel data mahasiswa menggunakan React dan Tailwind CSS."

Inilah workflow langkah demi langkah yang harus kamu ikuti:

Langkah 1: Sinkronisasi dengan Realitas Terbaru
Sebelum membuat branch baru, pastikan kamu memulai dari versi main paling mutakhir. Jangan sampai kamu membuat branch dari kode bulan lalu.

Bash 
git switch main
git pull origin main
Langkah 2: Buat Cabang Baru
Gunakan penamaan yang deskriptif. Format standar industri biasanya adalah [tipe]/[nama-fitur].

Bash 
git switch -c feature/student-data-table
Langkah 3: Menulis Kode (Fase Paralel)
Sekarang kamu berada di ruang terisolasimu. Kamu mulai menginstal dependency baru, menulis komponen React, menata styling dengan Tailwind, dan menyambungkannya ke API. Setelah seharian bekerja, fiturnya selesai.

Langkah 4: Commit Secara Berkala
Jangan melakukan satu commit raksasa di akhir minggu. Lakukan commit kecil dan logis.

Bash 
git add .
git commit -m "feat: add table structure for student data"
git commit -m "style: implement Tailwind classes for responsive table"
git commit -m "integrate: connect table to backend API endpoints"
Langkah 5: Publish ke Remote Repository
Teman kerjamu (atau saya, sebagai peninjau kodemu) tidak bisa melihat branch lokal di laptopmu. Kamu harus mendorongnya ke server.

Bash 
git push -u origin feature/student-data-table
Flag -u (singkatan dari --set-upstream) memberi tahu Git untuk menautkan branch lokalmu dengan branch yang baru dibuat di server. Untuk push selanjutnya di branch ini, kamu cukup mengetik git push.

Langkah 6: Pull Request (PR)
Di perusahaan, kamu tidak melakukan merge sendiri ke main secara diam-diam. Kamu membuka Pull Request di GitHub/GitLab. Di sinilah Code Review terjadi. Saya atau engineer lain akan melihat kodemu, memberikan komentar ("Tolong optimalkan query database-nya", atau "Beri jarak margin yang lebih besar di komponen ini"), dan setelah semuanya disetujui (Approved), barulah branch tersebut di-merge ke main.

4. Skenario Dunia Nyata 2: Bencana di Production (Hotfix)

Skenario ini pasti akan kamu alami. Kamu sedang asyik bereksperimen di branch feature/new-dashboard. Tiba-tiba, manajer proyek panik: "Ada bug kritikal di production! Endpoint API untuk login menggunakan Go mengalami crash!"

Sebagai engineer, kamu harus segera memperbaikinya. Tapi masalahnya, branch kerjamu saat ini sedang berantakan, kodenya setengah jadi dan error. Kamu tidak mungkin membawa kode setengah jadi ini ke main. Apa yang harus dilakukan?

Langkah 1: Selamatkan Pekerjaan Saat Ini (Stash)
Simpan sementara kodemu yang belum selesai tanpa perlu melakukan commit.

Bash 
git stash
Sekarang, ruang kerjamu bersih kembali seperti semula.

Langkah 2: Pindah ke Main dan Tarik Data Terbaru

Bash 
git switch main
git pull origin main
Langkah 3: Buat Branch Khusus Perbaikan Cepat (Hotfix)
Kita tidak menggunakan awalan feature/, melainkan hotfix/ karena ini darurat.

Bash 
git switch -c hotfix/api-login-crash
Langkah 4: Perbaiki Bug
Kamu menelusuri logic Go di backend, menemukan bahwa ada null pointer exception, dan memperbaikinya.

Bash 
git add .
git commit -m "fix: resolve null pointer in login handler"
git push -u origin hotfix/api-login-crash
Kamu segera membuat Pull Request, tim langsung me-review, dan di-merge ke main lalu di-deploy ke production. Krisis teratasi!

Langkah 5: Kembali ke Pekerjaan Semula
Setelah dipuji pimpinan, saatnya kembali ke realitasmu yang tertunda.

Bash 
git switch feature/new-dashboard
git stash pop
Perintah git stash pop akan mengembalikan kode React setengah jadimu persis seperti sebelum kekacauan terjadi. Kamu bisa melanjutkan pekerjaan seolah-olah tidak terjadi apa-apa. Ajaib, bukan?

5. Standar Industri: Git Flow Branching Model

Di tim berskala besar, sekadar punya main dan branch fitur tidaklah cukup. Kita butuh tata kelola yang lebih ketat. Salah satu model yang paling terkenal adalah Git Flow.

Dalam model Git Flow yang ketat, kita memiliki beberapa "jalur utama" yang hidup selamanya, dan "jalur sementara" yang akan dihapus:

  • master / main: Hanya berisi kode yang sedang berjalan di production. Sangat suci.
  • develop: Cabang tempat berkumpulnya semua fitur baru yang sudah selesai. Ini adalah branch utama untuk proses integrasi.
  • feature/*: Dicabangkan dari develop. Digunakan untuk membuat fitur baru. Setelah selesai, di-merge kembali ke develop.
  • release/*: Ketika develop sudah punya cukup fitur untuk versi baru (misal versi 2.0), kita membuat branch release. Di sini kita hanya melakukan tes akhir dan perbaikan bug kecil, tidak ada penambahan fitur baru. Setelah stabil, di-merge ke main dan develop.
  • hotfix/*: Dicabangkan langsung dari main jika ada darurat (seperti skenario kita sebelumnya), lalu di-merge kembali ke main dan develop.
Memahami peta aliran ini membedakan seorang amatir dengan seorang engineer yang siap bekerja di skala enterprise.

6. Merge vs Rebase: Perdebatan Abadi Para Senior

Ketika kamu ingin menggabungkan branch fiturmu ke main, ada dua cara untuk melakukannya: git merge dan git rebase. Kamu wajib tahu perbedaannya karena menggunakan alat yang salah di waktu yang salah bisa mengundang amarah tim.

Pendekatan "Merge" (Jalur Aman)

Bash 
git switch main
git merge feature/landing-page
Merge mengambil kedua ujung branch dan membuat satu commit baru yang menyatukan keduanya (disebut merge commit).

  • Kelebihan: Sangat aman. Sejarah Git tidak diubah. Kamu bisa melihat dengan jelas bahwa pada suatu titik, fitur ini dikerjakan secara paralel lalu digabung.
  • Kekurangan: Jika timmu besar, riwayat commit akan terlihat sangat berantakan dan rumit (seperti jaring laba-laba) dengan banyaknya merge commit.

Pendekatan "Rebase" (Jalur Bersih)

Bash 
git switch feature/landing-page
git rebase main
Rebase mengambil seluruh commit di branch fiturmu, dan secara ajaib "menulis ulang" sejarah dengan memindahkannya ke ujung paling depan dari main.

  • Kelebihan: Riwayat commit menjadi garis lurus yang linear dan sangat rapi. Mudah dibaca.
  • Kekurangan: BERBAHAYA JIKA SALAH DIGUNAKAN. Karena rebase mengubah ID sejarah (hash), jika kamu me-rebase branch yang sudah dipakai oleh engineer lain, repositori mereka akan bentrok dan hancur.
Aturan Emas dari Senior: Jangan pernah me-rebase branch yang bersifat publik atau sedang dibagikan dengan orang lain. Gunakan rebase hanya untuk merapikan branch lokalmu sendiri sebelum kamu membuka Pull Request.

7. Konflik! (Merge Conflicts) Jangan Panik

Suatu hari, terminalmu akan berteriak merah: CONFLICT (content): Merge conflict in index.tsx. Jantungmu mungkin berdegup kencang, tapi percayalah, ini hal biasa.

Konflik terjadi jika kamu dan rekan timmu mengubah baris kode yang persis sama di file yang sama, pada branch yang berbeda. Git itu pintar, tapi dia tidak berani menebak kode siapa yang benar. Jadi, dia menyerahkan keputusannya kepadamu.

Saat terjadi konflik, Git akan menyuntikkan marker aneh ke dalam kode aslimu, terlihat seperti ini:

Plaintext 
<<<<<<< HEAD
<button class="bg-blue-500 text-white">Login</button>
=======
<button class="bg-green-500 font-bold">Masuk</button>
>>>>>>> feature/update-button
  • <<<<<<< HEAD sampai ======= adalah kodemu saat ini (di branch tujuan).
  • ======= sampai >>>>>>> branch-lain adalah kode dari branch yang sedang mencoba masuk.
Cara Menyelesaikannya:

  1. Buka file yang bermasalah di code editor (VS Code biasanya menyorotinya dengan sangat jelas).
  2. Hapus marker Git (<<<<<<<, =======, >>>>>>>).
  3. Tentukan kode mana yang ingin kamu simpan. Apakah mau kode biru? Kode hijau? Atau gabungan keduanya?
  4. Setelah kodenya benar, simpan file.
  5. Jalankan git add nama-file.
  6. Jalankan git commit untuk menyelesaikan resolusi konflik.
Kuncinya adalah komunikasi. Jika kamu tidak yakin baris mana yang benar, panggil rekan timmu dan tanyakan, "Bro, kodenya bentrok nih di fungsi pembayaran, kita pakai logic-mu atau logic-ku?"

8. Pesan Penutup dan Best Practices

Menjadi mahir menggunakan Git Branching tidak diukur dari seberapa banyak perintah rumit yang kamu hafal, tetapi dari seberapa disiplin kamu menjaga kebersihan sistem kerja. Ingat beberapa best practice ini sebelum kamu menutup terminal:

  1. Tetap Pendek dan Fokus: Feature branch tidak boleh hidup berbulan-bulan. Usahakan satu branch fokus pada satu fitur atau satu tiket pekerjaan. Semakin lama branch terpisah dari main, semakin besar potensi konflik dan rasa sakit saat merge.
  2. Konvensi Penamaan yang Jelas: Jangan buat branch dengan nama fix-bug atau update-UI. Gunakan prefix yang jelas seperti feat/ (fitur baru), fix/ (perbaikan bug), chore/ (tugas pemeliharaan, misal update library), atau docs/ (dokumentasi). Contoh: feat/payment-gateway-integration.
  3. Tulis Pesan Commit yang Bermakna: Pesan git commit -m "fix stuff" akan membuat dirimu di masa depan (dan teman timmu) menderita. Gunakan pesan yang menjelaskan apa dan kenapa. Contoh: fix: handle edge case when user balance is zero.
Berlatihlah membuat cabang, beralih konteks, dan memecahkan konflik secara mandiri. Lakukan kesalahan di branch lokal, karena di sanalah tempat teraman untuk belajar. Selamat berlatih, Junior. Kopi saya sudah habis, sekarang waktunya kamu yang membuktikan diri di repository kita!
Sigit Wasis Subekti

Sigit Wasis Subekti

Software Engineer & Tech Educator

Software Engineer and Tech Educator sharing insights on web development and software architecture.

Kembali ke Artikel

Artikel Terkait

B
DevOps

Bedah Arsitektur Komodo: Menjembatani antara Simple Docker Compose dan Kompleksitas Kubernetes

11 min read