Top 40 de les preguntes i respostes de l’entrevista GIT el 2021

top 40 git interview questions

Preguntes d'entrevistes GIT més populars amb respostes i exemples:

Aquest tutorial informatiu inclou un conjunt de preguntes més probables a les entrevistes de Git juntament amb les seves respostes descriptives. Aquestes preguntes sens dubte us ajudaran a preparar-vos amb èxit per a qualsevol entrevista de Git.

Tant si sou un principiant o un professional experimentat, aquestes preguntes d’entrevistes a Git i respostes detallades us ajudaran a enriquir els vostres coneixements sobre el tema i excel·lir en el vostre treball i en les entrevistes.

Comencem!!

Preguntes més freqüents sobre l'entrevista GIT

A continuació, es detallen algunes de les preguntes més freqüents de l’entrevista GIT com a referència.

P # 1) Què és Git?

Resposta: Git és una eina de control de versions distribuïdes. És compatible amb fluxos de treball no lineals distribuïts, ja que ofereix garantia de dades per crear programari de bona qualitat.

Git és gratuït i de codi obert. Es pot utilitzar per a gairebé qualsevol tipus de projecte, ja sigui de mida petita o gran. Git és conegut per la seva gran velocitat i eficiència. Els dipòsits Git són molt fàcils de trobar i accedir. A causa de certes funcions, Git és altament flexible, segur i compatible amb el vostre sistema.

P # 2) Què és un sistema de control de versions distribuït?

Resposta: Un VCS distribuït és un sistema que no depèn d’un servidor central per conservar un fitxer de projecte i totes les seves versions. En VCS distribuït, cada col·laborador o desenvolupador obté una còpia local del dipòsit principal i això s’anomena clon.

(imatge font )

Com podeu veure al diagrama anterior, cada col·laborador manté un dipòsit local a les seves màquines locals. Poden confirmar i actualitzar els dipòsits locals sense cap problema.

Mitjançant una operació d’extracció, un desenvolupador pot actualitzar el seu dipòsit local amb els darrers canvis del servidor central. Mitjançant l’operació push, poden enviar els canvis des del dipòsit local al servidor central.

P # 3) Qui va crear Git?

Resposta: Git va ser creat per Linus Torvalds el 2005 durant el desenvolupament del Linux Kernel.

Q # 4) Quin idioma s'utilitza a Git?

Resposta: C és el llenguatge de programació subjacent en què s’escriu Git. El llenguatge C fa que Git sigui ràpid evitant les despeses generals d’execució relacionades amb altres llenguatges de programació d’alt nivell.

Q # 5) Quins són els avantatges / característiques principals de Git?

Resposta: A continuació es detallen els diversos f restaurants de Git.

(i) Lliure i de codi obert:

Git s’emet sota la llicència de codi obert GPL (General Public License). No heu de pagar res per utilitzar Git.

És absolutament gratuït. Com que és de codi obert, podeu modificar el codi font segons les vostres necessitats.

(ii) Velocitat:

Com que no cal que us connecteu a cap xarxa per executar totes les accions, realitza totes les tasques ràpidament. L'obtenció de l'historial de versions des d'un dipòsit emmagatzemat localment pot ser cent vegades més ràpid que l'obtenció del servidor remot.

Git s’escriu en C, que és el llenguatge de programació subjacent que eludeix les despeses generals de temps d’execució vinculades amb altres llenguatges d’alt nivell.

(iii) Escalable:

Git és altament escalable. Per tant, si el nombre de col·laboradors augmenta en els propers temps, Git pot adaptar-se fàcilment a aquest canvi.

Tot i que Git representa un repositori complet, les dades que es mantenen al costat del client són molt reduïdes, ja que Git compacta tota la gran quantitat de dades mitjançant una tècnica de compressió sense pèrdues.

(iv) Fiable:

Com que cada col·laborador té el seu propi repositori local, en cas d'error del sistema, les dades perdudes es poden recuperar de qualsevol dels repositoris locals. En tot moment, tindreu una còpia de seguretat de tots els vostres fitxers.

(v) Segur:

Git utilitza SHA1 (Secure Hash Function) per nomenar i identificar objectes dins del seu dipòsit. Cada artefacte i confirmació es suma i es recupera mitjançant la seva suma de comprovació durant el pagament.

