Lewati ke konten utama
BackendLabs
BackendLabsby RSLabs
Semua artikel
PemulaFondasi

Panduan Git & GitHub untuk Developer Pemula

Version control dari nol — commit, branch, merge, pull request, dan workflow tim yang benar.

25 menit baca
Bagikan

Instagram & WhatsApp Story tidak punya share-link langsung — unduh gambarnya, lalu unggah manual sebagai Story.

"Kode yang tidak di-version control adalah kode yang hidup di tepi jurang."

Tentang Artikel Ini

Artikel ini ditulis untuk kamu yang baru pertama kali mendengar Git, atau sudah pernah menggunakannya tapi belum benar-benar paham apa yang sedang terjadi di baliknya.

Kita akan belajar dari nol — mulai dari "apa itu version control dan kenapa saya butuh ini", sampai ke workflow tim yang dipakai di perusahaan software nyata. Tidak ada teori berlebihan. Setiap konsep langsung diikuti dengan contoh dan praktik.

Setelah selesai membaca artikel ini, kamu akan bisa:

  • Mengelola perubahan kode dengan percaya diri
  • Bekerja di branch terpisah tanpa takut merusak kode utama
  • Berkolaborasi dengan tim lewat GitHub Pull Request
  • Memahami workflow Git yang dipakai di tim profesional
  • Menyelesaikan konflik merge tanpa panik

Prasyarat: Kamu sudah bisa menggunakan terminal/command line dasar (cd, ls, mkdir). Tidak perlu tahu Git sama sekali.

Daftar Isi

  1. Mengapa Version Control Itu Penting
  2. Instalasi & Konfigurasi Git
  3. Konsep Inti: Repository, Commit, dan Staging Area
  4. Branching: Bekerja di Jalur Terpisah
  5. Merging & Menyelesaikan Konflik
  6. GitHub: Remote Repository & Kolaborasi
  7. Pull Request & Code Review
  8. Git Workflow di Tim Nyata
  9. Tips, Perintah Berguna & Troubleshooting

Bab 1: Mengapa Version Control Itu Penting

Masalah yang Semua Developer Pernah Alami

Bayangkan kamu sedang mengerjakan sebuah fitur. Setelah beberapa jam, kamu sadar ada yang salah — kode yang tadinya jalan sekarang rusak. Kamu tidak ingat persis perubahan apa yang menyebabkannya.

Atau: kamu dan rekan satu tim mengerjakan file yang sama. Kamu simpan perubahan kamu, dia simpan perubahannya. Salah satu versi hilang.

Atau yang klasik: folder dengan nama seperti ini —

project/
├── app.js
├── app_backup.js
├── app_final.js
├── app_final_v2.js
├── app_final_BENERAN.js
└── app_final_BENERAN_fix.js

Ini adalah version control yang dilakukan secara manual — dan semua orang pernah melakukannya. Git hadir untuk menyelesaikan masalah ini secara sistematis.

Apa Itu Version Control?

Kalau skenario penamaan file tadi terasa familiar, kabar baiknya: ada cara yang jauh lebih baik, dan sudah dipakai hampir semua tim software profesional. Version control adalah sistem yang merekam setiap perubahan pada file seiring waktu, sehingga kamu bisa:

  1. Melihat riwayat — apa yang berubah, kapan, dan oleh siapa
  2. Kembali ke versi sebelumnya — seperti "undo" yang tidak terbatas
  3. Bekerja paralel — kamu dan tim bisa mengerjakan fitur berbeda secara bersamaan
  4. Bereksperimen dengan aman — coba sesuatu di branch terpisah, tanpa risiko merusak kode utama

Apa Itu Git?

Nah, dari sekian banyak tools version control yang pernah dibuat, Git adalah yang akhirnya dipakai hampir di mana-mana. Dibuat oleh Linus Torvalds — orang yang sama yang bikin Linux kernel — pada 2005, dan sejak itu praktis jadi standar default di industri.

Beberapa hal yang membuat Git terasa beda begitu kamu pakai:

  • Distributed: setiap developer punya salinan penuh dari seluruh riwayat proyek di komputernya sendiri. Tidak bergantung pada satu server pusat.
  • Cepat: hampir semua operasi dilakukan secara lokal
  • Non-linear: branching dan merging yang cepat dan fleksibel

Git vs GitHub: Apa Bedanya?

Ini pertanyaan yang hampir selalu muncul di awal, dan wajar — namanya mirip, jadi banyak yang mengira keduanya sama:

  • Git adalah tools version control yang berjalan di komputermu. Lokal.
  • GitHub adalah layanan hosting online untuk menyimpan repository Git. GitHub bukan satu-satunya — ada GitLab, Bitbucket, dan lainnya.

