Belajar Git Branching Strategies - Feature Branch Workflow

#Pendahuluan

Setelah di episode 3 kita memahami Trunk-Based Development — branch utama tunggal dengan feature branch pendek dan feature flags — pada episode ini kita masuk ke Feature Branch Workflow, pendekatan paling umum dan banyak digunakan di industri. Di sini, setiap fitur baru atau perbaikan bug dibuat di branch terpisah dari main.

Feature Branch Workflow adalah fondasi dari GitHub Flow, GitFlow, dan GitLab Flow. Memahami workflow ini dengan baik akan memudahkan kalian memahami strategy lain yang lebih kompleks.

#Konsep Feature Branch

Prinsipnya sederhana: satu branch untuk satu fitur atau perbaikan. Kalian membuat branch dari main, bekerja di sana, lalu mengembalikannya ke main melalui Pull Request.

Branch dihapus setelah di-merge — ini housekeeping yang penting agar daftar branch tetap bersih.

#Naming Convention untuk Branch

Konsistensi naming menghindari kebingungan. Convention yang paling umum:

Aturan umum:

• Gunakan slash / sebagai pemisah tipe dan deskripsi.
• Gunakan hyphen - sebagai pemisah kata dalam deskripsi.
• Semua huruf kecil.
• Deskripsi singkat tapi informatif: feature/add-search-api, bukan feature/stuff.

#Alur Kerja Lengkap

Berikut adalah alur kerja feature branch dari awal sampai selesai:

#1. Buat Branch dari Main

git switch main
git pull origin main
git switch -c feature/add-search-api

Pastikan main sudah ter-update terlebih dahulu agar branch baru berbasis commit terbaru.

#2. Kerja dan Commit Secara Berkala

git add src/search.ts
git commit -m "feat: add search query builder"
 
git add src/routes/search.ts
git commit -m "feat: add search API endpoint"

Commit secara berkala — setiap perubahan logis. Hindari commit "WIP" atau "fix typo" yang tidak informatif.

#3. Push Branch

git push -u origin feature/add-search-api

Flag -u mengatur upstream tracking sehingga git push dan git pull tanpa argument bisa digunakan selanjutnya.

#4. Buka Pull Request

Di GitHub/GitLab, buka PR dari branch feature/add-search-api ke main. Deskripsi PR harus menjelaskan:

• Apa yang berubah.
• Mengapa perubahan ini diperlukan.
• Bagaimana cara menguji perubahan.

#5. Code Review dan CI Pipeline

Reviewer memeriksa kode, memberikan komentar, dan CI pipeline berjalan (lint, test, build). Diskusi terjadi di PR, bukan di Slack atau meeting.

#6. Merge dan Hapus Branch

Setelah PR disetujui dan CI passing:

git switch main
git pull origin main
git branch -d feature/add-search-api
git push origin --delete feature/add-search-api

Jika menggunakan squash merge di GitHub/GitLab, branch akan otomatis terhapus (bisa diaktifkan di repository settings).

#Penutup

Pada episode 4 ini, kalian telah memahami Feature Branch Workflow:

• Satu branch untuk satu fitur/perbaikan — isolasi kode yang jelas.
• Naming convention yang konsisten: feature/, bugfix/, hotfix/, release/.
• Alur kerja lengkap: create branch → work → push → PR → review → merge → cleanup.
• Branch dihapus setelah merge — housekeeping yang menjaga kebersihan repository.

Di episode 5 selanjutnya kita akan mempelajari Pull Request & Code Review Workflow — bagaimana PR menjadi gerbang kualitas kode, best practice code review, branch protection rules, dan merge strategy (merge commit, squash, rebase). Sampai jumpa di episode 5!