Pertanyaan Git saat wawancara kerja: 25 pertanyaan beserta jawabannya

Git diuji hampir di setiap wawancara developer, tester, atau DevOps: kadang sebagai blok tersendiri, kadang di sela-sela pembicaraan («bagaimana Anda membatalkan rilis yang gagal?»). Pewawancara lebih peduli pada pemahaman model daripada hafalan flag: apa itu commit, ke mana branch menunjuk, dan apa yang diubah oleh riwayat. Berikut 25 pertanyaan yang paling sering muncul, dengan jawaban pada tingkat yang memberi kesan baik.

Pertanyaan disusun dari yang dasar sampai yang lanjutan. Saat menjawab di wawancara, sebaiknya berikan contoh singkat dari pengalaman nyata; itu lebih dihargai daripada mengulang dokumentasi.

Pertanyaan dasar

1. Apa itu Git, dan apa bedanya sistem kontrol versi terdistribusi dengan yang terpusat?

Git adalah sistem kontrol versi terdistribusi: ia menyimpan riwayat perubahan proyek dan memungkinkan banyak orang bekerja di proyek yang sama secara paralel. Pada sistem terpusat (misalnya SVN), seluruh riwayat berada di satu server, dan developer hanya memiliki salinan kerja. Di Git, setiap klon berisi seluruh riwayat, sehingga commit, branch, melihat riwayat, dan penggabungan dilakukan secara lokal tanpa jaringan.

Dari sini muncul keuntungan praktis: kecepatan tinggi, bisa bekerja offline, dan tidak ada satu titik kegagalan. Server seperti GitHub atau GitLab dalam Git hanyalah kesepakatan tim tentang salinan «utama», bukan keharusan teknis.

2. Dari tiga area apa saja pekerjaan dengan Git tersusun?

Direktori kerja (berkas di disk), index atau staging area (snapshot yang disiapkan untuk commit berikutnya), dan repositori lokal (folder .git berisi riwayat). git add memindahkan perubahan dari direktori kerja ke index, dan git commit dari index ke repositori.

Nilai tambah yang baik adalah menyebutkan area keempat, yaitu repositori remote, beserta git push dan git fetch yang berhubungan dengannya.

3. Untuk apa index dibutuhkan, kalau bisa langsung commit?

Index memungkinkan commit yang disengaja: dari sepuluh berkas yang berubah, Anda bisa meng-commit tiga yang terkait satu tugas, dan sisanya ditunda. Dengan git add -p bahkan potongan di dalam satu berkas bisa dipilih.

Ini dasar commit atomik: satu commit untuk satu perubahan logis. Riwayat seperti itu mudah dibaca, direview, dibatalkan dengan revert, dan dipindahkan dengan cherry-pick.

4. Apa itu commit dari sudut pandang struktur internal Git?

Commit adalah objek yang menyimpan referensi ke pohon (tree) — snapshot seluruh berkas proyek — serta referensi ke commit induk, penulis, committer, tanggal, dan pesan. Ia diidentifikasi oleh hash SHA-1 (versi baru juga mendukung SHA-256 secara eksperimental) yang dihitung dari seluruh isinya.

Poin kuncinya: Git menyimpan snapshot, bukan diff. Berkas yang tidak berubah tidak diduplikasi; pohon hanya merujuk ke blob yang sama. Karena hash bergantung pada induknya, commit lama tidak bisa diubah tanpa mengubah hash semua commit sesudahnya.

5. Apa itu branch dan apa itu HEAD?

Branch adalah penunjuk yang bisa bergerak ke suatu commit: sebuah berkas di .git/refs/heads/ yang berisi hash. Itulah sebabnya membuat branch di Git terjadi seketika dan tidak menyalin apa pun. Saat ada commit baru, penunjuk branch aktif ikut bergeser.

HEAD adalah penunjuk ke tempat Anda berada sekarang; biasanya ia menunjuk ke branch (ref: refs/heads/main). Jika berpindah ke commit atau tag tertentu, HEAD menunjuk langsung ke commit itu — inilah keadaan detached HEAD.

6. Apa itu detached HEAD dan mengapa berbahaya?

Keadaan ketika HEAD menunjuk ke commit, bukan ke branch; contohnya setelah git switch --detach v1.0 atau git checkout a1b2c3d. Anda boleh melihat kode dan bahkan commit, tetapi commit baru tidak termasuk di branch mana pun.

