Panduan Lengkap Git dan GitHub untuk Pemula: Dari Nol sampai Mahir

Kenapa Kamu (Seharusnya) Perlu Git

Mungkin kamu pernah ada di posisi ini: folder proyek penuh file bernama final_version_v2_benar.zip, dan setiap mau mengubah kode, hati berdebar karena takut merusak sesuatu yang sudah berjalan. Atau ketika tim mulai bertambah, tidak ada yang tahu siapa mengubah apa — sampai suatu hari muncul error misterius di server, dan semua orang saling tunjuk.

Git menyelesaikan masalah itu, dan konsepnya tidak serumit yang terlihat. Git adalah version control system (VCS) terdistribusi: setiap perubahan dicatat sebagai snapshot, lengkap dengan penulis, waktu, dan alasannya. Seluruh riwayat proyek ada di laptopmu — bukan salinan terbaru saja. Karena itu hampir semua operasi Git bersifat menambah data; kehilangan pekerjaan secara permanen sangat sulit terjadi.

Tulisan ini adalah tutorial git pemula sampai mahir yang menyusun perintah dasar git dalam urutan yang masuk akal: instalasi dan commit pertama, lalu branch dan merge, kolaborasi lewat GitHub/GitLab, kemudian teknik yang biasa dipakai developer senior — rebase, interactive rebase, reflog, dan workflow tim. Prasyaratnya sederhana: komputer dengan akses internet. Akun GitHub atau GitLab baru benar-benar dibutuhkan di bagian remote.

Di akhir artikel, kamu diharapkan bukan sekadar hafal perintah, tapi paham alasan di baliknya: kenapa commit, kenapa branch, dan bagaimana keluar dari kesalahan dengan tenang.

Instalasi dan Konfigurasi Awal

Instalasi Git tergantung sistem operasi:

Verifikasi dengan:

git --version
# git version 2.55.0

Saat artikel ini ditulis, versi stabil Git berada di seri 2.55 (2026). Angka versi perlu disebut karena beberapa perilaku Git berubah antarversi — kita akan menyinggungnya di bagian branch default dan git switch/git restore.

Setelah terinstal, konfigurasi global berikut wajib. Tanpa ini Git menolak commit:

git config --global user.name "Budi"
git config --global user.email "budi@example.com"

Nama dan email tersebut yang tercantum di setiap commit yang kamu buat.

Tambahkan juga ini:

git config --global init.defaultBranch main

Kenapa? GitHub sudah menjadikan main branch default untuk repositori baru sejak Oktober 2020; GitLab menyusul kemudian di tahun 2021. Sementara itu, git init di command line — sampai Git 2.55 — masih membuat branch master. Default barunya pindah ke main di Git 3.0. Kalau tidak disamakan, kamu bisa mendapati branch master di lokal dan main di GitHub: dua branch terpisah yang membingungkan. Satu baris konfigurasi di atas mencegah perbedaan itu.

Satu konfigurasi opsional lagi: git config --global pull.rebase true. Ini membuat git pull memakai rebase alih-alih merge, sehingga riwayat tidak dipenuhi commit "Merge branch..." yang berisik. Sebagian tim memakainya, sebagian tidak — konvensi, bukan aturan mutlak. Efeknya akan terasa di bagian rebase.

Semua konfigurasi bisa dicek dengan git config --list. Satu catatan untuk yang lebih nyaman di VS Code: editor ini punya panel Source Control bawaan yang menampilkan status Git secara visual. Artikel ini tetap fokus ke command line karena konsepnya paling jelas terlihat dari sana; GUI enak dipakai sebagai alat bantu setelah kamu paham apa yang terjadi di baliknya.

git init, git add, git commit: Memahami Tiga Area Git

Sebelum mengetik perintah, kenali dulu model tiga area Git (Pro Git bab 2 menyebutnya the three states):

1. Working directory — file yang sedang kamu edit.
2. Staging area — perubahan yang sudah kamu tandai untuk commit berikutnya.
3. Repository — commit yang tersimpan permanen.

