Feature Branch di Git: apa itu, cara membuat dan bekerja dengan cabang

Apa itu Feature Branch di Git

Feature Branch (cabang fitur) — adalah cabang sementara di Git, dibuat dari develop untuk mengembangkan fungsionalitas terpisah. Berbeda dengan cabang jangka panjang main dan develop, cabang feature ada untuk waktu terbatas — dari beberapa jam hingga beberapa minggu.

Tujuan utama feature branch adalah mengisolasi perubahan yang terkait dengan satu tugas dari kode lainnya. Pengembang dapat bereksperimen, melakukan banyak commit, dan bahkan merusak kode di cabangnya tanpa memengaruhi pekerjaan anggota tim lainnya.

Setelah pengembangan selesai, cabang feature digabungkan kembali ke develop melalui Pull Request dengan peninjauan kode wajib. Setelah penggabungan, cabang biasanya dihapus untuk menjaga repositori tetap bersih.

Menurut Vincent Driessen, 2010, model Git Flow dengan cabang feature telah menjadi standar industri berkat pembagian tanggung jawab yang jelas antara berbagai jenis cabang.

Alur kerja dengan Feature Branch

Alur kerja dengan feature branch terdiri dari serangkaian langkah yang dilakukan pengembang untuk setiap fitur baru. Proses ini meminimalkan konflik penggabungan dan memastikan kontrol kualitas kode.

1. Pembuatan cabang dari commit terakhir develop. Pengembang beralih ke develop, memperbaruinya, dan membuat cabang feature baru.
2. Pengembangan dan commit di cabang feature. Pengembang melakukan perubahan, membuat commit dengan deskripsi yang jelas, dan secara periodik mendorong cabang ke repositori remote.
3. Sinkronisasi dengan develop — selama pengembangan, cabang utama dapat maju. Pengembang melakukan rebase atau merge develop ke cabang feature-nya.
4. Pembuatan Pull Request — ketika fitur siap, pengembang membuka PR untuk peninjauan kode. Tim memeriksa kode dan meninggalkan komentar.
5. Penggabungan dan penghapusan — setelah PR disetujui, cabang digabungkan ke develop dan dihapus baik secara lokal maupun remote.

Sinkronisasi periodik dengan develop sangat penting. Semakin lama cabang feature hidup tanpa menggabungkan perubahan dari develop, semakin tinggi kemungkinan konflik pada penggabungan akhir.

Frekuensi sinkronisasi cabang feature

Aturan penamaan cabang feature

Penamaan cabang — bagian penting dari disiplin tim. Standar penamaan yang seragam memungkinkan dengan cepat menentukan tugas apa yang sedang dikerjakan dan siapa yang melakukannya.

• feature/nama — prefiks feature/ digunakan di Git Flow klasik. Contoh: feature/added-auth-module.
• feature/JIRA-123-deskripsi — kaitan dengan nomor tugas di sistem pelacakan. Contoh: feature/PROJ-42-add-login.
• feature/jenis/nama — format diperluas dengan menunjukkan jenis tugas. Contoh: feature/feat/analytics-dashboard.

Menggunakan ID tugas dari JIRA, Trello, atau sistem lain adalah praktik terbaik. Ini secara otomatis menghubungkan kode dengan tugas dan menyederhanakan pencarian cabang melalui git log.

Proses Pull Request

Pull Request (atau Merge Request di GitLab) — adalah permintaan untuk menggabungkan cabang feature ke develop. PR bukan sekadar operasi teknis, tetapi proses peninjauan kode tim yang meningkatkan kualitas kode dan menyebarkan pengetahuan di dalam tim.

PR yang baik berisi judul dengan deskripsi singkat tugas, tautan ke tiket, dan deskripsi perubahan. Pengembang harus menunjukkan apa yang sebenarnya dilakukan, file apa yang diubah, dan apakah ada risiko potensial untuk bagian lain dari proyek.

Tim meninjau kode di PR, meninggalkan komentar, meminta perubahan (change requests), dan menyetujui penggabungan (approve). Setelah disetujui, merge atau squash merge dilakukan.