Analogi yang biasa saya pakai untuk menjelaskan ini: Git adalah Microsoft Word (software untuk nulis), GitHub adalah Google Drive (tempat menyimpan dan berbagi dokumen).

Jadi ya, secara teknis kamu bisa pakai Git tanpa pernah menyentuh GitHub sama sekali — semuanya tetap jalan di komputermu sendiri. Tapi begitu kamu bekerja dalam tim, atau sekadar ingin ada backup online kalau laptop tiba-tiba rusak, kamu akan butuh keduanya.

Bab 2: Instalasi & Konfigurasi Git

Instalasi

macOS:

# Opsi 1: lewat Homebrew (direkomendasikan)
brew install git
 
# Opsi 2: install Xcode Command Line Tools (otomatis include Git)
xcode-select --install

Windows: Download Git for Windows dari git-scm.com. Install dengan opsi default sudah cukup untuk pemula. Gunakan "Git Bash" yang terinstal untuk menjalankan perintah Git.

Linux (Ubuntu/Debian):

sudo apt update
sudo apt install git

Verifikasi instalasi:

git --version
# Output: git version 2.43.0

Konfigurasi Pertama

Sebelum mulai commit apa pun, ada satu langkah kecil yang sering terlewat: Git perlu tahu siapa kamu. Informasi ini akan melekat permanen di setiap commit yang kamu buat — jadi ada baiknya diisi dengan benar sejak awal, bukan asal-asalan.

git config --global user.name "Nama Kamu"
git config --global user.email "email@kamu.com"

--global berarti konfigurasi ini berlaku untuk semua project di komputermu. Jika ingin konfigurasi berbeda untuk satu project tertentu, jalankan perintah yang sama tanpa --global di dalam folder project itu.

Set editor default (digunakan saat menulis commit message panjang):

# Untuk VS Code
git config --global core.editor "code --wait"
 
# Untuk Nano (lebih mudah untuk pemula)
git config --global core.editor "nano"

Set default branch name (best practice modern: pakai main bukan master):

git config --global init.defaultBranch main

Cek konfigurasi yang sudah diset:

git config --list

Membuat Akun GitHub

  1. Buka github.com dan klik Sign up
  2. Pilih username yang profesional — ini akan terlihat di semua kontribusi kamu
  3. Verifikasi email

Autentikasi: SSH vs HTTPS

Ketika kamu mendorong (push) kode ke GitHub, GitHub perlu memastikan bahwa yang melakukannya benar pemilik akun tersebut, bukan orang lain. Ada dua cara untuk membuktikan itu:

HTTPS — lebih mudah di-setup, tapi kamu perlu memasukkan token setiap push:

# GitHub sudah tidak menerima password biasa, harus pakai Personal Access Token
# Generate di: GitHub → Settings → Developer settings → Personal access tokens

SSH — lebih nyaman untuk penggunaan sehari-hari karena sekali setup, tidak perlu masukkan password lagi:

# 1. Generate SSH key
ssh-keygen -t ed25519 -C "email@kamu.com"
# Tekan Enter untuk semua pertanyaan (gunakan lokasi default)
 
# 2. Tampilkan public key
cat ~/.ssh/id_ed25519.pub
 
# 3. Copy outputnya, lalu di GitHub:
#    Settings → SSH and GPG keys → New SSH key → Paste
 
# 4. Test koneksi
ssh -T git@github.com
# Output: Hi username! You've successfully authenticated...

Rekomendasi: Setup SSH dari awal. Lebih aman dan jauh lebih nyaman jangka panjang.

Bab 3: Konsep Inti: Repository, Commit, dan Staging Area

Repository (Repo)

Istilah ini yang paling sering bikin pemula bingung, jadi mari kita samakan dulu pemahamannya. Anggap saja repository sebagai "wadah" project kamu — folder yang dilacak oleh Git, tempat seluruh riwayat perubahan disimpan diam-diam di baliknya.

Ada dua jenis:

  • Local repository: ada di komputermu
  • Remote repository: ada di server (misalnya GitHub)

Membuat repository baru:

# Buat folder project
mkdir toko-api
cd toko-api
 
# Inisialisasi Git di folder ini
git init
 
# Output:
# Initialized empty Git repository in /Users/kamu/toko-api/.git/

Setelah git init, Git membuat folder tersembunyi .git/ di dalam project. Folder ini berisi seluruh database riwayat Git. Jangan hapus folder ini.

Meng-clone repository yang sudah ada:

git clone https://github.com/username/nama-repo.git
 
# Atau dengan SSH (jika sudah setup)
git clone git@github.com:username/nama-repo.git

Working Directory, Staging Area, dan Repository