Jika Anda kemudian berpindah ke branch lain, commit tersebut menjadi tidak dapat dijangkau dan lama-kelamaan dihapus oleh garbage collector. Untuk menyelamatkannya, buat branch: git switch -c fix-from-detached. Jika sudah terlanjur pergi, hash-nya bisa dicari di git reflog.

7. Apa bedanya git fetch dengan git pull?

git fetch mengunduh commit baru dan memperbarui referensi remote-tracking seperti origin/main, tetapi tidak menyentuh branch lokal maupun berkas Anda. git pull adalah fetch ditambah integrasi: secara default merge, dan dengan flag --rebase atau pengaturan pull.rebase=true menjadi rebase.

Developer berpengalaman sering menjalankan fetch secara terpisah, memeriksa git log HEAD..origin/main, dan baru kemudian memutuskan cara mengintegrasikan perubahan.

8. Bagaimana cara kerja .gitignore, dan mengapa berkas yang sudah ditambahkan ke sana tetap dilacak?

.gitignore berisi pola berkas yang tidak perlu ditawarkan Git untuk ditambahkan: dependensi, hasil build, log, dan konfigurasi lokal yang berisi rahasia. Aturannya hanya berlaku pada berkas yang belum dilacak.

Jika berkas sudah pernah di-commit, aturan pengabaian tidak berpengaruh padanya. Keluarkan berkas dari index tetapi biarkan di disk: git rm --cached config.local.php, lalu commit penghapusan dari pelacakan itu. Untuk mengetahui aturan mana yang berlaku, gunakan git check-ignore -v path.

Branch, penggabungan, dan konflik

9. Apa itu fast-forward merge?

Jika branch target tidak bergerak maju sejak percabangan, Git saat penggabungan cukup memajukan penunjuknya ke commit terakhir branch yang digabungkan, tanpa membuat commit baru. Riwayat tetap lurus.

Flag --no-ff memaksa pembuatan commit merge meskipun fast-forward dimungkinkan, sehingga riwayat menunjukkan bahwa sekelompok commit berasal dari satu fitur. Flag --ff-only sebaliknya hanya mengizinkan fast-forward dan menolak jika diperlukan merge sungguhan.

10. Bagaimana konflik penggabungan terjadi, dan bagaimana menyelesaikannya?

Konflik terjadi ketika kedua branch mengubah baris yang sama dalam berkas (atau berkas dihapus di satu branch dan diubah di branch lain), dan Git tidak bisa memutuskan sendiri. Git menghentikan penggabungan dan menandai lokasinya dengan penanda <<<<<<<, =======, dan >>>>>>>.

git status                 # daftar berkas yang konflik
# perbaiki berkas dengan memilih versi yang benar
git add app.js
git commit                 # untuk merge; untuk rebase: git rebase --continue

Jawaban yang kuat juga mencakup pencegahan: branch yang kecil, sering menarik dari branch utama, dan kesepakatan soal format kode. Dan sebutkan git merge --abort jika Anda perlu mundur.

11. Apa perbedaan merge dan rebase?

merge menggabungkan dua branch dengan membuat commit merge yang memiliki dua induk; commit yang sudah ada tidak berubah, dan riwayat jujur mencerminkan pekerjaan paralel. rebase memindahkan commit branch Anda ke atas branch lain dengan membuat salinannya dengan hash baru; hasilnya riwayat yang lurus.

Aturan umumnya: rebase untuk merapikan branch lokal sendiri sebelum dipublikasikan, merge untuk integrasi ke branch bersama. Me-rebase commit yang sudah dipublikasikan dan menjadi dasar kerja orang lain akan menimbulkan duplikasi dan kebingungan.

12. Apa itu rebase interaktif, dan untuk apa dipakai?

git rebase -i HEAD~5 membuka daftar lima commit terakhir, dan untuk setiap commit Anda bisa memilih tindakan: pick — biarkan, reword — ubah pesan, edit — berhenti dan perbaiki, squash dan fixup — gabungkan dengan commit sebelumnya, drop — hapus. Baris bisa diurutkan ulang.

Skenario tipikal: sebelum pull request, ubah «wip», «fix typo», dan «fix lagi» menjadi dua atau tiga commit yang bermakna. Kombinasi yang berguna: git commit --fixup=<hash>, lalu git rebase -i --autosquash.

13. Apa itu squash merge, dan kapan dipilih?

Pada squash merge, semua commit branch dipadatkan menjadi satu commit di branch tujuan (git merge --squash, atau tombol di GitHub/GitLab). Branch utama mendapat satu commit per fitur.