L'historial de Git es desa de manera que l'identificador d'una versió específica (un commit en termes de Git) es basa en l'historial de desenvolupament total que s'executa fins a aquest commit. Una vegada que s’envia una versió de fitxer a Git, no hi ha manera de canviar-la sense que se n’adonin.

(vi) Econòmic:

En el cas d’un sistema de control de versions centralitzat, el servidor central ha de ser prou fort per atendre les peticions de tot l’equip. Això no és un problema per als equips més petits, però, a mesura que l’equip s’expandeix, les limitacions de maquinari del servidor poden ser un impediment per al rendiment.

En el cas de sistemes de control de versions distribuïdes com Git, els membres de l’equip no requereixen interacció amb el servidor quan se’ls requereixi que s’introdueixin els canvis. Tota la càrrega pesada es produeix a l'extrem del client, de manera que el maquinari del servidor es pot mantenir bastant senzill.

(vii) Admet el desenvolupament no lineal:

Git proporciona ramificació i fusió ràpides i conté eines específiques per contemplar i recórrer un historial de desenvolupament no lineal. Una noció bàsica a Git és que un canvi es combinarà amb més freqüència del que s’escriu, ja que s’envia a diferents revisors.

Les branques Git són extremadament lleugeres. Una sucursal a Git fa referència només a una única confirmació. Es pot crear l’estructura de sucursal completa, amb l’ajut dels compromisos principals.

(viii) Ramificació fàcil:

La gestió d'oficines a través de Git és molt senzilla i senzilla. Només calen uns pocs cops per crear, suprimir i combinar branques. Les branques de funcions proporcionen un entorn aïllat a cada canvi de la vostra base de codis.

Quan un desenvolupador necessita començar a treballar en alguna cosa, independentment de la mida del treball, creen una nova branca. Això assegura que la branca mestra tingui constantment un codi de qualitat de producció.

(ix) Desenvolupament distribuït:

Git proporciona a tots els desenvolupadors una còpia local de tot l'historial de desenvolupament, a més dels canvis es clonen d'un repositori d'aquest tipus a un altre. Aquests canvis s’introdueixen com a branques de desenvolupament afegides i es poden combinar de la mateixa manera que una branca desenvolupada localment.

(x) Compatibilitat juntament amb els sistemes o protocols actuals:

Els dipòsits es poden publicar a través d’un protocol HTTP, FTP o Git a sobre d’un socket normal o ssh.

Q # 6) Com es crea un dipòsit a Git?

Resposta: Per crear un dipòsit, heu de crear un directori per al projecte si encara no existeix i, simplement, executeu l'ordre ' git init ”. En executar aquesta ordre, es crearà un directori .git dins del directori del projecte, és a dir, ara el directori del projecte s’ha convertit en un dipòsit Git.

P # 7) Què és un directori .git?

Resposta: En el moment que creeu un dipòsit, hi trobareu un directori .git. Aquest directori .git conté totes les metadades del dipòsit i manté un seguiment de tots els canvis fets als fitxers del vostre dipòsit, mantenint un historial de confirmacions.

Dins d’aquesta carpeta es guarda tota la informació relativa a les confirmacions, enganxaments, referències, bases de dades d’objectes, adreces de dipòsit remot, etc. Aquesta és la part més crucial de Git. Quan cloneu qualsevol dipòsit Git a la vostra màquina local, aquest .git és el directori que realment es copia.

Q # 8) Què passa si se suprimeix el directori .git?

Resposta: Si el directori .git / s’elimina, perdrà l’historial del projecte. El dipòsit ja no estarà sota control de versions.

P # 9) Quina ordre s'utilitza per escriure un missatge de confirmació a Git?

Resposta: L'ordre que s'utilitza per passar un missatge a un git commit és git commit -m 'missatge de confirmació'. La bandera m s'utilitza per passar un missatge de confirmació.

Q # 10) Què és el repositori Git? En què es diferencia d'un dipòsit Git estàndard / no nu?

Resposta: Dipòsits que es creen mitjançant git init són els dipòsits Git estàndard / no nus.

A la carpeta de nivell superior d’aquest dipòsit, trobareu dues coses:

1. Un subdirectori .git que guarda totes les metadades i el seguiment de la història de la vostra reposició.
2. Un arbre de treball.