Kalau ada satu konsep yang benar-benar wajib kamu pahami sebelum lanjut ke bab-bab berikutnya, ini dia — tiga "zona" tempat file kamu berpindah sebelum akhirnya tercatat permanen:

[Working Directory] → git add → [Staging Area] → git commit → [Repository]
  1. Working Directory: folder project kamu. Di sinilah kamu mengedit file.
  2. Staging Area (Index): "ruang tunggu" sebelum commit. Kamu memilih perubahan mana yang akan dimasukkan ke commit berikutnya.
  3. Repository: database permanen Git. Commit yang sudah masuk di sini tersimpan selamanya (kecuali kamu sengaja menghapus).

Mengapa ada Staging Area?

Ini pertanyaan yang wajar muncul — kenapa tidak langsung dari working directory ke commit saja? Jawabannya: staging area memberi kamu kontrol granular yang, begitu terbiasa, akan terasa sangat berguna. Bayangkan kamu mengubah 5 file, tapi hanya 3 yang relevan untuk satu fitur. Kamu bisa stage hanya 3 file itu, commit, lalu stage 2 file lainnya untuk commit terpisah. Hasilnya, riwayat commit jadi lebih bersih dan tiap commit benar-benar bercerita tentang satu hal, bukan campur aduk.

Perintah Dasar: Status, Add, Commit

Cek status:

git status

git status ini salah satu perintah yang paling sering saya jalankan, hampir refleks — dan dia akan memberitahu kamu:

  • File mana yang berubah tapi belum di-stage (Changes not staged for commit)
  • File mana yang sudah di-stage (Changes to be committed)
  • File baru yang belum dilacak Git (Untracked files)

Mari kita praktikkan dari awal:

# Di dalam folder toko-api, buat file baru
echo "# Toko API" > README.md
 
# Cek status
git status
# Output:
# On branch main
# No commits yet
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#         README.md

Staging file:

# Stage satu file
git add README.md
 
# Stage semua perubahan di folder saat ini
git add .
 
# Stage semua file dengan ekstensi .js
git add *.js
 
# Stage sebagian perubahan dari satu file (interactive)
git add -p README.md
# Setelah git add, cek status lagi
git status
# Output:
# On branch main
# No commits yet
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#         new file:   README.md

Membuat commit:

git commit -m "Inisialisasi project dengan README"

Flag -m diikuti dengan commit message dalam tanda kutip. Soal apa yang bikin commit message "baik", saya punya patokan sederhana: singkat (maks 72 karakter), dan fokus menjelaskan apa yang berubah — bukan bagaimana caranya, karena itu sudah kebaca dari diff-nya sendiri.

Contoh commit message yang baik:

✓ Tambahkan endpoint GET /products
✓ Perbaiki bug kalkulasi total harga
✓ Refactor fungsi validasi user input
✓ Update dokumentasi API authentication

Contoh commit message yang buruk:

✗ fix
✗ update
✗ changes
✗ asdfgh
✗ WIP (kecuali memang work in progress)

Melihat Riwayat Commit

# Lihat semua commit
git log
 
# Versi ringkas (satu baris per commit)
git log --oneline
 
# Dengan grafik branch
git log --oneline --graph --all
 
# Lihat 5 commit terakhir
git log -5
 
# Cari commit dengan keyword tertentu
git log --grep="authentication"

Contoh output git log --oneline:

a3f2c1d (HEAD -> main) Tambahkan validasi input produk
7b8e9f2 Perbaiki koneksi database
c4d5e6f Inisialisasi project dengan README

Setiap commit punya hash unik (seperti a3f2c1d) yang jadi "alamat" permanennya — nanti kamu akan sering merujuk ke hash ini, misalnya saat mau melihat detail commit tertentu atau kembali ke kondisi sebelumnya.

.gitignore: File yang Tidak Perlu Dilacak

Bukan berarti semua file di project harus ikut dilacak Git — justru sebaliknya, ada beberapa jenis file yang sebaiknya dijauhkan sama sekali. File seperti node_modules/, file .env (yang berisi password/secret), atau file hasil build, tidak seharusnya pernah di-commit.

Buat file .gitignore di root project:

# .gitignore untuk project Node.js
 
# Dependencies
node_modules/
 
# Environment variables (JANGAN pernah commit file ini!)
.env
.env.local
.env.production
 
# Logs
*.log
npm-debug.log*
 
# OS files
.DS_Store
Thumbs.db
 
# Build output
dist/
build/
.next/
 
# Editor
.vscode/
.idea/

⚠️ Peringatan Penting: File .env yang berisi database password, API key, atau secret tidak boleh pernah di-commit ke Git, apalagi ke repository publik. Ini adalah salah satu kesalahan paling fatal yang bisa dilakukan developer.

