Modul Pelajar — Git & GitHub

🗺️

Perjalanan Pelajar Fasa Ini

Apa yang bakal anda capai — dan kenapa ia penting untuk kerjaya anda.

🌟

GitHub adalah 'Instagram untuk Developer'

Ini platform anda untuk simpan kod, tunjuk portfolio, dan bekerjasama

▼

GitHub adalah 'Instagram untuk developer'. Ia tempat anda simpan kod, tunjuk portfolio, dan bekerjasama dengan orang lain.

Selepas fasa ini, anda akan ada:

Akaun GitHub dengan profil yang lengkap
Projek-projek yang BOLEH ditunjuk pada majikan
Bukti anda bukan sekadar 'cakap' — anda BINA
Sejarah commit yang menunjukkan konsistensi dan progress
Pull Request yang membuktikan anda boleh kerja dalam pasukan

Ingat: Dalam industri, resume boleh tipu. GitHub tidak. Tunjuk kod anda — biar kod yang bercakap.

🤔

Apa Itu Git & GitHub?

Konsep asas yang perlu difahami sebelum mula.

📌

Git — Sistem Kawalan Versi

Definisi mudah dan kenapa ia penting

▼

Git adalah alat yang merakam setiap perubahan pada kod anda. Ianya seperti "mesin masa" untuk folder projek anda.

🌟 Kenapa Git Penting?

Sejarah lengkap — setiapa perubahan direkod, boleh balik bila-bila masa
Cabang (branch) — boleh cuba idea baru tanpa risau rosakkan kod utama
Kolaborasi — ramai orang boleh kerja pada projek sama serentak
Backup — repositori ada di banyak tempat (lokal dan remote)
Accountability — tahu siapa buat apa dan bila

Ingat: Git berjalan di komputer anda (tempatan). Anda tak perlukan internet untuk guna Git. GitHub adalah platform dalam talian yang menggunakan Git.

🌐

GitHub — Platform Awan untuk Git

GitHub adalah repositori Git di awan

▼

GitHub adalah perkhidmatan hosting untuk repositori Git. Ianya seperti "Google Drive untuk kod" tetapi dengan superpowers kolaborasi.

Apa Yang GitHub Tambah?

Remote repo — simpan kod di awan, akses dari mana-mana
Pull Request (PR) — minta orang lain review kod sebelum merge
Issues — sistem tracking untuk bug dan feature request
Actions (CI/CD) — automasi test dan deploy
Projects — papan pengurusan projek (Kanban)
GitHub Pages — host laman web percuma

Ringkasan: Git = enjin. GitHub = dashboard + cloud storage.

🔧

Instalasi & Setup

Persediaan awal sebelum guna Git dan GitHub.

💻

Langkah 1: Install Git

Cara install Git ikut sistem operasi

▼

🪟 Windows

# Muat turun dari:
https://git-scm.com/download/win

# Atau guna winget (Windows 11):
winget install --id Git.Git -e --source winget

🍎 macOS

# Guna Homebrew:
brew install git

# Atau muat turun dari:
https://git-scm.com/download/mac

🐧 Linux (Ubuntu/Debian)

sudo apt update
sudo apt install git

✅ Sahkan Pemasangan

git --version
# Output: git version 2.x.x

👤

Langkah 2: Konfigurasi Awal Git

Set nama dan email untuk identiti commit

▼

Git perlukan nama dan email untuk merekod siapa buat commit. Set sekali je:

# Ganti dengan nama dan email anda
git config --global user.name "Nama Anda"
git config --global user.email "email@anda.com"

# Set default branch name ke "main"
git config --global init.defaultBranch main

# Semak konfigurasi
git config --list

Penting: Guna email yang sama dengan akaun GitHub anda. Nanti GitHub boleh kaitkan commit dengan akaun anda.

🐙

Langkah 3: Buka Akaun GitHub

Daftar akaun GitHub percuma

▼

Buka github.com dan klik "Sign up"
Masukkan email, password, dan username
Verify email (check inbox/spam)
Pilih plan percuma (Free)
Selesai! Dah boleh guna GitHub

Tip: Guna username yang profesional — bakal majikan akan tengok GitHub anda!

📁

Workflow Tempatan (Local)

Inisiasi repo, add, dan commit — nadi utama Git.

📂

Mulakan Repositori Baru

git init — cipta repositori git dalam folder

▼

Buka terminal dan navigasi ke folder projek anda:

# Buat folder projek baru
mkdir projek-pertama
cd projek-pertama

# Init repositori git
git init
# Output: Initialized empty Git repository in .../projek-pertama/.git/

