Top 40 de întrebări și răspunsuri la interviu GIT în 2021

top 40 git interview questions

Cele mai populare întrebări de interviu GIT cu răspunsuri și exemple:

Acest tutorial informativ include un set de întrebări cel mai probabil puse în interviurile Git împreună cu răspunsurile lor descriptive. Aceste întrebări vă vor ajuta cu siguranță să vă pregătiți și să spargeți cu succes orice interviu Git.

Indiferent dacă sunteți un novice sau un profesionist cu experiență, aceste întrebări de interviu pe Git și răspunsuri detaliate vă vor ajuta cu siguranță să vă îmbogățiți cunoștințele despre subiect și să excelați la munca dvs., precum și la interviuri.

Să începem!!

Cele mai frecvente întrebări de interviu GIT

Mai jos sunt enumerate câteva dintre întrebările frecvente ale interviului GIT pentru referință.

Q # 1) Ce este Git?

Răspuns: Git este un instrument de control al versiunii distribuite. Este compatibil cu fluxurile de lucru neliniare distribuite, deoarece oferă asigurarea datelor pentru crearea de software de bună calitate.

Git este gratuit și open-source. Poate fi folosit pentru aproape orice tip de proiect, fie el de dimensiuni mici sau mari. Git este cunoscut pentru marea sa viteză și eficiență. Depozitele Git sunt foarte ușor de găsit și accesat. Datorită anumitor caracteristici, Git este extrem de flexibil, sigur și compatibil cu sistemul dvs.

Q # 2) Ce este un sistem de control al versiunilor distribuit?

Răspuns: Un VCS distribuit este un sistem care nu depinde de un server central pentru a păstra un fișier de proiect și toate versiunile sale. În VCS distribuit, fiecare colaborator sau dezvoltator primește o copie locală a depozitului principal și aceasta se numește clonă.

clonați hard disk-ul la software-ul ssd

(imagine sursă )

După cum puteți vedea în diagrama de mai sus, fiecare colaborator menține un depozit local pe mașinile lor locale. Aceștia pot comite și actualiza depozitele locale fără probleme.

Folosind o operație de extragere, un dezvoltator își poate actualiza depozitul local cu cele mai recente modificări de pe serverul central. Folosind operațiunea push, aceștia își pot trimite modificările din depozitul local către serverul central.

Q # 3) Cine a creat Git?

Răspuns: Git a fost creat de Linus Torvalds în 2005 pe drumul dezvoltării Linux Kernel.

Q # 4) Ce limbă este utilizată în Git?

Răspuns: C este limbajul de programare subiacent în care este scris Git. Limbajul C face Git rapid evitând cheltuielile de execuție legate de alte limbaje de programare la nivel înalt.

Q # 5) Care sunt avantajele / caracteristicile principale ale Git?

Răspuns: Înscrise mai jos sunt diferitele f mâncărurile lui Git.

(i) Sursă gratuită și deschisă:

Git este emis sub licența open source GPL (General Public License). Nu trebuie să plătiți nimic pentru a utiliza Git.

Este absolut gratuit. Deoarece este open-source, puteți modifica codul sursă în funcție de nevoile dvs.

(ii) Viteza:

Deoarece nu vi se cere să vă conectați la nicio rețea pentru executarea tuturor acțiunilor, aceasta efectuează toate sarcinile rapid. Obținerea istoricului versiunilor dintr-un depozit stocat local poate fi de o sută de ori mai rapidă decât obținerea acestuia de pe serverul de la distanță.

Git este scris în C, care este limbajul de programare care evită cheltuielile de rulare legate de alte limbaje de nivel înalt.

(iii) Scalabil:

Git este foarte scalabil. Deci, dacă numărul colaboratorilor crește în timpul următor, atunci Git poate adapta cu ușurință această modificare.

În ciuda faptului că Git reprezintă un întreg depozit, datele păstrate de partea clientului sunt foarte mici, deoarece Git compactează datele vaste într-o tehnică de compresie fără pierderi.

(iv) Fiabile:

Deoarece fiecare colaborator are propriul depozit local, în caz de blocare a sistemului, datele pierdute pot fi recuperate din oricare dintre depozitele locale. În orice moment, veți avea o copie de rezervă a tuturor fișierelor dvs.

(v) Sigur:

Git utilizează SHA1 (Secure Hash Function) pentru a denumi și identifica obiectele din depozitul său. Fiecare artefact și comitere sunt însumate și recuperate prin suma sa de verificare în timpul plății.

