Maswali ya Git kwenye mahojiano: maswali 25 yenye majibu

Git inapimwa karibu kwenye mahojiano yote ya msanidi programu, mjaribu au mhandisi wa DevOps: wakati mwingine kama sehemu maalum, wakati mwingine kwa kupita («ungerudishaje toleo lililoshindwa?»). Mhojiwa anahitaji kuona uelewa wa muundo zaidi ya bendera: commit ni nini, tawi linaelekeza wapi, na historia inaandikwa upya vipi. Hapa chini ni maswali 25 yanayoulizwa mara nyingi, pamoja na majibu ya kiwango kinachotoa picha nzuri.

Maswali yanaanza na ya msingi kwenda kwenye ya juu. Unapojibu mahojiano, toa mfano mfupi kutoka kazini inapowezekana — hilo linathaminiwa kuliko kurudia nyaraka.

Maswali ya msingi

1. Git ni nini, na mfumo wa udhibiti wa matoleo uliosambazwa unatofautianaje na ule wa kati?

Git ni mfumo uliosambazwa wa udhibiti wa matoleo: unahifadhi historia ya mabadiliko ya mradi na unaruhusu watu kadhaa kufanya kazi sambamba. Kwenye mifumo ya kati (kwa mfano SVN) historia kamili iko kwenye seva moja, na msanidi ana nakala ya kazi tu. Kwenye Git kila clone ina historia yote, kwa hiyo commits, matawi, kuangalia historia na muunganisho vinafanya kazi kwenye kompyuta bila mtandao.

Faida za vitendo: kasi kubwa, uwezo wa kufanya kazi nje ya mtandao, na kutokuwepo kwa sehemu moja ya kushindwa. Seva kama GitHub au GitLab kwenye Git ni makubaliano ya timu kuhusu nakala «kuu», si hitaji la kiufundi.

2. Kazi na Git inagawanyika katika maeneo gani matatu?

Saraka ya kazi (faili kwenye diski), index au staging area (picha iliyoandaliwa ya commit ijayo), na hifadhi ya ndani (folda .git yenye historia). git add inahamisha mabadiliko kutoka saraka ya kazi kwenda index, git commit — kutoka index kwenda hifadhini.

Ongezeko zuri ni kutaja eneo la nne, hifadhi ya mbali, na amri git push na git fetch zinazofanya kazi nayo.

3. Kwa nini index inahitajika, ikiwa unaweza kufanya commit moja kwa moja?

Index inakuwezesha kujenga commit kwa makusudi: kati ya mafaili kumi yaliyobadilishwa unaweza ku-commit matatu yanayohusu kazi moja, na yaliyobaki kuyaacha. Kwa git add -p unaweza hata kuchagua vipande ndani ya faili.

Hii ndiyo msingi wa commits za atomiki: commit moja — mabadiliko moja ya kimantiki. Historia kama hiyo inasomeka kwa urahisi, inakaguliwa vizuri, inaghairiwa kwa revert, na inahamishwa kwa cherry-pick.

4. Commit ni nini kwa mtazamo wa muundo wa ndani wa Git?

Commit ni kitu kinachohifadhi kiungo cha mti (tree) — picha ya mafaili yote ya mradi, viungo vya commits za wazazi, mwandishi, committer, tarehe na ujumbe. Kinatambuliwa kwa hash ya SHA-1 (matoleo mapya yana msaada wa majaribio wa SHA-256) inayohesabiwa kutoka yaliyomo yote.

Wazo kuu: Git inahifadhi picha, si tofauti. Mafaili ambayo hayajabadilika hayanakiliwi — mti unaelekeza tu kwenye blob ile ile. Kwa kuwa hash inategemea mzazi, haiwezekani kubadilisha commit ya zamani bila kubadilisha hash za zote zinazofuata.

5. Tawi ni nini, na HEAD ni nini?

Tawi ni kielekezi kinachosonga tu kwenda kwenye commit, yaani faili lililo kwenye .git/refs/heads/ lenye hash ndani. Ndiyo maana kuunda tawi kwenye Git ni papo hapo na hakunakili chochote. Commit mpya inapofanyika, kielekezi cha tawi la sasa kinasogea kwenye commit hiyo.

HEAD ni kielekezi cha mahali ulipo sasa; kwa kawaida kinaelekeza kwenye tawi (ref: refs/heads/main). Ukihamia kwenye commit au tagi maalum, HEAD itaelekeza moja kwa moja kwenye commit — hali hiyo inaitwa detached HEAD.

6. Detached HEAD ni nini, na ina hatari gani?

