Git dan GitHub untuk Kolaborasi Tim

Dua developer mengerjakan proyek Laravel yang sama, saling mengirim file lewat ZIP atau langsung mengedit di server, lalu suatu hari fitur yang kemarin sudah jalan tiba-tiba hilang karena tertimpa. Masalah seperti ini sangat umum di tim kecil dan freelancer yang mulai bekerja berdua atau bertiga. Git dan GitHub menyelesaikannya, tetapi hanya jika tim sepakat pada alur kerja yang sama.

Artikel ini bukan daftar semua perintah Git. Fokusnya adalah alur kerja harian yang cukup untuk tim 2-10 orang: cara membuat branch, menulis commit, membuka pull request, me-review kode, dan menyelesaikan konflik tanpa panik.

Persiapan Repositori Proyek

Sebelum kolaborasi dimulai, pastikan repositori bersih dari file yang tidak boleh dibagikan. Untuk proyek Laravel, file .gitignore bawaan sudah mengabaikan folder vendor, node_modules, dan .env. Periksa lagi, lalu sediakan .env.example berisi nama variabel tanpa nilai rahasia.

# .gitignore (potongan penting untuk Laravel)
/vendor
/node_modules
/public/build
/public/storage
/storage/*.key
.env
.env.backup
.phpunit.result.cache

Jika .env berisi password database atau API key pernah ter-commit, menghapusnya di commit berikutnya tidak cukup karena masih ada di riwayat. Segera ganti semua kredensial yang bocor. Daftar pemeriksaan keamanan lain ada di checklist keamanan dasar Laravel.

Memilih Alur Kerja Branch

Untuk sebagian besar tim UMKM dan agensi kecil, GitHub Flow sudah cukup. Tambahkan branch staging hanya jika Anda memang punya server staging terpisah.

Alur Harian Langkah demi Langkah

1. Perbarui main lokal sebelum mulai kerja, agar branch baru berangkat dari kode terbaru.
2. Buat branch dengan nama deskriptif, misalnya fitur/laporan-penjualan atau perbaikan/stok-minus.
3. Commit kecil dan sering. Satu commit untuk satu perubahan logis.
4. Push branch ke GitHub dan buka pull request (PR), bahkan sebagai draft, agar rekan tahu apa yang sedang dikerjakan.
5. Minta review, perbaiki masukan dengan commit tambahan.
6. Merge ke main setelah disetujui dan pengecekan otomatis lolos, lalu hapus branch.

git switch main
git pull origin main
git switch -c fitur/laporan-penjualan

# ... ubah kode ...
git add app/Http/Controllers/ReportController.php resources/views/reports
git commit -m "Tambah laporan penjualan harian per kasir"

git push -u origin fitur/laporan-penjualan
# buka GitHub, klik "Compare & pull request"

Perintah git switch adalah pengganti yang lebih jelas untuk git checkout saat berpindah branch, tersedia sejak Git 2.23.

Menulis Commit dan Pull Request yang Membantu Tim

Pesan commit ditulis untuk rekan Anda enam bulan dari sekarang. Gunakan kalimat perintah singkat yang menjelaskan apa yang berubah, misalnya "Perbaiki perhitungan diskon saat qty lebih dari 10", bukan "update" atau "fix bug". Banyak tim memakai format Conventional Commits seperti feat:, fix:, dan docs: agar riwayat mudah dipindai.

Deskripsi PR yang baik menjawab tiga hal: apa yang berubah, kenapa, dan bagaimana mengujinya. Simpan template di .github/pull_request_template.md supaya otomatis muncul setiap PR dibuka:

## Apa yang berubah
-

## Kenapa
Tautan tiket/issue:

## Cara menguji
1. php artisan migrate
2. Buka /laporan/penjualan, pilih tanggal hari ini

## Checklist
- [ ] Ada migration baru? Sudah bisa di-rollback
- [ ] Tidak ada data rahasia di kode
- [ ] Tampilan dicek di layar HP

Perubahan struktur database perlu perhatian khusus saat review, karena migration yang salah bisa merusak data produksi. Praktiknya dibahas di migrasi database yang aman di Laravel.

Review Kode yang Efektif

• Jaga PR tetap kecil. PR di bawah 300-400 baris jauh lebih mudah di-review dengan teliti dibanding PR ribuan baris (angka ini patokan praktis, bukan aturan baku).
• Review logika dan risiko, bukan gaya penulisan. Serahkan format kode ke alat otomatis seperti Laravel Pint.
• Tulis komentar sebagai pertanyaan atau saran, misalnya "Apakah query ini perlu eager loading?", bukan "Ini salah".
• Batasi waktu tunggu. Sepakati PR di-review dalam satu hari kerja agar pekerjaan tidak menumpuk.

Menyelesaikan Merge Conflict

Konflik terjadi saat dua branch mengubah baris yang sama. Git tidak tahu mana yang benar, jadi ia menandai bagian itu dan meminta Anda memutuskan.

1. Perbarui branch Anda dengan main terbaru: git pull origin main (atau git rebase origin/main jika tim Anda memakai rebase).
2. Buka file yang ditandai. Anda akan melihat penanda <<<<<<<, =======, dan >>>>>>>.
3. Putuskan isi akhir: ambil salah satu versi, atau gabungkan keduanya. Hapus semua penanda.
4. Jalankan aplikasi dan test untuk memastikan hasil gabungan bekerja.
5. git add file tersebut, lalu git commit (atau git rebase --continue).

Editor seperti VS Code menampilkan tombol "Accept Current", "Accept Incoming", dan "Accept Both" yang memudahkan langkah ini. Konflik yang sering terjadi biasanya tanda branch hidup terlalu lama; gabungkan lebih sering.

Pengaturan GitHub yang Sebaiknya Diaktifkan

• Branch protection untuk main: wajib lewat PR, minimal satu approval, dan larang force push.
• GitHub Actions untuk menjalankan php artisan test dan Pint pada setiap PR.
• Secret scanning dan Dependabot untuk mendeteksi kredensial bocor dan dependensi rentan.
• Repositori privat untuk kode klien atau produk berbayar, dengan akses per orang yang ditinjau berkala.

Bekerja dengan Freelancer atau Anggota Sementara

Banyak UMKM dan agensi kecil menyewa freelancer untuk fitur tertentu. Jangan berikan akses admin repositori atau akses langsung ke server produksi. Undang mereka sebagai collaborator dengan hak write saja, minta semua pekerjaan masuk lewat pull request, dan jalankan review seperti anggota tim biasa. Saat kontrak selesai, cabut aksesnya di menu Settings, Collaborators, lalu ganti kredensial apa pun yang sempat Anda bagikan. Dengan cara ini, seluruh perubahan tetap tercatat dan bisa dibatalkan jika ternyata bermasalah.

Kesalahan Umum dan Cara Memulihkannya

Commit ke main secara langsung

Jika belum di-push, pindahkan ke branch baru dengan git switch -c fitur/x, lalu kembalikan main ke posisi remote dengan git switch main dan git reset --hard origin/main. Pastikan perubahan sudah aman di branch baru sebelum reset.

Pesan commit terakhir salah ketik

Selama belum di-push, gunakan git commit --amend. Jika sudah di-push ke branch bersama, biarkan saja dan tulis commit berikutnya dengan benar.

Ingin membatalkan commit yang sudah di main

Gunakan git revert <hash>, yang membuat commit baru berisi kebalikan perubahan. Jangan menulis ulang riwayat branch yang dipakai bersama.

Checklist Tim Sebelum Mulai

• .gitignore diperiksa, .env.example tersedia.
• Alur branch disepakati dan ditulis di README.
• Main diproteksi, wajib PR dan approval.
• Template PR tersedia.
• Test dan format otomatis berjalan di GitHub Actions.
• Panduan menjalankan proyek lokal tersedia untuk anggota baru, misalnya mengacu pada cara menjalankan source code Laravel.

Alur yang sama juga berlaku ketika tim Anda memodifikasi source code siap pakai, misalnya dari GudangCode: simpan versi asli sebagai commit pertama, lalu kerjakan kustomisasi di branch terpisah agar pembaruan dan perubahan Anda tetap terlacak.