Els dipòsits que es creen mitjançant git init –bare Els comandaments es coneixen com a repositoris Git nus. S’utilitzen principalment per compartir. No contenen cap arbre de treball. Mantenen l'historial de revisions git del vostre dipòsit a la carpeta arrel en lloc de tenir-lo dins de la subcarpeta .git.

Només conté dades de dipòsit nu. Així és com un dipòsit Git nu és diferent d’un dipòsit Git estàndard. A més, un dipòsit nu no té un control remot per defecte origen repositori, ja que serveix com a repositori d’origen per a diversos usuaris remots.

Com que un dipòsit nu no conté cap espai de treball, el fitxer git push i git pull les ordres no funcionen amb un repo nu. No està obligat a fer cap canvi en una reposició nua.

Q # 11) Esmenteu alguns serveis d'allotjament de dipòsits Git.

Resposta:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Plataforma de llançament
• Perforça
• mongetera
• Assembla

Q # 12) Anomeneu algunes operacions bàsiques a Git.

Resposta: Algunes operacions bàsiques a Git inclouen:

• Inicialitzar
• Afegeix
• Compromís
• Premeu
• Estirar

Q # 13) Anomeneu algunes operacions avançades a Git.

Resposta: Algunes operacions avançades a Git són:

• Ramificació
• Fusió
• Repassant

Q # 14) Com distingireu entre Git i SVN?

Resposta: Git és un control de versions distribuïdes mentre que SVN està centralitzat. Això condueix a moltes diferències entre les dues quant a les seves característiques i funcionalitats.

P # 15) Com diferencieu Git i GitHub?

Resposta: Git és un sistema de control de versions d'alta qualitat. Es distribueix per naturalesa i s’utilitza per fer un seguiment dels canvis en el codi font al llarg del desenvolupament de programari. Té un model de ramificació únic que ajuda a la sincronització del treball entre desenvolupadors i al seguiment dels canvis en qualsevol fitxer.

Els objectius principals de Git són la rapidesa, la integritat de les dades, proporcionar suport a fluxos de treball no lineals distribuïts. Git s'instal·la i es manté a la màquina local, en lloc del núvol.

GitHub és un servei d’allotjament de dipòsit Git basat en el núvol que reuneix equips. Us proporciona una interfície gràfica d’usuari basada en web, a més de proporcionar control d’accés i moltes funcions de col·laboració, eines fonamentals de gestió de tasques per a cada projecte.

A més, GitHub és un codi obert, és a dir, el codi es manté en un servidor centralitzat i tothom pot accedir-hi.

P # 16) Què és un conflicte a Git i com es pot resoldre?

Resposta: Git té una funció de combinació automàtica que gestiona les comissions de combinació per si sola, sempre que els canvis de codi s'hagin produït en línies i fitxers diferents.

Però, en cas de competir per a confirmacions en què hi ha canvis a les mateixes línies de codi d’un fitxer o s’ha suprimit un fitxer en una branca però existeix i s’ha modificat en una altra, Git no pot resoldre automàticament les diferències i, per tant, planteja el conflicte de combinació.

En aquests casos, necessiteu la vostra ajuda per decidir quin codi voleu incloure i quin codi descartar a la combinació final.

Es pot produir un conflicte de fusió durant la fusió d'una sucursal, la modificació de la sucursal o la realització d'una confirmació. Un cop detectat un conflicte, Git ressalta l'àrea en conflicte i us demana que ho resolgueu. Un cop resolt el conflicte, podeu continuar amb la combinació.

Seguiu els passos següents per resoldre un conflicte de combinació de canvis de línia competidors:

1. Obriu Git Bash (línia d’ordres de Git).
2. Ús cd ordre per anar al dipòsit local de Git que té el conflicte de combinació.
3. Utilitzar el estat git per produir la llista de fitxers afectats pel conflicte de combinació.
4. Obriu l’editor de text que utilitzeu i aneu al fitxer que té conflictes de combinació.
5. Per veure l'inici del conflicte de combinació al fitxer, busqueu el document per trobar el marcador de conflicte<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> NOM DE LA RAMA.
6. Trieu en cas que hàgiu de conservar només els canvis de la vostra sucursal, simplement mantenir els canvis de l’altra sucursal o fer un canvi nou, que pot incloure canvis de les dues sucursals. Esborreu els marcadors de conflicte<<<<<<>>>>>> i feu els canvis que necessiteu a la combinació final.
7. Ús git afegeix. per afegir o escenificar els vostres canvis.
8. Finalment, utilitzeu el fitxer git commit -m 'missatge' ordre per confirmar els canvis amb un comentari.

