Kontrol Versi Git: Referensi Teknis Lengkap untuk Pengembang

Git adalah sistem kontrol versi terdistribusi (DVCS) yang merekam snapshot pohon file proyek dari waktu ke waktu, memungkinkan sejumlah kontributor bekerja secara paralel tanpa menimpa perubahan satu sama lain. Setiap pengembang menyimpan salinan lengkap repositori — termasuk seluruh riwayat commit — di mesin lokal mereka, menghilangkan titik kegagalan tunggal dan memungkinkan alur kerja offline sepenuhnya.

Dibuat oleh Linus Torvalds pada April 2005 untuk menggantikan BitKeeper dalam pengembangan kernel Linux, Git dirancang dari prinsip dasar berdasarkan tiga persyaratan yang tidak dapat dikompromikan: kecepatan, integritas data, dan dukungan untuk alur kerja non-linear dan terdistribusi. Tujuan desain tersebut masih mendefinisikan apa yang membuat Git secara kategoris berbeda dari pendahulunya dan mengapa Git tetap menjadi VCS yang dominan lebih dari dua dekade kemudian.

Bagaimana Git Berbeda dari Kontrol Versi Terpusat

Memahami arsitektur Git memerlukan perbandingan langsung dengan sistem terpusat seperti Subversion (SVN) atau CVS, di mana satu server otoritatif menyimpan repositori kanonik dan pengembang melakukan checkout salinan kerja yang dangkal.

Model terdistribusi berarti bahwa bahkan jika platform hosting seperti GitHub mengalami gangguan, clone lokal setiap pengembang adalah cadangan lengkap dan otoritatif dari seluruh riwayat proyek.

Arsitektur Inti: Apa yang Sebenarnya Disimpan Git

Git tidak menyimpan diff. Git menyimpan snapshot. Setiap commit menunjuk ke objek tree yang mewakili keadaan penuh setiap file yang dilacak pada saat itu. Jika sebuah file tidak berubah antara dua commit, Git menyimpan pointer ke blob sebelumnya daripada menduplikasinya — inilah cara Git mencapai kelengkapan sekaligus efisiensi penyimpanan.

Empat tipe objek fundamental dalam penyimpanan objek Git (.git/objects/) adalah:

• Blob — konten file mentah, dialamatkan oleh hash SHA
• Tree — daftar direktori yang memetakan nama file ke hash blob atau subtree
• Commit — pointer ke tree, nol atau lebih commit induk, metadata penulis, dan pesan
• Tag — pointer beranotasi ke commit tertentu, digunakan untuk penanda rilis

Setiap objek bersifat immutable dan dialamatkan berdasarkan konten. Mengubah satu byte pada file mana pun menghasilkan hash SHA yang sepenuhnya berbeda, yang berdampak ke atas melalui objek tree dan commit. Inilah mengapa riwayat Git tahan terhadap pemalsuan secara kriptografis — Anda tidak dapat mengubah commit masa lalu secara diam-diam tanpa mengubah setiap hash commit berikutnya.

Staging area (juga disebut index, disimpan di .git/index) adalah file biner yang menyimpan commit berikutnya yang diusulkan. Model tiga zona ini — direktori kerja, index, repositori — adalah fitur arsitektur Git yang paling sering disalahpahami dan sumber kebingungan bagi pemula.

Menginstal dan Mengonfigurasi Git

Sebelum menjalankan perintah apa pun, verifikasi instalasi Anda dan konfigurasikan identitas Anda. Git menyematkan informasi penulis ke dalam setiap objek commit, dan identitas yang salah dikonfigurasi adalah salah satu penyebab paling umum dari riwayat commit yang berantakan di repositori bersama.

# Verify installation
git --version

# Set global identity (stored in ~/.gitconfig)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Set default branch name to 'main' (modern convention)
git config --global init.defaultBranch main

# Set preferred editor for commit messages
git config --global core.editor "vim"