Kalau malas menulis dari nol, GitHub sebenarnya sudah menyediakan template .gitignore untuk berbagai bahasa/framework — saat membuat repository baru di GitHub, kamu bisa langsung memilih template yang sesuai, jadi tidak perlu mengingat-ingat sendiri file mana saja yang biasa perlu diabaikan.

Melihat Perubahan

# Lihat perubahan yang belum di-stage
git diff
 
# Lihat perubahan yang sudah di-stage
git diff --staged
 
# Lihat perubahan di commit tertentu
git show a3f2c1d
 
# Bandingkan dua commit
git diff a3f2c1d 7b8e9f2

Membatalkan Perubahan

# Buang perubahan di working directory (kembali ke kondisi commit terakhir)
git restore namafile.js
 
# Un-stage file (keluarkan dari staging area tapi perubahan tetap ada)
git restore --staged namafile.js
 
# Amend commit terakhir (ubah message atau tambahkan file yang ketinggalan)
git commit --amend -m "Pesan commit yang dikoreksi"
# Catatan: jangan amend commit yang sudah di-push ke remote!

Bab 4: Branching: Bekerja di Jalur Terpisah

Mengapa Branching Penting?

Dari semua fitur Git, branching ini yang menurut saya paling mengubah cara kerja begitu benar-benar dipahami. Bayangkan kamu sedang mengerjakan fitur login, sementara rekan kamu mengerjakan fitur pencarian produk di waktu yang sama. Tanpa branch, kalian berdua akan terus-menerus saling menimpa pekerjaan satu sama lain di file yang sama.

Dengan branch, setiap fitur dikerjakan di "jalur" terpisah, jadi tidak saling mengganggu. Branch main (atau master) pun tetap bersih dan stabil — isinya hanya kode yang sudah benar-benar selesai dan teruji.

main:     A --- B --- C
                       \
feature:                D --- E --- F

Perintah Branch Dasar

# Lihat semua branch (branch aktif ditandai *)
git branch
 
# Buat branch baru
git branch feature/login
 
# Pindah ke branch lain
git checkout feature/login
# atau cara modern:
git switch feature/login
 
# Buat branch baru SEKALIGUS pindah ke sana (shortcut)
git checkout -b feature/login
# atau:
git switch -c feature/login
 
# Hapus branch (setelah di-merge)
git branch -d feature/login
 
# Hapus branch secara paksa (meski belum di-merge)
git branch -D feature/login
 
# Lihat branch remote
git branch -r
 
# Lihat semua branch (local + remote)
git branch -a

Konvensi Penamaan Branch

Nama branch yang asal-asalan (test, branch2, punya-saya) akan menyulitkan kamu sendiri begitu jumlah branch mulai banyak. Lebih baik gunakan nama yang deskriptif dan konsisten sejak awal — beberapa konvensi yang umum dipakai:

feature/nama-fitur     # Fitur baru
bugfix/deskripsi-bug   # Perbaikan bug
hotfix/nama-hotfix     # Perbaikan darurat di production
release/v1.2.0         # Branch untuk release
chore/nama-task        # Maintenance, update deps, dsb

Contoh nyata:

feature/user-authentication
feature/product-search
bugfix/cart-calculation-error
hotfix/payment-gateway-timeout

Praktik: Mengerjakan Fitur di Branch Terpisah

# Pastikan kamu di main dan sudah update
git switch main
git pull
 
# Buat branch untuk fitur baru
git switch -c feature/tambah-produk
 
# Kerjakan fitur...
# Buat file baru
echo "// product controller" > src/controllers/product.js
 
# Commit perubahan
git add src/controllers/product.js
git commit -m "Tambahkan controller untuk produk"
 
# Lanjutkan pengerjaan...
echo "// product routes" > src/routes/product.js
git add src/routes/product.js
git commit -m "Tambahkan routing untuk endpoint produk"
 
# Lihat perbedaan branch ini dengan main
git diff main

Stash: Simpan Sementara Perubahan yang Belum Selesai

Ini situasi yang lumayan sering terjadi: kamu sedang di tengah mengerjakan sesuatu, belum siap commit, tapi tiba-tiba harus pindah branch untuk urusan lain. Daripada commit setengah jadi cuma supaya bisa pindah, pakai saja git stash:

# Simpan perubahan sementara
git stash
 
# Pergi ke branch lain untuk fix sesuatu
git switch main
git switch -c hotfix/critical-bug
# ... lakukan perbaikan, commit ...
git switch feature/tambah-produk
 
# Ambil kembali perubahan yang disimpan
git stash pop
 
# Lihat daftar stash
git stash list
 
# Simpan stash dengan nama
git stash push -m "progress fitur tambah produk"
 
