Le 40 principali domande e risposte dell'intervista GIT nel 2021

top 40 git interview questions

Domande di intervista GIT più popolari con risposte ed esempi:

Questo tutorial informativo include una serie delle domande più probabili poste nelle interviste Git insieme alle loro risposte descrittive. Queste domande ti aiuteranno sicuramente a prepararti e a risolvere con successo qualsiasi intervista Git.

Che tu sia un principiante o un professionista esperto, queste domande di intervista su Git e risposte dettagliate ti aiuteranno sicuramente ad arricchire la tua conoscenza dell'argomento ed eccellere nel tuo lavoro e nelle interviste.

Iniziamo!!

Domande di intervista GIT più frequenti

Di seguito sono elencate alcune delle domande di intervista GIT più frequenti come riferimento.

D # 1) Cos'è Git?

Risposta: Git è uno strumento di controllo della versione distribuito. È compatibile con flussi di lavoro non lineari distribuiti in quanto offre la garanzia dei dati per la creazione di software di buona qualità.

Git è gratuito e open source. Può essere utilizzato per quasi tutti i tipi di progetti, sia di piccole che di grandi dimensioni. Git è noto per la sua grande velocità ed efficienza. I repository Git sono molto facili da trovare e accedere. Grazie alle sue caratteristiche, Git è altamente flessibile, sicuro e compatibile con il tuo sistema.

D # 2) Che cos'è un sistema di controllo della versione distribuito?

Risposta: Un VCS distribuito è un sistema che non dipende da un server centrale per conservare un file di progetto e tutte le sue versioni. In VCS distribuito, ogni collaboratore o sviluppatore ottiene una copia locale del repository principale e questo viene chiamato clone.

(Immagine fonte )

Come puoi vedere nel diagramma sopra, ogni collaboratore mantiene un repository locale sulle proprie macchine locali. Possono eseguire il commit e aggiornare i repository locali senza problemi.

Utilizzando un'operazione di pull, uno sviluppatore può aggiornare il suo repository locale con le ultime modifiche dal server centrale. Utilizzando l'operazione push, possono inviare le modifiche dal repository locale al server centrale.

D # 3) Chi ha creato Git?

Risposta: Git è stato creato da Linus Torvalds nel 2005 sulla strada per lo sviluppo del kernel Linux.

D # 4) Quale lingua viene utilizzata in Git?

Risposta: C è il linguaggio di programmazione sottostante in cui è scritto Git. Il linguaggio C rende Git veloce eludendo i sovraccarichi di runtime legati ad altri linguaggi di programmazione di alto livello.

Q # 5) Quali sono i vantaggi / le caratteristiche principali di Git?

Risposta: Di seguito sono elencati i vari f eatures di Git.

(i) Gratuito e open source:

Git è rilasciato sotto licenza open source GPL (General Public License). Non devi pagare nulla per usare Git.

È assolutamente gratuito. Poiché è open-source, puoi modificare il codice sorgente in base alle tue esigenze.

(ii) Velocità:

Poiché non è necessario connettersi a nessuna rete per eseguire tutte le azioni, esegue rapidamente tutte le attività. Ottenere la cronologia delle versioni da un repository memorizzato localmente può essere cento volte più veloce che ottenerlo dal server remoto.

Git è scritto in C, che è il linguaggio di programmazione sottostante che elude i sovraccarichi di runtime legati ad altri linguaggi di alto livello.

(iii) Scalabile:

Git è altamente scalabile. Quindi, se il numero di collaboratori aumenta nel tempo a venire, Git può facilmente accogliere questo cambiamento.

Nonostante il fatto che Git rappresenti un intero repository, i dati conservati dal lato client sono molto piccoli poiché Git compatta l'intera vasta dati attraverso una tecnica di compressione senza perdite.

(iv) Affidabile:

Poiché ogni collaboratore ha il proprio repository locale, nei casi di arresto anomalo del sistema, i dati persi possono essere recuperati da uno qualsiasi dei repository locali. In ogni momento, avrai un backup di tutti i tuoi file.

(v) Sicuro:

Git utilizza SHA1 (Secure Hash Function) per denominare e identificare gli oggetti all'interno del proprio repository. Ogni artefatto e commit vengono riepilogati e recuperati tramite il relativo checksum durante il checkout.

