Edit Bab

Batal

# Bab 2: Git dan Version Control

Kalau DevOps ada satu kemahiran yang anda wajib kuasai sebelum yang lain, ia adalah Git. Serius, tanpa Git, anda tidak boleh melangkah lebih jauh dalam dunia DevOps. Setiap CI/CD pipeline bermula dengan Git. Setiap Infrastructure as Code disimpan dalam Git. Setiap kerjasama pasukan bergantung kepada Git.

Berita baiknya, Git tidak susah. Ia cuma perlu masa untuk menjadi selesa. Dan kalau anda pernah self-host Gitea dalam homelab anda, anda sudah pun berjinak dengannya.

**Apa yang anda akan belajar:**

- Kenapa Git penting dalam DevOps
- Arahan asas Git yang anda perlukan setiap hari
- Strategi branching untuk pasukan (GitFlow dan trunk-based)
- Pull request dan code review
- Platform Git hosting (GitHub, GitLab, Gitea)
- Penggunaan `.gitignore` dan Git hooks
- Workflow praktikal yang boleh terus digunakan

## 2.1 Kenapa Git Penting

Sebelum Git, developer menyimpan kod dengan cara yang mengerikan. Ada yang guna folder bernama `projek_v1`, `projek_v2`, `projek_v2_final`, `projek_v2_final_BETUL`. Ada yang email fail zip kepada rakan sekerja. Ada yang guna shared drive dan berdoa tiada siapa tulis ganti fail mereka.

Git menyelesaikan semua masalah ini. Ia adalah sistem **version control** yang menjejaki setiap perubahan pada kod anda. Setiap perubahan dicatat dengan siapa yang buat, bila, dan kenapa. Anda boleh kembali ke mana-mana versi terdahulu pada bila-bila masa.

Dalam konteks DevOps, Git bukan sekadar tempat simpan kod. Ia adalah:

- **Sumber kebenaran tunggal (single source of truth)** untuk semua kod dan konfigurasi
- **Pencetus (trigger)** untuk CI/CD pipeline. Bila anda push kod, pipeline bermula
- **Alat kerjasama** yang membolehkan ramai orang bekerja pada kod yang sama tanpa konflik
- **Audit trail** yang merekodkan siapa ubah apa dan bila

> **Nota Beginner:** Version control bukan hanya untuk developer. Sebagai DevOps engineer, anda akan simpan Terraform files, Ansible playbooks, Dockerfile, Kubernetes manifests, dan pelbagai konfigurasi dalam Git. Kalau ia boleh ditulis sebagai teks, ia patut disimpan dalam Git.

## 2.2 Arahan Asas Git

Mari kita mula dengan arahan yang anda akan guna setiap hari. Saya andaikan anda sudah pasang Git seperti yang ditunjukkan dalam bab sebelumnya.

### Mencipta Repository Baru

```bash
# Buat direktori baru untuk projek
mkdir projek-devops
cd projek-devops

# Inisialisasi Git repository
git init

# Anda akan nampak mesej:
# Initialized empty Git repository in /home/user/projek-devops/.git/
```

Arahan `git init` mencipta folder `.git` tersembunyi yang menyimpan semua sejarah dan metadata repository anda. Jangan sesekali padam folder ini secara manual.

### Aliran Kerja Asas: Add, Commit, Push

Inilah aliran kerja Git yang paling asas. Anda akan ulang proses ini berpuluh kali sehari.

```bash
# 1. Buat atau ubah fail
echo "# Projek DevOps Pertama" > README.md

# 2. Semak status - lihat apa yang berubah
git status

# Output akan tunjukkan README.md sebagai "untracked file"

# 3. Tambah fail ke staging area
git add README.md

# 4. Commit perubahan dengan mesej yang bermakna
git commit -m "Tambah README untuk projek"

# 5. (Selepas setup remote) Push ke server
git push origin main
```

Mari kita fahamkan setiap langkah:

**`git status`** menunjukkan keadaan semasa working directory anda. Fail boleh berada dalam tiga keadaan: untracked (Git belum jejak), modified (sudah diubah tetapi belum staged), atau staged (sedia untuk commit).