Keuntungannya adalah riwayat main yang bersih. Kekurangannya, detail riwayat di dalam fitur hilang, dan Git tidak menganggap branch asal sudah tergabung, sehingga git branch -d menolak menghapusnya tanpa -D.

14. Apa itu cherry-pick, dan kapan tepat digunakan?

git cherry-pick <hash> menerapkan perubahan satu commit ke branch aktif, dengan membuat commit baru yang isinya sama tetapi hash-nya berbeda. Contoh klasiknya adalah memindahkan perbaikan bug dari develop ke branch rilis atau hotfix.

Jangan terlalu sering memakainya: satu perbaikan hidup di dua commit, dan penggabungan branch di kemudian hari bisa menimbulkan konflik. Flag -x menambahkan referensi ke commit asal di pesan.

Membatalkan perubahan dan pemulihan

15. Apa perbedaan reset --soft, --mixed, dan --hard?

Mode	Penunjuk branch	Index	Direktori kerja
--soft	bergeser	tidak berubah	tidak berubah
--mixed (default)	bergeser	direset	tidak berubah
--hard	bergeser	direset	direset, perubahan hilang

git reset --soft HEAD~3 berguna untuk menyusun ulang tiga commit terakhir menjadi satu. --hard berbahaya bagi perubahan yang belum di-commit: reflog pun tidak bisa mengembalikannya.

16. Apa bedanya git revert dengan git reset?

reset memindahkan penunjuk branch ke belakang sehingga riwayat pada dasarnya ditulis ulang. revert membuat commit baru yang membatalkan perubahan commit yang dipilih, dan tidak menulis ulang apa pun.

Karena itu, untuk commit yang sudah dipublikasikan di branch bersama, jawaban yang tepat adalah revert: riwayat rekan kerja tidak rusak, dan pembatalannya terlihat jelas di log. Untuk commit merge, induk utamanya harus ditentukan: git revert -m 1 <hash>.

17. Bagaimana memulihkan commit setelah git reset --hard yang tidak disengaja?

Dengan git reflog: log ini mencatat perpindahan HEAD dan branch secara lokal (secara default entri disimpan sekitar 90 hari). Cari entri sebelum perintah yang keliru, lalu kembali ke sana:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Tambahkan pembayaran
git reset --hard 9f8e7d6

Catatan penting: reflog hanya menyelamatkan yang sudah pernah di-commit. Perubahan yang tidak pernah masuk ke commit (atau setidaknya ke stash) tidak bisa dipulihkan oleh Git.

18. Bagaimana membatalkan perubahan pada berkas dan mengeluarkannya dari index?

Perintah modernnya: git restore app.js (kembalikan berkas ke keadaan index) dan git restore --staged app.js (keluarkan dari index dengan tetap menyimpan perubahan). Dahulu digunakan git checkout -- app.js dan git reset HEAD app.js; keduanya masih berfungsi.

19. Apa itu git stash, dan apa jebakannya?

git stash menyimpan sementara perubahan yang belum di-commit dan mengosongkan direktori kerja — misalnya untuk segera berpindah ke hotfix. Perubahan dikembalikan dengan git stash pop atau apply.

Jebakannya: berkas yang tidak dilacak tidak ikut tersimpan secara default (perlu -u); saat pop bisa terjadi konflik, dan dalam kasus itu entri tidak dihapus dari daftar; dan stash mudah terlupakan. Untuk pekerjaan yang panjang, lebih baik buat commit di branch tersendiri.

Lanjutan dan kerja tim

20. Bagaimana menemukan commit yang merusak fungsi?

Dengan git bisect, yaitu pencarian biner dalam riwayat. Anda menentukan commit yang pasti rusak dan commit yang pasti benar; Git lalu memindahkan Anda ke tengah rentang, dan seterusnya sampai pelakunya ditemukan dalam sekitar log2(N) langkah.

git bisect start
git bisect bad                 # versi saat ini rusak
git bisect good v2.3.0         # di sini semuanya berjalan
# periksa dan jawab good/bad sampai Git menunjuk commit
git bisect reset

Jika ada skrip pemeriksaan, prosesnya bisa otomatis: git bisect run npm test.

21. Mengapa git push --force berbahaya, dan apa penggantinya?

