Belajar Frontend - Git & Workflow Kolaborasi

#Pendahuluan

Setelah di episode 6 kode TokoKita memiliki tipe yang aman, episode ini membahas alat yang menyatukan semua developer dalam satu tim: Git. Sejauh ini kalian mungkin memakai Git sendirian — episode 7 mengubah perspektif menjadi workflow kolaborasi: bagaimana banyak orang mengerjakan fitur yang sama tanpa menimpa pekerjaan satu sama lain, dan bagaimana kode masuk ke produksi dengan aman.

Mengapa ini penting untuk frontend? Karena di dunia kerja, kalian hampir tidak pernah menulis kode sendirian. Branching, pull request, dan code review adalah "jalur rel" tempat semua pekerjaan mengalir. Salah memakai Git bisa memblokir seluruh tim — dan sebaliknya, Git yang rapi membuat tim bergerak cepat.

#Konsep Inti Git

Bayangkan Git sebagai mesin waktu untuk kode:

Konsep	Arti	Perintah Dasar
Commit	Snapshot permanen	`git commit -m "..."`
Staging	Menyiapkan file sebelum commit	`git add`
Branch	Jalur kerja terpisah	`git branch`, `git switch`
Merge	Menggabungkan dua jalur	`git merge`
Rebase	Menyusun ulang riwayat commit	`git rebase`
Remote	Repo di server (GitHub)	`git push`, `git pull`
PR	Permintaan menggabungkan branch	via GitHub

Alur harian paling dasar:

Workflow harian

git switch -c feat/cart-page
# ... menulis kode ...
git add .
git commit -m "feat: add cart page"
git push -u origin feat/cart-page

#Branching Strategy

Dua pendekatan yang umum di 2026:

Trunk-based: semua developer commit langsung ke satu branch utama (main) dengan branch pendek berumur 1-2 hari. Cocok untuk tim kecil dan CI yang cepat.
Feature branch: setiap fitur punya branch, digabung via PR setelah review. Cocok untuk tim besar dengan banyak developer.

Prinsip yang berlaku di keduanya: branch pendek, commit kecil, merge sering. Branch yang hidup terlalu lama ("feature hell") adalah sumber konflik dan kode yang usang sebelum selesai.

#Conventional Commits

Commit yang baik menjelaskan perubahan, bukan menulis ulang apa yang sudah jelas:

Format conventional commits

feat: add product detail page
fix: correct cart total rounding
chore: upgrade typescript to 5.9
refactor: extract product card component
test: add unit tests for cart reducer

Formatnya: <type>: <deskripsi>. Tipe feat, fix, chore, refactor, test, docs, perf. Banyak tim memakai format ini karena otomatis menghasilkan changelog dan semantic versioning — repo ini sendiri memakainya untuk rilis (lihat release.config.cjs).

Note

Kalian tidak perlu hafal konvensi commit di luar kepala — yang penting konsisten. Repo ini bahkan mengotomatiskan rilis dari jenis commit (feat → minor, fix → patch). Saat menulis PR, lihat gaya commit yang sudah ada di repo lalu tiru.

#Pull Request dan Code Review

Pull request adalah pintu masuk kode ke branch utama:

Push branch fitur ke remote.
Buka PR ke main dengan deskripsi: apa yang dikerjakan, kenapa, dan screenshot/perilaku.
Reviewer membaca diff dan memberi umpan balik.
Perbaiki, push lagi (commit baru), sampai disetujui.
Merge → branch fitur dihapus.

Code review bukan mencari-cari kesalahan, melainkan jaring pengaman tim. Fokus utama reviewer:

Kebenaran — apakah logika benar dan edge case tertangani?
Kualitas — apakah bisa dibaca dan dirawat 6 bulan lagi?
Konsistensi — apakah mengikuti konvensi tim (format, naming)?
Keamanan/performa — adakah XSS, atau fetch tanpa error handling?

Review lokal sebelum push

git diff          # lihat perubahan yang belum di-commit
git log --oneline # riwayat commit singkat

#Praktik: Workflow Kolaborasi TokoKita

Simulasikan kerja dua developer pada fitur berbeda:

Fitur kartu + fitur search berjalan paralel

git switch -c feat/product-card     # Developer A
git switch -c feat/product-search   # Developer B
# keduanya bekerja dari commit `main` yang sama

Developer A selesai lebih dulu

git add src/components/ProductCard.tsx
git commit -m "feat: add product card component"
git push -u origin feat/product-card
# buka PR → review → merge ke main

Developer B menyesuaikan main terbaru

git switch feat/product-search
git merge main
# selesaikan konflik (jika ada) → commit → PR → merge

Konflik muncul saat dua orang mengubah baris yang sama. Kuncinya bukan menghindari konflik, tetapi membuatnya mudah diselesaikan: file kecil, commit terfokus, dan merge sering.

#Common Pitfalls

Kesalahan	Dampak	Perbaikan
Commit raksasa ("WIP")	Sulit review & revert	Commit kecil per perubahan
Push langsung ke `main`	Tanpa review	Selalu lewat branch + PR
`git add .` tanpa cek	File tidak relevan ikut masuk	`git status` dulu, `git add` selektif
Merge `main` ke branch setiap hari	Riwayat berantakan	`git rebase` saat konflik kecil
Commit pesan tidak jelas	Changelog tidak terbaca	Conventional commits

#Penutup

Inti yang harus dibawa pulang:

Git = snapshot + jalur kerja: commit kecil, branch pendek, merge sering.
Branching: trunk-based untuk tim kecil, feature branch untuk tim besar; PR adalah pintu masuk kode.
Conventional commits (feat:, fix:, …) menghasilkan changelog dan versioning otomatis.
Code review = jaring pengaman: benar, jelas, konsisten, aman.

Di episode 8 selanjutnya kita masuk framework pertama: React dasar — components, props, state, hooks, dan era React Compiler, membangun antarmuka TokoKita yang reaktif. Ini lompatan besar dari vanilla JS. Sampai jumpa di episode 8!