GitHub Flow

Feature Branch Workflow di chapter sebelumnya lengkap sebagai pola kerja, tetapi diam tentang satu pertanyaan yang bagi tim web paling menentukan: kapan hasil merge sampai ke pengguna? GitHub Flow — workflow ringan yang dikanonisasi GitHub sendiri — menjadikan jawaban itu prinsip desainnya: main selalu dalam keadaan bisa dideploy, dan penyebaran ke produksi mengikuti ritme merge, bukan kalender rilis. Bab ini memetakan enam langkah resminya, membandingkannya dengan feature branch klasik, dan membuktikan inti Git-nya di sandbox.

Prinsip Inti: main Selalu Deployable #

Dua kalimat menampung seluruh filsafatnya. Pertama: apa pun yang berada di main boleh dikirim ke produksi kapan saja — bukan “besok setelah stabil”, melainkan saat itu juga. Kedua: semua yang belum siap tidak boleh menyentuh main — ia menunggu di branch sampai lolos review. Konsekuensinya menyebar ke seluruh kebiasaan tim: PR didorong kecil agar review cepat, commit dikirim harian agar pengerjaan terlihat, dan saat tombol merge ditekan, jarak menuju pengguna tinggal satu langkah deploy.

Branch-nya pun punya tugas jelas sejak bernama: deskriptif dan pendek — fitur/tema-gelap, perbaikan/footer-miring, bukan update. Nama branch pada GitHub Flow adalah pengumuman niat, karena PR-nya sering dibuka jauh sebelum pekerjaan selesai.

Enam Langkah Resmi #

Dokumen resmi GitHub merangkum alurnya dalam enam langkah bernomor:

Tata kalimat keempat layak digarisbawahi: menanggapi review adalah langkah resmi alurnya, bukan kejadian di luar kartu — pola commit-perbaikan-diatas-branch persis yang dilatih di Code Review . Penyebaran ke produksi mengikuti segera setelah langkah kelima; banyak tim bahkan menjalankan deploy otomatis yang dipicu oleh merge itu sendiri.

Demo Inti dari Terminal #

Sisi Git-nya ringkas: satu repository kerja, satu bare pusat, dua fitur berturut-turut. Kerangkanya dulu:

mkdir latihan-ghflow && cd latihan-ghflow
git init -b main
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'beranda\n' > situs.md
git add situs.md
git commit -m "Buat kerangka toko"
git init --bare ../toko-ghflow.git
git remote add origin ../toko-ghflow.git
git push -u origin main

Output yang Dihasilkan (perintah terakhir):

To ../toko-ghflow.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Fitur pertama menjalani langkah 1-2: branch deskriptif, satu commit, kirim:

git switch -c fitur/tema-gelap
printf 'mode gelap\n' > tema.md
git add tema.md
git commit -m "Tambah mode gelap"
git push -u origin fitur/tema-gelap

Output yang Dihasilkan (perintah terakhir):

To ../toko-ghflow.git
 * [new branch]      fitur/tema-gelap -> fitur/tema-gelap
branch 'fitur/tema-gelap' set up to track 'origin/fitur/tema-gelap'.

Di platform, langkah 3-5 berlangsung di halaman PR: status checks menjalankan build dan tes, reviewer menyetujui, tombol merge ditekan. Setelahnya langkah 6: branch dihapus. Kembali di terminal, penggabungan yang dilakukan tombol itu bisa kita jalankan sendiri — dan karena main belum bergerak sejak branch dibuat, merge-nya maju cepat:

git switch main
git merge fitur/tema-gelap
git push origin main

Output yang Dihasilkan (dua perintah pertama):

Switched to branch 'main'
Your branch is up to date with 'origin/main'.

Updating bc645f4..522d171
Fast-forward
 tema.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 tema.md

Fitur kedua sengaja dibedakan. Branch fitur/footer dibuat, dikirim, lalu digabung dengan --no-ff — meniru perilaku tombol merge platform yang selalu melahirkan commit merge eksplisit walau maju cepat dimungkinkan:

git switch -c fitur/footer
printf 'toko budi\n' > footer.md
git add footer.md
git commit -m "Tambah footer"
git push -u origin fitur/footer
git switch main
git merge --no-ff fitur/footer
git push origin main

Output yang Dihasilkan (git merge –no-ff):

Merge made by the 'ort' strategy.
 footer.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 footer.md

Riwayat di titik ini memperlihatkan kedua gaya berdampingan:

git log --oneline --graph --all --decorate

Output yang Dihasilkan:

*   fbe27dd (HEAD -> main, origin/main) Merge branch 'fitur/footer'
|\  
| * 5e3e1f2 (origin/fitur/footer, fitur/footer) Tambah footer
|/  
* 522d171 (origin/fitur/tema-gelap, fitur/tema-gelap) Tambah mode gelap
* bc645f4 Buat kerangka toko

Hash di mesin pembaca berbeda; komposisinya tidak. Tambah mode gelap menempel lurus di jalur main — hasil fast-forward. Tambah footer terkurung gelembung merge — hasil --no-ff ala tombol PR. Perbandingan kedua bentuk ini dibedah tuntas di Fast-Forward Merge . Dekorasi fitur/tema-gelap dan fitur/footer masih hadir karena kedua branch itu memang masih hidup — langkah keenam mengurusnya:

git branch -d fitur/tema-gelap fitur/footer

Output yang Dihasilkan:

Deleted branch fitur/tema-gelap (was 522d171).
Deleted branch fitur/footer (was 5e3e1f2).

Dua penunjuk lokal hilang dari dekorasi graf berikutnya; sepasang origin/fitur/... menyusul setelah branch dihapus di remote — di platform, tombol hapus pasca-merge mengerjakan keduanya sekaligus, dan padanan terminalnya git push origin --delete sudah dilatih di Feature Branch Workflow .

Beda dengan Feature Branch Klasik #

Feature Branch Workflow adalah pola dasar yang bisa diperluas ke mana saja; GitHub Flow memilih satu arah perluasan — kecepatan sampai pengguna — dan menukar semua perlengkapan rilis dengan disiplin kecil: satu branch, satu PR, satu merge, deploy. Bab Strategi Branching menyebut pola rilis sebagai cabang tersendiri; dalam GitHub Flow cabang itu sengaja dipangkas.

Kapan GitHub Flow Tepat — dan Kapan Tidak #

Batasnya bukan teknis melainkan konsumen: bila pengguna menerima perangkat lunak per nomor versi yang terjadwal, ritme “merge berarti deploy” kehilangan maknanya. Kebutuhan itulah yang dijawab model yang lebih berprotokol — GitFlow, chapter berikutnya — dengan branch rilis dan hotfix yang diatur seperti bagan kerja pabrik. Uraian resmi alur ini bisa dibaca di dokumentasi GitHub Flow .