# Ambil stash tertentu
git stash pop stash@{1}

Bab 5: Merging & Menyelesaikan Konflik

Merge: Menggabungkan Branch

Fitur sudah selesai dikerjakan di branch terpisah — sekarang tinggal langkah terakhir: menggabungkannya kembali ke main.

# Pindah ke branch tujuan (biasanya main)
git switch main
 
# Merge branch feature ke main
git merge feature/tambah-produk

Ada dua tipe merge:

Fast-forward merge: terjadi ketika branch main tidak ada commit baru sejak branch feature dibuat. Git cukup "maju" ke ujung branch feature.

Sebelum:
main:     A --- B
                 \
feature:          C --- D

Setelah fast-forward merge:
main:     A --- B --- C --- D

Merge commit: terjadi ketika ada commit baru di main setelah branch feature dibuat. Git membuat satu commit baru yang menggabungkan keduanya.

Sebelum:
main:     A --- B --- E
                 \
feature:          C --- D

Setelah merge:
main:     A --- B --- E --- M (merge commit)
                 \       /
feature:          C --- D

Konflik Merge: Jangan Panik

Konflik terjadi ketika dua branch sama-sama mengubah bagian yang sama dari file yang sama, dan Git — sepintar apa pun dia — tidak bisa menebak versi mana yang seharusnya menang. Jadi tugas itu dilempar balik ke kamu.

git merge feature/tambah-produk
# Output:
# Auto-merging src/app.js
# CONFLICT (content): Merge conflict in src/app.js
# Automatic merge failed; fix conflicts and then commit the result.

Buka file yang konflik (src/app.js). Git menandai area konflik seperti ini:

<<<<<<< HEAD
// Versi dari branch main
const PORT = process.env.PORT || 3000;
=======
// Versi dari branch feature/tambah-produk
const PORT = process.env.PORT || 8080;
>>>>>>> feature/tambah-produk

Kamu perlu:

  1. Pilih versi yang benar (atau gabungkan keduanya)
  2. Hapus semua marker Git (<<<<<<<, =======, >>>>>>>)
  3. Save file
  4. Stage file yang sudah diselesaikan
  5. Buat merge commit
# Setelah resolve konflik
git add src/app.js
 
# Buat merge commit
git commit -m "Merge feature/tambah-produk ke main"
 
# Atau jika mau batalkan merge (kembali ke sebelum merge)
git merge --abort

Tips menghindari konflik besar:

  • Sering-sering pull dari main ke branch feature kamu
  • Buat branch yang fokus (satu fitur, satu branch)
  • Komunikasikan dengan tim file mana yang sedang dikerjakan
  • Buat commit kecil dan sering

Rebase: Alternatif Merge yang Lebih Bersih

Selain merge, ada cara lain untuk mengintegrasikan perubahan yang hasilnya terasa jauh lebih rapi: git rebase. Alih-alih membuat merge commit tambahan, rebase "memindahkan" commit-commit branch kamu supaya seolah-olah dibuat di atas commit terbaru dari branch target.

# Di branch feature
git switch feature/tambah-produk
 
# Rebase ke main (ambil commit terbaru dari main, letakkan commit kita di atasnya)
git rebase main
Sebelum rebase:
main:     A --- B --- E
                 \
feature:          C --- D

Setelah rebase:
main:     A --- B --- E
                       \
feature:                C' --- D'

Hasilnya: riwayat linear yang lebih bersih.

⚠️ Aturan penting: Jangan pernah rebase branch yang sudah di-push ke remote dan sudah di-pakai orang lain. Rebase menulis ulang riwayat commit — ini akan menyebabkan masalah bagi developer lain yang sudah pull branch tersebut.

Aturan sederhana: Rebase aman dilakukan selama masih di branch local yang belum pernah di-push, atau di branch yang hanya kamu sendiri yang pakai.

Bab 6: GitHub: Remote Repository & Kolaborasi

Menambahkan Remote

Sampai titik ini, semua yang kita lakukan masih di komputer kamu sendiri. "Remote" adalah istilah untuk repository yang tersimpan di server — bukan di komputermu — dan biasanya di sinilah GitHub mulai masuk ke gambaran.

# Lihat remote yang terdaftar
git remote -v
 
# Tambahkan remote (biasanya dilakukan setelah git init)
git remote add origin git@github.com:username/toko-api.git
 
# 'origin' adalah nama konvensional untuk remote utama
 
# Ganti URL remote
git remote set-url origin git@github.com:username/toko-api-baru.git
 
# Hapus remote
git remote remove origin

Push: Kirim Commit ke Remote

# Push branch main ke remote 'origin'
git push origin main
 
# Push branch feature
git push origin feature/tambah-produk
 
