Best Practices & Kolaborasi Tim

Selamat! Kamu sudah menguasai dasarnya. Sekarang, mari kita bicara tentang bagaimana menggunakan git dengan benar.

Bekerja secara profesional, kode yang kamu tulis bukan hanya untuk mesin, tapi juga untuk manusia (rekan tim kamu, atau bahkan diri kamu sendiri di masa depan).

1. Menulis Commit Message

Pesan commit adalah dokumentasi sejarah proyek. Pesan yang buruk akan membuat tim bingung saat melacak bug.

Hindari pesan seperti ini:

• ❌ "update"
• ❌ "fix bug" (Bug yang mana?)
• ❌ "coba-coba"
• ❌ "final banget"

Gunakan format yang jelas: Pesan yang baik harus menjawab: Apa yang dilakukan commit ini?

Contoh yang baik:

• ✅ "Membuat struktur awal HTML untuk halaman login"
• ✅ "Memperbaiki error validasi pada form registrasi"
• ✅ "Menambahkan style CSS untuk tombol navigasi"
• ✅ "Menghapus kode yang tidak terpakai di index.js"

2. Strategi Branching (Jangan Sentuh Main!)

Jika kamu bekerja dalam tim (atau ingin membiasakan diri bekerja rapi) :

Branch main harus selalu berisi kode yang stabil, bersih, dan siap dirilis (production-ready).

Workflow Ideal:

1. Ingin fitur baru? Buat branch fitur-baru.
2. Ada bug? Buat branch fix-bug-login.
3. Selesai coding? Gabungkan branch tersebut ke main melalui proses Merge atau Pull Request.
4. Setelah merge? Hapus branch fitur tersebut agar repository tetap rapi.

Perintah menghapus branch (setelah di-merge):

git branch -d nama-branch

3. Mengenal Pull Request (PR)

Di bagian sebelumnya kita melakukan git merge secara manual di terminal. Namun, di GitHub/GitLab, kita biasanya menggunakan fitur bernama Pull Request (PR) atau Merge Request.

Apa itu Pull Request? Ini adalah cara formal untuk meminta izin menggabungkan kode kamu ke main.

Langkahnya:

1. Kamu push branch kamu: git push origin fitur-login.
2. Buka GitHub, kamu akan melihat tombol "Compare & pull request".
3. Tulis judul dan deskripsi tentang apa yang kamu ubah.
4. Klik Create Pull Request.

Mengapa ini penting? PR memungkinkan Code Review. Rekan tim kamu bisa melihat kode kamu, memberikan komentar, atau meminta revisi sebelum kode tersebut benar-benar masuk ke main.