**`git add`** memindahkan fail dari working directory ke staging area. Staging area adalah seperti "ruang menunggu" sebelum perubahan disimpan secara rasmi.

**`git commit`** menyimpan snapshot semua perubahan dalam staging area ke dalam sejarah Git. Setiap commit mempunyai ID unik (hash), mesej, penulis, dan cap masa.

**`git push`** menghantar commit tempatan anda ke repository remote (seperti GitHub atau GitLab).

> **Nota Beginner:** Fikirkan Git seperti sistem "save game." `git add` ialah memilih apa yang nak disimpan. `git commit` ialah menekan butang save. `git push` ialah upload save file ke cloud supaya tidak hilang.

### Melihat Sejarah

```bash
# Lihat senarai commit
git log

# Lihat log dalam format ringkas (satu baris per commit)
git log --oneline

# Lihat log dengan graf visual untuk branches
git log --oneline --graph --all

# Lihat perubahan yang belum di-commit
git diff

# Lihat perubahan yang sudah di-stage
git diff --staged
```

### Clone Repository Sedia Ada

Kebanyakan masa, anda tidak akan mula dari kosong. Anda akan clone repository yang sudah wujud.

```bash
# Clone dari GitHub
git clone https://github.com/username/repo-name.git

# Clone dari Gitea homelab anda
git clone https://gitea.homelab.local/username/repo-name.git

# Clone dan beri nama direktori berbeza
git clone https://github.com/username/repo-name.git nama-baru
```

### Pull Perubahan Terkini

Sebelum mula bekerja setiap hari, pastikan anda pull perubahan terkini dari remote.

```bash
# Pull perubahan terkini
git pull origin main

# Atau kalau anda sudah set upstream
git pull
```

Saya cadangkan jadikan ini tabiat pertama setiap pagi sebelum mula menulis kod. Ini mengelakkan konflik yang tidak perlu.

## 2.3 Branching: Bekerja Secara Selari

Branching adalah salah satu ciri paling berkuasa dalam Git. Ia membolehkan anda bekerja pada ciri baru atau pembetulan pepijat tanpa mengganggu kod utama.

Bayangkan kod utama anda seperti jalan raya utama. Branch adalah jalan keluar sementara. Anda keluar dari jalan utama, buat kerja anda, dan apabila siap, anda masuk semula ke jalan utama.

```bash
# Lihat semua branch
git branch

# Buat branch baru
git branch feature/tambah-login

# Tukar ke branch baru
git checkout feature/tambah-login

# Atau buat dan tukar sekaligus (cara lebih ringkas)
git checkout -b feature/tambah-login

# Selepas siap, kembali ke main
git checkout main

# Gabungkan branch ke main
git merge feature/tambah-login

# Padam branch yang sudah digabung
git branch -d feature/tambah-login
```

> **Nota Beginner:** Penamaan branch yang baik sangat penting. Gunakan format seperti `feature/nama-ciri`, `bugfix/nama-pepijat`, atau `hotfix/nama-pembetulan`. Ini memudahkan semua orang dalam pasukan memahami tujuan setiap branch.

## 2.4 Strategi Branching

Apabila anda bekerja dalam pasukan, anda perlukan strategi branching yang jelas supaya semua orang tahu cara bekerja bersama. Dua strategi yang paling popular ialah GitFlow dan trunk-based development.

### GitFlow

GitFlow adalah strategi yang lebih berstruktur. Ia menggunakan beberapa jenis branch:

- **`main`** (atau `master`): Kod production yang stabil
- **`develop`**: Branch integrasi untuk ciri-ciri baru
- **`feature/*`**: Branch untuk setiap ciri baru
- **`release/*`**: Branch untuk menyediakan release baru
- **`hotfix/*`**: Branch untuk pembetulan segera di production

```
main ──────●──────────────────●──────────── (production)
            \                /
develop ─────●───●───●───●──● ───────────── (integration)
              \     / \     /
feature/a ─────●───●   \   /
                    feature/b ──●───●
```