Apa jadi? Git cipta folder .git — tempat simpan semua data versi. Folder ni penting, jangan padam!

# Confirm folder .git wujud
ls -la
# Output: drwxr-xr-x  .git

Ingat: git init hanya perlu sekali untuk setiap projek. Lepas ni terus guna git add dan git commit.

➕

Stage Perubahan (git add)

git add — pilih perubahan yang nak disimpan

▼

Sebelum "simpan" perubahan, kita perlu stage dia dulu:

# Cipta fail baru
echo "# Projek Pertama" > README.md
echo "node_modules/" > .gitignore

# Check status
git status
# Output: Ada "Untracked files" — Git nampak fail baru

# Stage fail tertentu
git add README.md .gitignore

# Atau stage semua fail sekali
git add .

# Check status lagi
git status
# Output: "Changes to be committed" — fail dah stage

🧠 Staging Area

"Staging area" atau "index" adalah ruang persediaan sebelum commit. Ibarat meja di dapur — korang letak bahan-bahan yang nak dimasak sebelum mula masak. Guna git add untuk letak bahan ke meja.

# Lepas edit fail, stage semula
git add README.md

# Nak keluarkan dari staging (undo add)
git restore --staged README.md

💾

Simpan Snapshot (git commit)

git commit — simpan snapshot tetap ke sejarah

▼

Commit adalah "save point". Ia merakam apa yang ada di staging area pada masa itu.

# Commit dengan mesej ringkas
git commit -m "commit pertama: tambah README dan gitignore"

# Output:
# [main (root-commit) abc1234] commit pertama: tambah README dan gitignore
#  2 files changed, 2 insertions(+)

# Semak sejarah commit
git log
# Output ringkas:
git log --oneline
# abc1234 (HEAD -> main) commit pertama: tambah README dan gitignore

✍️ Cara Tulis Mesej Commit

Guna Bahasa Melayu atau Inggeris — konsisten
Mesej ringkas tapi deskriptif (kurang 50 aksara)
Guna imperatif: "tambah", "baiki", "kemaskini"
Contoh baik: "tambah fungsi login", "baiki bug navbar", "kemaskini README"
Contoh tak baik: "update", "fixed", "aaa", "commit baru"

Ingat: Commit kecil dan kerap lebih baik dari commit besar dan jarang. Commit setiap kali satu unit logik selesai.

🔄

Workflow Asas Git (Kitaran)

Kitaran asas: edit → add → commit → ulang

▼

┌──────────┐ ┌──────────┐ ┌──────────┐ │ Edit │────▶│ git add │────▶│ git │ │ Fail │ │ (Stage) │ │ commit │ └──────────┘ └──────────┘ └──────────┘ │ ▼ ┌──────────┐ │ Sejarah │ │ Commit │ └──────────┘

Edit fail dalam projek anda (code .)
Stage perubahan yang nak disimpan (git add)
Commit dengan mesej yang jelas (git commit -m "mesej")
Ulang langkah 1-3 setiap kali ada perubahan logik

☁️

GitHub — Remote Repo & Push

Sambung repo tempatan ke GitHub dan hantar kod.

🌍

Cipta Repositori di GitHub

Buat repo kosong di GitHub.com

▼

Login ke github.com
Klik ikon + di kanan atas → "New repository"
Masukkan nama repo (cth: projek-pertama)
Tambah description (optional) — "Projek pertama saya belajar Git"
Pilih Public (atau Private)
JANGAN tick "Initialize this repository with a README" (sebab kita dah ada)
Klik "Create repository"

Tip: Repo Public — semua orang boleh tengok. Sesuai untuk portfolio dan open source. Repo Private — hanya anda dan kolaborator jemputan.

📤

Push Kod ke GitHub

git remote add + git push

▼

Lepas cipta repo di GitHub, akan nampak arahan. Guna yang ni:

# Sambung repo tempatan ke remote GitHub
git remote add origin https://github.com/username/projek-pertama.git

# Semak remote yang dah setup
git remote -v
# Output:
# origin  https://github.com/username/projek-pertama.git (fetch)
# origin  https://github.com/username/projek-pertama.git (push)

# Push branch main ke GitHub
git push -u origin main

Lepas ni, refresh GitHub — kod anda dah online!

📝 Nota

origin — nama default untuk remote GitHub
-u (upstream) — set origin/main sebagai default untuk push/pull akan datang
Lepas guna -u sekali, kali seterusnya cukup git push je

Authentication: GitHub mungkin minta username/password atau token. Guna Personal Access Token (PAT) — Settings → Developer settings → Personal access tokens → Tokens (classic).

📩