Alurnya selalu: modified → staged → committed. git status adalah kompas untuk mengetahui file berada di area mana. Biasakan mengeceknya sebelum add, sebelum commit, dan sebelum push.

Buat repositori pertama:

git init
# Initialized empty Git repository in C:/projects/aplikasi-kasir/.git/

Folder .git yang muncul adalah "otak" repositori: menyimpan riwayat, konfigurasi lokal, dan semua objek commit. Jangan diutak-atik manual.

Sebelum commit pertama, buat .gitignore. Ini daftar file yang sengaja tidak dilacak Git. Contoh minimal untuk proyek PHP/Laravel:

vendor/
.env
*.log
.idea/
.DS_Store

.env wajib dikecualikan karena berisi kredensial database dan kunci aplikasi. Kalau terlanjur ke-commit, rahasia itu tersimpan di riwayat selamanya — dan bot pemindai di GitHub bisa menemukannya dalam hitungan jam, lalu menguras data aplikasi. Template .gitignore yang lengkap untuk berbagai bahasa (termasuk PHP dan Laravel) tersedia di repositori resmi github/gitignore.

Perhatikan satu hal: .gitignore hanya berpengaruh pada file yang belum dilacak. File yang sudah pernah di-commit tetap terlacak walau sudah masuk .gitignore. Untuk berhenti melacak tanpa menghapus file dari disk: git rm --cached .env. Kalau .env sempat terlanjur ter-commit, anggap kredensialnya bocor dan segera rotasi.

Sekarang jalankan commit pertama. Misal kamu punya satu file app.php:

$ git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        app.php

$ git add .
$ git commit -m "feat: inisialisasi proyek"
[main (root-commit) 1a2b3c4] feat: inisialisasi proyek
 2 files changed, 14 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.php

Catatan tentang git add .: pakai hanya setelah cek git status. Kalau asal menitik, file yang tidak kamu inginkan ikut terbawa. Kalau ragu, stage satu per satu: git add app.php.

Pesan commit di atas memakai gaya Conventional Commits: subjek singkat dengan prefiks tipe (feat: untuk fitur baru, fix: untuk perbaikan bug). Tiga prinsip yang perlu diingat sejak awal: satu commit = satu unit perubahan logis, subjek menjelaskan apa dan kenapa, dan hindari pesan seperti "update" atau "asd" — termasuk untuk dirimu sendiri tiga bulan lagi.

Lihat riwayatnya:

git log --oneline
# 1a2b3c4 feat: inisialisasi proyek

Satu commit adalah snapshot seluruh proyek pada saat itu, bukan daftar diff. Git membandingkan snapshot-snapshot ini untuk menentukan apa yang berubah. Terakhir: saat mengubah file, git diff menampilkan perubahan yang belum di-stage, sedangkan git diff --staged menampilkan yang sudah di-stage. Periksa keduanya sebelum commit kalau kamu tidak yakin.

git restore, git reset, git revert: Membatalkan Perubahan dengan Aman

Takut salah langkah? Justru di sinilah Git terasa paling aman.

File belum di-commit:

git restore app.php              # buang perubahan yang belum di-stage (kembalikan ke versi commit)
git restore --staged app.php     # keluarkan dari staging area; isi file tidak berubah

git switch dan git restore adalah hasil pemisahan peran git checkout yang dulu melakukan dua hal sekaligus — pindah branch dan restore file — dan menjadi sumber kebingungan. Keduanya hadir sejak Git 2.23 (2019), dan sejak siklus rilis 2.54/2.55 label eksperimentalnya resmi dihapus. Pakai git switch untuk branch, git restore untuk file; git checkout tetap berfungsi sebagai padanan lama.

Commit terakhir salah:

git commit --amend -m "feat: inisialisasi proyek dengan autentikasi"

--amend mengganti commit terakhir, untuk memperbaiki pesan atau menambahkan file yang lupa di-stage. Jangan dipakai pada commit yang sudah di-push dan dipakai orang lain, karena kamu menulis ulang riwayat bersama.

Commit belum di-push:

git reset --soft HEAD~1     # batalkan commit; perubahan tetap di staging area
git reset HEAD~1            # default (--mixed): perubahan pindah ke working directory
git reset --hard HEAD~1     # buang semuanya — hati-hati, perubahan ikut hilang