Istoricul Git este salvat într-un mod în care ID-ul unei versiuni specifice (un commit în termeni de Git) se bazează pe istoricul de dezvoltare total care rulează până la acel commit. Odată ce o versiune de fișier este împinsă pe Git, atunci nu există nicio modalitate de a o modifica fără a fi observat.

(vi) Economice:

În cazul unui sistem de control al versiunilor centralizat, serverul central trebuie să fie suficient de puternic pentru a participa la cererile întregii echipe. Aceasta nu este o problemă pentru echipele mai mici, cu toate acestea, pe măsură ce echipa se extinde, limitările hardware ale serverului pot fi un impediment pentru performanță.

În cazul sistemelor de control al versiunii distribuite, cum ar fi Git, membrii echipei nu necesită interacțiune cu serverul, așteaptă când sunt obligați să împingă sau să treacă modificările. Toate ridicările grele au loc la capătul clientului, astfel hardware-ul serverului poate fi păstrat cu siguranță destul de simplu.

(vii) Sprijină dezvoltarea neliniară:

Git oferă ramificare și fuzionare rapidă și conține instrumente speciale pentru a prevedea și parcurge o istorie de dezvoltare neliniară. O noțiune de bază în Git este că o modificare va fi combinată mai frecvent decât este scrisă, deoarece este trimisă către diferiți recenzori.

Ramurile Git sunt extrem de ușoare. O sucursală din Git se referă doar la o singură confirmare. Structura completă a ramurilor poate fi creată, cu ajutorul comitetelor părinte.

(viii) Ramificare ușoară:

Gestionarea sucursalelor prin Git este foarte simplă și simplă. Este nevoie de doar câteva repezici pentru a crea, șterge și îmbina ramuri. Ramurile de funcții oferă un mediu izolat fiecărei modificări a bazei de cod.

Atunci când un dezvoltator cere să înceapă să lucreze la ceva, indiferent de dimensiunea muncii, creează o nouă ramură. Acest lucru asigură faptul că filiala principală deține în mod constant un cod de calitate a producției.

(ix) Dezvoltare distribuită:

Git oferă fiecărui dezvoltator o copie locală a întregului istoric al dezvoltării, plus modificările sunt clonate de la un astfel de depozit la altul. Aceste modificări sunt introduse ca ramuri de dezvoltare adăugate și pot fi combinate în același mod ca o ramură dezvoltată local.

(x) Compatibilitate împreună cu sistemele sau protocolul actual:

Depozitele pot fi publicate prin HTTP, FTP sau un protocol Git deasupra unui socket simplu sau ssh.

Q # 6) Cum creați un depozit în Git?

Răspuns: Pentru a crea un depozit, trebuie să creați un director pentru proiect dacă acesta nu există deja și apoi pur și simplu executați comanda „ git init ”. Prin executarea acestei comenzi, un director .git va fi creat în directorul de proiect, adică acum directorul dvs. de proiect s-a transformat într-un depozit Git.

Q # 7) Ce este un director .git?

Răspuns: În momentul în care creați un depozit, veți găsi un director .git prezent în interiorul acestuia. Acest director .git conține toate metadatele depozitului și menține o evidență a tuturor modificărilor aduse fișierelor din depozitul dvs., păstrând un istoric de confirmare.

Toate informațiile referitoare la confirmări, cârlige, referințe, baze de date de obiecte, adrese de depozitare la distanță etc. sunt păstrate în acest folder. Aceasta este cea mai importantă parte a Git. Când clonați orice depozit Git pe mașina dvs. locală, acest .git este directorul care de fapt este copiat.

Q # 8) Ce se întâmplă dacă directorul .git este șters?

Răspuns: Dacă directorul .git / este șters, atunci veți pierde istoricul proiectului dvs. Depozitul nu va mai fi sub controlul versiunii.

Q # 9) Ce comandă este utilizată pentru scrierea unui mesaj de confirmare în Git?

Răspuns: Comanda folosită pentru a transmite un mesaj unui git commit este git commit -m „mesaj de comitere”. Steagul m este folosit pentru a transmite un mesaj de confirmare.

Q # 10) Ce este depozitul Git gol? Cum este diferit de un depozit Git standard / non-bare?

Răspuns: Depozite care sunt create prin git init comanda sunt depozitele Git standard / non-bare.

În dosarul de nivel superior al unui astfel de depozit, veți găsi două lucruri:

1. Un subdirector .git care păstrează toate metadatele și urmărirea istoricului repo.
2. Un copac de lucru.