Ni hali ambapo HEAD inaelekeza kwenye commit badala ya tawi, kwa mfano baada ya git switch --detach v1.0 au git checkout a1b2c3d. Unaweza kuangalia msimbo na hata kufanya commit, lakini commits mpya hazimilikiwi na tawi lolote.

Ukihamia tawi lingine, commits hizo zinakuwa hazifikiki na hatimaye zinafutwa na garbage collector. Ili kuhifadhi kazi, unda tawi: git switch -c fix-from-detached. Ikiwa tayari umeondoka, hash itapatikana kwenye git reflog.

7. Git fetch inatofautianaje na git pull?

git fetch inapakua commits mpya na kusasisha matawi ya remote kama origin/main, lakini haigusi matawi yako ya ndani wala mafaili. git pull ni fetch pamoja na ujumuishaji: kwa chaguo-msingi merge, na kwa bendera --rebase au mpangilio pull.rebase=true — rebase.

Wasanidi wenye uzoefu mara nyingi wanafanya fetch peke yake, wanaangalia git log HEAD..origin/main, na ndipo wanaamua jinsi ya kuunganisha mabadiliko.

8. .gitignore inafanyaje kazi, na kwa nini faili bado linafuatiliwa ingawa liko kwenye orodha?

.gitignore inaweka mifumo ya mafaili ambayo Git haipaswi kupendekeza kuongezwa: utegemezi, ujenzi, logi, mipangilio ya ndani yenye siri. Kanuni zinatumika tu kwa mafaili yasiyofuatiliwa.

Ikiwa faili lilishawekwa commit, ignore haliathiri. Linapaswa kuondolewa kwenye index huku likibaki kwenye diski: git rm --cached config.local.php, kisha ku-commit hatua hiyo ya kuondoa. Kukagua kanuni inayofanya kazi, tumia git check-ignore -v njia.

Matawi, muunganisho na conflicts

9. Fast-forward merge ni nini?

Ikiwa tawi lengwa halijasonga mbele tangu lilipotoka, Git wakati wa muunganisho inasogeza tu kielekezi chake hadi commit ya mwisho ya tawi linalounganishwa — bila commit mpya. Historia inabaki mstari mmoja.

Bendera --no-ff inalazimisha kuunda commit ya merge hata katika hali hii: kwenye historia inaonekana kwamba kundi la commits lilikuwa kipengele tofauti. Bendera --ff-only kinyume chake inaruhusu fast-forward pekee na inakataa pale inapohitajika merge halisi.

10. Conflict ya muunganisho hutokeaje, na inasuluhishwaje?

Conflict hutokea wakati mistari ile ile imebadilishwa kwenye matawi yote mawili (au faili limefutwa upande mmoja na kubadilishwa upande mwingine), na Git haiwezi kuamua yenyewe. Inasimamisha muunganisho na kuweka alama mahali pa tatizo kwa mistari <<<<<<<, =======, >>>>>>>.

git status                 # orodha ya mafaili yenye conflicts
# hariri mafaili, ukiacha toleo sahihi
git add app.js
git commit                 # kwa merge; kwa rebase — git rebase --continue

Jibu zuri linajumuisha pia kinga: matawi madogo, kuvuta mara kwa mara tawi kuu, makubaliano kuhusu uundaji wa msimbo. Na pia git merge --abort, ikiwa unahitaji kurudi nyuma.

11. Merge na rebase vinatofautianaje?

merge inaunganisha matawi mawili kwa kuunda commit ya merge yenye wazazi wawili; commits zilizopo hazibadiliki, na historia inaonyesha kwa uaminifu kazi sambamba. rebase inahamisha commits zako juu ya tawi jingine, ikiunda nakala zao zenye hash mpya; historia inakuwa mstari mmoja.

Kanuni ya kawaida: rebase — kwa kusafisha tawi lako la ndani kabla ya kulichapisha, merge — kwa kuunganisha kwenye matawi ya pamoja. Rebase ya commits zilizochapishwa ambazo wengine wanazitegemea inaleta marudio na mkanganyiko.

12. Rebase shirikishi ni nini, na inatumika kwa nini?

git rebase -i HEAD~5 inafungua orodha ya commits tano za mwisho, ambapo kwa kila moja unachagua kitendo: pick — kuiacha, reword — kubadilisha ujumbe, edit — kusimama na kuirekebisha, squash na fixup — kuiunganisha na iliyotangulia, drop — kuifuta. Mistari inaweza kupangwa upya.

Mfano wa kawaida: kabla ya pull request, badilisha «wip», «fix typo», «fix zaidi» kuwa commits mbili au tatu zenye maana. Mchanganyiko mzuri ni git commit --fixup=<hash> kisha git rebase -i --autosquash.

13. Squash merge hufanya nini, na huchaguliwa lini?