Commit sudah di-push dan dipakai bersama: jangan reset, pakai revert:

git revert 1a2b3c4

Perintah ini membuat commit baru yang membalik perubahan sebelumnya. Riwayat tetap utuh, tidak bentrok dengan riwayat orang lain.

Terakhir, kenalan dengan git reflog: catatan pergerakan HEAD yang merekam hampir semua operasi, termasuk reset dan rebase. Merasa kehilangan commit? Kemungkinan besar masih ada di sini (secara default tersimpan sekitar 90 hari). Contoh pemulihannya ada di bagian rebase.

git branch dan git merge: Bekerja di Banyak Jalur

Branch adalah pointer ringan ke sebuah commit — murah dibuat, murah dihapus. Fungsinya mengisolasi pekerjaan: kamu bisa bereksperimen tanpa menyentuh main, dan ini juga fondasi kolaborasi tim.

Perintah intinya:

git branch                 # daftar branch; tanda * = branch aktif
git switch -c fitur/login  # buat branch baru + langsung pindah ke sana
git switch main            # pindah branch
git branch -d fitur/login  # hapus branch yang sudah selesai (hanya jika sudah di-merge)

Praktik terbaiknya: setiap pekerjaan baru, buat branch sendiri. Commit langsung ke main menyulitkan review dan rollback.

Simulasikan alurnya. Kamu di branch fitur/login, sudah ada dua commit:

$ git switch main
$ git merge fitur/login
Updating 1a2b3c4..7d8e9f0
Fast-forward

Karena main tidak bergerak sejak branch dibuat, merge hanya menggeser pointer — ini fast-forward, tanpa commit tambahan. Kalau main sudah menerima perubahan lain duluan, Git melakukan three-way merge dan membuat merge commit. Keduanya normal; bedanya hanya bentuk riwayat. Untuk yang ingin mempertahankan titik merge, ada git merge --no-ff — inilah yang dipakai tombol "Create a merge commit" di GitHub.

Sekarang bagian yang paling ditakuti pemula: merge conflict.

Konflik bukan error. Konflik muncul ketika dua cabang mengubah baris yang sama dan Git tidak bisa memutuskan sendiri mana yang benar. Contoh: kamu dan teman satu tim sama-sama mengubah nilai 'debug' di config.php — kamu set true, dia set false. Saat di-merge:

$ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
        both modified:   config.php

Isi config.php di lokasi konflik tampak seperti ini:

<<<<<<< HEAD
'debug' => true,
=======
'debug' => false,
>>>>>>> fitur/teman

Antara <<<<<<< HEAD dan ======= adalah versi branch kamu; antara ======= dan >>>>>>> adalah versi branch lawan. Tugasmu: putuskan mana yang benar → git add config.php → git commit. Kalau ingin mundur utuh, git merge --abort mengembalikan semuanya seperti sebelum merge.

Jangan panik kalau ini terjadi — di tim profesional, konflik adalah kejadian biasa. VS Code bahkan punya tombol "Accept Current/Incoming/Both" untuk mempercepat penyelesaiannya. Setelah lewat sekali dua kali, konflik tidak lagi menakutkan.

Remote: GitHub dan GitLab

Repositori lokal baru setengah cerita. Kolaborasi butuh remote: salinan repositori di server (GitHub, GitLab, Bitbucket, atau server sendiri). Nama konvensional untuk remote utama adalah origin.

Repositori yang sudah ada di GitHub, ambil ke lokal:

git clone https://github.com/username/proyek.git

Repositori lokal yang sudah berjalan, sambungkan ke remote kosong:

git remote add origin https://github.com/username/proyek.git
git remote -v                   # cek URL remote
git push -u origin main         # push pertama + tandai upstream

-u mengikat branch lokal main ke origin/main. Sesudahnya cukup git push dan git pull.

Ini poin yang sering dilewatkan tutorial lama: sejak 13 Agustus 2021, GitHub menolak autentikasi password untuk operasi Git. Perubahannya diumumkan resmi oleh GitHub. Error yang muncul khas:

remote: Support for password authentication was removed.
fatal: Authentication failed for 'https://github.com/...'

Skema lama "ketik username dan password" sudah tidak berlaku. Penggantinya ada tiga jalur:

1. HTTPS + Personal Access Token (PAT) — buat di GitHub: Settings → Developer settings → Personal access tokens, centang scope repo. Token dipakai sebagai pengganti password. GitLab memakai pola yang sama.
2. SSH key — ssh-keygen untuk membuat pasangan key, lalu tempel isi file .pub ke pengaturan SSH di GitHub/GitLab. Sekali setup, tidak perlu repot memasukkan token berulang kali.
3. GitHub CLI — gh auth login. Jalur termudah untuk pemula: login sekali, credential helper dan autentikasi Git diatur otomatis. Padanannya di GitLab: glab.

Siklus kerja harian di tim:

git pull        # ambil perubahan remote + gabungkan (fetch + merge)
git push        # kirim commit lokal ke remote

git pull sebenarnya gabungan git fetch (mengunduh riwayat remote) lalu merge. Kadang push ditolak karena branch lokal tertinggal:

! [rejected]        main -> main (non-fast-forward)

Solusinya bukan force-push, melainkan:

git pull --rebase origin main   # tarik perubahan remote, susun ulang commit lokal di atasnya
git push

Kolaborasi yang benar lewat pull request (PR) di GitHub, atau merge request (MR) di GitLab: branch pendek untuk satu pekerjaan → push → buka PR/MR → review → merge → hapus branch. GitHub menyediakan tiga opsi merge:

GitLab punya padanannya: opsi squash saat merge, atau aturan fast-forward merge untuk memaksa riwayat linear. Jangan lupa aktifkan branch protection di main (GitHub) atau protected branches (GitLab) supaya tidak ada yang push langsung ke branch utama tanpa review.

git rebase: Riwayat yang Bersih

Rebase sering dianggap lawan merge, padahal keduanya menyelesaikan masalah yang sama: menggabungkan perubahan. Bedanya cara.

git merge mempertahankan topologi asli dan mencatat titik merge. git rebase memutar ulang commit di atas ujung branch lain sehingga riwayat tampak linear — seolah-olah fiturmu dikerjakan setelah semua perubahan terakhir di main:

git switch fitur/login
git rebase main

Karena isinya berubah, setiap commit hasil rebase mendapat hash baru. Karena itu berlaku golden rule: jangan pernah rebase branch yang sedang dipakai atau ditarik orang lain. Rebase hanya untuk commit yang belum di-push.

Kegunaan utama rebase: merapikan riwayat sebelum buka PR. Misal kamu punya tiga commit berantakan — "fix", "wip", "fix lagi". Rapikan dengan interactive rebase:

git rebase -i HEAD~3

Editor terbuka menampilkan daftar perintah yang bisa diubah:

• pick — pertahankan commit
• reword — pertahankan, ubah pesan
• squash — gabungkan ke commit sebelumnya, pesan ikut digabung
• fixup — gabungkan, buang pesannya
• drop — buang commit

Ubah dua baris terakhir menjadi fixup, simpan, dan tiga commit jadi satu:

pick 4a5b6c7 feat: tambah halaman login
fixup 8c9d0e1 fix: typo
fixup 1f2a3b4 wip

Karena hash berubah, push berikutnya memakai:

git push --force-with-lease

Kenapa bukan --force? --force menimpa remote buta — kalau ada orang lain push ke branch yang sama sejak fetch terakhir, commit-nya ikut tertimpa. --force-with-lease menolak push kalau remote ternyata sudah berubah sejak terakhir kamu tarik; "lease" bisa dianggap kuncian terhadap kondisi yang kamu lihat terakhir. Tetap dengan dua syarat: hanya branch pribadi, dan tidak pernah ke main atau branch bersama.

Satu lagi alat mahir: git cherry-pick 1a2b3c4 — mengambil satu commit dari branch lain ke branch aktif, misalnya memindahkan hotfix yang sudah digabung di branch release.