# Enable colored output
git config --global color.ui auto

# Verify configuration
git config --list

Konfigurasi berlapis: --system (semua pengguna, /etc/gitconfig), --global (pengguna saat ini, ~/.gitconfig), dan --local (repositori, .git/config). Cakupan yang lebih spesifik menggantikan yang lebih luas.

Perintah Git Penting: Referensi Lengkap

Menginisialisasi dan Mengkloning

git init membuat repositori baru dengan menulis direktori .git/ ke dalam folder saat ini. Ini tidak membuat commit apa pun — repositori dimulai dalam keadaan kosong.

git init
git init my-project        # Initialize into a new subdirectory
git init --bare repo.git   # Bare repository (no working tree, used for servers)

Bare repository hanya berisi penyimpanan objek dan refs — tanpa direktori kerja. Ini adalah format yang benar untuk repositori remote yang didorong oleh banyak pengembang. Jika Anda meng-hosting Git sendiri di server VPS Hosting, selalu inisialisasi repositori bersama sebagai bare.

git clone membuat salinan lokal lengkap dari repositori remote, termasuk semua branch, tag, dan riwayat.

git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git          # SSH transport (preferred for auth)
git clone --depth 1 https://github.com/user/repo.git  # Shallow clone (latest commit only)
git clone --branch develop https://github.com/user/repo.git  # Clone specific branch

Shallow clone (--depth) berguna untuk pipeline CI/CD di mana Anda hanya membutuhkan keadaan terbaru, bukan riwayat lengkap. Mereka secara dramatis mengurangi waktu clone pada repositori besar tetapi mencegah beberapa operasi yang bergantung pada riwayat seperti git bisect.

Memeriksa Status

git status adalah perintah yang paling sering dijalankan dalam alur kerja apa pun. Ini menampilkan status tiga zona repositori Anda.

git status
git status -s    # Short format: two-column status codes
git status -sb   # Short format with branch info

git diff membandingkan konten di seluruh zona atau commit.

git diff                    # Working directory vs. index (unstaged changes)
git diff --staged           # Index vs. last commit (what will be committed)
git diff HEAD               # Working directory vs. last commit (all changes)
git diff main..feature      # Compare tips of two branches
git diff abc123..def456     # Compare two specific commits
git diff --stat             # Show changed files and line counts only

git log melintasi grafik commit. Opsi filteringnya adalah salah satu fitur Git yang paling kuat dan jarang digunakan.

git log
git log --oneline --graph --decorate --all   # Visual branch graph
git log -p                                   # Show patch (diff) for each commit
git log --author="Jane"                      # Filter by author
git log --since="2 weeks ago"               # Filter by date
git log --grep="fix:"                        # Filter by commit message pattern
git log -- path/to/file                      # History of a specific file
git log --follow -- path/to/file             # Follow renames

Kombinasi --graph --oneline --decorate --all sangat berguna secara universal sehingga sebagian besar engineer membuat alias-nya:

git config --global alias.lg "log --oneline --graph --decorate --all"

Staging dan Committing

git add filename.py          # Stage a specific file
git add src/                 # Stage an entire directory
git add .                    # Stage all changes in current directory
git add -p                   # Interactive patch staging (stage hunks, not whole files)
git add -u                   # Stage modifications and deletions, but not new files

Interactive staging (git add -p) adalah salah satu fitur Git yang paling kuat dan jarang digunakan. Ini memungkinkan Anda meninjau dan secara selektif melakukan staging pada hunk individual dalam sebuah file, memungkinkan commit yang tepat dan atomik bahkan ketika direktori kerja Anda berisi beberapa perubahan yang tidak terkait.

git commit -m "feat: add OAuth2 token refresh logic"
git commit --amend           # Modify the most recent commit (message or content)
git commit --amend --no-edit # Amend content without changing the message
git commit -v                # Open editor showing full diff of staged changes