Kwa squash merge commits zote za tawi zinabanwa kuwa commit moja kwenye tawi lengwa (git merge --squash au kitufe cha GitHub/GitLab). Tawi kuu linapata commit moja kwa kila kipengele.

Faida ni historia safi ya main. Hasara ni kwamba historia ya kina ndani ya kipengele inapotea, na Git haichukulii tawi la asili kuwa limeunganishwa, kwa hiyo git branch -d itakataa kulifuta bila -D.

14. Cherry-pick ni nini, na inafaa lini?

git cherry-pick <hash> inatumia mabadiliko ya commit moja kwenye tawi la sasa, ikiunda commit mpya yenye maudhui yale yale lakini hash tofauti. Mfano wa kawaida ni kuhamisha marekebisho ya hitilafu kutoka develop kwenda tawi la release au hotfix.

Usiitumie kupita kiasi: marekebisho yale yale yanaishi kwenye commits mbili, na muunganisho wa baadaye wa matawi unaweza kuleta conflicts. Bendera -x inaongeza kwenye ujumbe kiungo cha commit ya asili.

Kughairi na kurejesha

15. Reset --soft, --mixed na --hard zinatofautianaje?

Hali	Kielekezi cha tawi	Index	Saraka ya kazi
--soft	kinasogea	haibadiliki	haibadiliki
--mixed (chaguo-msingi)	kinasogea	inawekwa upya	haibadiliki
--hard	kinasogea	inawekwa upya	inawekwa upya, mabadiliko yanapotea

git reset --soft HEAD~3 ni muhimu kugeuza commits tatu za mwisho kuwa moja. --hard ni hatari kwa mabadiliko ambayo hayajawekwa commit: hata reflog haiwezi kuyarejesha.

16. Git revert inatofautianaje na git reset?

reset inasogeza kielekezi cha tawi nyuma, na kwa vitendo inaandika upya historia. revert inaunda commit mpya inayoghairi mabadiliko ya ile uliyoitaja, na haiandiki upya chochote.

Kwa hiyo kwa commits zilizochapishwa kwenye tawi la pamoja, jibu sahihi ni revert: historia ya wenzako haivunjiki, na kughairi kunaonekana wazi kwenye log. Kwa commit ya merge lazima utaje mzazi mkuu: git revert -m 1 <hash>.

17. Jinsi ya kurejesha commits baada ya git reset --hard ya bahati mbaya?

Kupitia git reflog: inahifadhi historia ya mienendo ya HEAD na matawi kwenye kompyuta yako (kwa chaguo-msingi ingizo zinaishi takriban siku 90). Tunapata ingizo kabla ya amri mbaya na tunarudi:

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

Tahadhari muhimu: reflog inaokoa yaliyowekwa commit pekee. Mabadiliko ambayo hayajawahi kuingia kwenye commit (au angalau kwenye stash), Git haiwezi kuyarejesha.

18. Jinsi ya kughairi mabadiliko kwenye faili na kuliondoa kwenye index?

Amri za kisasa ni git restore app.js (kurudisha faili kwenye hali ya index) na git restore --staged app.js (kuliondoa kwenye index huku mabadiliko yakibaki). Zamani zilitumika git checkout -- app.js na git reset HEAD app.js; zinafanya kazi bado.

19. Git stash ni nini, na ina mitego gani?

git stash inahifadhi kwa muda mabadiliko ambayo hayajawekwa commit na kusafisha saraka ya kazi — kwa mfano ili kubadili haraka kwenda hotfix. Unayarudisha kwa git stash pop au apply.

Mitego: kwa chaguo-msingi mafaili yasiyofuatiliwa hayahifadhiwi (yanahitaji -u); wakati wa pop conflict inaweza kutokea, na kisha ingizo halifutwi kwenye orodha; stash ni rahisi kusahaulika. Kwa kazi ya muda mrefu ni bora commit kwenye tawi tofauti.

Maswali ya juu na kazi ya timu

20. Unapataje commit iliyovunja utendaji?

Kwa git bisect — utafutaji wa binary kwenye historia. Unataja commit mbaya kwa uhakika na nzuri kwa uhakika, na Git inakupeleka katikati ya safu hadi ipate mhusika kwa hatua log2(N).

git bisect start
git bisect bad                 # toleo la sasa limevunjika
git bisect good v2.3.0         # hapa kila kitu kilifanya kazi
# kagua na ujibu good/bad hadi Git itaje commit
git bisect reset

Ikiwa kuna script ya ukaguzi, mchakato unajiendesha: git bisect run npm test.

21. Kwa nini git push --force ni hatari, na nini kinaweza kuichukua nafasi?