Per resoldre el conflicte de combinació de fitxers eliminat, heu de seguir els passos següents:

1. Obriu Git Bash (línia d’ordres de Git).
2. Ús cd ordre per anar al dipòsit local de Git que té el conflicte de combinació.
3. Utilitzar el estat git per produir la llista de fitxers afectats pel conflicte de combinació.
4. Obriu l’editor de text que utilitzeu i aneu al fitxer que té conflictes de combinació.
5. Trieu si voleu conservar el fitxer eliminat. Podeu comprovar els darrers canvis fets al fitxer eliminat a l’editor de text.
6. Ús git add per afegir el fitxer eliminat al dipòsit. O bé, Utilitza vaja rm per eliminar el fitxer del dipòsit.
7. Finalment, utilitzeu el fitxer git commit -m 'missatge' ordre per confirmar els canvis amb un comentari.

P # 17) Com arreglareu un compromís trencat?

Resposta: Per corregir una confirmació fallida o canviar l'última confirmació, el mètode més convenient és utilitzar l'ordre ' git commit -amend ’ .

Permet combinar els canvis en fases amb el commit anterior com a alternativa per crear un commit completament nou. Això substitueix la confirmació més recent per la confirmació modificada.

(imatge font )

Mitjançant aquesta ordre, també podeu editar el missatge de confirmació anterior sense canviar-ne la instantània.

P # 18) Quin ús té git instaweb?

Resposta: És un script mitjançant el qual podeu navegar instantàniament pel vostre dipòsit Git que funciona en un navegador web.

Aquest script configura gitweb i un servidor web per navegar pel dipòsit local. Dirigeix ​​automàticament un navegador web i executa un servidor web a través d’una interfície al vostre dipòsit local.

P # 19) Què és git is-tree?

Resposta: 'Git is-tree' significa un objecte d'arbre que comprèn el mode i el nom de tots els elements juntament amb el valor SHA-1 del blob o l'arbre.

Q # 20) Hi ha alguna manera de revertir un compromís git que ja s'hagi impulsat i fet públic?

amb què obrir fitxers swf

Resposta: Sí, per corregir o revertir un error de lliurament, hi ha dos enfocaments que es poden utilitzar en funció de l'escenari.

Ells són:

1. La manera molt òbvia és fer una nova confirmació en què elimineu el fitxer incorrecte o solucioneu els errors que hi apareixen. Un cop fet, podeu enviar-lo a un dipòsit remot.
2. Un altre enfocament és crear una nova confirmació per desfer tots els canvis que es van fer a la confirmació incorrecta anterior. Això es pot fer mitjançant l'ordre git revert - ' git revert '

Q # 21) Com diferencieu entre git pull i git fetch?

Resposta: Git pull L'ordre extreu totes les confirmacions noves d'una branca específica del dipòsit central i fa que la branca de destinació del vostre dipòsit local estigui actualitzada.

Git fetch també apunta al mateix, però la seva funcionalitat subjacent és una mica diferent. Quan feu una recuperació de git, totes les confirmacions noves d'una branca específica s'extreuran al vostre dipòsit central i aquests canvis s'emmagatzemaran en una branca nova del vostre repositori local. Això s’anomena branca recuperada.

Si voleu veure aquests canvis a la vostra branca de destinació, haureu de realitzar un vés a fusionar després de buscar git. La branca de destinació s'actualitzarà amb els darrers canvis només després de combinar-la amb la branca obtinguda.

Per tant, un git pull fa que la branca local estigui actualitzada amb la seva versió remota, mentre que una recuperació de git no canvia directament la vostra pròpia branca local o còpia de treball a refs / caps. Es pot utilitzar Git fetch per actualitzar les branques de seguiment remot que hi ha a sota referències / comandaments a distància //.

En paraules simples, git pull és igual a git fetch seguit d’una combinació de git .

P # 22) Quin ús fa de la zona d’intercanvi o de la indexació a Git?

Resposta: Des de la perspectiva de Git, hi ha tres àrees on es poden mantenir els canvis de fitxers, és a dir, directori de treball, àrea de prova i repositori.