Aturan penting: Jangan pernah mengamend commit yang sudah di-push ke remote bersama. Amending menulis ulang hash commit, memaksa kolaborator untuk melakukan rebase atau reset branch lokal mereka.

Pushing dan Pulling

git push origin main
git push origin feature/auth     # Push a specific branch
git push -u origin feature/auth  # Push and set upstream tracking
git push --force-with-lease      # Safer force push (fails if remote has new commits)
git push origin --delete old-branch  # Delete a remote branch
git push --tags                  # Push all local tags

Lebih baik gunakan --force-with-lease daripada --force ketika Anda harus menulis ulang riwayat remote. Ini memeriksa bahwa tidak ada orang lain yang telah melakukan push sejak fetch terakhir Anda, mencegah kehilangan data yang tidak disengaja.

git pull origin main
git pull --rebase origin main    # Fetch and rebase instead of merge
git pull --ff-only               # Only fast-forward; abort if a merge commit would be created

git fetch mengunduh perubahan remote tanpa menyentuh direktori kerja atau branch saat ini. Ini adalah cara aman untuk memeriksa perubahan upstream sebelum mengintegrasikannya.

git fetch origin
git fetch --all          # Fetch from all remotes
git fetch --prune        # Remove remote-tracking branches that no longer exist upstream

Branching dan Merging: Alur Kerja Inti

Model branching Git adalah fitur yang paling signifikan secara arsitektur. Branch hanyalah sebuah pointer bernama (file 41-byte di .git/refs/heads/) ke hash commit. Membuat branch bersifat instan terlepas dari ukuran repositori.

Manajemen Branch

git branch                        # List local branches
git branch -a                     # List all branches (local and remote-tracking)
git branch -v                     # List branches with last commit info
git branch feature/user-auth      # Create a new branch
git branch -d feature/user-auth   # Delete merged branch
git branch -D feature/user-auth   # Force delete (even if unmerged)
git branch -m old-name new-name   # Rename a branch

Berpindah Branch

Git modern (2.23+) memisahkan fungsi git checkout menjadi dua perintah khusus:

git switch main                   # Switch to existing branch
git switch -c feature/payments    # Create and switch in one step
git restore filename.py           # Discard working directory changes to a file
git restore --staged filename.py  # Unstage a file (remove from index)

git checkout masih berfungsi untuk semua ini, tetapi git switch dan git restore memiliki semantik yang lebih jelas dan tidak ambigu serta harus lebih diutamakan dalam alur kerja modern.

Strategi Merging

git merge feature/user-auth           # Standard merge (creates merge commit if needed)
git merge --no-ff feature/user-auth   # Always create merge commit (preserves branch topology)
git merge --squash feature/user-auth  # Squash all branch commits into one staged change
git merge --abort                     # Abort an in-progress conflicted merge

Fast-forward merge terjadi ketika branch target tidak menyimpang dari sumber — Git hanya memindahkan pointer ke depan. Tidak ada merge commit yang dibuat. --no-ff memaksa merge commit bahkan dalam kasus ini, yang mempertahankan riwayat visual branch fitur di git log --graph.

Squash merge menggabungkan semua commit dari branch fitur menjadi satu perubahan yang di-stage, yang kemudian Anda commit secara manual. Ini menghasilkan riwayat linear yang bersih di main tetapi membuang riwayat commit granular dari branch fitur.

Rebasing

git rebase memutar ulang commit dari satu branch di atas branch lain, menulis ulang hash mereka untuk membuat riwayat linear.

git rebase main                  # Rebase current branch onto main
git rebase -i HEAD~5             # Interactive rebase: edit last 5 commits
git rebase --onto main server client  # Transplant client branch onto main, excluding server
git rebase --abort               # Abort a rebase in progress
git rebase --continue            # Continue after resolving a conflict

Interactive rebase (-i) adalah alat kebersihan commit para profesional. Ini memungkinkan Anda mengatur ulang, menggabungkan, mengedit, menghapus, atau memisahkan commit sebelum berbagi. Kasus penggunaan umum: membersihkan branch fitur yang berantakan sebelum membuka pull request.