--force inaandika juu ya tawi la mbali kwa toleo lako, na commits ambazo wenzako walizituma zinapotea kwenye seva. Salama zaidi ni git push --force-with-lease: itaandika juu ya tawi tu ikiwa liko kwenye seva katika hali uliyoiona wakati wa fetch ya mwisho.

Force push ni kawaida kwa tawi lako binafsi la feature baada ya rebase; kwenye main na matawi mengine ya pamoja kwa kawaida inazuiwa kwa ulinzi wa matawi kwenye seva.

22. Ni mitiririko gani ya kazi ya Git unayoifahamu?

GitHub Flow: tawi moja kuu linalokuwa tayari kwa utoaji wakati wote, na matawi mafupi ya feature yanayounganishwa kupitia pull request baada ya ukaguzi na CI. Git Flow: matawi main na develop, pamoja na feature/*, release/* na hotfix/*; yanafaa bidhaa zenye matoleo yaliyopangwa. Trunk-based development: kila mtu anaunganisha kwenye trunk mara nyingi sana, na kazi isiyokamilika inafichwa nyuma ya feature flags.

Jibu zuri linaeleza uchaguzi: kwa huduma ya wavuti yenye utoaji endelevu Git Flow kwa kawaida ni nzito mno, na kwa maktaba yenye msaada wa matoleo kadhaa inafaa.

23. Pull request ni nini, na ndani yake huangaliwa nini?

Pull request (kwenye GitLab — merge request) ni ombi la kuunganisha tawi, linalopitia ukaguzi wa msimbo na majaribio ya kiotomatiki ya CI kabla ya kuingizwa. Ni kipengele cha jukwaa (GitHub, GitLab, Bitbucket), si cha Git yenyewe.

PR nzuri ni ndogo, inatatua kazi moja, ina maelezo wazi, na imeunganishwa na kazi kwenye mfumo wa kufuatilia. Mkaguzi anaangalia usahihi, usomaji, majaribio, na kama hakuna mafaili ya ziada au siri zilizoingia.

24. Ni kanuni zipi za ujumbe mzuri wa commit unazozifuata?

Kichwa kifupi (hadi herufi 50–72) katika nafsi ya amri — «Ongeza uthibitishaji wa barua pepe», kisha mstari tupu na mwili unaoeleza «kwa nini», si «nini» (kilichobadilika kinaonekana kwenye diff). Timu nyingi zinatumia Conventional Commits: feat:, fix:, docs:, refactor:.

Ujumbe kama huu unaruhusu kutengeneza changelog, kupata haraka kitu kupitia git log --grep, na kuelewa sababu za mabadiliko baada ya miaka.

25. Ukisukuma nywila kwenye hifadhi kimakosa, utafanya nini?

Kwanza kabisa — batilisha na utengeneze upya siri: imeshavuja hata ukiifuta baada ya dakika moja (clones, forks, akiba). Kisha ondoa faili kwenye ufuatiliaji, liweke kwenye .gitignore, na ikibidi safisha historia kwa zana kama git filter-repo, ukifuatiwa na force push na onyo kwa timu.

Mhojiwa hapa anaangalia vipaumbele: mgombea anayeanza kwa kuandika upya historia na kusahau kubadilisha ufunguo, anajibu vibaya.

Jinsi ya kujiandaa kwa maswali ya Git

Njia inayoaminika zaidi ni kutokukariri majibu, bali kupitia kila hali kwa mikono kwenye hifadhi ya majaribio: kuunda conflict na kuisuluhisha, kufanya reset --hard kisha kurejesha kwa reflog, kubana commits kwa rebase shirikishi. Kwenye mahojiano ya Git mara nyingi hutolewa kazi ya vitendo au kuombwa kuchora grafu ya commits kabla na baada ya amri — ukiwa umeshazifanya mwenyewe, jibu linachorwa kwa urahisi.

Pia ni vizuri kujaribu jaribio fupi la Git kwa kujipima: jaribu kujibu bila msaada nini kitatokea kwenye historia baada ya git rebase main au git revert HEAD. Ukijibu kwa uhakika swali la «nini kinabadilika kwenye maeneo matatu», msingi wako ni thabiti.

Muhtasari

Mahojiano ya Git karibu kila mara yanagusa mada tatu: muundo wa data (commits, matawi, HEAD, index), kuunganisha mabadiliko (merge, rebase, conflicts, fetch na pull), na kughairi kwa usalama (reset, revert, reflog). Ongeza uelewa wa mtiririko wa kazi wa timu na pull request — utakuwa umefunika sehemu kubwa ya maswali. Hali hizi zote, ikiwemo kazi ya timu na zana za juu, zinafanyiwa mazoezi ya vitendo katika kozi ya Git.