Depozitele care sunt create folosind git init –bare comanda sunt cunoscute sub numele de depozite Git goale. Acestea sunt utilizate în principal pentru partajare. Nu conțin niciun copac de lucru. Acestea păstrează istoricul reviziilor git al depozitului dvs. în folderul rădăcină, mai degrabă decât să îl aibă în subfolderul .git.

Conține doar date goale din depozit. Acesta este modul în care un depozit Git gol este diferit de un depozit Git standard. De asemenea, un depozit gol nu are o telecomandă implicită origine depozit, deoarece servește ca depozit de origine pentru mai mulți utilizatori la distanță.

Deoarece un depozit simplu nu conține niciun spațiu de lucru, git push și git pull comenzile nu funcționează pe un repo gol. Nu vi se cere să comiteți nicio modificare a unei repo-uri goale.

Q # 11) Menționați câteva servicii de găzduire a depozitelor Git.

Răspuns:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Platforma de lansare
• Forțează
• Beanstalk
• Arată ca

Q # 12) Denumiți câteva operațiuni de bază în Git.

Răspuns: Câteva operațiuni de bază din Git includ:

• Inițializați
• Adăuga
• Angajează-te
• Apăsați
• Trage

Q # 13) Denumiți câteva operații avansate în Git.

Răspuns: Unele operațiuni avansate în Git sunt:

• Ramificare
• Fuziune
• Rebasing

Q # 14) Cum veți face distincția între Git și SVN?

Răspuns: Git este un control al versiunii distribuite, în timp ce SVN este centralizat. Acest lucru duce la multe diferențe între cele două în ceea ce privește caracteristicile și funcționalitățile lor.

Q # 15) Cum veți face diferența între Git și GitHub?

Răspuns: Git este un sistem de control al versiunilor de înaltă calitate. Este distribuit în natură și este utilizat pentru a urmări modificările în codul sursă pe parcursul dezvoltării software-ului. Are un model unic de ramificare care ajută la sincronizarea activității între dezvoltatori și la urmărirea modificărilor din orice fișier.

Obiectivele principale ale Git sunt viteza, integritatea datelor, oferind suport fluxurilor de lucru neliniare distribuite. Git este instalat și întreținut pe mașina locală, în loc de cloud.

GitHub este un serviciu de găzduire a depozitului Git bazat pe cloud, care reunește echipe. Vă oferă o interfață grafică web, precum și controlul accesului și multe funcții de colaborare, instrumente fundamentale de gestionare a sarcinilor pentru fiecare proiect.

De asemenea, GitHub este un open-source, adică codul este păstrat pe un server centralizat și poate fi accesat de toată lumea.

Q # 16) Ce este un conflict în Git și cum să îl rezolvi?

Răspuns: Git are o caracteristică de fuzionare automată care gestionează singur comitetele de fuziune, cu condiția ca modificările de cod să aibă loc pe linii diferite și în fișiere diferite.

Dar, în cazul concurenței pentru comitetele în care există modificări în aceleași linii de cod ale unui fișier sau un fișier a fost șters într-o ramură, dar există și a fost modificat în alta, Git nu poate rezolva automat diferențele și astfel ridică conflictul de fuziune.

În astfel de cazuri, este nevoie de ajutorul dvs. pentru a decide ce cod să includeți și ce cod să renunțați la îmbinarea finală.

Un conflict de fuziune poate apărea în timpul fuzionării unei sucursale, rebasarea unei ramuri sau preluarea unei comisii. Odată detectat un conflict, Git evidențiază zona conflictuală și vă cere să o rezolvați. Odată ce conflictul este rezolvat, puteți continua cu îmbinarea.

Urmați pașii de mai jos pentru a rezolva un conflict concurențial de îmbinare a modificărilor de linie:

1. Deschideți Git Bash (linia de comandă Git).
2. Utilizare CD comanda pentru a merge la depozitul local Git care are conflictul de îmbinare.
3. Folosește statutul git comanda pentru a produce lista de fișiere afectate de conflictul de îmbinare.
4. Deschideți editorul de text pe care îl utilizați și treceți la fișierul care are conflicte de îmbinare.
5. Pentru a vedea începutul conflictului de îmbinare în fișierul dvs., căutați documentul pentru marcatorul de conflict<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> NUME-SUCURSALĂ.
6. Alegeți în cazul în care trebuie să păstrați doar modificările sucursalei, să păstrați modificările celeilalte sucursale sau să efectuați o modificare nouă, care poate include modificări din cele două sucursale. Ștergeți marcatorii de conflict<<<<<<>>>>>> și efectuați modificările de care aveți nevoie în îmbinarea finală.
7. Utilizare adaugă git. comanda pentru a adăuga sau a pune în scenă modificările.
8. În cele din urmă, utilizați git commit -m „mesaj” comanda pentru a comite modificările dvs. cu un comentariu.

