Git Flow: apa itu, model percabangan dan penggunaannya dalam proyek

Apa itu Git Flow?

Git Flow — adalah model percabangan Git yang menetapkan struktur ketat cabang dan aturan penggabungan untuk mengelola pengembangan, rilis, dan perbaikan. Vincent Driessen menerbitkan artikel 'A successful Git branching model' pada Januari 2010 dan sejak itu Git Flow menjadi standar de facto dalam pengembangan perusahaan Java dan .NET. Ide utama — membagi kode menjadi lima jenis cabang dengan tingkat stabilitas yang berbeda.

Menurut Atlassian Git Tutorials, 2024, Git Flow didasarkan pada dua cabang permanen: main (sebelumnya master) dan develop. Semua cabang lainnya bersifat sementara: feature, release, hotfix. Setiap jenis cabang memiliki siklus hidup dan aturan penggabungan yang ditentukan dengan jelas. Dalam pengembangan mobile, Git Flow diterapkan dalam proyek dengan siklus rilis teratur (2–4 minggu) dan dukungan untuk beberapa versi.

Git Flow berbeda dari model sederhana (GitHub Flow) karena memerlukan cabang develop terpisah untuk integrasi. Ini menambahkan satu langkah dalam proses penggabungan, tetapi memberikan isolasi tambahan fitur yang belum selesai dari kode yang siap rilis.

Vincent Driessen dan sejarah Git Flow

Pada tahun 2010, Vincent Driessen menerbitkan postingan 'A successful Git branching model', yang menjadi salah satu yang paling banyak dikutip dalam sejarah Git. Model ini dibuat untuk proyek dengan rilis tetap dan dukungan versi paralel. Pada tahun 2020, Driessen mengakui bahwa Git Flow sudah usang untuk praktik CI/CD modern, tetapi model ini tetap relevan untuk proyek dengan siklus rilis panjang dan kebutuhan mendukung versi lama.

# Inisialisasi Git Flow
git flow init

# Membuat cabang feature
git flow feature start "add-auth"

# Menyelesaikan cabang feature (penggabungan ke develop)
git flow feature finish "add-auth"

# Membuat release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Cabang Main: kode rilis dan penandaan

Main (sebelumnya master) — cabang utama yang hanya berisi kode rilis siap untuk deploy. Setiap commit di main harus sesuai dengan versi produk tertentu yang ditandai dengan tag dalam format versioning semantik, misalnya v1.0.0, v1.1.0. Tidak ada pengembangan langsung di main — perubahan masuk ke sini hanya melalui cabang release atau hotfix.

Menurut semver.org, 2024, tag di main menggunakan format MAJOR.MINOR.PATCH. MAJOR ditingkatkan untuk perubahan API yang tidak kompatibel, MINOR — untuk penambahan fungsionalitas dengan kompatibilitas mundur, PATCH — untuk perbaikan bug. Di Git Flow, setiap finish release secara otomatis membuat commit di main dengan tag versi.

Main — satu-satunya cabang yang di-deploy ke produksi. Untuk proyek mobile, ini berarti saat push ke main, pipeline pembuatan App Bundle atau IPA dan publikasi ke Google Play / App Store akan berjalan. Di pengaturan CI/CD GitLab, main dilindungi dari force-push dan penghapusan.

Versioning semantik dan tag

Setiap commit di main disertai dengan tag dalam format SemVer: vMAJOR.MINOR.PATCH. MAJOR — untuk perubahan API yang tidak kompatibel, MINOR — untuk fungsionalitas baru dengan kompatibilitas mundur, PATCH — untuk perbaikan bug. Contoh: v2.1.0 berarti rilis major kedua dengan fitur baru dan tanpa perbaikan bug. Di Git Flow, tag dibuat secara otomatis saat finish release atau hotfix melalui perintah git flow release finish.

Cabang Develop: jalur integrasi pengembangan

Develop — cabang permanen kedua Git Flow, ditujukan untuk integrasi semua fitur yang selesai. Pengembang menggabungkan cabang feature ke develop setelah melewati review kode dan pemeriksaan CI/CD. Develop berisi versi kode stabil terbaru yang mencakup semua fitur yang diimplementasikan dari sprint saat ini.

Menurut DataSift Git Flow Guide, 2024, develop mungkin untuk sementara tidak stabil karena integrasi yang belum selesai. Untuk mencegah masalah, tim mempraktikkan Continuous Integration (CI): setiap fitur sebelum digabungkan ke develop menjalani serangkaian tes lengkap. Jika CI gagal — pengembang memperbaiki kode hingga penggabungan berikutnya. Develop selalu terhubung ke versi main saat ini: segera setelah rilis, develop disinkronkan dengan main melalui penggabungan.

Cabang Feature: pengembangan fungsionalitas baru

Cabang feature — cabang sementara untuk mengembangkan fitur individual, perbaikan bug, atau eksperimen. Setiap cabang feature dibuat dari develop dan setelah selesai digabungkan kembali ke develop. Nama cabang feature biasanya berisi nomor tugas atau deskripsi singkat: feature/APP-123-add-oauth, feature/redesign-profile. Di Git Flow, cabang feature dapat ada untuk waktu yang tidak terbatas.