La cronologia di Git viene salvata in un modo in cui l'ID di una versione specifica (un commit in termini di Git) si basa sulla cronologia di sviluppo totale fino a quel commit. Una volta che una versione del file è stata inviata a Git, non c'è modo di cambiarla senza essere notato.

(vi) Economico:

Nel caso di un sistema di controllo delle versioni centralizzato, il server centrale deve essere sufficientemente potente per rispondere alle richieste dell'intero team. Questo non è un problema per i team più piccoli, tuttavia man mano che il team si espande, i limiti hardware del server possono essere un ostacolo per le prestazioni.

Nel caso di sistemi di controllo delle versioni distribuiti come Git, i membri del team non richiedono l'interazione con il server quando devono eseguire il push o il pull delle modifiche. Tutto il lavoro pesante avviene all'estremità del client, quindi l'hardware del server può essere mantenuto abbastanza semplice certamente.

(vii) Supporta lo sviluppo non lineare:

Git fornisce ramificazioni e fusioni rapide e contiene strumenti particolari per immaginare e attraversare una storia di sviluppo non lineare. Una nozione di base in Git è che una modifica verrà fusa più frequentemente di quanto non venga scritta poiché viene inviata a revisori diversi.

I rami Git sono estremamente leggeri. Un ramo in Git si riferisce solo a un singolo commit. La struttura completa del ramo può essere creata, con l'aiuto dei commit genitore.

(viii) Facile diramazione:

La gestione delle filiali tramite Git è molto semplice e diretta. Bastano pochi istanti per creare, eliminare e unire i rami. I rami delle funzionalità forniscono un ambiente isolato a ogni modifica alla base di codice.

Quando uno sviluppatore richiede di iniziare a lavorare su qualcosa, indipendentemente dalle dimensioni del lavoro, crea un nuovo ramo. Ciò garantisce che il ramo principale mantenga costantemente un codice di qualità della produzione.

(ix) Sviluppo distribuito:

Git fornisce a ogni sviluppatore una copia locale dell'intera cronologia dello sviluppo, inoltre le modifiche vengono clonate da uno di questi repository a un altro. Queste modifiche vengono introdotte come rami di sviluppo aggiunti e possono essere unite allo stesso modo di un ramo sviluppato localmente.

(x) Compatibilità con i sistemi o protocolli attuali:

I repository possono essere pubblicati tramite HTTP, FTP o un protocollo Git su un semplice socket o ssh.

D # 6) Come si crea un repository in Git?

Risposta: Per creare un repository, è necessario creare una directory per il progetto se non esiste già, quindi eseguire semplicemente il comando ' git init '. Eseguendo questo comando, verrà creata una directory .git all'interno della directory del progetto, ovvero ora la directory del tuo progetto è diventata un repository Git.

differenza tra test del fumo e test di sanità mentale

D # 7) Cos'è una directory .git?

Risposta: Nel momento in cui crei un repository, troverai una directory .git presente al suo interno. Questa directory .git contiene tutti i metadati del repository e mantiene una traccia di tutte le modifiche apportate ai file nel tuo repository, mantenendo una cronologia dei commit.

Tutte le informazioni riguardanti commit, hook, refs, database di oggetti, indirizzi di repository remoti, ecc. Sono conservate all'interno di questa cartella. Questa è la parte più cruciale di Git. Quando cloni un repository Git sulla tua macchina locale, questo .git è la directory che viene effettivamente copiata.

D # 8) Cosa succede se la directory .git viene eliminata?

Risposta: Se la directory .git / viene eliminata, perderai traccia della cronologia del tuo progetto. Il repository non sarà più sotto il controllo della versione.

D # 9) Quale comando viene utilizzato per scrivere un messaggio di commit in Git?

Risposta: Il comando utilizzato per passare un messaggio a un commit git è git commit -m 'messaggio di commit'. La bandiera m viene utilizzato per passare un messaggio di commit.

D # 10) Cos'è il repository Git nudo? In che modo è diverso da un repository Git standard / non nudo?

Risposta: Repository creati tramite git init sono i repository Git standard / non nudi.

Nella cartella di primo livello di tale repository, troverai due cose:

1. Una sottodirectory .git che conserva tutti i metadati e traccia la cronologia del tuo repository.
2. Un albero funzionante.