Pentru a rezolva conflictul de îmbinare a fișierelor eliminat, trebuie să urmați pașii de mai jos:

1. Deschideți Git Bash (linia de comandă Git).
2. Utilizare CD comanda pentru a merge la depozitul Git local care are conflictul de îmbinare.
3. Folosește statutul git comanda pentru a produce lista de fișiere afectate de conflictul de îmbinare.
4. Deschideți editorul de text pe care îl utilizați și treceți la fișierul care are conflicte de îmbinare.
5. Alegeți dacă doriți să păstrați fișierul eliminat. Puteți verifica cele mai recente modificări efectuate în fișierul eliminat din editorul de text.
6. Utilizare git add comanda pentru a adăuga fișierul eliminat înapoi în depozit. Sau, Utilizați du-te rm comanda pentru a elimina fișierul din depozit.
7. În cele din urmă, utilizați git commit -m „mesaj” comanda pentru a comite modificările dvs. cu un comentariu.

Q # 17) Cum veți remedia o comisie neregulată?

Răspuns: Pentru a remedia un commit defect sau pentru a schimba ultimul commit, cea mai convenabilă metodă este să folosiți comanda „ git commit -amend ’ .

Vă permite să combinați modificările etapizate cu commit-ul anterior ca alternativă pentru crearea unui commit complet nou. Aceasta înlocuiește cea mai recentă validare cu validarea modificată.

(imagine sursă )

Prin această comandă, puteți, de asemenea, să editați mesajul de comitere anterior fără a modifica instantaneul acestuia.

Î # 18) La ce folosește git instaweb?

Răspuns: Este un script prin care puteți răsfoi instantaneu depozitul Git de lucru într-un browser web.

Acest script configurează gitweb și un server web pentru a naviga în depozitul local. Acesta direcționează automat un browser web și rulează un server web printr-o interfață în depozitul dvs. local.

Q # 19) Ce este git is-tree?

Răspuns: „Git is-tree” semnifică un obiect de copac care cuprinde modul și numele tuturor articolelor împreună cu valoarea SHA-1 a blobului sau a arborelui.

Q # 20) Există o modalitate de a reveni la un comitet git care a fost deja împins și făcut public?

Răspuns: Da, pentru a remedia sau reveni la o comitere greșită, există două abordări care pot fi utilizate pe baza scenariului.

Sunt:

1. Modul foarte evident este de a face un commit nou în cazul în care eliminați fișierul greșit sau remediați erorile din acesta. După ce ați terminat, îl puteți împinge către un depozit la distanță.
2. O altă abordare este de a crea un nou commit pentru a anula toate modificările care au fost făcute în commit-ul rău anterior. Acest lucru se poate face prin comanda git revert - „ git revine '

Q # 21) Cum veți face diferența între git pull și git fetch?

Răspuns: Git pull comanda extrage toate validările noi dintr-o ramură specifică din depozitul central și actualizează ramura țintă din depozitul dvs. local.

Git fetch vizează, de asemenea, același lucru, cu toate acestea, funcționalitatea sa de bază este puțin diferită. Când efectuați o preluare de git, toate comenzile noi dintr-o anumită ramură vor fi extrase în depozitul central și aceste modificări vor fi stocate într-o nouă ramură din depozitul dvs. local. Aceasta se numește o ramură preluată.

Dacă doriți să vedeți aceste modificări în ramura țintă, atunci trebuie să efectuați o du-te fuzionează după preluarea gitului. Ramura țintă va fi actualizată cu cele mai recente modificări numai după îmbinarea ei cu ramura preluată.

Deci, o extragere git aduce ramura locală actualizată cu versiunea sa la distanță, în timp ce o preluare git nu schimbă direct propria ramură locală sau copia de lucru în refs / capete. Git fetch poate fi utilizat pentru a actualiza ramurile dvs. de urmărire la distanță refs / telecomenzi //.

Cu cuvinte simple, git pull este egal cu git fetch urmat de un git merge .

ce să folosiți în loc de ccleaner

Q # 22) La ce folosește zona de etapizare sau indexarea în Git?