Aliran kerja GitFlow:

```bash
# Mula ciri baru dari develop
git checkout develop
git checkout -b feature/user-auth

# Buat kerja, commit...
git add .
git commit -m "Tambah fungsi login"

# Selesai, gabung balik ke develop
git checkout develop
git merge feature/user-auth

# Sedia untuk release
git checkout -b release/1.0.0
# Buat testing, fix bugs...

# Deploy ke production
git checkout main
git merge release/1.0.0
git tag v1.0.0
```

GitFlow sesuai untuk projek yang mempunyai jadual release yang tetap, contohnya release sebulan sekali atau setiap sprint.

### Trunk-Based Development

Trunk-based development adalah pendekatan yang lebih ringkas dan digemari dalam budaya DevOps moden. Semua developer bekerja pada satu branch utama (trunk), biasanya `main`.

```
main ──●──●──●──●──●──●──●──●──●── (semua kerja di sini)
        \   /       \   /
    short-lived   short-lived
     branch        branch
```

Prinsip utama:

- Branch hidup **tidak lebih dari satu atau dua hari**
- Perubahan dibuat dalam bahagian kecil
- Feature flags digunakan untuk menyembunyikan ciri yang belum siap
- CI/CD pipeline berjalan pada setiap commit ke main

```bash
# Buat branch pendek untuk satu tugas kecil
git checkout -b fix/typo-readme

# Buat perubahan kecil
git add .
git commit -m "Betulkan typo dalam README"

# Push dan buat pull request
git push origin fix/typo-readme

# Selepas di-review dan di-merge, padam branch
git branch -d fix/typo-readme
```

> **Nota Beginner:** Kalau anda baru bermula, saya cadangkan trunk-based development. Ia lebih mudah difahami dan lebih sesuai dengan amalan CI/CD. GitFlow cenderung menjadi terlalu kompleks untuk pasukan kecil.

Dari pengalaman saya, kebanyakan pasukan DevOps yang matang menggunakan trunk-based development kerana ia menggalakkan perubahan kecil dan kerap, yang sememangnya nadi DevOps.

## 2.5 Pull Request dan Code Review

Pull request (PR) atau merge request (MR) adalah mekanisme untuk meminta rakan sepasukan menyemak kod anda sebelum ia digabungkan ke branch utama. Ini adalah amalan penting dalam DevOps kerana ia:

- Menangkap pepijat awal sebelum masuk ke production
- Berkongsi pengetahuan dalam pasukan
- Mengekalkan kualiti kod yang konsisten
- Mencipta dokumentasi tentang kenapa perubahan dibuat

### Aliran Kerja Pull Request

```bash
# 1. Buat branch untuk tugasan anda
git checkout -b feature/tambah-health-check

# 2. Buat perubahan dan commit
# Katakan anda tambah health check endpoint
git add .
git commit -m "Tambah /health endpoint untuk monitoring"

# 3. Push branch ke remote
git push origin feature/tambah-health-check

# 4. Buat pull request melalui GitHub/GitLab/Gitea
# Biasanya melalui web interface, atau guna CLI:

# Untuk GitHub CLI
gh pr create --title "Tambah health check endpoint" \
  --body "Menambah /health endpoint supaya monitoring tools boleh periksa status aplikasi"

# Untuk GitLab CLI
glab mr create --title "Tambah health check endpoint" \
  --description "Menambah /health endpoint untuk monitoring"
```

### Tips Code Review Yang Baik

Sebagai reviewer, fokus pada perkara berikut:

1. **Logik kod**: Adakah kod ini betul? Ada edge case yang terlepas?
2. **Keselamatan**: Ada credential yang terdedah? Input yang tidak disahkan?
3. **Kebolehbacaan**: Bolehkah orang lain faham kod ini tanpa penjelasan?
4. **Testing**: Ada ujian untuk perubahan ini?
5. **Dokumentasi**: Perlu ke kemaskini dokumentasi?

Sebagai penulis PR, bantu reviewer anda:

- Tulis deskripsi yang jelas tentang apa dan kenapa
- Pastikan PR bersaiz kecil (kurang 400 baris kalau boleh)
- Sertakan screenshot kalau ada perubahan UI
- Jalankan semua ujian sebelum minta review

## 2.6 Platform Git Hosting

Anda perlukan tempat untuk menyimpan repository Git anda secara remote. Berikut adalah pilihan utama.

### GitHub

Platform paling popular. Percuma untuk repository awam dan peribadi. Dilengkapi dengan GitHub Actions untuk CI/CD.

```bash
# Setup SSH key untuk GitHub
ssh-keygen -t ed25519 -C "email@anda.com"
cat ~/.ssh/id_ed25519.pub
# Salin dan tampal ke GitHub Settings > SSH Keys

# Uji sambungan
ssh -T git@github.com
```

### GitLab

Platform lengkap dengan CI/CD terbina dalam. Boleh di-self-host. Sangat popular dalam organisasi enterprise.

### Gitea (Dari Homelab Anda)

Kalau anda sudah self-host Gitea dalam homelab, tahniah. Anda sudah ada platform Git hosting sendiri. Ini sangat bagus untuk belajar kerana anda mempunyai kawalan penuh.

```bash
# Clone dari Gitea homelab
git clone git@gitea.homelab.local:username/projek.git

# Tambah remote untuk GitHub sebagai backup
git remote add github git@github.com:username/projek.git

# Push ke kedua-dua remote
git push origin main
git push github main
```

> **Nota Beginner:** Saya cadangkan anda guna GitHub untuk projek awam dan portfolio, dan Gitea dalam homelab untuk eksperimen peribadi. Mempunyai profil GitHub yang aktif adalah aset besar apabila memohon kerja DevOps.

## 2.7 Fail `.gitignore`

Fail `.gitignore` memberitahu Git fail mana yang tidak perlu dijejaki. Ini sangat penting kerana anda tidak mahu commit perkara seperti password, API key, atau fail yang dijana secara automatik.

Buat fail `.gitignore` di root repository anda:

```bash
# Buat .gitignore
cat > .gitignore << 'EOF'
# Fail persekitaran dan rahsia
.env
.env.local
.env.production
*.pem
*.key
credentials.json

# Fail sistem operasi
.DS_Store
Thumbs.db

# Dependencies
node_modules/
vendor/
__pycache__/
*.pyc

# Fail yang dijana
*.log
*.tmp
dist/
build/
*.o
*.class

# Fail IDE
.vscode/
.idea/
*.swp
*.swo

# Fail Docker yang tidak perlu
docker-compose.override.yml

# Terraform state (mengandungi maklumat sensitif)
*.tfstate
*.tfstate.backup
.terraform/
EOF
```

Ini adalah antara kesilapan yang paling biasa saya nampak. Developer baru sering terlupa untuk setup `.gitignore` dan akhirnya commit fail `.env` yang mengandungi password database ke GitHub. Kalau ini berlaku, anggap password itu sudah terdedah dan tukar segera, walaupun anda padam fail itu kemudian. Sejarah Git menyimpan segala-galanya.

> **Nota Beginner:** Kalau anda sudah tersilap commit fail sensitif, gunakan `git filter-branch` atau alat seperti BFG Repo Cleaner untuk membuangnya dari sejarah. Tetapi langkah pertama tetap menukar semua credential yang terdedah.

## 2.8 Git Hooks

Git hooks adalah script yang berjalan secara automatik pada titik-titik tertentu dalam aliran kerja Git. Ia adalah bentuk automation yang paling asas dan sangat berguna.

Hooks disimpan dalam folder `.git/hooks/`. Berikut adalah beberapa hooks yang berguna.

### Pre-commit Hook

Berjalan sebelum commit dibuat. Sesuai untuk memeriksa kualiti kod.

