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.

22 menit baca

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

Tentang E-Book Ini

E-book 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 e-book 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?

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?

Git adalah sistem version control yang paling banyak dipakai di dunia. Dibuat oleh Linus Torvalds (pencipta Linux kernel) pada 2005.

Yang membuat Git berbeda dari sistem lainnya:

  • 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 sering membingungkan pemula.

  • 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: Git adalah Microsoft Word (software untuk nulis), GitHub adalah Google Drive (tempat menyimpan dan berbagi dokumen).

Kamu bisa pakai Git tanpa GitHub. Tapi ketika bekerja dalam tim atau ingin backup online, kamu 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 menggunakan Git, kamu perlu memberi tahu Git siapa kamu. Informasi ini akan melekat pada setiap commit yang kamu buat.

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 tahu bahwa kamu adalah pemilik akun tersebut. Ada dua cara:

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)

Repository adalah "wadah" project kamu — folder yang dilacak oleh Git. Di dalamnya Git menyimpan seluruh riwayat perubahan.

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

Ini adalah tiga "zona" yang perlu kamu pahami — ini adalah konsep paling penting di Git:

[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?

Staging area memberi kamu kontrol granular. 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. Ini membuat riwayat commit lebih bersih dan bermakna.

Perintah Dasar: Status, Add, Commit

Cek status:

git status

Output git status 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. Commit message yang baik adalah singkat (maks 72 karakter) dan menjelaskan apa yang berubah, bukan bagaimana.

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). Kamu bisa menggunakan hash ini untuk merujuk ke commit tertentu.

.gitignore: File yang Tidak Perlu Dilacak

Tidak semua file perlu masuk ke Git. File seperti node_modules/, file .env (yang berisi password/secret), atau file hasil build tidak seharusnya 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.

GitHub menyediakan template .gitignore untuk berbagai bahasa/framework. Saat membuat repository baru di GitHub, kamu bisa langsung memilih template.

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?

Branch adalah salah satu fitur paling powerful di Git. Bayangkan kamu sedang mengerjakan fitur login, sementara rekan kamu mengerjakan fitur pencarian produk. Tanpa branch, kalian akan terus-menerus saling mengganggu.

Dengan branch, setiap fitur dikerjakan di "jalur" terpisah. Branch main (atau master) tetap bersih dan stabil — hanya berisi kode yang sudah 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

Gunakan nama yang deskriptif dan konsisten. Beberapa konvensi yang umum:

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

Kadang kamu perlu pindah branch tapi pekerjaanmu belum selesai dan belum siap untuk di-commit. Gunakan 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

Setelah fitur selesai di branch terpisah, kamu perlu 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 mengubah bagian yang sama dari file yang sama. Git tidak bisa memutuskan versi mana yang benar — kamu yang harus memilih.

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

git rebase adalah cara lain untuk mengintegrasikan perubahan. Alih-alih membuat merge commit, rebase "memindahkan" commit-commit branch kamu ke 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

"Remote" adalah repository yang tersimpan di server (bukan di komputermu).

# 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

Gunakan git fetch dulu lalu git diff origin/main jika ingin melihat apa yang berubah di remote sebelum merge.

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

Fork adalah fitur GitHub (bukan Git) yang membuat salinan repository orang lain ke akun GitHub kamu. Ini adalah cara kontribusi ke 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?

Pull Request (PR) adalah cara resmi untuk mengusulkan perubahan kode ke branch utama. Ini adalah mekanisme code review: sebelum kode kamu masuk ke main, satu atau lebih anggota tim akan mereview dan menyetujuinya.

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

Sebagai reviewer, fokus pada:

  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

Gitflow adalah workflow yang populer untuk project dengan release cycle yang teratur.

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)

GitHub Flow lebih simpel dan cocok untuk tim yang melakukan continuous deployment.

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

Conventional Commits adalah konvensi untuk commit message yang structured. Ini memudahkan generate changelog otomatis dan memahami riwayat dengan cepat.

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

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.

Git mungkin terasa overwhelming di awal, tapi semakin sering dipakai, semakin terasa natural. Yang paling penting adalah mulai praktik sekarang. 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