Răspuns: Din perspectiva lui Git, există trei domenii în care modificările fișierelor pot fi păstrate, adică directorul de lucru, zona intermediară și depozitul.

Mai întâi, efectuați modificări în directorul de lucru al proiectului dvs. stocat în sistemul de fișiere al computerului. Toate modificările rămân aici până când le adăugați la o zonă intermediară numită zonă intermediară.

Puteți pune în scenă modificările executând git add. comanda. Această zonă intermediară vă oferă o previzualizare a următorului dvs. commit și, practic, vă permite să vă ajustați commiturile. Puteți adăuga sau elimina modificări în zona de etapă până când sunteți mulțumit de versiunea pe care urmează să o comiteți.

Odată ce v-ați verificat modificările și v-ați deconectat de la etapa modificată, puteți finaliza modificările. La comitere, ei merg în depozitul local, adică în directorul .git / objects.

Dacă utilizați Git GUI, atunci veți vedea opțiunea de a vă schimba modificările. În captura de ecran de mai jos, fișierul sample.txt se află în zona de modificări neetajate, ceea ce înseamnă că se află în directorul dvs. de lucru.

Puteți selecta un fișier și faceți clic pe „etapa modificată”, apoi acesta va fi mutat în zona intermediară. De exemplu , fișierul hello.txt este prezent în zona modificată (va comite). Puteți verifica modificările dvs. și apoi puteți face o semnare, urmată de un commit.

Stadierea este, de asemenea, denumită indexare, deoarece git menține un fișier index pentru a urmări modificările fișierului dvs. în aceste trei zone. Fișierele care sunt aranjate sunt în prezent în indexul dvs.

Când adăugați modificări în zona de etapă, informațiile din index sunt actualizate. Când efectuați un commit, este de fapt ceea ce este în indexul care este angajat, și nu ceea ce este în directorul de lucru. Puteți utiliza statutul git pentru a vedea ce este în index.

Q # 23) Ce este Git Stash?

Răspuns: GIT stash captează starea actuală a directorului și indexului de lucru și îl păstrează în stivă pentru o utilizare viitoare. Revine modificările neacceptate (atât etapizate, cât și necontenite) din directorul dvs. de lucru și vă returnează un arbore de lucru curat.

Puteți lucra la altceva acum și, când vă întoarceți, puteți aplica din nou aceste modificări. Deci, dacă doriți să treceți de la un context la altul fără a vă pierde modificările actuale, atunci puteți utiliza stashing.

Este util în comutarea rapidă a contextului, în care vă aflați într-o cale intermediară a unei modificări de cod pe care nu doriți să o comiteți sau să o anulați acum și aveți altceva la care să lucrați. Comanda de utilizat este git stash.

Q # 24) Ce este scăderea Git Stash?

Răspuns: Când nu mai aveți nevoie de o memorie specifică, o puteți elimina executând comanda git stash drop . Dacă doriți să eliminați toate stocurile dintr-o singură mișcare din depozit, atunci puteți rula comanda git stash clear .

Q # 25) Ce se aplică Git stash? În ce este diferit de Git stash pop?

Răspuns: Ambele comenzi sunt folosite pentru a aplica din nou modificările ascunse și pentru a începe să lucreze de unde ai plecat.

În git stash se aplică comanda, modificările vor fi aplicate din nou copiei dvs. de lucru și vor fi, de asemenea, păstrate în stoc. Această comandă poate fi utilizată atunci când doriți să aplicați aceleași modificări ascunse la mai multe ramuri.

În git stash pop , modificările sunt eliminate din stoc și sunt aplicate din nou la copia de lucru.

Q # 26) La ce folosește comanda git clone?

Răspuns: git clona comanda creează o copie a depozitului central Git existent în mașina dvs. locală.

Q # 27) Când se utilizează comanda git config?

Răspuns: git config comanda este utilizată pentru a seta opțiunile de configurare pentru instalarea Git.

De exemplu, după ce descărcați Git, trebuie să utilizați mai jos comenzile de configurare pentru a configura numele de utilizator și, respectiv, să adresați adresa de e-mail în Git:

$ git config –global user.name „”

$ git config –utilizator global.email „”

Deci, în principal, lucruri precum comportamentul depozitului, informațiile utilizatorului și preferințele pot fi configurate cu ajutorul acestei comenzi.

Î. 28) Cum veți identifica dacă filiala este deja fuzionată în master?

Răspuns:

Executând comenzile de mai jos, puteți cunoaște starea de îmbinare a ramurilor:

1. git branch - master fuzionat: Aceasta va lista toate ramurile care au fost redenumite în master.
2. ramură git - fuzionată: Aceasta va enumera toate ramurile care au fost îmbinate în HEAD.
3. git branch –no-fuzionată: Aceasta va enumera toate ramurile care nu sunt încă îmbinate.

În mod implicit, această comandă indică starea de îmbinare numai a sucursalelor locale. Dacă doriți să aflați atât starea de îmbinare a ramurilor locale, cât și la distanță, atunci puteți utiliza -la steag. Dacă doriți să verificați numai ramurile la distanță, atunci puteți utiliza -r steag.

Q # 29) Ce sunt Hooks în Git?

Răspuns: Cârligele Git sunt anumite scripturi pe care Git le rulează înainte sau după un eveniment cum ar fi commit, push, actualizare sau primire. Veți găsi folderul „hooks” în directorul .git din depozitul dvs. local. Aici veți găsi scripturile încorporate pre-commit, post-commit, pre-push, post push.

Aceste scripturi sunt executate local înainte sau după apariția unui eveniment. De asemenea, puteți modifica aceste scripturi în funcție de nevoile dvs., iar Git va executa scriptul atunci când apare acel eveniment.

Q # 30) La ce folosește furca git? În ce diferență bifurcarea față de clonare?

Răspuns: A furniza un proiect înseamnă a crea o copie de la distanță, pe server, a depozitului original. Puteți redenumi această copie și puteți începe să faceți un nou proiect în jurul acestuia, fără a afecta proiectul original. Furca nu este conceptul de bază al Git.

Operația furcă este utilizată de fluxul de lucru Git și această idee există mai mult timp pentru software-ul gratuit și open-source, cum ar fi GitHub. În general, după ce ați bifurcat proiectul, rareori veți contribui din nou la proiectul părinte.

De exemplu, OpenBSD este un sistem de operare open-source de tip Unix, dezvoltat prin bifurcarea NetBSD, care este un alt sistem de operare open-source de tip Unix.

Cu toate acestea, în furcă, există o conexiune directă între copia dvs. furcată și depozitul original. În orice moment, puteți contribui înapoi la proiectul original utilizând cererile de extragere.

În copierea bifurcată, toate datele principale, cum ar fi codurile și fișierele, sunt copiate din depozitul original, totuși ramurile, cererile de extragere și alte caracteristici nu sunt copiate. Forkingul este un mod ideal de colaborare open source.

Clonarea este în esență un concept Git. O clonă este o copie locală a oricărui depozit la distanță. Când clonăm un depozit, întregul depozit sursă, împreună cu istoricul și ramurile sale sunt copiate pe mașina noastră locală.

Spre deosebire de forking, nu există o legătură directă între depozitul clonat și depozitul original la distanță. Dacă doriți să faceți cereri de extragere și să continuați înapoi la proiectul original, atunci ar trebui să vă adăugați ca colaborator în depozitul original.

Clonarea este, de asemenea, o modalitate excelentă de a crea o copie de rezervă a depozitului original, deoarece copia clonată are tot istoricul de comitere.

Q # 31) Cum veți afla ce fișiere au fost modificate într-un anumit commit Git?

Răspuns: Utilizând valoarea hash a unui anumit commit, puteți executa comanda de mai jos pentru a obține lista de fișiere care au fost modificate într-un anumit commit:

git diff-tree -r {hash}

Aceasta va lista toate fișierele care au fost modificate, precum și fișierele care au fost adăugate. Steagul -r este utilizat pentru a lista fișierele individuale împreună cu calea lor în loc să le prăbușească numai în numele directorului rădăcină.

De asemenea, puteți utiliza comanda de mai jos:

git diff-tree –no-commit-id –name-only -r {hash}

diferența dintre soapui și soapui pro

–No-commit-id va recalifica numerele hash de validare care vor apărea în rezultat. În timp ce, -name va exclude căile de fișiere și va da doar numele fișierelor în ieșire.

Q # 32) Care este diferența dintre git checkout (numele sucursalei) și git checkout -b (numele sucursalei)?

Răspuns: Comanda git checkout (numele sucursalei) va trece de la o ramură la alta.

Comanda git checkout -b (numele sucursalei) va crea o ramură nouă și va trece la ea.

Q # 33) Ce este SubGit?

Răspuns: SubGit este un instrument utilizat pentru migrarea SVN la Git. Este dezvoltat de o companie numită TMate. Convertește depozitele SVN în Git și vă permite să lucrați simultan pe ambele sisteme. Se sincronizează automat SVN cu Git.

