Mga tanong tungkol sa Git sa job interview: 25 tanong na may sagot

Halos lahat ng interview para sa developer, tester, o DevOps engineer ay may tanong tungkol sa Git: minsan bilang hiwalay na bahagi, minsan bilang bahagi ng usapan ("paano ninyo i-rollback ang sirang release?"). Hindi gaanong mahalaga sa interviewer ang pagkabisado ng mga flag, kundi ang pag-unawa sa modelo: ano ang commit, saan nakaturo ang branch, at ano ang binabago ng history. Narito ang 25 tanong na pinakamadalas lumitaw, kasama ang mga sagot na nag-iiwan ng magandang impresyon.

Mula sa pangunahing tanong hanggang sa advanced ang pagkakasunod-sunod. Kapag sumasagot sa interview, magbigay kung maaari ng maikling halimbawa mula sa praktika: mas pinahahalagahan ito kaysa sa pag-uulit ng dokumentasyon.

Mga pangunahing tanong

1. Ano ang Git, at ano ang pagkakaiba ng distributed na version control sa centralized?

Ang Git ay distributed version control system: iniimbak nito ang history ng mga pagbabago ng proyekto at nagpapahintulot sa maraming tao na magtrabaho nang sabay. Sa mga centralized na sistema (halimbawa SVN), nasa iisang server ang buong history, at ang developer ay mayroon lang working copy. Sa Git, may kumpletong history ang bawat clone, kaya gumagana nang lokal at walang network ang mga commit, branch, pagtingin sa history, at merge.

Ang praktikal na bentahe: mabilis, gumagana offline, at walang iisang punto ng pagkabigo. Ang server gaya ng GitHub o GitLab ay kasunduan lang ng team tungkol sa "pangunahing" kopya, hindi teknikal na pangangailangan ng Git.

2. Ilang lugar ang sakop ng pagtatrabaho sa Git?

Working directory (mga file sa disk), index o staging area (inihandang snapshot ng susunod na commit), at lokal na repository (ang folder na .git na may history). Inililipat ng git add ang pagbabago mula working directory papunta sa index, at ng git commit mula index papunta sa repository.

Magandang dagdag na banggitin ang ikaapat na lugar, ang remote repository, at ang mga command na git push at git fetch na nakikipag-ugnayan dito.

3. Bakit may index pa, kung puwedeng mag-commit nang direkta?

Pinapayagan ng index na bumuo ng commit nang sinasadya: sa sampung binagong file, puwede ninyong i-commit ang tatlong kaugnay ng iisang gawain, at iwan ang iba. Sa git add -p, kahit ang mga bahagi sa loob ng file ay mapipili.

Ito ang pundasyon ng atomic commits: isang lohikal na pagbabago, isang commit. Madaling basahin, i-review, i-revert gamit ang revert, at ilipat gamit ang cherry-pick ang ganitong history.

4. Ano ang commit mula sa pananaw ng internal na istruktura ng Git?

Ang commit ay object na naglalaman ng reference sa tree (snapshot ng lahat ng file ng proyekto), reference sa mga parent commit, author, committer, petsa, at mensahe. Natutukoy ito ng SHA-1 hash ng buong nilalaman nito (sa mas bagong bersyon, may eksperimental na suporta para sa SHA-256).

Pangunahing ideya: nag-iimbak ang Git ng mga snapshot, hindi ng mga diff. Hindi dinudoble ang mga file na hindi nagbago; tumuturo lang ang tree sa parehong blob. Dahil nakabatay ang hash sa parent, imposibleng baguhin ang lumang commit nang hindi binabago ang hash ng lahat ng kasunod nito.

5. Ano ang branch, at ano ang HEAD?

Ang branch ay isang gumagalaw na pointer sa commit: file sa .git/refs/heads/ na may hash sa loob. Kaya agad-agad ang paggawa ng branch at walang kinokopya. Kapag may bagong commit, sumusulong ang pointer ng kasalukuyang branch.

Ang HEAD ay pointer kung nasaan kayo ngayon; karaniwan, nakaturo ito sa branch (ref: refs/heads/main). Kapag lumipat sa isang partikular na commit o tag, direktang nakaturo ang HEAD sa commit: ito ang estadong detached HEAD.

6. Ano ang detached HEAD, at bakit ito mapanganib?

Ito ang estado kapag nakaturo ang HEAD sa commit at hindi sa branch, halimbawa pagkatapos ng git switch --detach v1.0 o git checkout a1b2c3d. Puwedeng tingnan ang code at mag-commit, pero hindi nabibilang sa anumang branch ang mga bagong commit.

