Belajar Git - Memahami Git Collaboration Workflows

#Pendahuluan

Empat episode terakhir membekali kalian perintah-perintah lengkap: branch, merge, push, pull, hingga penghapusan branch remote. Namun perintah hanyalah alat; di dunia nyata, tim yang sama-sama paham Git bisa bekerja dengan cara yang sangat berbeda. Perbedaan inilah yang disebut collaboration workflow.

Workflow adalah aturan main: kapan membuat branch, apa saja branch yang wajib ada, bagaimana kode sampai ke production. Pilihan workflow memengaruhi kecepatan rilis, tingkat risiko, dan budaya review tim. Di episode ini kita memetakan empat pola yang paling dikenal — dari yang paling sederhana hingga yang dipakai perusahaan teknologi raksasa.

#Apa Itu Collaboration Workflow?

Secara sederhana, workflow menjawab tiga pertanyaan:

Di branch mana pekerjaan dimulai?
Bagaimana fitur baru dikerjakan dan diuji?
Bagaimana kode final mencapai production?

Tidak ada jawaban yang benar mutlak — setiap pola punya trade-off. Yang penting adalah memilih yang sesuai dengan ukuran tim, ritme rilis, dan kematangan proses kalian. Kabar baiknya, semua perintah untuk mengeksekusi pola ini sudah kalian kuasai: git switch -c untuk membuka branch, git merge untuk menggabungkan, dan git push untuk mengirim.

#Centralized Workflow

Pola paling sederhana, mirip cara kerja SVN: semua orang berkomitmen langsung ke main. Tidak ada branch fitur, tidak ada Pull Request. Perubahan kecil dan cepat.

Alur Centralized Workflow

main
  developer A: commit -> push
  developer B: pull -> commit -> push
  developer C: pull -> commit -> push

Keunggulannya simpel dan minim konfigurasi. Kekurangannya jelas: tidak ada perlindungan terhadap kesalahan, dan setiap konflik terjadi tepat di cabang produksi. Cocok untuk project pribadi, prototype, atau tim super kecil.

#Feature Branch Workflow

Pola yang paling populer saat ini. Setiap fitur baru dikerjakan di branch terpisah, lalu digabungkan kembali setelah disetujui lewat Pull Request. Branch utama main selalu dalam keadaan siap rilis.

Alur Feature Branch Workflow

git switch -c feature/checkout
# kerjakan fitur, beberapa commit
git push -u origin feature/checkout
# buka Pull Request ke main

Keunggulannya: isolasi risiko, riwayat rapi, dan review berjalan sebelum kode menyentuh main. Ini kombinasi paling aman untuk tim kecil hingga menengah, dan fondasi dari alur kerja GitHub default.

#Gitflow Workflow

Dikembangkan oleh Vincent Driessen (2010), Gitflow membawa kumpulan branch yang lebih formal: main untuk rilis resmi, develop sebagai titik integrasi harian, lalu feature/*, release/*, dan hotfix/*.

feature/* bercabang dari develop, kembali ke develop.
release/* menyiapkan rilis berikutnya dari develop, lalu di-merge ke main dan develop.
hotfix/* bercabang dari main untuk perbaikan darurat produksi, di-merge kembali ke keduanya.

Struktur branch Gitflow

main
  \ develop
      \ feature/login
      \ feature/payment
      \ release/1.2.0
      \ hotfix/critical-bug

Gitflow unggul untuk project dengan rilis terjadwal dan semver ketat. Tapi formalitasnya berat untuk tim kecil: dua branch utama permanen plus sejumlah cabang pendukung membuat sejarah dan konflik lebih kompleks. Banyak tim modern justru meninggalkannya demi kesederhanaan.

#Trunk-Based Development

Pendekatan modern favorit ekosistem CI/CD. Semua orang bekerja di branch berumur pendek (beberapa jam hingga beberapa hari), lalu menggabungkannya ke main (trunk) sesering mungkin — idealnya beberapa kali sehari. Fitur besar tidak bersembunyi di branch panjang; perubahan dikontrol lewat feature flags.

Alur Trunk-Based Development

main
  branch kecil A  -> merge ke main (hari ini)
  branch kecil B  -> merge ke main (hari ini)
  branch kecil C  -> merge ke main (besok)

Keunggulannya: konflik jarang terjadi karena branch pendek, integrasi terus-menerus sehingga bug ketahuan cepat, dan main selalu dekat dengan production. Inilah pola yang memungkinkan tim melakukan deploy puluhan kali sehari seperti di GitHub, Netflix, dan Google.

Important

Trunk-Based Development baru bisa dipakai sungguhan jika pipeline CI cepat dan culture review ringan. Tanpa keduanya, "merge kecil tapi sering" akan berubah menjadi bottleneck antrean review.

#Perbandingan Empat Workflow

Workflow	Branch Kunci	Umur Branch Fitur	Kekuatan	Kelemahan
Centralized	`main` saja	Tidak ada	Paling simpel	Tanpa pengaman, rawan konflik
Feature Branch	`main` + branch fitur	Hari sampai minggu	Isolasi dan PR review	Branch panjang bisa basi
Gitflow	`main`, `develop`, `feature/`, `release/`, `hotfix/*`	Minggu sampai bulan	Rilis terjadwal, semver ketat	Kompleks untuk tim kecil
Trunk-Based	`main` saja	Jam sampai hari	Integrasi cepat, cocok CI/CD	Butuh disiplin dan feature flags

#Memilih Workflow yang Tepat

Panduan praktis memilih:

Tim 1-3 orang, belum ada rilis ketat → Centralized sebagai titik awal.
Tim 3-20 orang, satu rilis per minggu atau bulan → Feature Branch dengan PR.
Project dengan rilis terjadwal dan semver wajib → Gitflow.
Team produk dengan CI/CD kuat dan deploy harian → Trunk-Based Development.

Aturan penting: workflow adalah alat, bukan dogma. Banyak tim memakai campuran — misalnya Feature Branch untuk fitur besar, Trunk-Based untuk hotfix kecil. Yang buruk hanyalah tidak konsisten.

#Penutup

Poin kunci episode ini:

Centralized: semua push ke main, cocok untuk project sangat kecil.
Feature Branch: setiap fitur di branch sendiri, digabung lewat PR.
Gitflow: main, develop, feature/*, release/*, hotfix/* untuk rilis terjadwal.
Trunk-Based: branch pendek, merge sering ke main, andalan CI/CD modern.
Tidak ada workflow sempurna; pilih berdasarkan ukuran tim dan ritme rilis.

Kalian sudah punya landasan perintah dan pola kolaborasi. Di episode 11 kita mempraktikkannya lewat Pull Request dan Code Review di GitHub — bagaimana membuka PR dari UI maupun gh CLI, menulis deskripsi yang informatif, dan memilih strategi merge commit. Sampai jumpa!