En primer lloc, feu canvis al directori de treball del projecte emmagatzemat al sistema de fitxers de l’ordinador. Tots els canvis romanen aquí fins que no els afegiu a una àrea intermèdia anomenada àrea de prova.

Podeu escenificar els canvis executant git add. comandament. Aquesta àrea de prova us proporciona una previsualització de la vostra pròxima confirmació i, bàsicament, us permet afinar els vostres compromisos. Podeu afegir o eliminar canvis a l'àrea de prova fins que estigueu satisfet amb la versió que voleu confirmar.

Un cop verifiqueu els canvis i tanqueu l’escenari canviat, podreu finalment fer els canvis. En fer el commit, van al repositori local, és a dir, al directori .git / objects.

Si utilitzeu Git GUI, veureu l'opció d'escenificar els vostres canvis. A la captura de pantalla següent, el fitxer sample.txt es troba a l’àrea de canvis sense fases, cosa que significa que es troba al directori de treball.

Podeu seleccionar un fitxer i fer clic a 'etapa canviat' i, a continuació, es mourà a l'àrea de prova. Per exemple , el fitxer hello.txt està present a l'àrea de canvi de fase (es comprometrà). Podeu verificar els canvis i, a continuació, iniciar la sessió, seguida d'un compromís.

La posició en fase també es coneix com indexació perquè git manté un fitxer d’índex per fer un seguiment dels canvis del fitxer en aquestes tres àrees. Els fitxers que s’organitzen es troben actualment al vostre índex.

Quan afegiu canvis a l'àrea de prova, la informació de l'índex s'actualitza. Quan feu una confirmació, en realitat és el que hi ha a l’índex que es compromet, i no el que hi ha al directori de treball. Podeu utilitzar el fitxer estat git per veure què hi ha a l’índex.

P # 23) Què és Git Stash?

Resposta: GIT stash captura l'estat actual del directori i índex de treball i el manté a la pila per al seu ús futur. Reverteix els canvis no compromesos (tant per fases com per fases) del directori de treball i us proporciona un arbre de treball net.

Ara podeu treballar en una altra cosa i, quan torneu, podeu tornar a aplicar aquests canvis. Per tant, si voleu canviar d’un context a un altre sense perdre els canvis actuals, podeu fer servir la funció de reserva.

És útil per canviar ràpidament de context, on esteu en un canvi de codi que no voleu cometre o desfer en aquest moment i teniu alguna cosa més a treballar. L'ordre a utilitzar és git stash.

P # 24) Què és el descens de Git Stash?

Resposta: Quan ja no necessiteu cap reserva específica, podeu eliminar-la executant-la ordre git stash drop . Si voleu eliminar totes les ratlles d'un sol cop del repositori, podeu executar-les ordre git stash clear .

P # 25) Què s'aplica Git stash? En què es diferencia del Git stash pop?

Resposta: Ambdues ordres s’utilitzen per tornar a aplicar els canvis ocults i començar a treballar des d’on havíeu deixat.

En s'aplica git stash , els canvis s'aplicaran de nou a la vostra còpia de treball i també es conservaran a la memòria cau. Aquesta ordre es pot utilitzar quan vulgueu aplicar els mateixos canvis ocults a diverses branques.

En git stash pop , els canvis s’eliminen de la memòria cau i es tornen a aplicar a la còpia de treball.

P # 26) Què utilitza l'ordre git clone?

Resposta: El git clon L'ordre crea una còpia del dipòsit central Git existent a la vostra màquina local.

P # 27) Quan s'utilitza l'ordre git config?

Resposta: El git config s'utilitza per establir opcions de configuració per a la instal·lació de Git.

Per exemple, després de descarregar Git, heu d'utilitzar a sota de les ordres de configuració per configurar el nom d'usuari i confirmar l'adreça de correu electrònic a Git respectivament:

$ git config –nom d'usuari global “”

$ git config –global user.email “”

Així, principalment, es poden configurar coses com el comportament del dipòsit, la informació de l'usuari i les preferències amb l'ajut d'aquesta ordre.

P # 28) Com identificareu si la branca ja està fusionada en mestra?

Resposta:

Executant les ordres següents, podeu conèixer l'estat de combinació de sucursals:

1. branca git: mestre fusionat: Es mostraran totes les branques que han canviat el nom de mestre.
2. branca git –fusionada: Aquí s'enumeren totes les branques que s'han fusionat a HEAD.
3. branca git –no combinada: Es mostraran totes les branques que encara no s’han combinat.

Per defecte, aquesta ordre només indica l'estat de combinació de les sucursals locals. Si voleu conèixer l'estat de combinació de sucursals tant local com remot, podeu utilitzar-lo -a bandera. Si voleu cercar només sucursals remotes, podeu utilitzar-lo -r bandera.

P # 29) Què són els ganxos de Git?

Resposta: Els ganxos de Git són certs scripts que Git s’executa abans o després d’un esdeveniment com ara commit, push, actualització o recepció. Trobareu la carpeta 'ganxos' al directori .git del vostre dipòsit local. Aquí trobareu els scripts integrats pre-commit, post-commit, pre-push, post push.

Aquests scripts s’executen localment abans o després de l’esdeveniment d’un esdeveniment. També podeu modificar aquests scripts segons les vostres necessitats i Git executarà el script quan es produeixi aquest esdeveniment en particular.

P # 30) Per a què serveix la forquilla git? En què es diferencia la forquilla de la clonació?

Resposta: Forcar un projecte significa crear una còpia remota, al servidor, del dipòsit original. Podeu canviar el nom d'aquesta còpia i començar a fer un projecte nou sense afectar el projecte original. La forquilla no és el concepte bàsic de Git.

El flux de treball de Git utilitza l'operació de forquilla i aquesta idea existeix més temps per al programari lliure i de codi obert com GitHub. En general, un cop hagueu forcat el projecte, poques vegades tornareu a contribuir al projecte pare.

Per exemple, OpenBSD és un sistema operatiu de codi obert similar a Unix que es va desenvolupar mitjançant la forquilla de NetBSD, que és un altre sistema operatiu de codi obert similar a Unix.

Tanmateix, a la bifurcació, existeix una connexió directa entre la vostra còpia bifurcada i el dipòsit original. En qualsevol moment, podeu tornar a contribuir al projecte original mitjançant les sol·licituds d'extracció.

A la còpia bifurcada, totes les dades principals, com ara codis i fitxers, es copien del dipòsit original, tot i que no es copien les branques, les sol·licituds d'extracció i altres funcions. El bifurcació és una forma ideal de col·laboració de codi obert.

La clonació és essencialment un concepte Git. Un clon és una còpia local de qualsevol dipòsit remot. Quan clonem un dipòsit, tot el dipòsit font junt amb el seu historial i les seves branques es copia a la nostra màquina local.

A diferència del forking, no hi ha cap connexió directa entre el dipòsit clonat i el dipòsit remot original. Si voleu fer sol·licituds d'extracció i tornar al projecte original, us hauríeu d'afegir com a col·laborador al repositori original.

La clonació també és una manera excel·lent de crear una còpia de seguretat del dipòsit original, ja que la còpia clonada també té tot l'historial de confirmacions.

P # 31) Com esbrinarà què han canviat tots els fitxers en un commit Git concret?

Resposta: En utilitzar el valor hash de la confirmació particular, podeu executar l'ordre següent per obtenir la llista de fitxers que s'han canviat en una confirmació determinada:

git diff-tree -r {hash}

Això mostrarà tots els fitxers que s'han modificat i també els fitxers que s'han afegit. El senyalador -r s'utilitza per llistar fitxers individuals juntament amb el seu camí en lloc de replegar-los només als noms del directori arrel.

També podeu utilitzar l'ordre següent:

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

–No-commit-id tornarà a entrenar els números de hash de confirmació que apareixeran a la sortida. Mentre que, -name exclourà els camins de fitxers i només donarà els noms de fitxer a la sortida.

Q # 32) Quina diferència hi ha entre git checkout (nom de sucursal) i git checkout -b (nom de sucursal)?

Resposta: L'ordre git checkout (nom de la sucursal) canviarà d'una branca a una altra.

L'ordre git checkout -b (nom de la sucursal) crearà una nova sucursal i també hi canviarà.

P # 33) Què és SubGit?

Resposta: SubGit és una eina que s’utilitza per a la migració de SVN a Git. Està desenvolupat per una empresa anomenada TMate. Converteix els dipòsits SVN a Git i us permet treballar simultàniament en els dos sistemes. Sincronitza automàticament el SVN amb Git.

