Git Workflow untuk Tim: Branching Strategy yang Sering Dipakai di Proyek Production

Konflik Git yang berantakan, commit "fix bug" tanpa keterangan lebih lanjut, dan branch yang hidup selama berbulan-bulan sampai lupa isinya apa — semua ini bukan masalah Git-nya, tapi masalah workflow yang tidak disepakati bersama sejak awal. Berikut strategi branching yang paling sering kami pakai di proyek klien, dari tim kecil sampai tim dengan banyak developer paralel.

Kenapa Butuh Strategi, Bukan Asal Push ke main

Tim yang langsung commit ke main tanpa branch biasanya baik-baik saja — sampai dua orang mengerjakan fitur berbeda di waktu bersamaan, atau ada bug production yang harus diperbaiki mendesak sementara fitur baru masih setengah jadi. Tanpa strategi branching, situasi seperti ini berubah jadi kepanikan.

Struktur Branch yang Direkomendasikan

• main — selalu mencerminkan kondisi yang sedang live di production. Tidak pernah di-commit langsung.
• develop — branch integrasi tempat semua fitur digabung sebelum rilis (opsional untuk tim kecil, wajib untuk tim besar dengan rilis terjadwal).
• feature/nama-fitur — satu branch untuk satu fitur atau task, dibuat dari develop (atau main untuk tim kecil).
• hotfix/nama-perbaikan — untuk perbaikan mendesak di production, dibuat langsung dari main.

Alur Kerja Fitur Baru, Langkah demi Langkah

# 1. Pastikan branch utama Anda paling baru
git checkout develop
git pull origin develop

# 2. Buat branch baru khusus untuk fitur ini
git checkout -b feature/checkout-midtrans

# 3. Kerjakan, lalu commit dengan pesan yang jelas
git add .
git commit -m "feat: tambah integrasi payment gateway Midtrans"

# 4. Push branch ke remote
git push origin feature/checkout-midtrans

# 5. Buka Pull Request / Merge Request ke develop untuk direview tim

Konvensi Penamaan Commit yang Memudahkan Semua Orang

Pesan commit seperti "update", "fix", atau "asdf" tidak membantu siapa pun di masa depan — termasuk Anda sendiri. Konvensi Conventional Commits berikut sangat mudah diikuti dan langsung membuat riwayat commit jauh lebih berguna:

feat: menambahkan fitur baru
fix: memperbaiki bug
docs: perubahan dokumentasi saja
style: perubahan format kode, tidak mengubah logika
refactor: restrukturisasi kode tanpa mengubah fungsionalitas
test: menambah atau memperbaiki test
chore: pekerjaan rutin (update dependency, config, dll.)

# Contoh penggunaan nyata:
git commit -m "fix: perbaiki validasi email yang tidak terdeteksi duplikat"
git commit -m "feat: tambah fitur export laporan ke Excel"
git commit -m "refactor: pisahkan logic pembayaran ke service class terpisah"

Manfaat konkretnya: dengan format ini, Anda bisa generate changelog otomatis, dan siapa pun yang membaca git log langsung tahu jenis perubahan di tiap commit tanpa perlu membuka kodenya satu per satu.

Menangani Hotfix Mendesak di Production

Ini skenario yang paling sering bikin panik kalau tidak ada alur yang jelas: fitur baru sedang setengah jalan di develop, tapi ada bug kritis di production yang harus segera diperbaiki.

# 1. Buat branch hotfix LANGSUNG dari main, bukan dari develop
git checkout main
git pull origin main
git checkout -b hotfix/perbaikan-payment-gagal

# 2. Perbaiki, commit, lalu push
git commit -am "fix: perbaiki callback payment yang gagal update status order"
git push origin hotfix/perbaikan-payment-gagal

# 3. Merge ke main (untuk deploy segera)
git checkout main
git merge hotfix/perbaikan-payment-gagal
git push origin main

# 4. JANGAN LUPA merge juga ke develop, supaya perbaikan ini
#    tidak hilang saat develop di-merge ke main nanti
git checkout develop
git merge hotfix/perbaikan-payment-gagal
git push origin develop

Menyelesaikan Merge Conflict Tanpa Panik

Conflict itu normal, bukan tanda ada yang salah. Yang penting adalah cara menyelesaikannya dengan hati-hati:

# 1. Update branch Anda dengan perubahan terbaru dari develop
git checkout feature/checkout-midtrans
git fetch origin
git merge origin/develop

# Git akan menandai file yang konflik seperti ini:
# <<<<<<< HEAD
# kode versi Anda
# =======
# kode versi dari develop
# >>>>>>> origin/develop

# 2. Edit manual, pilih/gabungkan kode yang benar, hapus penanda <<< === >>>

# 3. Tandai sudah selesai, lalu commit
git add .
git commit -m "merge: selesaikan konflik dengan develop"

Tips praktis: merge/rebase branch develop ke feature branch Anda secara rutin (minimal sekali sehari kalau tim aktif), jangan menunggu sampai dua minggu kemudian — semakin lama ditunda, semakin besar dan rumit konfliknya.

merge vs rebase: Mana yang Harus Dipakai?

Ini perdebatan klasik, tapi aturan praktis yang aman untuk kebanyakan tim:

• Gunakan merge untuk menggabungkan feature branch ke develop/main — riwayatnya tetap jujur menunjukkan kapan fitur digabung.
• Gunakan rebase untuk merapikan commit di branch pribadi Anda sebelum di-push pertama kali — riwayat jadi lebih bersih dan linear.
• Jangan pernah rebase branch yang sudah di-push dan sedang dipakai orang lain — ini akan merusak riwayat mereka dan menyebabkan konflik berantai.

Checklist Sebelum Membuka Pull Request

• ✅ Branch sudah di-update dengan perubahan terbaru dari develop
• ✅ Tidak ada file debug/log/.env yang ikut ter-commit
• ✅ Pesan commit mengikuti konvensi yang disepakati tim
• ✅ Kode sudah dites minimal secara manual di lokal
• ✅ Deskripsi PR menjelaskan apa dan kenapa, bukan cuma apa

Kesimpulan

Strategi branching yang baik bukan tentang mengikuti aturan yang rumit — tapi tentang membuat semua orang di tim tahu persis di mana kode yang aman untuk production, di mana kode yang masih dalam pengembangan, dan bagaimana cara menggabungkan keduanya tanpa saling menimpa pekerjaan orang lain. Sepakati alur ini di awal proyek, tulis di README, dan konsisten menjalankannya — jauh lebih murah dibanding membereskan histori Git yang berantakan di tengah jalan.