Kapag lumipat sa ibang branch pagkatapos nito, magiging hindi na maaabot ang mga commit at kalaunan ay buburahin ng garbage collector. Para mapanatili ang gawa, gumawa ng branch: git switch -c fix-from-detached. Kung nakaalis na, makikita ang hash sa git reflog.

7. Ano ang pagkakaiba ng git fetch at git pull?

Dina-download ng git fetch ang mga bagong commit at ina-update ang remote-tracking na branch gaya ng origin/main, pero hindi nito ginagalaw ang inyong mga lokal na branch at file. Ang git pull ay fetch kasama ang integrasyon: sa default ay merge, at sa flag na --rebase o setting na pull.rebase=true ay rebase.

Madalas na hiwalay na ginagawa ng mga bihasang developer ang fetch, tinitingnan ang git log HEAD..origin/main, at saka lang nagpapasya kung paano isasama ang mga pagbabago.

8. Paano gumagana ang .gitignore, at bakit sinusubaybayan pa rin ang file kahit nasa listahan na?

Naglalaman ang .gitignore ng mga pattern ng file na hindi dapat imungkahi ng Git para idagdag: dependencies, build, log, at lokal na config na may secrets. Sa mga hindi pa sinusubaybayang file lang gumagana ang mga patakaran.

Kung na-commit na ang file, walang epekto ang ignore dito. Kailangang alisin ito sa index at iwan sa disk: git rm --cached config.local.php, at i-commit ang pagbura. Para malaman kung aling patakaran ang tumatama, makakatulong ang git check-ignore -v path.

Mga branch, merge, at conflict

9. Ano ang fast-forward merge?

Kung hindi lumayo pa ang target na branch mula sa punto ng pagsanga, ililipat lang ng Git ang pointer nito sa huling commit ng branch na isasama, nang walang bagong commit. Nananatiling linear ang history.

Pinipilit ng flag na --no-ff ang paggawa ng merge commit kahit ganito: nakikita sa history na hiwalay na feature ang grupo ng mga commit. Ang --ff-only naman ay pinapayagan lang ang fast-forward at tumatanggi kapag kailangan ang tunay na merge.

10. Paano nagkakaroon ng merge conflict, at paano ito inaayos?

Nagkakaroon ng conflict kapag binago ang parehong mga linya ng file sa dalawang branch (o binura ito sa isa at binago sa kabila), at hindi ito malutas nang awtomatiko ng Git. Hihinto ang merge at mamarkahan ang mga bahagi gamit ang <<<<<<<, =======, at >>>>>>>.

git status                 # listahan ng mga file na may conflict
# ayusin ang mga file, iwan ang tamang bersyon
git add app.js
git commit                 # para sa merge; para sa rebase, git rebase --continue

Kumpleto ang sagot kapag may kasamang pag-iwas: maliliit na branch, madalas na pull mula sa pangunahing branch, at kasunduan sa formatting. Banggitin din ang git merge --abort kung kailangang umatras.

11. Ano ang pagkakaiba ng merge at rebase?

Pinagsasama ng merge ang dalawang branch sa pamamagitan ng merge commit na may dalawang parent; hindi nagbabago ang mga umiiral na commit, at tapat na ipinapakita ng history ang sabay-sabay na trabaho. Inililipat naman ng rebase ang mga commit ng inyong branch sa ibabaw ng ibang branch, gumagawa ng kopya ng mga ito na may bagong hash; nagiging linear ang history.

Karaniwang tuntunin: rebase para ayusin ang sariling lokal na branch bago i-publish, at merge para isama sa shared na branch. Ang rebase ng mga na-publish na commit na ginagamit pa ng iba ay nagdudulot ng duplicate at kalituhan.

12. Ano ang interactive rebase, at para saan ito?

Ang git rebase -i HEAD~5 ay nagbubukas ng listahan ng huling limang commit, kung saan puwedeng pumili ng aksyon para sa bawat isa: pick para panatilihin, reword para baguhin ang mensahe, edit para huminto at ayusin, squash at fixup para pagsamahin sa nauna, at drop para burahin. Puwedeng ayusin ang pagkakasunod ng mga linya.

Karaniwang gamit: bago ang pull request, gawing dalawa o tatlong makabuluhang commit ang "wip", "fix typo", "isa pang fix". Maginhawang pares nito ang git commit --fixup=<hash> at pagkatapos ang git rebase -i --autosquash.

13. Ano ang squash merge, at kailan ito pinipili?

Sa squash merge, lahat ng commit ng branch ay pinagsasama sa iisang commit sa target na branch (git merge --squash, o ang button sa GitHub/GitLab). Isang commit kada feature ang nakukuha ng pangunahing branch.