--force menimpa branch remote dengan versi Anda, sehingga commit yang sudah dikirim rekan Anda hilang dari server. Pilihan yang lebih aman adalah git push --force-with-lease: perintah ini hanya menimpa jika branch di server masih berada di keadaan yang Anda lihat saat fetch terakhir.

Force push wajar dilakukan pada branch fitur pribadi setelah rebase; untuk main dan branch bersama lainnya, biasanya dilarang lewat proteksi branch di server.

22. Alur kerja Git apa saja yang Anda kenal?

GitHub Flow: satu branch utama yang selalu siap dirilis, dan branch fitur pendek yang digabung lewat pull request setelah review dan CI. Git Flow: branch main dan develop, ditambah feature/*, release/*, dan hotfix/*; cocok untuk produk dengan rilis berversi. Trunk-based development: semua orang mengintegrasikan perubahan ke trunk sangat sering, dan pekerjaan yang belum selesai disembunyikan di balik feature flag.

Jawaban yang kuat menjelaskan alasan pilihan: untuk layanan web dengan deploy berkelanjutan, Git Flow biasanya berlebihan; untuk pustaka yang mendukung beberapa versi sekaligus, Git Flow justru bermanfaat.

23. Apa itu pull request, dan apa yang diperiksa di dalamnya?

Pull request (di GitLab disebut merge request) adalah permintaan penggabungan branch yang melewati code review dan pemeriksaan otomatis CI sebelum digabung. Ini fitur platform (GitHub, GitLab, Bitbucket), bukan bagian dari Git itu sendiri.

Pull request yang baik itu kecil, menyelesaikan satu tugas, memiliki deskripsi yang jelas, dan terkait dengan tugas di pelacak. Reviewer memeriksa kebenaran, keterbacaan, tes, serta memastikan tidak ada berkas yang tidak perlu atau rahasia yang ikut masuk.

24. Aturan apa yang Anda ikuti untuk pesan commit yang baik?

Judul singkat (sampai 50–72 karakter) dalam bentuk kalimat perintah, misalnya «Tambahkan validasi e-mail», diikuti baris kosong dan isi yang menjelaskan «mengapa», bukan «apa» (apa yang berubah sudah terlihat di diff). Banyak tim memakai Conventional Commits: feat:, fix:, docs:, refactor:.

Pesan seperti ini memungkinkan pembuatan changelog secara otomatis, mempermudah pencarian dengan git log --grep, dan membuat alasan perubahan tetap bisa dipahami bertahun-tahun kemudian.

25. Apa yang Anda lakukan jika secara tidak sengaja mengirim kata sandi ke repositori?

Hal pertama: cabut dan buat ulang rahasianya. Rahasia itu sudah bocor, meskipun Anda menghapusnya satu menit kemudian, karena klon, fork, dan cache sudah menyimpannya. Berikutnya, hentikan pelacakan berkas itu, tambahkan ke .gitignore, dan bila perlu bersihkan riwayat dengan alat seperti git filter-repo, diikuti force push dan pemberitahuan kepada tim.

Pewawancara menilai prioritas Anda: kandidat yang mulai dengan menulis ulang riwayat dan lupa merotasi kunci menjawab dengan keliru.

Cara bersiap menghadapi pertanyaan Git

Cara paling andal bukan menghafal jawaban, melainkan menjalankan setiap skenario dengan tangan di repositori uji: membuat konflik lalu menyelesaikannya, melakukan reset --hard lalu memulihkan lewat reflog, dan memadatkan commit dengan rebase interaktif. Di wawancara, sering diberikan tugas praktis atau diminta menggambar graf commit sebelum dan sesudah suatu perintah. Jika Anda pernah melakukannya sendiri, jawabannya akan mudah digambar.

Berguna juga untuk menguji diri dengan tes singkat tentang Git: cobalah menjawab tanpa bantuan apa yang akan terjadi pada riwayat setelah git rebase main atau git revert HEAD. Jika Anda yakin menjawab pertanyaan «apa yang berubah di ketiga area», dasar Anda sudah kuat.

Ringkasan

Wawancara Git hampir selalu berkisar pada tiga topik: model data (commit, branch, HEAD, index), integrasi perubahan (merge, rebase, konflik, fetch dan pull), dan pembatalan yang aman (reset, revert, reflog). Tambahkan pemahaman tentang alur kerja tim dan pull request, dan Anda sudah mencakup sebagian besar pertanyaan. Semua skenario ini, termasuk kerja tim dan alat lanjutan, dilatih dengan praktik dalam kursus Git.