(imatge font )

Podeu crear un mirall SVN || Git amb aquesta eina. SubGit s’hauria d’instal·lar al servidor Git. Detectarà tots els paràmetres del vostre dipòsit SVN remot, incloses les revisions, branques i etiquetes de SVN, i els convertirà en confirmacions de Git.

També conserva l'historial, incloses les dades de combinació de seguiment.

P # 34) Podeu recuperar una sucursal suprimida a Git?

Resposta: Si, tu pots. Per recuperar una branca suprimida, heu de conèixer el SHA de la part superior del cap. SHA o hash és un identificador únic que Git crea amb cada operació.

Quan suprimiu una sucursal, es mostra el SHA al terminal:

S'ha suprimit la branca (era)

Podeu utilitzar l'ordre següent per recuperar la branca suprimida:

git checkout -b

Si no coneixeu el SHA per al commit a la punta de la vostra sucursal, primer podeu utilitzar el anar reflog per conèixer el valor SHA i, a continuació, apliqueu l'ordre de compra anterior per restaurar la vostra sucursal.

P # 35) Què és git diff comandament? En què es diferencia estat git?

Resposta: Git diff és una ordre de diversos usos que es pot executar per mostrar les diferències entre dues confirmacions arbitràries, canvis entre l'arbre de treball i una confirmació, canvis entre l'arbre de treball i un índex, canvis entre dos fitxers, canvis entre índex i un arbre, etc.

El estat git La comanda s'utilitza per inspeccionar un dipòsit. Mostra l'estat del directori de treball i l'àrea de prova. Enumerarà els fitxers que s’han posat en escena, que no s’han posat en escena i els que no s’han seguit.

P # 36) Què conté un objecte Commit?

Resposta: L'objecte de confirmació conté el hash d'objecte d'arbre de nivell superior, el pare de verificació hash (si n'hi ha), informació sobre l'autor i committer, data de confirmació i missatge de confirmació

Podeu veure-ho a través de registre de git comandament.

Exemple:

(imatge font )

P # 37) Què és el git cherry-pick? Quins són els escenaris en què es pot utilitzar el git cherry-pick?

Resposta: Git picant de cireres és una ordre potent per aplicar els canvis introduïts per una o més confirmacions existents. Us permet escollir una confirmació d’una sucursal i aplicar-la a una altra.

git cherry-pick commitSha és l'ordre que s'utilitza per recollir cireres. commitSha és la referència de commit.

Aquesta ordre es pot utilitzar per desfer canvis. Per exemple, si per error heu fet un compromís amb una branca equivocada, podeu comprovar la branca correcta i triar la confirmació a on hauria de pertànyer.

També es pot utilitzar en col·laboració en equip. Hi pot haver escenaris en què cal compartir el mateix codi entre dos components del producte. En aquest cas, si un desenvolupador ja ha escrit aquest codi, l’altre pot escollir el mateix.

La selecció de cireres també és útil en correccions d'errors on es pot triar una confirmació de pedaç directament a la branca mestra per solucionar el problema tan aviat com sigui possible.

P # 38) Per a què s’utilitza ‘git reset’? Quin és el mode per defecte d'aquesta ordre?

Resposta: Restabliment de Git és un poderós comandament per desfer canvis locals a l'estat d'un repositori de Git. Aquesta ordre restableix el HEAD actual a l'etapa especificada.

Restableix l'índex i el directori de treball a l'estat de l'última confirmació. El restabliment de Git té tres modes, és a dir, suau, dur i mixt. El mode d'operació per defecte és mixt.

P # 39) Quina diferència hi ha entre 'CAP', 'arbre de treball' i 'índex'?

Resposta: L’arbre de treball o l’espai de treball és el directori que conté els fitxers font en què esteu treballant actualment.

L'índex és l'àrea de prova de Git on es preparen les confirmacions. Es troba entre el compromís i el vostre arbre de treball. Git index és un fitxer binari gran que registra tots els fitxers de la branca actual, els seus noms, sumes de comprovació sha1 i marques de temps.

Aquest fitxer es troba a /.git/index. HEAD és la referència o el punter cap a l'última confirmació de la branca de pagament actual.