I repository che vengono creati utilizzando git init –bare sono noti come repository Git nudi. Sono utilizzati principalmente per la condivisione. Non contengono alcun albero funzionante. Mantengono la cronologia delle revisioni git del tuo repository nella cartella principale anziché nella sottocartella .git.

Contiene solo i dati del repository nudo. Ecco come un repository Git nudo è diverso da un repository Git standard. Inoltre, un repository nudo non dispone di un telecomando predefinito origine repository in quanto funge da repository di origine per più utenti remoti.

Poiché un repository nudo non contiene alcuno spazio di lavoro, il file git push e git pull i comandi non funzionano su un semplice repository. Non è necessario eseguire il commit di alcuna modifica su un semplice repository.

D # 11) Menziona alcuni servizi di hosting del repository Git.

Risposta:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Trampolino di lancio
• Perforce
• Pianta di fagioli
• Sembra

D # 12) Assegna un nome ad alcune operazioni di base in Git.

Risposta: Alcune operazioni di base in Git includono:

• Inizializzare
• Inserisci
• Commettere
• spingere
• Tirare

D # 13) Nomina alcune operazioni avanzate in Git.

Risposta: Alcune operazioni avanzate in Git sono:

• Ramificazione
• Fusione
• Ribasatura

Q # 14) Come distinguerai tra Git e SVN?

Risposta: Git è un controllo di versione distribuito mentre SVN è centralizzato. Ciò porta a molte differenze tra i due in termini di caratteristiche e funzionalità.

D # 15) Come distinguerai tra Git e GitHub?

Risposta: Git è un sistema di controllo delle versioni di alta qualità. È distribuito in natura e viene utilizzato per tenere traccia delle modifiche nel codice sorgente durante lo sviluppo del software. Ha un modello di ramificazione unico che aiuta a sincronizzare il lavoro tra gli sviluppatori e tenere traccia delle modifiche in qualsiasi file.

Gli obiettivi principali di Git sono la velocità, l'integrità dei dati e il supporto a flussi di lavoro distribuiti e non lineari. Git viene installato e mantenuto sulla macchina locale, invece che sul cloud.

GitHub è un servizio di hosting di repository Git basato su cloud che riunisce i team. Fornisce una GUI basata sul Web, nonché il controllo degli accessi e molte funzionalità di collaborazione, strumenti di gestione delle attività fondamentali per ogni progetto.

Inoltre, GitHub è un open-source, ovvero il codice è conservato su un server centralizzato ed è accessibile a tutti.

D # 16) Cos'è un conflitto in Git e come risolverlo?

Risposta: Git ha una funzione di unione automatica che gestisce i commit di unione da sola, a condizione che le modifiche al codice siano avvenute su righe diverse e in file diversi.

Ma, in caso di competizione per i commit in cui ci sono modifiche nelle stesse righe di codice di un file o un file è stato cancellato in un ramo ma esiste e modificato in un altro, Git non è in grado di risolvere automaticamente le differenze e quindi solleva conflitti di unione.

In questi casi, è necessario il tuo aiuto per decidere quale codice includere e quale codice eliminare nell'unione finale.

Un conflitto di unione può verificarsi durante l'unione di un ramo, il rebase di un ramo o la selezione di un commit. Una volta rilevato un conflitto, Git evidenzia l'area in conflitto e ti chiede di risolverlo. Una volta risolto il conflitto, puoi procedere con l'unione.

Seguire i passaggi seguenti per risolvere un conflitto di unione di modifiche di riga in competizione:

1. Apri Git Bash (riga di comando Git).
2. Uso CD comando per andare al repository Git locale che sta avendo il conflitto di unione.
3. Usa il stato git comando per produrre l'elenco dei file interessati dal conflitto di unione.
4. Apri l'editor di testo che utilizzi e accedi al file con conflitti di unione.
5. Per vedere l'inizio del conflitto di unione nel tuo file, cerca nel documento l'indicatore di conflitto<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> BRANCH-NAME.
6. Scegli nel caso in cui devi mantenere solo le modifiche del tuo ramo, conserva solo le modifiche dell'altro ramo o apporta una nuova modifica, che potrebbe includere modifiche dai due rami. Cancella gli indicatori di conflitto<<<<<<>>>>>> ed esegui le modifiche di cui hai bisogno nell'unione finale.
7. Uso git aggiunge. comando per aggiungere o mettere in scena le modifiche.
8. Infine, usa il file git commit -m 'messaggio' comando per confermare le modifiche con un commento.