Ang bentahe: malinis na history ng main. Ang kapalit: nawawala ang detalyadong history sa loob ng feature, at hindi itinuturing ng Git na na-merge ang pinagmulang branch, kaya tatanggi ang git branch -d na burahin ito kung walang -D.

14. Ano ang cherry-pick, at kailan ito angkop?

Ang git cherry-pick <hash> ay naglalapat ng pagbabago ng iisang commit sa kasalukuyang branch, at gumagawa ng bagong commit na may kaparehong nilalaman pero ibang hash. Klasikong halimbawa: ilipat ang ayos ng bug mula sa develop papunta sa release branch o hotfix.

Huwag itong abusuhin: nabubuhay ang iisang ayos sa dalawang commit, at maaaring magkaroon ng conflict sa susunod na merge ng mga branch. Ang flag na -x ay nagdaragdag ng reference sa orihinal na commit sa mensahe.

Pag-undo at pagbawi

15. Ano ang pagkakaiba ng git reset na --soft, --mixed, at --hard?

Mode	Pointer ng branch	Index	Working directory
--soft	gumagalaw	hindi nagbabago	hindi nagbabago
--mixed (default)	gumagalaw	nire-reset	hindi nagbabago
--hard	gumagalaw	nire-reset	nire-reset, nawawala ang mga pagbabago

Kapaki-pakinabang ang git reset --soft HEAD~3 para gawing isang commit ang huling tatlong commit. Mapanganib ang --hard para sa mga hindi pa naka-commit na pagbabago: hindi na ito maibabalik kahit ng reflog.

16. Ano ang pagkakaiba ng git revert at git reset?

Inililipat ng reset ang pointer ng branch pabalik, na epektibong nagsusulat muli ng history. Gumagawa naman ng bagong commit ang revert na nagkakansela sa pagbabago ng tinukoy na commit, at walang isinusulat muli.

Kaya para sa mga na-publish na commit sa shared na branch, tamang sagot ang revert: hindi nasisira ang history ng mga kasama, at makikita sa log ang pagkansela mismo. Para sa merge commit, kailangang tukuyin ang pangunahing parent: git revert -m 1 <hash>.

17. Paano ibabalik ang mga commit pagkatapos ng aksidenteng git reset --hard?

Gamit ang git reflog: iniimbak nito ang kasaysayan ng paggalaw ng HEAD at ng mga branch nang lokal (karaniwang nananatili ang mga entry nang mga 90 araw). Hanapin ang entry bago ang maling command at bumalik doon:

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

Mahalagang paalala: ang reflog ay nagliligtas lang ng mga na-commit na. Ang mga pagbabagong hindi kailanman napunta sa commit (o kahit sa stash) ay hindi na maibabalik ng Git.

18. Paano i-undo ang mga pagbabago sa file at alisin ito sa index?

Ang mga kasalukuyang command ay git restore app.js (ibalik ang file sa estado ng index) at git restore --staged app.js (alisin sa index, pero itira ang pagbabago). Dati, ginagamit ang git checkout -- app.js at git reset HEAD app.js; gumagana pa rin ang mga ito.

19. Ano ang git stash, at ano ang mga bitag nito?

Pansamantalang itinatabi ng git stash ang mga hindi pa naka-commit na pagbabago at nililinis ang working directory, halimbawa para agad lumipat sa hotfix. Maibabalik ang mga ito gamit ang git stash pop o apply.

Mga bitag: hindi kasama ang mga hindi sinusubaybayang file bilang default (kailangan ang -u); kapag nagkaconflict sa pop, hindi nabubura ang entry sa listahan; madaling makalimutan ang stash. Para sa mahabang gawain, mas mabuting mag-commit sa hiwalay na branch.

Mga advanced na tanong at teamwork

20. Paano hahanapin ang commit na sumira sa functionality?

Gamit ang git bisect, isang binary search sa history. Itinuturo ninyo ang tiyak na masamang commit at ang tiyak na mabuting commit, at inilalagay kayo ng Git sa gitna ng saklaw nang paulit-ulit hanggang makita ang salarin sa log2(N) na hakbang.

git bisect start
git bisect bad                 # sira ang kasalukuyang bersyon
git bisect good v2.3.0         # gumana pa noon
# suriin at sumagot ng good/bad hanggang sabihin ng Git ang commit
git bisect reset

Kung may script para sa pagsusuri, puwedeng i-automate: git bisect run npm test.

21. Bakit delikado ang git push --force, at ano ang dapat gamitin kapalit nito?

Pinapalitan ng --force ang remote na branch ng sarili ninyong bersyon, at mawawala sa server ang mga commit na naipadala na ng mga kasama. Mas ligtas ang git push --force-with-lease: i-o-overwrite lang nito ang branch kung nasa estadong nakita ninyo ito noong huling fetch.