# Push dan set upstream (agar selanjutnya cukup git push)
git push -u origin feature/tambah-produk
 
# Setelah set upstream, cukup:
git push

Pull: Ambil Perubahan dari Remote

# Fetch + merge (paling umum digunakan)
git pull
 
# Sama dengan:
git fetch origin
git merge origin/main
 
# Pull dengan rebase (riwayat lebih bersih)
git pull --rebase

Perbedaan fetch vs pull:

  • git fetch: hanya download informasi dari remote, tidak mengubah working directory
  • git pull: download + langsung merge ke branch aktif

Kalau saya pribadi, sebelum merge saya lebih suka git fetch dulu, baru cek git diff origin/main untuk lihat persis apa yang berubah di remote — baru setelah itu memutuskan mau merge atau tidak. Kebiasaan kecil ini beberapa kali menyelamatkan saya dari kejutan yang tidak perlu.

Clone: Salin Repository

# Clone repository ke folder dengan nama repo
git clone git@github.com:username/toko-api.git
 
# Clone ke folder dengan nama custom
git clone git@github.com:username/toko-api.git nama-folder-saya
 
# Clone hanya branch tertentu
git clone -b develop git@github.com:username/toko-api.git

Fork: Membuat Salinan Repository Orang Lain

Ini fitur GitHub, bukan fitur Git — jadi jangan bingung kalau tidak menemukan perintah git fork. Fork membuat salinan repository orang lain ke akun GitHub kamu sendiri, dan biasanya inilah pintu masuk kalau kamu ingin mulai kontribusi ke project open source:

  1. Fork repository di GitHub (klik tombol Fork)
  2. Clone fork kamu ke lokal: git clone git@github.com:AKUN_KAMU/nama-repo.git
  3. Tambahkan remote ke repo original: git remote add upstream git@github.com:PEMILIK_ASLI/nama-repo.git
  4. Kerjakan perubahan di branch terpisah
  5. Push ke fork kamu
  6. Buat Pull Request ke repo original

Bab 7: Pull Request & Code Review

Apa Itu Pull Request?

Di sinilah kerja tim yang sesungguhnya dimulai. Pull Request (PR) adalah cara resmi untuk mengusulkan perubahan kode ke branch utama — bukan sekadar formalitas, tapi mekanisme code review: sebelum kode kamu masuk ke main, satu atau lebih anggota tim akan membacanya dulu, dan baru menyetujuinya kalau memang sudah layak.

Workflow standar:

1. Buat branch dari main
2. Kerjakan fitur/bugfix
3. Push branch ke GitHub
4. Buat Pull Request di GitHub
5. Tim review kode
6. Perbaiki jika ada feedback
7. PR di-approve & di-merge
8. Branch dihapus

Membuat Pull Request yang Baik

Di GitHub:

  1. Setelah push branch, buka repository di GitHub
  2. Klik Compare & pull request (biasanya muncul otomatis)
  3. Isi title dan description dengan informatif

Template PR description yang baik:

## Apa yang berubah?
Menambahkan endpoint CRUD untuk manajemen produk.
 
## Kenapa perubahan ini diperlukan?
Fitur ini dibutuhkan untuk halaman admin dapat mengelola produk toko.
 
## Cara test:
1. `npm install`
2. `npm run dev`
3. POST ke `/api/products` dengan body: `{"name": "Produk A", "price": 50000}`
4. Cek response 201 dengan data produk
 
## Screenshot (jika ada UI change):
[screenshot di sini]
 
## Checklist:
- [x] Unit test ditambahkan
- [x] Dokumentasi API diupdate
- [x] Tidak ada console.log tertinggal

Melakukan Code Review

Kalau posisinya kebalik dan kamu yang jadi reviewer, ada beberapa hal yang menurut pengalaman saya paling layak diperhatikan dulu — supaya waktu review tidak habis untuk hal-hal kecil:

  1. Logika: apakah kodenya benar secara logika?
  2. Edge cases: apakah semua kasus tepi sudah ditangani?
  3. Security: ada potensi celah keamanan?
  4. Readability: apakah kode mudah dipahami?
  5. Performa: ada operasi yang tidak efisien?

Cara memberikan feedback yang konstruktif:

✓ "Fungsi ini bisa disederhanakan dengan Array.reduce() — lebih readable"
✓ "Perlu validasi jika `userId` undefined di baris 42 untuk mencegah crash"
✗ "Kode ini jelek"
✗ "Kenapa nulis gini sih"

Gunakan prefix untuk membedakan tipe komentar:

  • nit: — nitpick kecil, tidak harus diubah
  • suggestion: — saran, bisa dipertimbangkan
  • blocking: — harus difix sebelum merge
  • question: — pertanyaan untuk klarifikasi