```bash
# Buat pre-commit hook
cat > .git/hooks/pre-commit << 'HOOK'
#!/bin/bash

echo "Menjalankan pemeriksaan sebelum commit..."

# Semak kalau ada fail .env yang cuba di-commit
if git diff --cached --name-only | grep -q '\.env'; then
    echo "AMARAN: Anda cuba commit fail .env!"
    echo "Sila keluarkan fail .env dari staging area."
    exit 1
fi

# Semak kalau ada TODO yang tertinggal
if git diff --cached | grep -q 'TODO'; then
    echo "AMARAN: Terdapat TODO dalam kod anda."
    echo "Pastikan ini disengajakan."
    # Tidak block commit, hanya amaran
fi

echo "Pemeriksaan selesai. Meneruskan commit."
HOOK

# Jadikan boleh dilaksanakan
chmod +x .git/hooks/pre-commit
```

### Commit-msg Hook

Berjalan selepas mesej commit ditulis. Sesuai untuk memastikan format mesej commit konsisten.

```bash
# Buat commit-msg hook
cat > .git/hooks/commit-msg << 'HOOK'
#!/bin/bash

commit_msg=$(cat "$1")

# Pastikan mesej commit bermula dengan huruf besar
if ! echo "$commit_msg" | head -1 | grep -qE '^[A-Z]'; then
    echo "RALAT: Mesej commit mesti bermula dengan huruf besar."
    echo "Contoh: 'Tambah fungsi login' bukan 'tambah fungsi login'"
    exit 1
fi

# Pastikan mesej commit sekurang-kurangnya 10 aksara
if [ ${#commit_msg} -lt 10 ]; then
    echo "RALAT: Mesej commit terlalu pendek (minimum 10 aksara)."
    exit 1
fi
HOOK

chmod +x .git/hooks/commit-msg
```

> **Nota Beginner:** Hooks dalam folder `.git/hooks/` tidak dikongsi melalui Git. Untuk berkongsi hooks dengan pasukan, simpan mereka dalam folder seperti `scripts/hooks/` dan buat setup script yang mencipta symlink. Atau lebih baik lagi, gunakan alat seperti `pre-commit` framework.

### Berkongsi Hooks Dengan Pasukan

Cara yang lebih praktikal untuk menguruskan hooks dalam pasukan:

```bash
# Simpan hooks dalam repo
mkdir -p scripts/hooks

# Pindahkan hooks ke folder yang dijejak Git
cp .git/hooks/pre-commit scripts/hooks/pre-commit
cp .git/hooks/commit-msg scripts/hooks/commit-msg

# Buat setup script
cat > scripts/setup-hooks.sh << 'SETUP'
#!/bin/bash
echo "Memasang Git hooks..."

HOOK_DIR=".git/hooks"
SCRIPT_DIR="scripts/hooks"

for hook in "$SCRIPT_DIR"/*; do
    hook_name=$(basename "$hook")
    ln -sf "../../$SCRIPT_DIR/$hook_name" "$HOOK_DIR/$hook_name"
    echo "  Dipasang: $hook_name"
done

echo "Semua hooks telah dipasang."
SETUP

chmod +x scripts/setup-hooks.sh

# Setiap ahli pasukan hanya perlu jalankan:
# ./scripts/setup-hooks.sh
```

## 2.9 Workflow Praktikal: Dari Mula Hingga Akhir

Mari kita gabungkan semua yang telah kita belajar dalam satu contoh workflow yang lengkap. Katakan anda bekerja dalam pasukan dan perlu menambah ciri health check pada aplikasi.