Clone Repo Dari GitHub

git clone — salin repo orang lain

▼

Nak dapatkan repositori orang lain (atau repositori sendiri dari komputer lain):

# Dapatkan URL repo dari GitHub (butang Code → HTTPS)
git clone https://github.com/username/nama-repo.git

# Masuk folder repo
cd nama-repo

# Dah sedia — semua sejarah commit pun ada!

🧠 git clone vs git init

git init — mula repo baru dari kosong
git clone — salin repo sedia ada (dah ada .git, remote, sejarah commit)

Tip: Guna git clone untuk dapatkan kod dari GitHub — dah siap dengan remote setup. Tak payah git remote add lagi.

🌿

Branch & Merge

Kerja dalam "dunia selari" dan gabungkan semula.

🌱

Apa Itu Branch?

Branch = cabang = dunia selari

▼

Branch adalah cabang dari kod utama yang membolehkan anda:

Cuba feature baru tanpa risau rosakkan kod utama
Kerja dalam pasukan tanpa ganggu orang lain
Eksperimen dan kalau tak jadi, padam branch je

main: A───B───C───D───E │ └───F───G───H ← feature-login (branch)

Titik C adalah tempat branch "feature-login" mula. Commit F, G, H berlaku dalam branch tu tanpa mengubah main. Bila feature dah siap, kita merge balik ke main.

🔀

Cara Buat & Guna Branch

git branch, git checkout, git merge

▼

# 1. Semak branch semasa
git branch
# * main (tanda * = branch aktif)

# 2. Buat branch baru
git branch feature-navbar

# 3. Tukar ke branch baru
git checkout feature-navbar
# Atau satu langkah: git checkout -b feature-navbar

# 4. Buat perubahan
echo "nav { background: #333; }" > nav.css
git add nav.css
git commit -m "tambah navbar styling"

# 5. Balik ke main
git checkout main

# 6. Merge branch feature-navbar ke main
git merge feature-navbar

# 7. Padam branch (kalau dah tak perlu)
git branch -d feature-navbar

📋 Naming Convention Branch

Jenis	Format	Contoh
Feature	`feature/nama`	`feature/login-page`
Bug Fix	`fix/nama`	`fix/navbar-height`
Hot Fix	`hotfix/nama`	`hotfix/crash-login`
Experiment	`experiment/nama`	`experiment/new-api`

⚔️

Merge Conflict — Bila & Macam Mana

Bila dua branch ubah line sama, Git konfius

▼

Merge conflict berlaku bila dua branch ubah line yang sama dalam fail yang sama. Git tak tahu mana satu nak simpan.

# Tanda conflict dalam fail:
<<<<<<< HEAD
Ini perubahan dari branch main
=======
Ini perubahan dari branch feature-x
>>>>>>> feature-x

🔧 Cara Resolve Conflict

Buka fail yang ada conflict (VS Code akan highlight)
Pilih: guna Current Change (main), Incoming Change (branch), atau kedua-duanya
Padam tanda <<<<<<<, =======, >>>>>>>
Simpan fail
git add nama-fail
git commit — Git akan cipta merge commit

Ingat: Merge conflict bukan benda buruk! Ia bermakna Git terlalu jujur untuk pilih mana satu — biar korang decide sendiri. Normal dalam kolaborasi.

🔄

Pull Request (PR)

Cara standard untuk kolaborasi — minta review sebelum merge.

📥

Apa Itu Pull Request?

PR = permintaan untuk merge perubahan

▼

Pull Request (PR) adalah permintaan rasmi untuk menggabungkan perubahan dari satu branch ke branch lain.

📋 Proses PR

Buat branch dari main — git checkout -b feature-anda
Buat perubahan dan commit — git add && git commit
Push branch ke GitHub — git push -u origin feature-anda
Buka GitHub → klik "Compare & pull request"
Tulis diskripsi — apa yang anda ubah dan kenapa
Assign reviewer — minta orang lain semak
Review — reviewer bagi komen, approve, atau minta perubahan
Merge — klik "Merge pull request"

Best Practice: Buat PR awal-awal (draft PR) dan tulis "WIP: " kat title. Bila dah siap, tukar ke "Ready for review".

👁️

Cara Review & Merge PR

Sebagai reviewer — semak kod, komen, approve

▼

👀 Sebagai Reviewer

Buka PR di GitHub → tab "Files changed"
Baca setiap perubahan — fokus pada logic, bukan styling
Klik line tertentu untuk tinggalkan komen
Klik "Review changes" → pilih:
— Comment: feedback biasa
— Approve: setuju, boleh merge
— Request changes: ada yang perlu dibaiki