Aturan emas rebasing: Jangan pernah melakukan rebase pada commit yang ada di branch publik bersama. Rebasing menulis ulang hash commit. Jika rekan tim telah mendasarkan pekerjaan pada commit tersebut, riwayat mereka akan menyimpang dan mereka akan menghadapi rekonsiliasi yang menyakitkan.

Menyelesaikan Konflik Merge

Konflik terjadi ketika dua branch memodifikasi wilayah yang sama dari file yang sama. Git menandai konflik dalam file dengan penanda konflik standar:

<<<<<<< HEAD
const timeout = 30000;
=======
const timeout = 60000;
>>>>>>> feature/increase-timeout

Alur kerja resolusi:

# After a conflicted merge or rebase
git status                    # Identify conflicted files (marked as "both modified")
# Edit each conflicted file, remove markers, keep correct content
git add resolved-file.js      # Mark as resolved
git commit                    # Complete the merge (message is pre-populated)

Untuk konflik yang kompleks, alat three-way merge memberikan tampilan yang lebih jelas:

git mergetool                 # Launch configured merge tool (vimdiff, meld, etc.)
git config --global merge.tool vimdiff

Membatalkan Perubahan: Matriks Keputusan

Memilih perintah undo yang salah adalah salah satu cara paling umum pengembang kehilangan pekerjaan atau merusak riwayat bersama. Pilihan yang tepat bergantung pada dua variabel: di mana perubahan berada dan apakah sudah di-push.

git reset --soft HEAD~1      # Undo commit, keep changes in index
git reset HEAD~1             # Undo commit, keep changes in working dir
git reset --hard HEAD~1      # Undo commit, discard all changes permanently

git revert abc1234           # Create new commit that inverts abc1234
git revert HEAD~3..HEAD      # Revert last 3 commits (creates 3 revert commits)
git revert -n HEAD~3..HEAD   # Stage the reversals without committing (batch revert)

git reset --hard tidak dapat dipulihkan melalui perintah Git biasa. Jika Anda tidak sengaja menjalankannya, satu-satunya jalur pemulihan adalah git reflog, yang mencatat setiap posisi yang pernah ditunjuk HEAD selama sekitar 90 hari.

git reflog                   # Show HEAD movement history with hashes
git checkout -b recovery abc1234  # Recover by creating a branch at the lost commit

Perintah Lanjutan untuk Alur Kerja Produksi

git stash

git stash menyimpan direktori kerja saat ini dan status index ke dalam stack, memberikan Anda working tree yang bersih untuk beralih konteks.

git stash                        # Stash tracked changes
git stash -u                     # Include untracked files
git stash push -m "WIP: auth refactor"  # Stash with a descriptive name
git stash list                   # List all stash entries
git stash pop                    # Apply most recent stash and remove it from stack
git stash apply stash@{2}        # Apply specific stash without removing it
git stash drop stash@{2}         # Delete a specific stash entry
git stash branch feature/wip     # Create a new branch from a stash

git cherry-pick

git cherry-pick abc1234                    # Apply a single commit to current branch
git cherry-pick abc1234 def5678            # Apply multiple commits
git cherry-pick abc1234 --no-commit        # Apply changes without committing
git cherry-pick main~3..main              # Apply a range of commits

Cherry-pick adalah mekanisme standar untuk backporting perbaikan bug ke branch pemeliharaan. Jika Anda memperbaiki kerentanan keamanan kritis di main, Anda melakukan cherry-pick commit tersebut ke v2.1-stable dan v2.0-stable tanpa menggabungkan fitur yang tidak terkait.

git bisect

git bisect melakukan pencarian biner melalui riwayat commit untuk menemukan commit tepat yang memperkenalkan bug. Ini adalah salah satu alat debugging Git yang paling kuat dan paling jarang diketahui.