```bash
# 1. Pastikan anda berada di branch main dan up to date
git checkout main
git pull origin main

# 2. Buat branch baru untuk tugasan
git checkout -b feature/health-check

# 3. Buat perubahan
cat > healthcheck.py << 'EOF'
from flask import Flask, jsonify
import datetime

app = Flask(__name__)

@app.route('/health')
def health():
    return jsonify({
        "status": "healthy",
        "timestamp": datetime.datetime.now().isoformat(),
        "version": "1.0.0"
    })

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)
EOF

# 4. Semak apa yang berubah
git status
git diff

# 5. Stage dan commit
git add healthcheck.py
git commit -m "Tambah health check endpoint untuk monitoring"

# 6. Push ke remote
git push origin feature/health-check

# 7. Buat pull request (guna GitHub CLI)
gh pr create \
  --title "Tambah health check endpoint" \
  --body "## Perubahan
- Tambah /health endpoint yang mengembalikan status, timestamp, dan versi
- Endpoint ini akan digunakan oleh monitoring system

## Cara Uji
1. Jalankan: python healthcheck.py
2. Buka: http://localhost:5000/health
3. Pastikan response JSON dikembalikan"

# 8. Selepas PR di-approve dan di-merge, kemas kini local
git checkout main
git pull origin main

# 9. Padam branch yang sudah selesai
git branch -d feature/health-check
```

## 2.10 Situasi Biasa dan Penyelesaian

Berikut adalah beberapa situasi yang anda pasti akan hadapi dan cara menanganinya.

### Merge Conflict

Merge conflict berlaku apabila dua orang mengubah bahagian yang sama dalam fail yang sama.

```bash
# Apabila pull atau merge menyebabkan conflict
git pull origin main
# CONFLICT (content): Merge conflict in config.yml

# Buka fail yang bermasalah
# Anda akan nampak penanda seperti ini:
# <<<<<<< HEAD
# port: 8080
# =======
# port: 3000
# >>>>>>> origin/main

# Edit fail, pilih versi yang betul, buang penanda
# Kemudian:
git add config.yml
git commit -m "Selesaikan merge conflict pada config.yml"
```

### Undo Perubahan

```bash
# Buang perubahan pada fail yang belum di-stage
git checkout -- nama-fail.txt

# Buang fail dari staging area (tetapi kekalkan perubahan)
git reset HEAD nama-fail.txt

# Kembali ke commit sebelumnya (buat commit baru yang membatalkan)
git revert HEAD

# Lihat fail pada commit tertentu
git show abc1234:nama-fail.txt
```

### Stash: Simpan Kerja Sementara

```bash
# Anda tengah coding, tapi perlu tukar branch segera
git stash

# Tukar branch, buat kerja lain
git checkout main
# ... buat sesuatu ...

# Kembali dan ambil semula kerja yang di-stash
git checkout feature/my-feature
git stash pop
```

> **Nota Beginner:** `git stash` sangat berguna apabila anda perlu tukar konteks dengan cepat. Fikirkan ia seperti meletakkan kerja anda dalam laci sementara. `git stash pop` mengeluarkan semula dari laci.

## Ringkasan

Dalam bab ini, kita telah belajar:

- **Git adalah asas DevOps**. Setiap pipeline, setiap IaC, setiap kerjasama pasukan bergantung kepada Git.
- **Arahan asas** (`init`, `add`, `commit`, `push`, `pull`, `clone`) adalah rutin harian anda.
- **Branching** membolehkan kerja selari tanpa mengganggu kod utama.
- **GitFlow** sesuai untuk release berjadual. **Trunk-based development** sesuai untuk CI/CD yang kerap.
- **Pull request** dan **code review** mengekalkan kualiti kod dalam pasukan.
- **`.gitignore`** melindungi fail sensitif daripada masuk ke repository.
- **Git hooks** menjalankan pemeriksaan secara automatik untuk mengekalkan standard.

Git mungkin kelihatan mudah pada permulaan, tetapi ia mempunyai kedalaman yang luar biasa. Jangan risau kalau anda belum ingat semua arahan. Dengan masa dan amalan, ia akan menjadi sebahagian daripada memori otot anda.

Saya cadangkan anda luangkan masa beberapa hari untuk bermain dengan Git. Buat repository dalam homelab Gitea anda, cuba buat branch, simulate merge conflict, dan praktik workflow yang kita bincangkan. Lebih banyak anda praktik, lebih selesa anda akan jadi.

Dalam bab seterusnya, kita akan melihat bagaimana Git menjadi pencetus kepada CI/CD pipeline, iaitu jantung DevOps automation.

Teruskan belajar, anda sedang berada di landasan yang betul.

\newpage