Dan soal commit yang "hilang" tadi: kalau rebase-nya berantakan, cek reflog, lalu kembali ke posisi sebelum rebase. Contohnya (angka hash dan HEAD@{n} di bawah hanya ilustrasi — punyamu akan berbeda):

git reflog
# 3f4a5b6c HEAD@{0}: rebase (finish): returning to refs/heads/fitur/login
# 7d8e9f0 HEAD@{1}: rebase (start): checkout main
# 1a2b3c4 HEAD@{2}: commit (initial): feat: inisialisasi proyek

git reset --hard HEAD@{2}

Hampir semua kesalahan Git bisa dipulihkan lewat reflog. Itulah kenapa langkah pertama saat panik adalah: berhenti, git reflog, baru putuskan.

Perkakas Mahir Lainnya

Beberapa perintah yang tidak kalah berguna di keseharian:

• Tag rilis — git tag -a v1.0.0 -m "Rilis 1.0.0" menandai commit sebagai versi rilis; kirim dengan git push origin v1.0.0.
• Stash — git stash menyimpan perubahan yang belum di-commit saat kamu terpaksa pindah branch sekarang juga; git stash pop mengembalikannya. Cek daftarnya dengan git stash list.
• Bisect — git bisect start, git bisect bad, git bisect good v1.0, lalu ulangi sampai Git menemukan commit pertama yang memperkenalkan bug. Pencarian biner ini jauh lebih cepat daripada menebak-nebak.
• Blame — git blame app.php menunjukkan siapa mengubah baris mana dan kapan; berguna saat menemukan kode aneh dan butuh konteks.
• Visualisasi — git log --graph --oneline --all menampilkan riwayat dalam bentuk grafik cabang yang mudah dibaca.

Untuk file biner besar, gunakan Git LFS — GitHub menolak file di atas 100 MB dengan error GH001: Large files detected (peringatan mulai muncul di atas 50 MB). Kalau riwayat sudah terlanjur kotor karena file besar atau rahasia, bersihkan dengan git filter-repo, bukan git filter-branch yang lambat. Untuk pencegahan, hooks seperti pre-commit bisa memblokir commit .env secara otomatis (sejak Git 2.54, hooks juga bisa didefinisikan lewat konfigurasi, tidak hanya di folder .git/hooks).

Workflow Tim: Pilih Strategi yang Tepat

Perintah sudah dikuasai; pertanyaan berikutnya: bagaimana tim sebaiknya memakainya? Tiga pola dominan:

GitLab Flow adalah varian lain: main ditambah environment branches (staging, production) dan alur merge request.

Tidak ada satu yang paling benar. Workflow terbaik adalah yang konsisten dipakai tim dan cocok dengan model rilisnya. Untuk pembaca artikel ini, rekomendasi praktis: mulai dengan GitHub Flow + squash merge — satu branch utama, PR untuk setiap perubahan, riwayat rapi. Git Flow baru terasa perlu saat kamu benar-benar harus mendukung beberapa versi rilis sekaligus.

Kesalahan Umum dan Solusinya

Beberapa error yang paling sering menghadang developer:

Penutup

Peta belajarnya bisa diringkas begini: pahami tiga area (working, staging, repository), kuasai siklus commit, lanjut ke branch dan merge, kolaborasi lewat remote dan pull request, lalu rebase untuk riwayat bersih, dan terakhir pilih workflow yang cocok untuk tim.

Sekarang giliran berlatih. Bikin repositori "playground" khusus percobaan: coba git reset, git rebase -i, git revert, bahkan sengaja bikin konflik — lalu pulihkan dengan reflog. Di playground tidak ada yang bisa rusak. Setelah cukup percaya diri, tantangan berikutnya adalah kontribusi kecil ke proyek open source, yang sekaligus melatih alur pull request sungguhan.

Kalau mau mendalami: Pro Git gratis dan tersedia versi bahasa Indonesianya, dokumentasi resmi ada di git-scm.com/docs, dan tutorial Atlassian soal merge vs rebase bagus untuk perbandingan. Selamat belajar — semoga tidak ada lagi file bernama final_version_v2_benar.zip.