Mengelola Feedback PR

# Ambil perubahan terbaru dari remote (jika ada update di main)
git fetch origin
git rebase origin/main
 
# Setelah melakukan perbaikan, push lagi
git add .
git commit -m "Perbaiki validasi input berdasarkan feedback review"
git push
# PR akan otomatis update

Bab 8: Git Workflow di Tim Nyata

Gitflow Workflow

Kalau kamu pernah masuk ke tim yang punya jadwal release ketat — misalnya rilis tiap dua minggu sekali — kemungkinan besar kamu akan bertemu Gitflow. Ini salah satu workflow paling populer untuk situasi seperti itu.

Branch utama:

  • main — kode yang ada di production
  • develop — kode terbaru yang sudah siap untuk release berikutnya

Branch pendukung:

  • feature/nama — fitur baru (dibuat dari develop)
  • release/v1.x.x — persiapan release (dibuat dari develop)
  • hotfix/nama — perbaikan darurat di production (dibuat dari main)
main:    ----A---------B---------C------
              \                 /
develop:  ----D---E---F---G---H---------
                   \       /
feature:            I---J

Kapan cocok: Project dengan jadwal release teratur, tim yang besar, atau product yang sudah live di production.

GitHub Flow (Lebih Sederhana)

Kalau Gitflow terasa terlalu banyak tahapan untuk kebutuhan kamu, GitHub Flow adalah versi yang jauh lebih simpel — dan menurut saya lebih masuk akal untuk tim yang deploy sering, bahkan beberapa kali sehari.

Aturannya cukup 6:

  1. main selalu deployable
  2. Semua pekerjaan dilakukan di branch terpisah
  3. Commit dan push ke branch kamu secara reguler
  4. Buat PR ketika butuh feedback atau siap merge
  5. Merge setelah di-approve
  6. Deploy setelah merge ke main

Kapan cocok: Tim kecil-menengah, aplikasi web, continuous deployment, startup.

Conventional Commits

Ini konvensi yang cukup sederhana tapi dampaknya lumayan besar buat saya pribadi: commit message ditulis dalam format yang terstruktur, sehingga mudah di-generate jadi changelog otomatis, dan siapa pun yang buka git log bisa langsung paham riwayatnya tanpa perlu buka satu-satu diff-nya.

Format:

<type>(<scope>): <description>

[optional body]

[optional footer]

Type yang umum:

  • feat — fitur baru
  • fix — perbaikan bug
  • docs — perubahan dokumentasi
  • style — formatting, missing semicolons (tidak ada perubahan logika)
  • refactor — refactoring kode
  • test — menambahkan atau memperbaiki test
  • chore — update build tools, package manager, dll

Contoh:

feat(auth): tambahkan endpoint login dengan JWT
fix(cart): perbaiki kalkulasi total saat ada diskon
docs(api): update dokumentasi endpoint produk
refactor(user): extract validasi ke fungsi terpisah
chore(deps): update express ke versi 4.18.2

Strategi Merge untuk Tim

Soal cara menggabungkan branch ke main, ada tiga pilihan yang biasa dipakai tim, dan masing-masing punya trade-off sendiri.

Squash and merge — gabungkan semua commit di branch jadi satu commit sebelum merge ke main. Riwayat main jadi sangat bersih.

Sebelum:
feature: A --- B --- C --- D (4 commit pengerjaan fitur)

Setelah squash merge ke main:
main: ... --- X (satu commit "feat: tambah fitur produk")

Rebase and merge — commit-commit di branch di-rebase ke atas main, lalu digabungkan tanpa merge commit. Riwayat linear.

Merge commit — buat merge commit eksplisit. Riwayat menunjukkan dengan jelas kapan branch digabungkan.

Rekomendasi untuk tim kecil: Gunakan Squash and merge untuk fitur, Merge commit untuk release. Riwayat main jadi bersih dan mudah dibaca.

Bab 9: Tips, Perintah Berguna & Troubleshooting

Perintah yang Sering Dipakai

# Shortcut: stage semua + commit dalam satu perintah (hanya untuk file yang sudah tracked)
git commit -am "Pesan commit"
 
# Lihat siapa yang menulis baris kode tertentu
git blame src/app.js
 
# Cari commit yang memasukkan bug (binary search)
git bisect start
git bisect bad                  # commit saat ini ada bugnya
git bisect good a3f2c1d         # commit terakhir yang masih oke
# Git akan checkout ke commit di tengah, kamu test, lalu:
git bisect good / git bisect bad
# Ulangi sampai Git menemukan commit penyebab bug
git bisect reset                # selesai
 
# Salin satu commit dari branch lain ke branch saat ini
git cherry-pick a3f2c1d
 