Per risolvere il conflitto di unione dei file rimossi, è necessario seguire i passaggi seguenti:

1. Apri Git Bash (riga di comando Git).
2. Uso CD comando per andare al repository Git locale che ha il conflitto di unione.
3. Usa il stato git comando per produrre l'elenco dei file interessati dal conflitto di unione.
4. Apri l'editor di testo che utilizzi e accedi al file con conflitti di unione.
5. Scegli se desideri mantenere il file rimosso. Puoi controllare le ultime modifiche apportate nel file rimosso nel tuo editor di testo.
6. Uso git add comando per aggiungere nuovamente il file rimosso al repository. Oppure Usa vai rm comando per rimuovere il file dal tuo repository.
7. Infine, usa il file git commit -m 'messaggio' comando per confermare le modifiche con un commento.

D # 17) Come risolverai un commit interrotto?

Risposta: Per correggere un commit danneggiato o per modificare l'ultimo commit, il metodo più conveniente è usare il comando ' git commit -amend ' .

Ti consente di combinare le modifiche a fasi con il commit precedente come alternativa per creare un commit completamente nuovo. Questo sostituisce il commit più recente con il commit modificato.

(Immagine fonte )

Attraverso questo comando, puoi anche modificare il messaggio di commit precedente senza cambiarne lo snapshot.

D # 18) A cosa serve git instaweb?

Risposta: È uno script attraverso il quale puoi navigare istantaneamente nel tuo repository Git funzionante in un browser web.

Questo script imposta gitweb e un server web per esplorare il repository locale. Dirige automaticamente un browser web e gestisce un server web attraverso un'interfaccia nel tuo repository locale.

D # 19) Cos'è git is-tree?

Risposta: 'Git is-tree' indica un oggetto albero che comprende la modalità e il nome di tutti gli elementi insieme al valore SHA-1 del blob o dell'albero.

Q # 20) C'è un modo per annullare un commit git che è già stato inviato e reso pubblico?

Risposta: Sì, per correggere o annullare un bad commit, ci sono due approcci che possono essere utilizzati in base allo scenario.

Sono:

1. Il modo molto ovvio è fare un nuovo commit in cui rimuovi il file danneggiato o correggi gli errori in esso. Una volta terminato, puoi inviarlo a un repository remoto.
2. Un altro approccio consiste nel creare un nuovo commit per annullare tutte le modifiche apportate nel precedente bad commit. Questo può essere fatto tramite il comando git revert - ' git revert '

Q # 21) Come distinguerai tra git pull e git fetch?

Risposta: Git pull Il comando estrae tutti i nuovi commit da un ramo specifico nel repository centrale e aggiorna il ramo di destinazione nel tuo repository locale.

Git fetch mira anche alla stessa cosa, tuttavia, la sua funzionalità di base è leggermente diversa. Quando esegui un git fetch, tutti i nuovi commit da un ramo specifico verranno estratti nel tuo repository centrale e queste modifiche verranno archiviate in un nuovo ramo nel tuo repository locale. Questo è chiamato ramo recuperato.

Se desideri vedere questi cambiamenti nel tuo ramo di destinazione, devi eseguire un file vai unisci dopo git fetch. Il ramo di destinazione verrà aggiornato con le ultime modifiche solo dopo averlo unito al ramo recuperato.

Quindi, un git pull aggiorna il ramo locale con la sua versione remota, mentre un git fetch non cambia direttamente il tuo ramo locale o la copia di lavoro sotto rifs / teste. Git fetch può essere utilizzato per aggiornare i rami di monitoraggio remoto in refs / remotes //.

In parole semplici, git pull è uguale a git fetch seguito da un git merge .

D # 22) Qual è l'uso dell'area di staging o dell'indicizzazione in Git?

Risposta: Dal punto di vista di Git, ci sono tre aree in cui è possibile mantenere le modifiche al file, ovvero directory di lavoro, area di staging e repository.