Menurut Pro Git Book, 2024, cabang feature adalah lingkungan pengembangan yang terisolasi: perubahan di satu cabang tidak mempengaruhi yang lain hingga saat penggabungan. Dalam proyek mobile, cabang feature disinkronkan dengan develop melalui rebase atau merge untuk menghindari konflik besar saat penyelesaian. Disarankan untuk melakukan rebase cabang feature ke develop sebelum membuat MR.

# Membuat cabang feature secara manual (tanpa git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Membuat MR di GitLab melalui CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Cabang Release: persiapan rilis

Cabang release — cabang sementara yang dibuat dari develop untuk persiapan rilis. Ketika develop berisi kumpulan fitur yang cukup untuk versi baru, tim membuat cabang release/X.Y.Z (misalnya, release/2.1.0). Di cabang ini hanya dilakukan perubahan akhir: peningkatan versi, pembaruan lokalisasi, pengujian akhir, perbaikan bug kritis.

Menurut Atlassian Git Tutorials, 2024, cabang release memecahkan masalah kunci: isolasi perubahan akhir dari pengembangan paralel. Sementara release dipersiapkan untuk rilis, di develop terus digabungkan fitur baru untuk rilis berikutnya. Setelah selesai, cabang release digabungkan ke main (dengan tag) dan ke develop (untuk menyinkronkan peningkatan versi).

Cabang Hotfix: perbaikan mendesak di produksi

Cabang hotfix — cabang sementara untuk perbaikan mendesak bug kritis di produksi. Satu-satunya jenis cabang Git Flow yang dibuat dari main, bukan dari develop. Format nama: hotfix/X.Y.Z+1 (misalnya, hotfix/2.1.1). Setelah selesai, cabang hotfix digabungkan secara bersamaan ke main (sebagai rilis patch baru) dan ke develop (agar perbaikan tidak hilang pada rilis berikutnya).

Menurut DataSift Git Flow Guide, 2024, cabang hotfix harus sesingkat mungkin — hanya perbaikan dan pengujian. Hotfix tidak boleh menyertakan fitur baru atau refactoring. Dalam pengembangan mobile, hotfix digunakan untuk memperbaiki crash kritis (tingkat crash > 0.1%), kerentanan keamanan, atau bug yang memblokir di App Store.

Kelebihan dan kekurangan Git Flow untuk pengembangan mobile

Git Flow memberikan struktur yang jelas yang sangat berguna untuk tim besar dan proyek dengan rilis teratur. Kelebihan: isolasi fitur yang belum selesai di cabang feature, kemungkinan persiapan rilis tanpa memblokir pengembangan, dukungan untuk beberapa versi melalui hotfix. Kekurangan: kompleksitas untuk pemula, kebutuhan rebase rutin cabang feature, konflik pada cabang berumur panjang.

Menurut Martin Fowler, 2024, kelemahan utama Git Flow — cabang feature berumur panjang. Jika fitur dikembangkan 2+ minggu tanpa sinkronisasi dengan develop, konflik saat penggabungan menjadi signifikan. Untuk proyek mobile, disarankan untuk menyinkronkan cabang feature setiap hari melalui rebase ke develop.

Git Flow tidak direkomendasikan untuk proyek dengan Continuous Deployment (setiap commit ke main → ke produksi). Untuk proyek semacam itu, GitHub Flow atau Trunk-Based Development memberikan model yang lebih sederhana dan cepat. Tetapi untuk proyek dengan siklus rilis dan dukungan versi lama, Git Flow tetap menjadi pilihan optimal.

Kapan Git Flow merugikan tim

Git Flow menjadi masalah dalam tiga kasus: tim kurang dari 5 orang (kompleksitas berlebihan), Continuous Deployment (keterlambatan pengiriman), kurangnya disiplin rebase (cabang feature berumur panjang menciptakan konflik penggabungan). Jika tim menghabiskan lebih dari 20% waktu untuk menggabungkan cabang dan menyelesaikan konflik — Git Flow tidak cocok untuk tim tersebut, bahkan dengan ukuran besar.

Alternatif Git Flow: GitHub Flow dan Trunk-Based Development

Alternatif Git Flow menawarkan proses yang lebih sederhana untuk tim yang mempraktikkan CI/CD. GitHub Flow hanya menggunakan satu cabang permanen (main) dan cabang feature. Setiap fitur dibuat dari main, setelah review dan CI digabungkan kembali ke main dan segera di-deploy. GitHub Flow lebih sederhana, tetapi tidak mendukung isolasi fitur yang belum selesai dan persiapan rilis paralel.

Menurut GitHub Docs, 2024, Trunk-Based Development (TBD) melangkah lebih jauh: semua pengembang bekerja dalam satu cabang (trunk), menggunakan cabang feature berumur pendek 1–2 hari. Feature toggles (sakelar fitur) mengontrol visibilitas kode yang belum selesai. TBD memerlukan disiplin CI/CD tinggi dan otomatisasi pengujian.

• GitHub Flow — satu main + cabang feature, ideal untuk CI/CD dan tim kecil
• GitLab Flow — mengembangkan Git Flow dengan cabang lingkungan (staging, production)
• Trunk-Based Development — satu cabang + feature toggles, maksimal CI/CD, minimal penggabungan
• One Flow — Git Flow yang disederhanakan tanpa cabang develop, hanya main + feature + release