git bisect start
git bisect bad                   # Mark current commit as broken
git bisect good v2.3.0           # Mark a known-good commit or tag
# Git checks out the midpoint commit automatically
# Test your code, then:
git bisect good                  # If this commit is fine
git bisect bad                   # If this commit is broken
# Repeat until Git identifies the first bad commit
git bisect reset                 # Return to original HEAD when done

Pada repositori dengan 1.000 commit antara titik baik dan buruk, git bisect menemukan pelakunya dalam paling banyak 10 langkah.

git tag

Tag menandai commit tertentu sebagai signifikan — biasanya versi rilis.

git tag v1.4.2                          # Lightweight tag (just a pointer)
git tag -a v1.4.2 -m "Release 1.4.2"   # Annotated tag (recommended; stores metadata)
git tag -a v1.4.2 abc1234              # Tag a specific past commit
git push origin v1.4.2                 # Push a specific tag
git push origin --tags                 # Push all tags
git tag -d v1.4.2                      # Delete local tag
git push origin --delete v1.4.2        # Delete remote tag

Selalu gunakan annotated tag untuk rilis. Tag ini menyimpan nama, email, tanggal, dan pesan pembuat tag, serta dapat ditandatangani dengan GPG. Lightweight tag hanya cocok untuk penanda lokal sementara.

git worktree

git worktree memungkinkan beberapa direktori kerja di-checkout dari repositori yang sama secara bersamaan — masing-masing pada branch yang berbeda. Ini menghilangkan kebutuhan untuk melakukan stash atau commit pekerjaan yang sedang berjalan ketika Anda perlu beralih ke hotfix.

git worktree add ../hotfix-branch hotfix/critical-auth-bug
git worktree list
git worktree remove ../hotfix-branch

Ini sangat berharga pada Dedicated Server yang menjalankan pipeline CI/CD di mana beberapa pekerjaan build memerlukan akses simultan ke branch berbeda dari repositori yang sama tanpa saling mengganggu.

Alur Kerja Git untuk Tim

Strategi branching yang tepat bergantung pada ritme rilis dan ukuran tim Anda. Tiga model dominan ada:

Alur Kerja Feature Branch

Setiap fitur atau perbaikan berada di branch-nya sendiri. Pengembang membuka pull request untuk merge ke main. Sederhana, efektif untuk sebagian besar tim.

Gitflow

Mendefinisikan branch main dan develop yang berumur panjang, ditambah branch feature/, release/, dan hotfix/ yang berumur pendek dengan aturan merge yang ketat. Cocok untuk perangkat lunak dengan rilis berversi eksplisit (library, aplikasi yang dikemas).

Trunk-Based Development

Pengembang melakukan commit langsung ke main (atau menggunakan branch berumur sangat pendek yang di-merge dalam sehari). Sangat bergantung pada feature flag untuk menyembunyikan pekerjaan yang belum selesai. Disukai oleh tim berkecepatan tinggi yang mempraktikkan continuous deployment.

Hosting Repositori Git: Self-Hosted vs. Platform Terkelola

Untuk tim yang memerlukan kedaulatan data, kepatuhan, atau infrastruktur privat, self-hosting server Git adalah pilihan yang layak dan sering kali diperlukan. Opsi termasuk Gitea (ringan, berbasis Go), GitLab CE (platform DevOps lengkap), dan Forgejo (fork Gitea dengan tata kelola komunitas).

Instance Gitea self-hosted minimal berjalan dengan nyaman pada paket VPS Hosting dengan 2 vCPU dan 2 GB RAM. Untuk tim yang lebih besar atau GitLab CE dengan CI runner, 4–8 GB RAM adalah minimum praktis.

Saat self-hosting, amankan server Git Anda dengan:

• Autentikasi kunci SSH (nonaktifkan autentikasi kata sandi sepenuhnya)
• HTTPS dengan sertifikat yang valid — SSL Certificates sangat penting untuk melindungi kredensial dalam transit
• Aturan firewall yang membatasi eksposur port Git (22 atau port SSH kustom, 443 untuk HTTPS)
• Backup otomatis reguler dari direktori repositori bare .git
• Webhook secret untuk integrasi CI/CD

Untuk tim yang menggunakan pipeline deployment berbasis Git yang juga mengelola infrastruktur web, memasangkan server Git self-hosted dengan VPS dengan cPanel memberi Anda hook deployment terintegrasi bersama alat manajemen hosting yang familiar.

Git Hooks: Mengotomatiskan Quality Gate

Git hook adalah skrip yang dieksekusi secara otomatis pada titik-titik tertentu dalam siklus hidup Git. Mereka berada di .git/hooks/ dan tidak di-commit ke repositori secara default (gunakan alat seperti pre-commit atau husky untuk berbagi).

Hook utama untuk alur kerja produksi:

# Example pre-commit hook: reject commits with debug print statements
#!/bin/bash
if git diff --cached | grep -E '^+.*(console.log|debugger|print("DEBUG)'; then
  echo "ERROR: Debug statement detected. Remove before committing."
  exit 1
fi

Hook post-receive pada repositori server bare adalah fondasi deployment berbasis Git yang sederhana: push ke server, hook melakukan checkout HEAD baru ke web root, menjalankan langkah build, dan me-restart layanan — tanpa platform CI eksternal yang diperlukan.

.gitignore: Menjaga Repositori Tetap Bersih

File .gitignore memberi tahu Git file dan pola mana yang harus dibiarkan tidak dilacak. File ini harus di-commit ke repositori dan dipelihara dengan cermat.

# Dependencies
node_modules/
vendor/

# Build artifacts
dist/
build/
*.o
*.pyc
__pycache__/

# Environment and secrets — NEVER commit these
.env
.env.local
*.pem
*.key
config/secrets.yml

# IDE files
.idea/
.vscode/
*.swp

# OS files
.DS_Store
Thumbs.db

Jebakan kritis: Jika sebuah file sudah dilacak sebelum ditambahkan ke .gitignore, Git akan terus melacaknya. Anda harus secara eksplisit menghentikan pelacakannya:

git rm --cached path/to/sensitive-file
git commit -m "chore: stop tracking secrets file"

Jangan pernah melakukan commit kredensial, kunci API, atau kunci privat ke repositori — bahkan yang privat sekalipun. Gunakan variabel lingkungan, manajer secret (HashiCorp Vault, AWS Secrets Manager), atau file .env yang di-.gitignore.

Penyetelan Performa untuk Repositori Besar

Git standar mengalami penurunan performa pada repositori dengan jutaan file atau aset biner berukuran gigabyte. Strategi mitigasi:

• Git LFS (Large File Storage): Menggantikan file biner besar dengan file pointer di repositori dan menyimpan konten sebenarnya di server LFS terpisah. Penting untuk repositori yang berisi media, bobot model ML, atau biner yang dikompilasi.
• Partial clone: git clone --filter=blob:none mengunduh commit dan tree tetapi mengambil blob sesuai permintaan. Secara dramatis mengurangi ukuran clone awal untuk monorepo besar.
• Sparse checkout: git sparse-checkout set path/to/subdir hanya melakukan checkout sebagian dari working tree. Berguna dalam monorepo di mana pengembang hanya bekerja di satu direktori layanan.
• File commit-graph: git commit-graph write --reachable menghitung grafik commit sebelumnya, mempercepat operasi seperti git log --graph dan kueri keterjangkauan pada riwayat besar.
• git maintenance start: Menjadwalkan tugas pemeliharaan latar belakang (pengemasan objek longgar, pembaruan commit-graph, prefetch fetch) untuk menjaga operasi repositori tetap cepat dari waktu ke waktu.

Daftar Periksa Teknis Poin Utama