Per prima cosa, apporti modifiche nella directory di lavoro del tuo progetto memorizzata nel file system del tuo computer. Tutte le modifiche rimangono qui finché non vengono aggiunte a un'area intermedia chiamata area di staging.

Puoi mettere in scena le modifiche eseguendo git add. comando. Questa area di staging ti offre un'anteprima del tuo prossimo commit e in pratica ti consente di mettere a punto i tuoi commit. È possibile aggiungere o rimuovere modifiche nell'area di gestione temporanea finché non si è soddisfatti della versione che si intende eseguire il commit.

Dopo aver verificato le modifiche e aver terminato la fase modificata, puoi finalmente eseguire il commit delle modifiche. Dopo il commit, vanno nel repository locale, cioè nella directory .git / objects.

Se usi Git GUI, vedrai l'opzione per mettere in scena le tue modifiche. Nello screenshot qui sotto, il file sample.txt si trova nell'area delle modifiche non organizzate, il che significa che si trova nella directory di lavoro.

Puoi selezionare un file e fare clic su 'fase modificata', quindi verrà spostato nell'area di gestione temporanea. Per esempio , il file hello.txt è presente nell'area di fase modificata (eseguirà il commit). È possibile verificare le modifiche e quindi eseguire un sign-off, seguito da un commit.

Lo staging viene anche definito indicizzazione perché git mantiene un file di indice per tenere traccia delle modifiche al file in queste tre aree. I file che vengono gestiti sono attualmente nel tuo indice.

Quando aggiungi modifiche all'area di gestione temporanea, le informazioni nell'indice vengono aggiornate. Quando si esegue un commit, è effettivamente ciò che è nell'indice che viene eseguito il commit e non ciò che è nella directory di lavoro. Puoi usare il file stato git comando per vedere cosa c'è nell'indice.

D # 23) Cos'è Git Stash?

Risposta: Lo stash GIT acquisisce lo stato corrente della directory di lavoro e dell'indice e lo mantiene nello stack per un utilizzo futuro. Ripristina le modifiche non salvate (sia in fasi che non in fase) dalla directory di lavoro e restituisce un albero di lavoro pulito.

Puoi lavorare su qualcos'altro ora e quando torni, puoi riapplicare queste modifiche. Quindi, se vuoi passare da un contesto a un altro senza perdere le modifiche attuali, puoi usare lo stashing.

È utile nel cambio di contesto rapido, in cui ti trovi a metà di una modifica del codice che non vuoi eseguire o annullare in questo momento e hai qualcos'altro su cui lavorare. Il comando da usare è git stash.

D # 24) Cos'è il drop di Git Stash?

Risposta: Quando non hai più bisogno di una scorta specifica, puoi rimuoverla eseguendo comando git stash drop . Se vuoi rimuovere tutti gli stash in una volta dal repository, puoi eseguire comando git stash clear .

D # 25) Cos'è l'applicazione di Git stash? In cosa differisce dallo stash pop di Git?

Risposta: Entrambi i comandi vengono utilizzati per riapplicare le modifiche nascoste e iniziare a lavorare da dove eri rimasto.

Nel git stash apply le modifiche verranno applicate nuovamente alla tua copia di lavoro e saranno anch'esse conservate nella stash. Questo comando può essere utilizzato quando si desidera applicare le stesse modifiche nascoste a più rami.

Nel git stash pop comando, le modifiche vengono rimosse dallo stash e vengono nuovamente applicate alla copia di lavoro.

D # 26) Qual è l'uso del comando git clone?

come faccio ad aprire un file eps in Windows 10

Risposta: Il git clone Il comando crea una copia del repository Git centrale esistente nella tua macchina locale.

Q # 27) Quando viene utilizzato il comando git config?

Risposta: Il git config viene utilizzato per impostare le opzioni di configurazione per l'installazione di Git.

Per esempio, dopo aver scaricato Git, è necessario utilizzare di seguito i comandi di configurazione per impostare rispettivamente il nome utente e l'indirizzo email di commit in Git:

$ git config –nome.utente globale ''

$ git config –utente globale.email ''

Quindi, principalmente, cose come il comportamento del repository, le informazioni dell'utente e le preferenze possono essere impostate con l'aiuto di questo comando.

Q # 28) Come identificherai se il ramo è già stato unito al master?

Risposta:

Eseguendo i seguenti comandi, puoi conoscere lo stato di unione dei rami:

1. git branch –merged master: Questo elencherà tutti i rami che sono stati rinominati in master.
2. git branch -merged: Questo elencherà tutti i rami che sono stati uniti in HEAD.
3. git branch –no-merged: Questo elencherà tutti i rami che non sono ancora stati uniti.

Per impostazione predefinita, questo comando indica solo lo stato di unione dei rami locali. Se vuoi conoscere lo stato di unione dei rami sia locali che remoti, puoi usare -per bandiera. Se vuoi controllare solo i rami remoti, puoi usare -r bandiera.

D # 29) Cosa sono gli hook in Git?

Risposta: Gli hook Git sono determinati script che Git esegue prima o dopo un evento come commit, push, aggiornamento o ricezione. Troverai la cartella 'hooks' all'interno della directory .git nel tuo repository locale. Troverai gli script integrati qui pre-commit, post-commit, pre-push, post push.

Questi script vengono eseguiti localmente prima o dopo il verificarsi di un evento. Puoi anche modificare questi script in base alle tue esigenze e Git eseguirà lo script quando si verifica quel particolare evento.

Q # 30) Qual è l'uso di git fork? In che modo il fork è diverso dalla clonazione?

Risposta: Eseguire il fork di un progetto significa creare una copia lato server remota del repository originale. Puoi rinominare questa copia e iniziare a fare un nuovo progetto attorno a questo senza influire sul progetto originale. Il fork non è il concetto centrale di Git.

L'operazione di fork viene utilizzata dal flusso di lavoro Git e questa idea esiste più a lungo per il software gratuito e open source come GitHub. In genere, una volta biforcato il progetto, raramente contribuirai di nuovo al progetto principale.

Per esempio, OpenBSD è un sistema operativo open source simile a Unix che è stato sviluppato mediante fork di NetBSD, un altro sistema operativo open source simile a Unix.

Tuttavia, nel fork, esiste una connessione diretta tra la copia biforcuta e il repository originale. In qualsiasi momento, puoi contribuire di nuovo al progetto originale utilizzando le richieste pull.

Nella copia biforcuta, tutti i dati principali come codici e file vengono copiati dal repository originale, tuttavia, rami, richieste pull e altre funzionalità non vengono copiati. Il fork è un modo ideale per la collaborazione open source.

La clonazione è essenzialmente un concetto di Git. Un clone è una copia locale di qualsiasi repository remoto. Quando cloniamo un repository, l'intero repository di origine insieme alla sua cronologia e ai rami vengono copiati sul nostro computer locale.

A differenza del fork, non esiste una connessione diretta tra il repository clonato e il repository remoto originale. Se vuoi eseguire richieste pull e tornare al progetto originale, dovresti farti aggiungere come collaboratore nel repository originale.

La clonazione è anche un ottimo modo per creare un backup del repository originale poiché la copia clonata ha anche tutta la cronologia dei commit.

D # 31) Come scoprirai cosa sono stati modificati tutti i file in un particolare commit Git?

Risposta: Utilizzando il valore hash del particolare commit, è possibile eseguire il comando seguente per ottenere l'elenco dei file che sono stati modificati in un particolare commit:

git diff-tree -r {hash}

Questo elencherà tutti i file che sono stati modificati e anche i file che sono stati aggiunti. Il flag -r viene utilizzato per elencare i singoli file insieme al loro percorso invece di comprimerli solo nei nomi della directory principale.

Puoi anche usare il comando seguente:

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

–No-commit-id riqualificherà i numeri hash di commit in modo che vengano visualizzati nell'output. Mentre -name escluderà i percorsi dei file e fornirà solo i nomi dei file nell'output.

Q # 32) Qual è la differenza tra git checkout (nome ramo) e git checkout -b (nome ramo)?

Risposta: Il comando git checkout (nome filiale) passerà da un ramo all'altro.

Il comando git checkout -b (nome ramo) creerà un nuovo ramo e passerà anche ad esso.

Q # 33) Cos'è SubGit?

Risposta: SubGit è uno strumento utilizzato per la migrazione da SVN a Git. È sviluppato da una società chiamata TMate. Converte i repository SVN in Git e ti consente di lavorare su entrambi i sistemi contemporaneamente. Sincronizza automaticamente SVN con Git.