(imagine sursă )

Puteți crea o oglindă SVN || Git folosind acest instrument. SubGit trebuie instalat pe serverul dvs. Git. Acesta va detecta toate setările depozitului dvs. SVN la distanță, inclusiv reviziile SVN, ramurile și etichetele, și le va converti în confirmări Git.

De asemenea, păstrează istoricul, inclusiv urmărirea datelor de îmbinare.

Q # 34) Puteți recupera o sucursală ștearsă în Git?

Răspuns: Da, poti. Pentru a recupera o ramură ștearsă, ar trebui să știți SHA din partea de sus a capului. SHA sau hash este un ID unic pe care Git îl creează cu fiecare operație.

Când ștergeți o ramură, afișați SHA pe terminal:

Sucursala ștearsă (a fost)

Puteți utiliza comanda de mai jos pentru a recupera ramura ștearsă:

git checkout -b

Dacă nu cunoașteți SHA pentru commit la vârful sucursalei, puteți utiliza mai întâi du-te reflog pentru a cunoaște valoarea SHA și apoi aplicați comanda de checkout de mai sus pentru a vă restabili sucursala.

Q # 35) Ce este git diff comanda? În ce este diferit de statutul git?

Răspuns: Git diff este o comandă cu mai multe utilizări care poate fi executată pentru a arăta diferențele dintre două confirmări arbitrare, modificări între arborele de lucru și un commit, modificări între arborele de lucru și un index, modificări între două fișiere, modificări între index și un arbore etc.

statutul git comanda este utilizată pentru a inspecta un depozit. Afișează starea directorului de lucru și a zonei intermediare. Se va afișa fișierele care au fost puse în scenă, care nu au fost puse în scenă și fișierele care nu au fost urmărite.

Q # 36) Ce conține un obiect Commit?

Răspuns: Obiectul de confirmare conține hash-ul de arbore de nivel superior, părintele confirmă hash (dacă există), informații despre autor și comitter, data de confirmare și mesajul de confirmare.

Puteți vizualiza acest lucru prin git log comanda.

Exemplu:

(imagine sursă )

Q # 37) Ce este git cherry-pick? Care sunt scenariile în care git cherry-pick poate fi folosit?

Răspuns: Git cherry-pick este o comandă puternică pentru a aplica modificările introduse de una sau mai multe confirmări existente. Vă permite să alegeți un commit dintr-o sucursală și să o aplicați la alta.

git cherry-pick commitSha este comanda folosită pentru culegerea cireșelor. commitSha este referința commit.

Această comandă poate fi utilizată pentru anularea modificărilor. De exemplu, dacă din greșeală ați făcut un commit către o ramură greșită, atunci puteți verifica ramura corectă și puteți alege comitetul unde ar trebui să aparțină.

Poate fi folosit și în colaborarea în echipă. Pot exista scenarii în care același cod trebuie împărțit între două componente ale produsului. În acest caz, dacă un dezvoltator a scris deja acel cod, atunci celălalt poate alege același lucru.

Cireșul este, de asemenea, util în remedierile rapide ale erorilor, unde o comitere de patch-uri poate fi culesă direct în ramura principală pentru a remedia problema cât mai curând posibil.

Î # 38) Pentru ce se folosește „resetarea git”? Care este modul implicit al acestei comenzi?

Răspuns: Resetare Git este o comandă puternică pentru anularea modificărilor locale la starea unui repo Git. Această comandă resetează HEAD-ul curent la stadiul specificat.

Resetează atât indexul, cât și directorul de lucru la starea ultimului dvs. commit. Resetarea Git are trei moduri, adică soft, hard și mixt. Modul de operare implicit este mixt.

Q # 39) Care este diferența dintre „CAP”, „copac de lucru” și „index”?

Răspuns: Arborele de lucru sau spațiul de lucru este directorul care conține fișierele sursă la care lucrați în prezent.

Indexul este zona de etapă din Git unde sunt pregătite comitetele. Se află între comitere și arborele tău de lucru. Git index este un fișier binar mare care înregistrează toate fișierele din ramura curentă, numele lor, sumele de verificare sha1 și marcajele de timp.

Acest fișier este prezent la /.git/index. HEAD este referința sau indicatorul către cea mai recentă confirmare din ramura de checkout curentă.

Q # 40) Care este diferența dintre rebase și fusion? Când ar trebui să refaceți și când ar trebui să fuzionați?

