Alur Kerja Git untuk Tim Kecil: Branch, Commit, dan Merge Request

Hampir semua tim developer sudah memakai Git, tetapi banyak tim kecil memakainya seperti folder bersama: semua orang langsung push ke main, pesan commit berisi "update" atau "fix", dan setiap kali ada konflik, seseorang menyalin file secara manual. Hasilnya, sulit mencari kapan sebuah bug muncul, dan rilis ke klien terasa menegangkan. Artikel ini membahas alur kerja Git yang cukup sederhana untuk tim 2–5 orang, tetapi sudah cukup rapi untuk proyek aplikasi kesehatan yang dipakai setiap hari.

Satu aturan utama: main selalu siap rilis

Branch main hanya berisi kode yang sudah di-review dan lolos pengujian. Tidak ada yang push langsung ke main. Di GitLab maupun GitHub, aturan ini bisa dipaksa dengan fitur protected branch, sehingga perubahan hanya bisa masuk lewat merge request.

Dengan aturan ini, kapan pun klien meminta rilis darurat, Anda tahu bahwa isi main aman untuk dipasang.

Branch untuk setiap pekerjaan

Setiap fitur atau perbaikan dikerjakan di branch sendiri, dengan nama yang menjelaskan isinya:

Usahakan branch berumur pendek, idealnya selesai dalam 1–3 hari. Branch yang dibiarkan berminggu-minggu hampir pasti berakhir dengan konflik besar. Fitur yang besar sebaiknya dipecah menjadi beberapa merge request kecil.

Perintah sehari-hari

# mulai pekerjaan baru dari main terbaru
git switch main
git pull
git switch -c feature/jadwal-dokter-poli

# simpan perubahan secara bertahap
git add -p
git commit -m "Tambah validasi jam praktik dokter"

# kirim branch ke server
git push -u origin feature/jadwal-dokter-poli

git add -p menampilkan setiap potongan perubahan dan menanyakan apakah akan dimasukkan. Kebiasaan ini mencegah file sisa percobaan, log, atau konfigurasi lokal ikut ter-commit tanpa sengaja.

Menulis pesan commit yang berguna

Pesan commit adalah catatan untuk diri Anda sendiri enam bulan lagi, saat mencari tahu mengapa sebuah perubahan dibuat. Aturan sederhananya:

• Baris pertama singkat, sekitar 50–72 karakter, dan menjelaskan apa yang berubah: "Perbaiki perhitungan tagihan saat resep diubah".
• Bila perlu, tambahkan paragraf setelah satu baris kosong yang menjelaskan mengapa: bug apa yang terjadi, keputusan apa yang diambil.
• Satu commit untuk satu perubahan logis. Jangan mencampur perbaikan bug dengan perubahan format seluruh file.
• Hindari pesan seperti "update", "fix", atau "wip" di commit yang akan masuk ke main.

Sebagian tim memakai format Conventional Commits, misalnya fix: tagihan ganda saat resep diubah. Format ini berguna bila Anda ingin membuat catatan rilis otomatis, tetapi tidak wajib. Yang penting konsisten.

Alur merge request

1. Buka merge request dari branch Anda ke main, dengan deskripsi: apa yang berubah, cara mengujinya, dan tangkapan layar bila ada perubahan tampilan.
2. Pipeline CI menjalankan build dan tes otomatis.
3. Minimal satu anggota tim me-review. Panduannya ada di code review yang efektif untuk tim kecil.
4. Setelah disetujui dan pipeline hijau, merge ke main dan hapus branch-nya.

Merge request yang kecil, di bawah sekitar 400 baris perubahan, jauh lebih cepat di-review dan lebih jarang meloloskan bug.

Mengatasi konflik

Konflik terjadi saat dua orang mengubah baris yang sama. Cara paling tenang menanganinya:

git switch feature/jadwal-dokter-poli
git fetch origin
git merge origin/main
# buka file yang konflik, pilih versi yang benar, hapus tanda <<<<<<< ======= >>>>>>>
git add file-yang-konflik
git commit

Setelah konflik diselesaikan, jalankan aplikasi dan tes sekali lagi. Konflik yang "berhasil" di-merge belum tentu menghasilkan kode yang benar. Menyinkronkan branch dengan main setiap hari membuat konflik tetap kecil.

Rilis dan hotfix

Tandai setiap versi yang dipasang di klien dengan tag, misalnya git tag -a v1.4.0 -m "Rilis modul farmasi" lalu git push origin v1.4.0. Bila ada bug darurat, buat branch hotfix/ dari main, perbaiki, review singkat, merge, lalu beri tag baru seperti v1.4.1. Dengan tag, Anda selalu tahu persis versi mana yang sedang berjalan di rumah sakit atau klinik mana.

Untuk membatalkan perubahan yang sudah masuk ke main, gunakan git revert, yang membuat commit baru berisi kebalikan perubahan tersebut. Hindari menulis ulang riwayat branch yang sudah dipakai bersama.

Bila password atau data sensitif ter-commit

Ini kesalahan yang sering terjadi: file .env, kunci API, atau dump database ikut ter-push. Menghapus file di commit berikutnya tidak cukup, karena isinya tetap ada di riwayat Git dan di salinan repository milik orang lain.

1. Anggap rahasia itu sudah bocor. Segera ganti password atau buat ulang kunci API di layanan terkait.
2. Hapus file dari repository dan tambahkan ke .gitignore.
3. Bila perlu, bersihkan riwayat dengan alat khusus seperti git filter-repo, lalu minta semua anggota tim meng-clone ulang.
4. Bila yang bocor adalah data pasien, laporkan ke atasan dan ikuti prosedur insiden. Baca keamanan data pasien dan UU PDP.

Pencegahannya: sertakan .gitignore sejak commit pertama, simpan contoh konfigurasi sebagai .env.example tanpa nilai asli, dan jangan pernah menyimpan dump database produksi di dalam folder proyek.

Pertanyaan yang sering diajukan

Merge atau rebase? Untuk tim kecil, merge lebih mudah dipahami dan lebih aman. Rebase boleh dipakai untuk merapikan branch pribadi sebelum membuka merge request, asalkan branch itu belum dipakai orang lain.

Apakah perlu branch develop terpisah? Untuk tim kecil biasanya tidak. Satu branch main yang dilindungi, ditambah branch pendek per pekerjaan, sudah cukup. Branch tambahan hanya menambah pekerjaan sinkronisasi.

Bagaimana dengan deploy otomatis? Setelah alur ini berjalan, langkah berikutnya adalah menjalankan tes dan deploy otomatis dari pipeline. Pembahasannya ada di DevOps untuk tim kecil.