Cara Memakai Git untuk Tim Kecil: Alur Branch yang Masuk Akal

Selama developer-nya satu, git boleh dipakai seenaknya — commit langsung ke main, pesan "update", tidak ada yang protes. Orang kedua mengubah segalanya: pekerjaan mulai saling menimpa, "kode di laptop saya beda dengan di server" jadi kalimat mingguan, dan satu sore hilang untuk membereskan kekusutan yang tidak perlu terjadi. Kabar baiknya, obatnya bukan mempelajari seluruh git — cukup satu alur kerja sederhana yang disepakati bersama. Tutorial ini adalah alur itu: yang kami pakai sendiri untuk tim berukuran dua sampai delapan orang.

Masalah yang muncul saat tim tumbuh dari satu jadi tiga

Tanpa kesepakatan, tiga orang di satu repository menghasilkan pola yang sama di mana-mana: kerjaan setengah jadi didorong ke main dan merusak build; dua orang mengedit file yang sama tanpa tahu; dan tidak ada yang bisa menjawab "versi mana yang sedang jalan di server?". Semua alur kerja git yang baik — sesederhana apa pun — menyelesaikan ini dengan satu prinsip: main adalah wilayah suci yang selalu siap deploy, dan semua pekerjaan berlangsung di luar wilayah itu sampai layak masuk.

Langkah 1: Sepakati alur: main selalu bisa deploy

Aturannya muat di empat baris, dan layak ditempel di README:

1. Tidak ada commit langsung ke main. Tidak juga "cuma benerin typo".
2. Setiap pekerjaan — fitur, perbaikan, eksperimen — hidup di branch sendiri.
3. Masuk ke main hanya lewat pull request yang dilihat minimal satu orang lain.
4. Apa pun yang ada di main boleh di-deploy kapan saja tanpa tanya-tanya.

Kuncilah aturan ini secara teknis, bukan hanya moral: di GitHub, Settings → Branches → branch protection untuk main — wajib lewat PR, dan kalau Anda sudah punya CI, wajib lulus test. Aturan yang ditegakkan mesin tidak butuh diperdebatkan tiap minggu.

Langkah 2: Kerjakan fitur di branch terpisah

Ritme hariannya:

git switch main
git pull                     # selalu mulai dari main terbaru
git switch -c fitur/export-excel

# ...kerja, commit kecil-kecil...
git add -A
git commit -m "Tambah tombol export di halaman laporan"

git push -u origin fitur/export-excel

Dua kebiasaan yang menentukan mutu: mulai dari main yang segar (branch yang lahir dari kode basi akan menua jadi konflik), dan branch berumur pendek — satu branch satu tujuan, selesai dalam hitungan hari, bukan minggu. Branch raksasa berumur sebulan adalah cara paling pasti menciptakan konflik merge yang menakutkan; sepuluh branch kecil yang mengalir cepat hampir tidak pernah bentrok.

Langkah 3: Review lewat pull request

Buka PR begitu branch didorong. Fungsinya melampaui mencari bug: PR adalah tempat pengetahuan menyebar — reviewer jadi tahu bagian yang tidak ia tulis, dan enam bulan lagi PR adalah dokumentasi kenapa perubahan itu dibuat. Supaya sehat untuk tim kecil: deskripsi PR menjawab "apa dan kenapa" dalam tiga kalimat; ukuran PR kecil (PR raksasa memaksa review asal lewat — pecah saja); review datang cepat (PR yang menggantung dua hari membekukan pekerjaan di belakangnya); dan komentar menunjuk kode, bukan orangnya. Setelah disetujui: merge, hapus branch, lanjut.

Langkah 4: Selesaikan konflik merge tanpa panik

Konflik bukan kecelakaan — ia git yang bertanya, "dua orang mengubah baris yang sama; mana yang benar?" Saat terjadi (biasanya ketika menarik main terbaru ke branch Anda):

git switch fitur/export-excel
git merge main
# CONFLICT (content): Merge conflict in laporan.py

Buka file yang disebut: git menandai kedua versi di antara <<<<<<< dan >>>>>>>. Tugas Anda bukan trik git — melainkan keputusan manusia: pilih salah satu, atau gabungkan keduanya dengan tangan, hapus tanda-tandanya, lalu git add dan git commit. Kalau perubahan lawan tidak Anda pahami, tanya penulisnya — dua menit bertanya mengalahkan menebak. Dan kalau semua terasa kusut: git merge --abort mengembalikan keadaan semula; tidak ada yang hilang, coba lagi dengan kepala dingin.

Aturan commit message yang menolong enam bulan kemudian

Pesan commit dibaca paling sering justru saat ada masalah — git log dan git blame di tengah insiden. Standar minimum yang murah dijaga: baris pertama ringkas dan bermakna dalam bahasa yang tim sepakati ("Perbaiki total laporan salah saat ada retur" — bukan "fix", bukan "update lagi"), dan untuk perubahan yang tidak jelas alasannya dari kodenya, tambah satu-dua kalimat kenapa di badan pesan. Ukurannya sederhana: enam bulan lagi, orang yang membaca log harus bisa menemukan commit yang ia cari tanpa membuka satu per satu.

Alur ini — branch pendek, PR kecil, main yang selalu hijau — adalah fondasi yang membuat deploy otomatis aman dipasang di atasnya. Dan kalau Anda ingin melihat bagaimana disiplin ini dijalankan di proyek sungguhan, begitu cara tim software Clovertechno bekerja di setiap proyek klien.