# Reset branch ke kondisi commit tertentu
git reset --soft HEAD~1         # batalkan commit terakhir, perubahan tetap di staging
git reset --mixed HEAD~1        # batalkan commit terakhir, perubahan ke working dir
git reset --hard HEAD~1         # batalkan commit terakhir, perubahan dihapus (HATI-HATI)
 
# Lihat semua aksi yang pernah dilakukan (berguna untuk recovery)
git reflog

Alias untuk Produktivitas

Tambahkan alias di ~/.gitconfig untuk perintah yang sering dipakai:

[alias]
    st = status
    co = checkout
    sw = switch
    br = branch
    ci = commit
    lg = log --oneline --graph --all --decorate
    undo = reset --soft HEAD~1
    unstage = restore --staged

Penggunaan:

git st         # sama dengan git status
git lg         # pretty log dengan grafik
git undo       # batalkan commit terakhir

Masalah Umum & Solusinya

"I accidentally committed to main directly"

# Buat branch dari kondisi saat ini
git switch -c feature/fitur-yang-terlanjur-di-main
 
# Reset main ke kondisi sebelum commit tadi
git switch main
git reset --hard HEAD~1  # sesuaikan angkanya
 
# Push main yang sudah di-reset (HATI-HATI jika sudah di-push)
git push --force-with-lease origin main

"I need to undo a push"

# Revert (membuat commit baru yang membatalkan perubahan — lebih aman)
git revert HEAD
git push
 
# ATAU reset + force push (berbahaya jika orang lain sudah pull)
git reset --hard HEAD~1
git push --force-with-lease

"My branch is behind main"

git switch feature/nama-feature
git fetch origin
git rebase origin/main
# Resolve konflik jika ada
git push --force-with-lease origin feature/nama-feature

"I committed sensitive data (password/API key)"

Ini serius. Langkah yang harus dilakukan:

  1. Segera revoke/regenerate credential yang ter-expose
  2. Hapus dari riwayat Git menggunakan git filter-branch atau tool BFG Repo Cleaner
  3. Force push ke remote
  4. Minta semua orang yang clone repo untuk fresh clone

Cara terbaik: jangan sampai kejadian. Selalu cek git diff --staged sebelum commit, dan pastikan .gitignore sudah benar.

"Merge conflict everywhere"

# Abort merge dan kembali ke kondisi sebelumnya
git merge --abort
 
# Coba lagi dengan strategi berbeda
git merge -X ours feature/nama   # pilih versi kita untuk semua konflik
git merge -X theirs feature/nama # pilih versi mereka untuk semua konflik

Konfigurasi yang Berguna

# Warnai output Git
git config --global color.ui auto
 
# Gunakan 'patience' diff algorithm (lebih readable untuk konflik besar)
git config --global diff.algorithm patience
 
# Selalu rebase saat pull
git config --global pull.rebase true
 
# Push hanya branch yang aktif (bukan semua branch)
git config --global push.default current
 
# Simpan credential agar tidak perlu login berulang (macOS)
git config --global credential.helper osxkeychain

Penutup

Selamat — kamu sudah menyelesaikan panduan Git & GitHub ini.

Kalau boleh jujur, branching dan force-push adalah dua hal yang paling lama saya hindari waktu belajar Git dulu — rasanya terlalu berisiko untuk disentuh sembarangan. Setelah dipakai berulang kali, dan beberapa kali sempat bikin konflik yang bikin sedikit panik, keduanya justru jadi alat yang paling saya andalkan: branch untuk eksperimen tanpa takut merusak main, dan force-push (dengan --force-with-lease, bukan sembarangan) untuk membereskan riwayat yang terlanjur berantakan. Yang paling penting sekarang adalah mulai praktik. Buat repository, commit setiap perubahan kecil, dan jangan takut membuat branch.

Recap konsep kunci:

  • Repository: wadah project yang dilacak Git
  • Commit: snapshot perubahan yang permanen
  • Branch: jalur pengerjaan terpisah
  • Merge/Rebase: cara menggabungkan kembali branch
  • Remote: repository di server (GitHub)
  • Push/Pull: sinkronisasi antara lokal dan remote
  • Pull Request: mekanisme code review sebelum merge

Langkah selanjutnya:

  1. Gunakan Git di semua project kamu mulai sekarang — termasuk project pribadi
  2. Kontribusi ke open source di GitHub untuk latihan workflow tim
  3. Pelajari lebih lanjut tentang: interactive rebase, git hooks, dan GitHub Actions

Jika ada pertanyaan, bergabunglah ke komunitas Discord BackendLabs — kami dengan senang hati membantu.

Lanjutkan ke

Membangun REST API dengan Node.js & Express