(Immagine fonte )

Puoi creare un mirror SVN || Git usando questo strumento. SubGit dovrebbe essere installato sul tuo server Git. Rileverà tutte le impostazioni del tuo repository SVN remoto, comprese le revisioni, i rami e i tag SVN, e le convertirà in commit Git.

Conserva anche la cronologia, incluso il monitoraggio dei dati di unione.

Q # 34) Puoi recuperare un ramo cancellato in Git?

Risposta: Si, puoi. Per recuperare un ramo cancellato, dovresti conoscere lo SHA in cima alla tua testa. SHA o hash è un ID univoco che Git crea con ogni operazione.

Quando elimini un ramo, ottieni SHA visualizzato sul terminale:

Ramo eliminato (era)

È possibile utilizzare il comando seguente per ripristinare il ramo eliminato:

git checkout -b

Se non conosci lo SHA per il commit sulla punta del tuo ramo, puoi prima usare il vai a reflog comando per conoscere il valore SHA e quindi applicare il comando di checkout sopra per ripristinare il tuo ramo.

Q # 35) Che cos'è git diff comando? In cosa è diverso da stato git?

Risposta: Git diff è un comando multiuso che può essere eseguito per mostrare le differenze tra due commit arbitrari, i cambiamenti tra l'albero di lavoro e un commit, i cambiamenti tra l'albero di lavoro e un indice, i cambiamenti tra due file, i cambiamenti tra l'indice e un albero, ecc.

Il stato git comando viene utilizzato per ispezionare un repository. Mostra lo stato della directory di lavoro e dell'area di staging. Elencherà i file che sono stati organizzati, che non sono stati organizzati e i file che non sono stati tracciati.

D # 36) Cosa contiene un oggetto Commit?

Risposta: L'oggetto commit contiene l'hash dell'oggetto albero di livello superiore, l'hash dei commit genitore (se presente), le informazioni sull'autore e sul committer, la data di commit e il messaggio di commit.

Puoi visualizzarlo tramite git log comando.

Esempio:

(Immagine fonte )

Q # 37) Cos'è git cherry-pick? Quali sono gli scenari in cui può essere utilizzato git cherry-pick?

Risposta: Git cherry-pick è un potente comando per applicare le modifiche introdotte da uno o più commit esistenti. Ti consente di scegliere un commit da un ramo e applicarlo a un altro.

git cherry-pick commitSha è il comando utilizzato per la selezione delle ciliegie. commitSha è il riferimento al commit.

Questo comando può essere utilizzato per annullare le modifiche. Ad esempio, se per errore hai effettuato un commit su un ramo sbagliato, puoi controllare il ramo corretto e selezionare il commit a cui dovrebbe appartenere.

Può essere utilizzato anche nella collaborazione in team. Possono esserci scenari in cui lo stesso codice deve essere condiviso tra due componenti del prodotto. In questo caso, se uno sviluppatore ha già scritto quel codice, l'altro può scegliere lo stesso.

La selezione della ciliegia è utile anche negli hotfix di bug in cui un commit di patch può essere selezionato direttamente nel ramo master per risolvere il problema il prima possibile.

D # 38) A cosa serve 'git reset'? Qual è la modalità predefinita di questo comando?

Risposta: Ripristina Git è un potente comando per annullare le modifiche locali allo stato di un repository Git. Questo comando reimposta l'attuale HEAD allo stadio specificato.

Reimposta sia l'indice che la directory di lavoro allo stato dell'ultimo commit. Git reset ha tre modalità: soft, hard e mixed. La modalità di funzionamento predefinita è mista.

D # 39) Qual è la differenza tra 'HEAD', 'albero di lavoro' e 'index'?

Risposta: L'albero di lavoro o lo spazio di lavoro è la directory contenente i file di origine su cui si sta attualmente lavorando.

L'indice è l'area di staging in Git in cui vengono preparati i commit. Si trova tra il commit e il tuo albero di lavoro. L'indice Git è un file binario di grandi dimensioni che arruola tutti i file nel ramo corrente, i loro nomi, checksum sha1 e timestamp.

Questo file è presente in /.git/index. HEAD è il riferimento o il puntatore all'ultimo commit nel ramo di checkout corrente.