🔀 Sebagai Penggabung

# Lepas approve, ada 3 pilihan merge:
Create a merge commit — standard (simpan semua commit)
Squash and merge — satukan semua commit jadi satu
Rebase and merge — sejarah linear, tanpa merge commit

Untuk pemula, guna "Create a merge commit" je dulu.

🎫

GitHub Issues

Tracking bugs, feature requests, dan tugas.

📌

Buat & Urus Isu

Issues = sistem tracking untuk projek

▼

Issues digunakan untuk track segala yang perlu dibuat — bug, feature, improvement, tugas.

📝 Cara Buat Isu

Buka repo di GitHub → tab "Issues" → "New issue"
Tulis Title yang jelas: "Login button tak responsive di mobile"
Tulis Description:
— Apa yang berlaku
— Langkah untuk reproduce (kalau bug)
— Apa yang sepatutnya berlaku
— Screenshot (kalau ada)
Assign Labels: bug, enhancement, documentation, etc.
Assign Assignee — siapa yang akan selesaikan
Assign Project — kalau guna GitHub Projects
Klik "Submit new issue"

🔗 Auto-Close Isu dengan Commit

# Dalam mesej commit, guna keyword ni:
git commit -m "baiki button login responsive di mobile

Fixes #12"

Bila PR ni di-merge ke main, isu #12 akan auto close. Keyword lain: Closes #, Resolves #, Fixes #.

Best Practice: Guna templates untuk issue — GitHub ada fitur "Issue templates". Pelajar akan lebih konsisten cara lapor.

🤖

GitHub MCP dalam Claude Code

Guna kuasa AI untuk urus GitHub terus dari terminal.

🔌

Apa Itu GitHub MCP?

MCP = Model Context Protocol — sambung Claude ke GitHub

▼

GitHub MCP (Model Context Protocol) adalah plugin yang membolehkan Claude Code berinteraksi dengan GitHub API secara langsung.

Apa Yang Boleh Dibuat?

Melihat dan mengurus Pull Request
Membuat code review automatik
Mengurus Issues (buat, tutup, assign)
Menyemak status CI/CD
Membaca kod dalam PR tanpa buka GitHub

🔐

Cara Setup GitHub MCP

Satu kali setup, lepas tu terus guna

▼

Buka Claude Code dalam terminal
Taip: Guna GitHub MCP untuk authenticate
Claude akan jalankan mcp__github__authenticate
Ikut arahan OAuth — login ke akaun GitHub
Selesai! Dah boleh guna GitHub MCP

Alternatif: Kalau OAuth tak jalan, guna gh auth login di terminal — Claude akan detect token yang dah ada.

💬

Contoh Penggunaan GitHub MCP

Arahan yang boleh anda beri kepada Claude

▼

📋 Contoh Prompt

"Semak pull request #5 dalam repo ini dan bagi ringkasan
perubahan yang dibuat."

"Buat issue baru dengan title 'Tambah dark mode' dan
description: 'Pengguna minta dark mode untuk aplikasi.
Sila tambah CSS variables untuk warna gelap.'"

"Review PR #3 dan senaraikan
Apa yang berubah
Isu keselamatan yang mungkin
Cadangan penambahbaikan"

"List semua open issues yang berlabel 'bug' dan assign
kepada saya."

Power Move: Guna GitHub MCP + Sequential Thinking untuk buat code review yang mendalam — Claude akan analisis PR langkah demi langkah.

🤝

Kolaborasi: Fork → Clone → PR → Merge

Workflow lengkap kolaborasi open source.

🍴

Fork & Clone

Salin repo orang lain ke akaun GitHub anda

▼

Fork = salin repositori orang lain ke akaun GitHub sendiri. Clone = salin ke komputer tempatan.

# 1. Buka repo GitHub orang lain
# 2. Klik butang "Fork" di kanan atas
# 3. Pilih akaun sendiri → "Create fork"

# 4. Clone fork anda ke komputer
git clone https://github.com/username/nama-repo.git
cd nama-repo

# 5. Setup upstream (repo asal) untuk sync perubahan
git remote add upstream https://github.com/original-owner/nama-repo.git

# 6. Semak remote
git remote -v
# origin   → fork anda
# upstream → repo asal

Ingat: Fork berbeza dengan branch. Fork adalah salinan penuh repo di GitHub. Branch adalah cabang dalam repo yang sama.

🔄

Workflow Kolaborasi Lengkap

Dari fork hingga PR di-merge

▼