P # 40) Quina diferència hi ha entre rebaixar i fusionar? Quan haureu de tornar a crear una nova versió i quan hauríeu de fusionar-vos?

Resposta: Tant les ordres de reincorporació com de combinació s'utilitzen per integrar els canvis d'una branca a una altra però d'una manera diferent.

Com es pot veure a les dues imatges següents, suposem que teniu confirmacions (això és abans de combinar / rebaixar). Després de la combinació, obtindreu el resultat com una combinació de confirmacions. Uneix les històries de les dues branques i crea un nou 'commit commit' a la branca de funcions.

D'altra banda, rebase mourà tota la branca de funcions per començar a la punta de la branca mestra.

(imatge font )

Els compromisos seran els següents:

No es recomana tornar a canviar la versió de les oficines públiques, ja que crea repositoris inconsistents. Tanmateix, tornar a aplicar una nova opció és una bona opció per a sucursals privades / desenvolupadors individuals. No és molt adequat per al mode de sucursal per funció. Però si teniu un model de sucursal per desenvolupador, la rebaixa de les dades no és perjudicial.

A més, el rebase és una operació destructiva, de manera que el vostre equip de desenvolupament ha de ser prou expert per aplicar-lo correctament. En cas contrari, es pot perdre el treball compromès.

A més, revertir una combinació és més fàcil que revertir una rebaixa. Per tant, si sabeu que pot haver-hi possibilitats de revertir, hauríeu d’utilitzar la combinació.

La combinació persevera la història tal com és, mentre que rebase reescriu la història. Per tant, si voleu veure l'historial completament tal com es va produir, hauríeu d'utilitzar merge.

P # 41) Quina és la sintaxi per tornar a basar?

Resposta: La sintaxi de l'ordre rebase és git rebase (new-commit)

Q # 42) Com treureu un fitxer de Git sense eliminar-lo del vostre sistema de fitxers local?

Resposta: Podeu fer servir l'opció 'a la memòria cau' per fer-ho:

git rm -rf –cache $ FILES

Aquesta ordre eliminarà els fitxers del dipòsit sense esborrar-los del disc.

P # 43) Quin és el patró de ramificació comú a Git?

Resposta: El patró de ramificació comú es basa en el flux de git. Té dues branques principals: el domini i el desenvolupament.

• La branca mestra conté el codi de producció. Tot el codi de desenvolupament es combina en la branca mestra en algun moment del temps.
• La branca de desenvolupament conté el codi de preproducció. Quan es completen les funcions, es combinen amb la branca mestra, generalment a través d'una canalització CI / CD.

Aquest model també té algunes branques de suport que s’utilitzen durant el cicle de desenvolupament:

• Branques de funcions / branques de temes: S'utilitzen per desenvolupar noves funcions per a les properes versions. Es pot ramificar des de la branca de desenvolupament i s'ha de tornar a combinar amb la branca de desenvolupament. Generalment, aquestes branques només existeixen als dipòsits de desenvolupadors i no a l’origen.
• Branques de revisió: S'utilitzen per a versions de producció no planificades quan és necessari corregir immediatament qualsevol error crític a la versió de prod. Poden separar-se del mestre i s'han de fusionar de nou en desenvolupament i mestre.
• Llançament de sucursals: S'utilitzen per a la preparació de la versió de nova producció. La branca de la versió us permet fer correccions d'errors menors i preparar metadades per a la versió. Poden separar-se del desenvolupament i s'han de fusionar de nou en mestre i desenvolupament.

Conclusió

Hem recorregut les preguntes importants que generalment es fan durant les entrevistes de Git en aquest tutorial.

Això no només us ajudarà a preparar-vos per a les properes entrevistes, sinó que també us aclarirà els conceptes.

Tot el millor per a la vostra entrevista!

Lectura recomanada

• Preguntes i respostes de l’entrevista
• Algunes preguntes d’entrevistes de proves de programari interessants
• Top 40 C Preguntes i respostes de l'entrevista de programació
• Top 40 de les preguntes i respostes populars de l'entrevista J2EE que hauríeu de llegir
• Preguntes i respostes d’entrevistes de proves ETL
• Més de 20 preguntes i respostes de les entrevistes més freqüents
• Preguntes principals sobre les entrevistes sobre formularis i informes d'Oracle
• Algunes preguntes i respostes de proves manuals complicades