Q # 40) Qual è la differenza tra rebase e merge? Quando dovresti rebase e quando dovresti unire?

Risposta: Entrambi i comandi rebase e merge vengono utilizzati per integrare le modifiche da un ramo all'altro ma in modo diverso.

Come si vede nelle due immagini sottostanti, supponi di avere dei commit (questo è prima di merge / rebase). Dopo l'unione, otterrai il risultato come una combinazione di commit. Unisce le cronologie di entrambi i rami e crea un nuovo 'commit di unione' nel ramo delle funzionalità.

D'altra parte, rebase sposterà l'intero ramo della caratteristica per iniziare dalla punta del ramo principale.

(Immagine fonte )

I commit avranno il seguente aspetto:

Il rebasing non è consigliato per le filiali pubbliche poiché crea archivi incoerenti. Tuttavia, il rebasing è una buona opzione per filiali private / singoli sviluppatori. Non è molto adatto per la modalità branch-per-feature. Ma se hai un modello branch-per-developer, il rebasing non è dannoso.

Inoltre, il rebase è un'operazione distruttiva, quindi il tuo team di sviluppo dovrebbe essere abbastanza esperto da applicarlo correttamente. In caso contrario, il lavoro impegnato può essere perso.

come rilevare i bug durante la build automation

Inoltre, il ripristino di un'unione è più semplice che il ripristino di un rebase. Quindi, se sai che ci possono essere possibilità di ripristino richiesto, allora dovresti usare l'unione.

Merge persevera la storia così com'è mentre rebase riscrive la storia. Quindi, se vuoi vedere la cronologia completamente come si è verificata, dovresti usare merge.

Q # 41) Qual è la sintassi per il rebase?

Risposta: La sintassi per il comando rebase è git rebase (new-commit)

Q # 42) Come rimuoverai un file da Git senza rimuoverlo effettivamente dal tuo filesystem locale?

Risposta: Puoi utilizzare l'opzione 'cache' per questo:

git rm -rf –cached $ FILES

Questo comando rimuoverà i file dal tuo repository senza eliminarli dal tuo disco.

D # 43) Qual è il modello di ramificazione comune in Git?

Risposta: Il modello di ramificazione comune è basato sul flusso git. Ha due rami principali, ovvero master e sviluppo.

• Il ramo principale contiene il codice di produzione. Tutto il codice di sviluppo viene unito al ramo principale ad un certo punto nel tempo.
• Il ramo di sviluppo contiene il codice di pre-produzione. Quando le funzionalità sono state completate, vengono unite al ramo principale, generalmente tramite una pipeline CI / CD.

Questo modello ha anche alcuni rami di supporto che vengono utilizzati durante il ciclo di sviluppo:

• Rami delle funzionalità / Rami degli argomenti: Sono utilizzati per sviluppare nuove funzionalità per le prossime versioni. Può diramarsi dal ramo di sviluppo e deve essere nuovamente unito al ramo di sviluppo. In genere, questi rami esistono solo nei repository degli sviluppatori e non in origine.
• Rami hotfix: Vengono utilizzati per il rilascio di produzione non pianificato quando è necessario correggere immediatamente qualsiasi bug critico nella versione live prod. Possono diramarsi dal master e devono essere fusi di nuovo in development e master.
• Filiali di rilascio: Sono utilizzati per la preparazione della nuova versione di produzione. Il ramo di rilascio ti consente di correggere piccoli bug e preparare i metadati per il rilascio. Possono derivare dallo sviluppo e devono essere fusi di nuovo in master e sviluppo.

Conclusione

Abbiamo esaminato le domande importanti che vengono generalmente poste durante le interviste a Git in questo tutorial.

Questo non solo ti aiuterà a prepararti per le prossime interviste, ma chiarirà anche i tuoi concetti git.

Tutto il meglio per la tua intervista!

Lettura consigliata

• Domande e risposte dell'intervista
• Alcune interessanti domande di intervista sul test del software
• Top 40 domande e risposte al colloquio di programmazione C.
• Le 40 principali domande e risposte dell'intervista J2EE da leggere
• Domande e risposte al colloquio di prova ETL
• 20+ Domande e risposte al colloquio di uscita più comuni
• Principali domande di colloquio su Oracle Forms and Reports
• Alcune domande e risposte sui test manuali complicati