Sebelum menganggap pengaturan Git Anda siap produksi, verifikasi setiap hal berikut:

• Identitas dikonfigurasi: user.name dan user.email diatur dengan benar pada cakupan konfigurasi yang sesuai
• Kunci SSH digunakan: Autentikasi kata sandi ke remote digantikan dengan pasangan kunci SSH atau HTTPS berbasis token
• .gitignore di-commit: Secret, artefak build, dan file OS dikecualikan sebelum commit pertama
• Branch default bernama main: init.defaultBranch diatur secara global untuk menghindari penamaan master yang lama
• Pesan commit mengikuti konvensi: Conventional Commits (feat:, fix:, chore:) atau format yang disepakati tim diterapkan melalui hook commit-msg
• git revert untuk riwayat publik: git reset --hard hanya digunakan pada commit lokal yang belum di-push
• --force-with-lease daripada --force: Mencegah penimpaan push rekan tim yang tidak disengaja
• Annotated tag untuk rilis: git tag -a dengan pesan, bukan lightweight tag
• Hook dibagikan melalui pre-commit atau husky: Quality gate diterapkan secara konsisten di seluruh tim
• Git LFS dikonfigurasi jika repositori berisi aset biner di atas 1 MB
• Bare repository di server: Remote self-hosted diinisialisasi dengan git init --bare
• git fetch --prune reguler: Ref pelacak remote dijaga tetap sinkron dengan status remote yang sebenarnya

Pertanyaan yang Sering Diajukan

Apa perbedaan antara git fetch dan git pull?

git fetch mengunduh commit, branch, dan tag dari remote ke dalam ref pelacak remote lokal Anda (misalnya, origin/main) tanpa menyentuh direktori kerja atau branch saat ini. git pull adalah git fetch yang segera diikuti oleh git merge (atau git rebase jika dikonfigurasi). Gunakan git fetch ketika Anda ingin memeriksa perubahan upstream sebelum mengintegrasikannya.

Kapan saya harus menggunakan git rebase daripada git merge?

Gunakan rebase untuk melinearkan branch fitur lokal Anda sebelum membuka pull request, menjaga riwayat proyek tetap mudah dibaca. Jangan pernah melakukan rebase pada branch yang sudah di-clone atau dijadikan dasar pekerjaan oleh pengembang lain — menulis ulang hash commit yang sudah dipublikasikan memaksa semua orang untuk merekonsiliasi riwayat yang menyimpang secara manual.

Bagaimana cara menghapus file sensitif yang tidak sengaja di-commit secara permanen?

Gunakan git filter-repo (pengganti modern untuk git filter-branch): git filter-repo --path secrets.env --invert-paths. Ini menulis ulang seluruh riwayat repositori, menghapus file dari setiap commit. Setelah penulisan ulang, force-push semua branch dan tag, lalu segera rotasi kredensial yang terekspos — anggap sudah dikompromikan terlepas dari seberapa cepat Anda bertindak.

Apa itu status detached HEAD dan bagaimana cara memulihkannya?

Detached HEAD berarti pointer HEAD Anda mereferensikan hash commit tertentu secara langsung daripada nama branch. Commit apa pun yang Anda buat tidak akan termasuk dalam branch mana pun dan akan menjadi tidak terjangkau setelah Anda berpindah. Untuk memulihkan: git switch -c new-branch-name untuk melampirkan commit ke branch baru, atau git switch main untuk membuangnya.

Bagaimana Git menangani file biner secara berbeda dari file teks?

Git menyimpan file biner sebagai blob buram — Git tidak dapat menghitung diff tingkat baris yang bermakna atau melakukan merge otomatis pada file tersebut. Konflik dalam file biner harus diselesaikan dengan memilih satu versi sepenuhnya. Untuk repositori dengan aset biner yang signifikan, konfigurasikan Git LFS untuk menyimpan biner secara eksternal dan menjaga repositori itu sendiri tetap ramping dan cepat.