1. Fork repo (GitHub) │ 2. Clone fork (git clone) │ 3. Buat branch (git checkout -b feature) │ 4. Edit & commit (git add + git commit) │ 5. Push branch ke fork (git push -u origin feature) │ 6. Buka Pull Request (GitHub) │ 7. PR review & discussion (GitHub) │ 8. Merge PR (GitHub — maintainer) │ 9. Sync fork dengan upstream (git pull upstream main) │ 10. Padam branch (git branch -d feature)

📝 Nota Penting

Jangan guna main branch untuk buat perubahan — guna branch feature
Sync fork selalu — git pull upstream main
Commit message yang baik memudahkan reviewer
Jangan takut feedback — PR review adalah peluang belajar

📖

Case Studies — Git & GitHub dalam Aksi Sebenar

Dua senario dunia sebenar yang menunjukkan kuasa Git dan GitHub dalam pembangunan.

🌐

Case 1: Portfolio di GitHub Pages

Deploy portfolio peribadi dengan auto-deploy via GitHub Actions

▼

🎯 Senario

Anda telah membina portfolio peribadi dalam Fasa 5 (HTML/CSS). Sekarang, anda mahu ia boleh diakses oleh dunia — secara percuma dan profesional.

📋 Langkah-langkah

Buat repo GitHub baru: username.github.io (Public)
Clone repo ke komputer tempatan: git clone https://github.com/username/username.github.io.git
Salin semua portfolio code (HTML, CSS, JS) ke folder repo
Commit dan push: git add . && git commit -m "deploy: portfolio v1" && git push
Buka GitHub repo → Settings → Pages → Pilih branch main → Save
Tunggu 1-2 minit — portfolio anda akan live di https://username.github.io

⚡ Auto-Deploy dengan GitHub Actions

Setiap kali anda push perubahan, GitHub Actions boleh deploy semula portfolio secara automatik:

# Buat fail: .github/workflows/deploy.yml
name: Deploy Portfolio
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: .

✅ Hasil

Portfolio anda live 24/7 — percuma
Setiap git push = auto-deploy (melalui GitHub Actions)
URL profesional: username.github.io
Boleh dikongsi dalam resume dan LinkedIn
Majikan boleh lihat kod portfolio terus di GitHub

Power Tip: Tambah domain kustom (cth: namasaya.com) di GitHub Pages settings untuk portofolio yang lebih profesional.

👥

Case 2: Collaboration Dua Pelajar

Pair-programming dengan branch, PR, dan resolve konflik

▼

🎯 Senario

Pelajar A dan Pelajar B sedang membina halaman web mudah untuk projek kelas. Mereka menggunakan workflow branch + Pull Request — macam pasukan developer sebenar.

👤 Pelajar A — Membina Feature

Clone repo bersama: git clone https://github.com/projek-kelas/laman-web.git
Buat branch baru: git checkout -b feature-header
Bina header komponen dalam header.html dan style.css
Commit: git add . && git commit -m "feat: add responsive header"
Push: git push -u origin feature-header
Buka Pull Request ke branch main
Assign Pelajar B sebagai reviewer

👤 Pelajar B — Review & Merge

Buka PR di GitHub → tab "Files changed"
Review kod — tinggalkan komen:
— "Bagus! Maybe tambah alt text pada logo?"
— "CSS ni responsive ke untuk mobile?"
Pelajar A baiki berdasarkan feedback — commit tambahan muncul automatik dalam PR
Pelajar B approve PR: "Review changes" → "Approve"
Merge PR: "Merge pull request" → "Confirm merge"

⚔️ Bonus: Konflik & Resolve

Bayangkan Pelajar A dan B dua-dua edit baris yang sama dalam index.html. Bila PR nak di-merge, GitHub akan bagitahu ada merge conflict.

# Tanda conflict dalam fail:
<<<<<<< feature-header
Selamat Datang ke Projek Kami
=======
Welcome to Our Project
>>>>>>> main

Pelajar B (atau A) buka fail yang conflict di editor
Pilih versi mana nak simpan — atau gabungkan kedua-duanya
Padam tanda <<<<<<<, =======, >>>>>>>
git add index.html
git commit -m "resolve conflict: gabung header EN dan BM"
Push dan merge

✅ Hasil Pembelajaran

Kedua-dua pelajar faham workflow branch + PR
Mereka alami sendiri proses code review — bukan sekadar teori
Mereka belajar resolve konflik — kemahiran yang sangat diperlukan di industri
Komunikasi pasukan bertambah baik melalui review comments
Mereka bersedia untuk kerja pasukan sebenar

Ingat: Konflik bukan kegagalan. Ia normal dalam kolaborasi. Yang penting adalah cara anda selesaikannya — dengan komunikasi dan kerjasama.