Normal ang force push sa sariling feature branch pagkatapos ng rebase; sa main at iba pang shared na branch, karaniwang ipinagbabawal ito ng proteksyon ng branch sa server.

22. Anong mga Git workflow ang alam ninyo?

GitHub Flow: iisang pangunahing branch na laging handang i-deploy, at maiikling feature branch na isinasama sa pamamagitan ng pull request pagkatapos ng review at CI. Git Flow: mga branch na main at develop, kasama ang feature/*, release/*, at hotfix/*; angkop sa mga produktong may versioned na release. Trunk-based development: madalas na nagsasama ang lahat sa trunk, at nakatago sa likod ng feature flags ang hindi pa tapos.

Malakas ang sagot kapag ipinaliwanag ang pagpili: para sa web service na may tuloy-tuloy na deploy, kadalasang sobra ang Git Flow; para sa library na may suporta sa maraming bersyon, makatwiran ito.

23. Ano ang pull request, at ano ang sinusuri dito?

Ang pull request (sa GitLab, merge request) ay kahilingan na isama ang isang branch, at dumadaan ito sa code review at awtomatikong pagsusuri ng CI bago ma-merge. Feature ito ng platform (GitHub, GitLab, Bitbucket), hindi ng Git mismo.

Maliit ang magandang PR, nilulutas ang iisang gawain, may malinaw na paglalarawan, at naka-link sa task sa tracker. Tinitingnan ng reviewer ang katumpakan, pagiging madaling basahin, mga test, at kung may hindi dapat naroon, tulad ng dagdag na file o secret.

24. Anong mga patakaran ang sinusunod ninyo sa mensahe ng commit?

Maikling pamagat (hanggang 50 hanggang 72 karakter) sa imperative na anyo, gaya ng "Idagdag ang validation ng e-mail", kasunod ng blangkong linya at katawan na nagpapaliwanag ng "bakit", hindi ng "ano" (makikita na ang "ano" sa diff). Maraming team ang gumagamit ng Conventional Commits: feat:, fix:, docs:, refactor:.

Ang ganitong mga mensahe ang nagpapahintulot na gumawa ng changelog, mabilis na mahanap ang kailangan sa pamamagitan ng git log --grep, at maintindihan pagkalipas ng mga taon ang dahilan ng mga pagbabago.

25. Ano ang gagawin ninyo kung aksidenteng na-push ang password sa repository?

Una: bawiin at palitan ang secret; compromised na ito kahit burahin pa sa loob ng isang minuto (may mga clone, fork, at cache). Pagkatapos, alisin ang file sa pagsubaybay, idagdag sa .gitignore, at kung kinakailangan, linisin ang history gamit ang mga tool gaya ng git filter-repo, kasunod ng force push at babala sa team.

Sinusuri dito ng interviewer ang mga prayoridad: ang kandidatong magsisimula sa pagsusulat muli ng history at makakalimutan ang pagpapalit ng key ay mali ang sagot.

Paano maghanda para sa mga tanong tungkol sa Git

Ang pinakamaaasahang paraan ay hindi ang pagkabisado ng mga sagot, kundi ang pagpapatakbo ng bawat senaryo nang sarili sa test repository: lumikha ng conflict at ayusin ito, gawin ang reset --hard at bumalik gamit ang reflog, pagsamahin ang mga commit gamit ang interactive rebase. Sa interview tungkol sa Git, madalas na may praktikal na gawain o hinihiling na iguhit ang graph ng mga commit bago at pagkatapos ng isang command. Kung ginawa ninyo ito nang mag-isa, madali nang maiguhit ang sagot.

Kapaki-pakinabang din ang maikling pagsusulit sa Git para sa sariling pagsusuri: subukang sagutin nang walang tulong kung ano ang mangyayari sa history pagkatapos ng git rebase main o git revert HEAD. Kung kumpiyansa kayo sa tanong na "ano ang nagbabago sa tatlong lugar", matibay ang pundasyon ninyo.

Buod

Halos palaging umiikot ang interview tungkol sa Git sa tatlong paksa: modelo ng data (commit, branch, HEAD, index), pagsasama ng mga pagbabago (merge, rebase, conflict, fetch at pull), at ligtas na pag-undo (reset, revert, reflog). Idagdag ang pag-unawa sa workflow ng team at pull request, at masasagot na ninyo ang malaking bahagi ng mga tanong. Ang lahat ng senaryong ito, kasama ang teamwork at mga advanced na tool, ay isinasagawa nang praktikal sa kurso ng Git.