Waktu rata-rata peninjauan PR dalam pengembangan mobile adalah 4 hingga 24 jam. Pustaka Danger mengotomatiskan sebagian pemeriksaan, menjalankan linter dan tes langsung di PR.

Rekomendasi untuk membuat PR yang baik

• Ukuran — tidak lebih dari 300-400 baris perubahan. PR besar sulit ditinjau, kualitas pemeriksaan menurun.
• Satu PR — satu tugas — hindari mencampur perubahan yang tidak terkait dalam satu permintaan.
• Tangkapan layar — untuk perubahan UI, lampirkan tangkapan layar sebelum dan sesudah.
• Tes — untuk fungsionalitas baru, tulis tes unit dan sertakan dalam PR.

Strategi penggabungan cabang feature

Setelah PR disetujui, cabang feature dapat digabungkan ke develop dengan berbagai cara. Pemilihan strategi penggabungan memengaruhi riwayat commit dan kemungkinan pengembalian perubahan.

• Merge commit — membuat commit penggabungan, mempertahankan seluruh riwayat commit cabang feature. Riwayat tetap lengkap, tetapi graf percabangan menjadi lebih kompleks.
• Squash merge — menggabungkan semua commit cabang feature menjadi satu dan menambahkannya di atas develop. Riwayat menjadi lebih bersih, tetapi informasi tentang commit antara hilang.
• Rebase and merge — menulis ulang commit cabang feature di atas commit terakhir develop dan menggabungkan tanpa commit tambahan. Riwayat tetap linier.

Untuk proyek mobile dengan rilis sering, paling sering digunakan squash merge: memberikan riwayat bersih di develop, sementara detail pengembangan tetap ada di deskripsi PR dan tugas tracker.

Kesalahan umum saat bekerja dengan Feature Branch

Bahkan pengembang berpengalaman pun membuat kesalahan saat bekerja dengan cabang feature. Mengetahui masalah umum membantu menghindari kehilangan waktu dan data.

• Umur cabang terlalu lama — cabang feature hidup lebih dari 2-3 minggu tanpa sinkronisasi dengan develop, yang menyebabkan konflik penggabungan masif.
• Commit dengan deskripsi tidak jelas — pesan seperti “fix” atau “update” tidak menjelaskan apa yang diubah dan mengapa.
• Mencampur tugas — dalam satu cabang feature dikembangkan dua fungsi yang tidak terkait, sehingga tidak memungkinkan pengembalian selektif.
• Kurang sinkronisasi — pengembang tidak melakukan git fetch dan tidak memperbarui develop, sehingga pada merge akhir muncul konflik.

Cara terbaik untuk menghindari masalah ini adalah menyepakati aturan kerja di awal proyek dan menggunakan pemeriksaan otomatis di pipeline CI/CD.

Contoh perintah untuk bekerja dengan Feature Branch

Mari kita pertimbangkan skenario praktis: seorang pengembang memulai fitur autentikasi baru di aplikasi mobile. Dia membuat cabang feature, bekerja pada kode, dan menyelesaikan tugas dengan Pull Request.

# Memperbarui develop dan membuat cabang feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Bekerja pada fitur: commit
git add src/ui/login/
git commit -m "Add login screen layout"

# Mengirim cabang feature ke server
git push origin feature/add-login-screen

# Sinkronisasi dengan develop (rebase)
git fetch origin develop
git rebase origin/develop

# Setelah PR disetujui: memperbarui local develop dan menghapus cabang
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Perintah git branch -d menghapus cabang hanya setelah perubahannya sepenuhnya digabungkan. Jika cabang tidak digabungkan, Git akan menyarankan menggunakan git branch -D untuk penghapusan paksa — gunakan flag ini dengan hati-hati.

Otomatisasi pemeriksaan di cabang feature

Pipeline CI/CD harus dijalankan untuk setiap cabang feature sebelum membuat PR. Ini memungkinkan deteksi masalah pada tahap awal, sebelum kode masuk ke peninjauan pengembang lain.

# GitHub Actions untuk memeriksa cabang feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Pipeline memeriksa apakah kode dikompilasi, tes lulus, dan gaya kode sesuai dengan standar yang diterima di tim. Hanya setelah lulus semua pemeriksaan, Pull Request dapat dibuat.