Belajar Git Branching Strategies - GitHub Flow (Scott Chacon)
Filosofi GitHub Flow: hanya satu branch persisten (main), semua perubahan via Pull Request dari feature branch pendek, deploy dilakukan dari main setelah PR di-merge, serta keunggulan kesederhanaan untuk continuous deployment dan tim kecil-menengah.
#Pendahuluan
Setelah di episode 6 kita mempelajari GitFlow — lima jenis branch dengan alur merge terstruktur — pada episode ini kita beralih ke kebalikannya: GitHub Flow, pendekatan yang menghilangkan kompleksitas GitFlow dan hanya menyisakan satu branch persisten.
GitHub Flow dikembangkan oleh Scott Chacon (penulis buku "Pro Git") dan menjadi standar di GitHub sendiri. Filosofinya: simplicity is the ultimate sophistication.
#Filosofi GitHub Flow
Prinsip inti GitHub Flow:
- Hanya ada satu branch persisten:
main. - Semua perubahan via Pull Request dari feature branch pendek.
- Deploy dilakukan dari
mainsetelah PR di-merge.
Tidak ada branch develop, tidak ada release/*, tidak ada hotfix/*. Semua perubahan — fitur, perbaikan, hotfix — menggunakan jalur yang sama: buat branch → kerja → buka PR → review → merge → deploy.
Perhatikan: main adalah satu-satunya branch yang persisten. Semua branch lain (feature, fix) dibuat, di-merge, lalu dihapus.
#Alur Kerja GitHub Flow
#Langkah 1: Buat Branch dari Main
git switch main && git pull origin main
git switch -c feature/add-search#Langkah 2: Kerja, Commit, Push
git add . && git commit -m "feat: add search API"
git push -u origin feature/add-search#Langkah 3: Buka Pull Request
Buka PR dari feature/add-search ke main. Deskripsikan apa yang berubah dan mengapa. CI pipeline berjalan otomatis.
#Langkah 4: Review, Diskusi, CI Berjalan
Reviewer memberikan komentar, diskusi terjadi di PR, perbaikan di-push ke branch yang sama. PR otomatis ter-update.
#Langkah 5: Merge ke Main → Deploy Otomatis
Setelah PR disetujui dan CI passing, merge ke main. Deploy pipeline berjalan otomatis — kode baru langsung di-deploy ke production.
#Keunggulan GitHub Flow
#Sederhana dan Mudah Dipahami
Developer baru bisa langsung produktif: buat branch, buka PR, merge. Tidak perlu memahami lima jenis branch dan alur merge yang berbeda.
#Ideal untuk Continuous Deployment
Karena main selalu bisa di-deploy, setiap merge ke main bisa langsung trigger deployment. Tidak ada gap antara kode siap dan kode di-deploy.
#Mengurangi Kompleksitas Branch Management
Satu jenis branch (feature/fix), satu alur merge (PR), satu branch untuk deploy (main). Kekacauan branch berkurang drastis.
#Kapan Menggunakan GitHub Flow
| Kondisi | Gunakan GitHub Flow? |
|---|---|
| SaaS / web apps dengan deploy pipeline | Ya — ideal |
| Tim kecil-menengah yang ingin continuous delivery | Ya |
| Mobile apps dengan release berkala | Kurang cocok — perlu branch release |
| Produk enterprise dengan multiple version | Kurang cocok — GitFlow lebih fleksibel |
Tip
GitHub Flow adalah starting point terbaik untuk tim yang baru mengadopsi branching strategy. Jika merasa kurang, kalian bisa berkembang ke GitFlow atau GitLab Flow nanti. Mulai dari yang sederhana.
#Penutup
Pada episode 7 ini, kalian telah memahami GitHub Flow:
- Hanya satu branch persisten:
main— semua perubahan via PR. - Alur kerja: branch → work → PR → review → merge → deploy.
- Keunggulan: sederhana, ideal untuk continuous deployment, mengurangi kompleksitas.
- Cocok untuk SaaS, web apps, dan tim kecil-menengah.
Di episode 8 selanjutnya kita akan mempelajari GitLab Flow & Environment Branches — kombinasi GitHub Flow dengan environment branches untuk deployment hierarchy, serta release branching untuk maintenance versi lama. Sampai jumpa di episode 8!