Răspuns: Ambele comenzi rebase și fusion sunt utilizate pentru a integra modificările de la o ramură la alta, dar într-un mod diferit.

După cum se vede în cele două imagini de mai jos, să presupunem că aveți confirmări (aceasta este înainte de îmbinare / rebase). După îmbinare, veți obține rezultatul ca o combinație de confirmări. Acesta leagă istoricul ambelor ramuri și creează o nouă „îmbinare de îmbinare” în ramura caracteristică.

Pe de altă parte, rebase va muta întreaga ramură de caracteristici pentru a începe de la vârful ramurii principale.

(imagine sursă )

Comitetele vor arăta astfel:

Rebasing nu este recomandat pentru sucursalele publice, deoarece creează depozite inconsistente. Cu toate acestea, rebasing este o opțiune bună pentru sucursale private / dezvoltatori individuali. Nu este foarte potrivit pentru modul ramură pe caracteristică. Dar dacă aveți un model de sucursală per dezvoltator, atunci refacerea nu este deloc dăunătoare.

De asemenea, rebase-ul este o operațiune distructivă, astfel încât echipa dvs. de dezvoltare ar trebui să fie suficient de pricepută pentru ao aplica corect. În caz contrar, munca angajată poate fi pierdută.

Mai mult, revenirea unei îmbinări este mai ușoară decât revenirea la o rebase. Deci, dacă știți că pot exista posibilități de revenire necesare, atunci ar trebui să utilizați îmbinarea.

Merge perseverează istoria așa cum este, în timp ce rebase rescrie istoria. Astfel, dacă doriți să vedeți istoricul complet așa cum a avut loc, atunci ar trebui să utilizați merge.

Q # 41) Care este sintaxa pentru rebasing?

Răspuns: Sintaxa pentru comanda rebase este git rebase (new-commit)

Q # 42) Cum veți elimina un fișier din Git fără a-l elimina efectiv din sistemul de fișiere local?

Răspuns: Puteți utiliza opțiunea „cache” pentru aceasta:

git rm -rf –cache $ FILES

Această comandă va elimina fișierele din depozitul dvs. fără a le șterge de pe disc.

Q # 43) Care este modelul comun de ramificare în Git?

Răspuns: Modelul comun de ramificare se bazează pe fluxul git. Are două ramuri principale, adică master și dezvoltare.

• Ramura principală conține codul de producție. Tot codul de dezvoltare este fuzionat în ramura master la un moment dat.
• Ramura de dezvoltare conține codul de pre-producție. Când funcțiile sunt finalizate, acestea sunt îmbinate cu ramura principală, în general printr-o conductă CI / CD.

Acest model are, de asemenea, câteva ramuri de sprijin care sunt utilizate în timpul ciclului de dezvoltare:

• Sucursale de caracteristici / Sucursale de subiecte: Acestea sunt folosite pentru a dezvolta noi caracteristici pentru lansările viitoare. Se poate ramifica din ramura de dezvoltare și trebuie să fie îmbinată înapoi în ramura de dezvoltare. În general, aceste ramuri există doar în depozitele de dezvoltatori și nu în origine.
• Ramuri de remediere rapidă: Acestea sunt utilizate pentru lansarea neplanificată a producției atunci când este nevoie să remediați imediat orice eroare critică în versiunea live prod. Acestea se pot despărți de master și trebuie să fie reunite în dezvoltare și master.
• Sucursale de lansare: Acestea sunt utilizate pentru pregătirea noii versiuni de producție. Ramura de lansare vă permite să remediați erori minore și să pregătiți metadatele pentru lansare. Acestea se pot desprinde de la dezvoltare și trebuie reunite în master și se dezvoltă.

Concluzie

Am parcurs întrebările importante care sunt adresate în general în timpul interviurilor Git din acest tutorial.

Acest lucru nu numai că vă va ajuta să vă pregătiți pentru interviurile viitoare, dar vă va clarifica și conceptele git.

Toate cele bune pentru interviu!

Lectură recomandată

• Întrebări și răspunsuri la interviu
• Câteva întrebări interesante despre testarea software-ului
• Top 40 C Întrebări și răspunsuri la interviu de programare
• Top 40 de întrebări și răspunsuri populare despre interviurile J2EE pe care ar trebui să le citiți
• Întrebări și răspunsuri la interviuri de testare ETL
• 20+ Cele mai frecvente întrebări de ieșire și răspunsuri la interviu
• Întrebări de interviuri despre formularele și rapoartele Oracle de top
• Câteva întrebări și răspunsuri dificile de testare manuală