top 40 git interview questions
Questions d'entrevue GIT les plus populaires avec des réponses et des exemples:
Ce didacticiel informatif comprend un ensemble de questions les plus fréquemment posées dans les entretiens Git ainsi que leurs réponses descriptives. Ces questions vous aideront certainement à vous préparer et à réussir toute interview Git.
Que vous soyez novice ou professionnel expérimenté, ces questions d'entretien sur Git et les réponses détaillées vous aideront certainement à enrichir votre connaissance du sujet et à exceller dans votre travail ainsi que dans les entretiens.
Commençons!!
Questions d'entretien GIT les plus fréquemment posées
Voici quelques-unes des questions d'entrevue GIT les plus fréquemment posées pour votre référence.
Q # 1) Qu'est-ce que Git?
Répondre: Git est un outil de contrôle de version distribué. Il est compatible avec les flux de travail non linéaires distribués car il offre une assurance des données pour la création de logiciels de bonne qualité.
Git est gratuit et open source. Il peut être utilisé pour presque tous les types de projets, qu'ils soient petits ou grands. Git est connu pour sa grande vitesse et son efficacité. Les référentiels Git sont très faciles à trouver et à accéder. En raison de ses certaines fonctionnalités, Git est très flexible, sécurisé et compatible avec votre système.
Q # 2) Qu'est-ce qu'un système de contrôle de version distribué?
Répondre: Un VCS distribué est un système qui ne dépend pas d'un serveur central pour conserver un fichier de projet et toutes ses versions. Dans le VCS distribué, chaque collaborateur ou développeur obtient une copie locale du référentiel principal et cela s'appelle un clone.
[image la source ]
Comme vous pouvez le voir dans le diagramme ci-dessus, chaque collaborateur gère un référentiel local sur ses machines locales. Ils peuvent valider et mettre à jour les référentiels locaux sans aucun problème.
À l'aide d'une opération d'extraction, un développeur peut mettre à jour son référentiel local avec les dernières modifications du serveur central. À l'aide de l'opération push, ils peuvent envoyer leurs modifications du référentiel local au serveur central.
Q # 3) Qui a créé Git?
Répondre: Git a été créé par Linus Torvalds en 2005 sur la route du développement du noyau Linux.
Q # 4) Quelle langue est utilisée dans Git?
Répondre: C est le langage de programmation sous-jacent dans lequel Git est écrit. Le langage C rend Git rapide en évitant les surcoûts d'exécution liés à d'autres langages de programmation de haut niveau.
Q # 5) Quels sont les avantages / principales fonctionnalités de Git?
Réponse: enrôlés ci-dessous sont les divers f eatures de Git.
(i) Gratuit et Open Source:
Git est délivré sous la licence open source GPL (General Public License). Vous n'avez rien à payer pour utiliser Git.
C'est absolument gratuit. Comme il est open-source, vous pouvez modifier le code source en fonction de vos besoins.
(ii) Vitesse:
Comme vous n'êtes pas obligé de vous connecter à un réseau pour exécuter toutes les actions, il effectue toutes les tâches rapidement. L'obtention de l'historique des versions à partir d'un référentiel stocké localement peut être cent fois plus rapide que de l'obtenir à partir du serveur distant.
Git est écrit en C, qui est le langage de programmation sous-jacent qui évite les surcharges d'exécution liées à d'autres langages de haut niveau.
(iii) Évolutif:
Git est hautement évolutif. Donc, si le nombre de collaborateurs augmente dans les temps à venir, alors Git peut facilement s'adapter à ce changement.
Malgré le fait que Git représente un référentiel entier, les données conservées côté client sont très petites car Git compacte les vastes données entières grâce à une technique de compression sans perte.
(iv) Fiable:
Comme chaque collaborateur a son propre référentiel local, en cas de panne du système, les données perdues peuvent être récupérées à partir de n'importe lequel des référentiels locaux. A tout moment, vous aurez une sauvegarde de tous vos fichiers.
(v) Sécurisé:
Git utilise la SHA1 (Secure Hash Function) pour nommer et identifier les objets dans son référentiel. Chaque artefact et commit sont additionnés de contrôle et récupérés via sa somme de contrôle lors de l'extraction.
L'historique Git est enregistré de manière à ce que l'ID d'une version spécifique (un commit en termes de Git) repose sur l'historique de développement total jusqu'à ce commit. Une fois qu'une version de fichier est poussée vers Git, il n'y a aucun moyen de la modifier sans être remarqué.
(vi) Économique:
Dans le cas d'un système de contrôle de version centralisé, le serveur central doit être suffisamment puissant pour répondre aux demandes de toute l'équipe. Ce n'est pas un problème pour les petites équipes, mais à mesure que l'équipe s'agrandit, les limitations matérielles du serveur peuvent constituer un obstacle aux performances.
Dans le cas des systèmes de contrôle de version distribués tels que Git, les membres de l’équipe n’ont pas besoin d’interagir avec le serveur, sauf quand ils doivent pousser ou extraire des modifications. Tout le gros du travail se produit du côté du client, ainsi le matériel du serveur peut être très simple.
(vii) Soutient le développement non linéaire:
Git fournit des branchements et des fusions rapides et contient des outils particuliers pour envisager et parcourir un historique de développement non linéaire. Une notion de base dans Git est qu'une modification sera fusionnée plus fréquemment qu'elle n'est écrite lorsqu'elle est envoyée à différents réviseurs.
Les branches Git sont extrêmement légères. Une branche dans Git ne fait référence qu'à un seul commit. La structure de branche complète peut être créée à l'aide des commits parents.
(viii) Branchement facile:
La gestion des succursales via Git est très simple et directe. Il suffit de quelques instants pour créer, supprimer et fusionner des branches. Les branches de fonctionnalités donnent un environnement isolé à chaque modification de votre base de code.
Lorsqu'un développeur a besoin de commencer à travailler sur quelque chose, quelle que soit la taille du travail, il crée une nouvelle branche. Cela garantit que la branche principale contient en permanence un code de qualité de production.
(ix) Développement distribué:
Git fournit à chaque développeur une copie locale de tout l'historique de développement, et les modifications sont clonées d'un tel dépôt à un autre. Ces modifications sont introduites en tant que branches de développement ajoutées et peuvent être fusionnées de la même manière qu'une branche développée localement.
(x) Compatibilité avec les systèmes ou protocoles actuels:
Les référentiels peuvent être publiés via HTTP, FTP ou un protocole Git au-dessus d'un socket simple ou ssh.
Q # 6) Comment créer un référentiel dans Git?
Répondre: Pour créer un référentiel, vous devez créer un répertoire pour le projet s'il n'existe pas déjà, puis exécuter simplement la commande ' git init ». En exécutant cette commande, un répertoire .git sera créé dans le répertoire du projet, c'est-à-dire que maintenant votre répertoire de projet est devenu un référentiel Git.
Q # 7) Qu'est-ce qu'un répertoire .git?
Répondre: Au moment où vous créez un référentiel, vous trouverez un répertoire .git présent à l'intérieur. Ce répertoire .git contient toutes les métadonnées du référentiel et maintient une trace de toutes les modifications apportées aux fichiers de votre référentiel, en conservant un historique des validations.
Toutes les informations concernant les commits, les hooks, les refs, les bases de données d'objets, les adresses de référentiels distants, etc. sont conservées dans ce dossier. C'est la partie la plus cruciale de Git. Lorsque vous clonez un référentiel Git sur votre machine locale, ce .git est le répertoire qui est réellement copié.
Q # 8) Que se passe-t-il si le répertoire .git est supprimé?
Répondre: Si le répertoire .git / est supprimé, vous perdrez l'historique de votre projet. Le référentiel ne sera plus sous contrôle de version.
Q # 9) Quelle commande est utilisée pour écrire un message de validation dans Git?
Répondre: La commande utilisée pour passer un message à un commit git est git commit -m «message de validation». Le drapeau m est utilisé pour transmettre un message de validation.
Q # 10) Qu'est-ce que le dépôt Git nu? En quoi est-il différent d'un référentiel Git standard / non nu?
Répondre: Les référentiels créés via git init sont les référentiels Git standard / non nus.
Dans le dossier de niveau supérieur d'un tel référentiel, vous trouverez deux choses:
- Un sous-répertoire .git conservant toutes les métadonnées et une trace de l'historique de votre dépôt.
- Un arbre de travail.
Les référentiels créés à l'aide git init –bare sont connus sous le nom de dépôts Git nus. Ils sont principalement utilisés pour le partage. Ils ne contiennent aucun arbre de travail. Ils conservent l'historique des révisions git de votre référentiel dans le dossier racine plutôt que de l'avoir dans le sous-dossier .git.
Il ne contient que des données de référentiel nues. C'est ainsi qu'un référentiel Git nu est différent d'un référentiel Git standard. De plus, un référentiel nu n'a pas de télécommande par défaut origine référentiel car il sert de référentiel d'origine pour plusieurs utilisateurs distants.
Puisqu'un référentiel nu ne contient aucun espace de travail, le git push et git pull les commandes ne fonctionnent pas sur un dépôt nu. Vous n'êtes pas obligé de valider les modifications d'un dépôt nu.
Q # 11) Mentionnez certains services d'hébergement de référentiel Git.
Répondre:
- Github
- Pikacode
- Gitlab
- Microsoft VSTS
- BitBucket
- GitEnterprise
- SourceForge
- Rampe de lancement
- Forcément
- Haricot
- On dirait
Q # 12) Nommez quelques opérations de base dans Git.
Répondre: Certaines opérations de base dans Git incluent:
- Initialiser
- Ajouter
- S'engager
- Pousser
- Tirer
Q # 13) Nommez quelques opérations avancées dans Git.
Répondre: Certaines opérations avancées dans Git sont:
- Ramification
- Fusion
- Rebasage
Q # 14) Comment allez-vous faire la distinction entre Git et SVN?
Répondre: Git est un contrôle de version distribué alors que SVN est centralisé. Cela conduit à de nombreuses différences entre les deux en termes de caractéristiques et de fonctionnalités.
Aller | SVN | |
---|---|---|
Teneur | Hash cryptographique SHA-1. | Aucun contenu haché. |
Architecture du serveur | L'ordinateur sur lequel votre Git a installé agit à la fois comme client et serveur. Chaque développeur dispose d'une copie locale de l'historique complet des versions du projet sur ses ordinateurs individuels. Les changements Git se produisent localement. Par conséquent, le développeur n'est pas obligé d'être connecté au réseau à tout moment. Uniquement pour les opérations push et pull, les développeurs auraient besoin d'une connexion Internet pour se connecter au serveur distant. | SVN a un client et un serveur séparés. Il n'est pas disponible localement. Vous devrez être connecté au réseau pour effectuer toute action. De plus, dans SVN, puisque tout est centralisé, donc en cas de panne ou de corruption du serveur central, cela entraînera une perte totale de données pour le projet. |
Ramification | Git est principalement préféré par les développeurs en raison de son modèle de branchement efficace. Les branches Git sont légères mais puissantes. Ce ne sont que des références à un commit particulier. Vous pouvez créer, supprimer ou modifier une branche à tout moment sans impact sur les autres commits. Ainsi, la fourche, la branche et la fusion sont faciles avec Git. | SVN a un modèle de branchement et de fusion compliqué et sa gestion prend du temps. Dans SVN, les branches sont générées sous forme de répertoires dans le référentiel. Cette structure de répertoires est principalement problématique. Lorsque la branche est prête, vous devez vous engager à nouveau sur le tronc. Étant donné que vous n’êtes pas le seul à fusionner les modifications, la version du camion peut ne pas être considérée comme une branche de développeur. Cela peut entraîner des conflits, des fichiers manquants et des modifications confuses dans votre branche. |
Contrôle d'accès | Git suppose que tous les contributeurs auront les mêmes autorisations. | SVN vous permet de définir des contrôles d'accès en lecture / écriture à chaque niveau de répertoire. |
Auditabilité | Dans Git, les modifications sont suivies au niveau du référentiel. Git ne se soucie pas trop de maintenir l'historique précis des modifications apportées dans votre référentiel. La nature distribuée de Git permet à tout collaborateur de modifier n'importe quelle partie de l'historique de son dépôt local. Avec Git, il est difficile de trouver un véritable historique des changements dans votre base de code. Par exemple, vous perdrez l'historique après avoir renommé dans Git. | Dans SVN, les modifications sont suivies au niveau du fichier. SVN maintient un historique des changements assez cohérent et précis. Vous pouvez récupérer exactement les mêmes données qu'à tout instant dans le passé. L'historique SVN est permanent et toujours défini. |
Exigences de stockage | Git et SVN stockent les données de la même manière. L'utilisation de l'espace disque est la même pour les deux. La seule différence vient en image dans le cas de fichiers binaires. Git n'est pas compatible avec les fichiers binaires. Il ne peut pas gérer le stockage de gros fichiers binaires. | SVN a un algorithme de compression xDelta qui fonctionne à la fois pour les fichiers binaires et texte. Ainsi, SVN peut gérer le stockage de gros fichiers binaires dans un espace comparativement moindre que Git. |
Convivialité | Git et SVN utilisent tous deux la ligne de commande comme interface utilisateur principale. Git est largement utilisé par les développeurs / utilisateurs techniques. | SVN est largement utilisé par des utilisateurs non techniques car il est plus facile à apprendre. |
Numéro de révision global | Pas disponible | Disponible |
Q # 15) Comment allez-vous différencier Git et GitHub?
Répondre: Git est un système de contrôle de version de haute qualité. Il est distribué dans la nature et est utilisé pour suivre les modifications du code source tout au long du développement logiciel. Il possède un modèle de branchement unique qui permet de synchroniser le travail entre les développeurs et de suivre les modifications dans tous les fichiers.
Les principaux objectifs de Git sont la vitesse, l'intégrité des données, la prise en charge des flux de travail distribués et non linéaires. Git est installé et maintenu sur la machine locale, au lieu du cloud.
GitHub est un service d'hébergement de référentiels Git basé sur le cloud qui rassemble des équipes. Il vous offre une interface graphique Web et fournit un contrôle d'accès et de nombreuses fonctionnalités de collaboration, des outils fondamentaux de gestion des tâches pour chaque projet.
De plus, GitHub est un open-source, c'est-à-dire que le code est conservé sur un serveur centralisé et accessible à tous.
Q # 16) Qu'est-ce qu'un conflit dans Git et comment le résoudre?
Répondre: Git dispose d'une fonctionnalité de fusion automatique qui gère les validations de fusion de manière autonome, à condition que les modifications de code se soient produites sur différentes lignes et dans différents fichiers.
comment déclarer la file d'attente en java
Mais, en cas de concurrence pour les commits où il y a des changements dans les mêmes lignes de code d'un fichier ou un fichier a été supprimé dans une branche mais existe et modifié dans une autre, Git est incapable de résoudre automatiquement les différences et déclenche ainsi un conflit de fusion.
Dans de tels cas, votre aide est nécessaire pour décider du code à inclure et du code à supprimer lors de la fusion finale.
Un conflit de fusion peut se produire lors de la fusion d'une branche, du rebasage d'une branche ou de la sélection d'un commit. Une fois qu'un conflit est détecté, Git met en évidence la zone en conflit et vous demande de le résoudre. Une fois le conflit résolu, vous pouvez procéder à la fusion.
Suivez les étapes ci-dessous pour résoudre un conflit de fusion de changement de ligne concurrent:
- Ouvrez Git Bash (ligne de commande Git).
- Utilisation CD commande pour accéder au référentiel Git local qui a le conflit de fusion.
- Utilisez le état git commande pour produire la liste des fichiers affectés par le conflit de fusion.
- Ouvrez l'éditeur de texte que vous utilisez et accédez au fichier présentant des conflits de fusion.
- Pour voir le début du conflit de fusion dans votre fichier, recherchez le marqueur de conflit dans le document<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> BRANCH-NAME.
- Choisissez si vous ne souhaitez conserver que les modifications de votre branche, conservez simplement les modifications de l'autre branche ou effectuez une nouvelle modification, qui peut inclure des modifications des deux branches. Effacer les marqueurs de conflit<<<<<<>>>>>> et effectuez les modifications dont vous avez besoin lors de la fusion finale.
- Utilisation ajoute git. pour ajouter ou mettre en scène vos modifications.
- Enfin, utilisez le git commit -m 'message' commande pour valider vos modifications avec un commentaire.
Pour résoudre le conflit de fusion de fichiers supprimé, vous devez suivre les étapes ci-dessous:
- Ouvrez Git Bash (ligne de commande Git).
- Utilisation CD pour accéder au référentiel Git local qui a le conflit de fusion.
- Utilisez le état git commande pour produire la liste des fichiers affectés par le conflit de fusion.
- Ouvrez l'éditeur de texte que vous utilisez et accédez au fichier présentant des conflits de fusion.
- Choisissez si vous souhaitez conserver le fichier supprimé. Vous pouvez vérifier les dernières modifications apportées au fichier supprimé dans votre éditeur de texte.
- Utilisation git ajouter pour ajouter le fichier supprimé au référentiel. Ou utiliser aller rm pour supprimer le fichier de votre référentiel.
- Enfin, utilisez le git commit -m 'message' commande pour valider vos modifications avec un commentaire.
Q # 17) Comment allez-vous réparer un commit cassé?
Répondre: Pour réparer un commit cassé ou pour changer le dernier commit, la méthode la plus pratique consiste à utiliser la commande ' git commit -amend » .
Il vous permet de combiner des modifications par étapes avec le commit précédent comme alternative pour créer un tout nouveau commit. Cela remplace le commit le plus récent par le commit modifié.
[image la source ]
Grâce à cette commande, vous pouvez également modifier le message de validation précédent sans changer son instantané.
Q # 18) Quelle est l'utilisation de git instaweb?
Répondre: C'est un script à travers lequel vous pouvez parcourir instantanément votre référentiel Git opérationnel dans un navigateur Web.
Ce script configure gitweb et un serveur Web pour parcourir le référentiel local. Il dirige automatiquement un navigateur Web et exécute un serveur Web via une interface dans votre référentiel local.
Q # 19) Qu'est-ce que git is-tree?
Répondre: «Git is-tree» signifie un objet d'arborescence comprenant le mode et le nom de tous les éléments ainsi que la valeur SHA-1 de l'objet blob ou de l'arborescence.
Q # 20) Existe-t-il un moyen de revenir sur un commit git qui a déjà été poussé et rendu public?
Répondre: Oui, pour corriger ou annuler une mauvaise validation, deux approches peuvent être utilisées en fonction du scénario.
Elles sont:
- Le moyen le plus évident est de faire un nouveau commit où vous supprimez le mauvais fichier ou corrigez les erreurs qu'il contient. Une fois cela fait, vous pouvez le pousser vers un référentiel distant.
- Une autre approche consiste à créer un nouveau commit pour annuler toutes les modifications qui ont été effectuées lors du mauvais commit précédent. Cela peut être fait via la commande git revert - ' git revert '
Q # 21) Comment allez-vous différencier git pull et git fetch?
Répondre: Git pull La commande extrait tous les nouveaux commits d'une branche spécifique dans le référentiel central et met à jour la branche cible de votre référentiel local.
Git chercher vise également la même chose, cependant, sa fonctionnalité sous-jacente est un peu différente. Lorsque vous effectuez une extraction git, tous les nouveaux commits d'une branche spécifique seront extraits dans votre référentiel central et ces modifications seront stockées dans une nouvelle branche de votre référentiel local. C'est ce qu'on appelle une branche récupérée.
Si vous souhaitez voir ces changements dans votre branche cible, vous devez effectuer un aller fusionner après git fetch. La branche cible sera mise à jour avec les dernières modifications uniquement après sa fusion avec la branche récupérée.
Ainsi, un git pull met la branche locale à jour avec sa version distante, alors qu'un git fetch ne change pas directement votre propre branche locale ou copie de travail sous réfs / têtes. Git fetch peut être utilisé pour mettre à jour vos branches de suivi à distance sous refs / télécommandes //.
En termes simples, git pull est égal à git fetch suivi d'une git merge .
Q # 22) Quelle est l'utilisation de la zone de transit ou de l'indexation dans Git?
Répondre: Du point de vue de Git, il existe trois zones dans lesquelles les modifications de fichier peuvent être conservées, à savoir le répertoire de travail, la zone de préparation et le référentiel.
Tout d'abord, vous apportez des modifications dans le répertoire de travail de votre projet stocké sur votre système de fichiers informatique. Toutes les modifications restent ici jusqu'à ce que vous les ajoutiez à une zone intermédiaire appelée zone de transit.
Vous pouvez mettre en scène les modifications en exécutant git add. commander. Cette zone de préparation vous donne un aperçu de votre prochain commit et vous permet essentiellement d'affiner vos commits. Vous pouvez ajouter ou supprimer des modifications dans la zone de préparation jusqu'à ce que vous soyez satisfait de la version que vous allez valider.
Une fois que vous avez vérifié vos modifications et approuvé l'étape modifiée, vous pouvez enfin valider les modifications. Lors de la validation, ils vont dans le référentiel local, c'est-à-dire dans le répertoire .git / objects.
Si vous utilisez l'interface graphique Git, vous verrez l'option pour organiser vos modifications. Dans la capture d'écran ci-dessous, le fichier sample.txt se trouve dans la zone des modifications non organisées, ce qui signifie qu'il se trouve dans votre répertoire de travail.
Vous pouvez sélectionner un fichier et cliquer sur «l'étape modifiée», puis il sera déplacé dans la zone de préparation. Par exemple , le fichier hello.txt est présent dans la zone de modification de l'étape (va valider). Vous pouvez vérifier vos modifications, puis procéder à une approbation, suivie d'une validation.
Le transfert est également appelé indexation car git gère un fichier d'index pour suivre les modifications de votre fichier dans ces trois zones. Les fichiers mis en scène se trouvent actuellement dans votre index.
Lorsque vous ajoutez des modifications à la zone de préparation, les informations de l'index sont mises à jour. Lorsque vous effectuez une validation, c'est en fait ce qui se trouve dans l'index qui est validé, et non ce qui se trouve dans le répertoire de travail. Vous pouvez utiliser le état git commande pour voir le contenu de l'index.
Q # 23) Qu'est-ce que Git Stash?
Répondre: GIT stash capture l'état actuel du répertoire de travail et de l'index et le conserve sur la pile pour une utilisation future. Il annule les modifications non validées (à la fois par étapes et non) de votre répertoire de travail et vous renvoie une arborescence de travail propre.
Vous pouvez travailler sur autre chose maintenant, et lorsque vous reviendrez, vous pourrez réappliquer ces modifications. Ainsi, si vous souhaitez passer d'un contexte à un autre sans perdre vos modifications actuelles, vous pouvez utiliser le stashing.
Il est utile dans le changement de contexte rapide, lorsque vous êtes à mi-chemin d'un changement de code que vous ne voulez pas valider ou annuler pour le moment et que vous avez autre chose sur lequel travailler. La commande à utiliser est git stash.
Q # 24) Qu'est-ce que le drop Git Stash?
Répondre: Lorsque vous n'avez plus besoin d'une réserve spécifique, vous pouvez la supprimer en exécutant commande git stash drop . Si vous souhaitez supprimer toutes les caches en une seule fois du référentiel, vous pouvez exécuter commande git stash clear .
Q # 25) Qu'est-ce que Git stash s'applique? En quoi est-ce différent de Git stash pop?
Répondre: Les deux commandes sont utilisées pour réappliquer vos modifications cachées et commencer à travailler là où vous les aviez laissées.
Dans git stash apply commande, les modifications seront réappliquées à votre copie de travail et seront également conservées dans la réserve. Cette commande peut être utilisée lorsque vous souhaitez appliquer les mêmes modifications cachées à plusieurs branches.
Dans git stash pop commande, les modifications sont supprimées de la réserve et sont réappliquées à la copie de travail.
Q # 26) Quelle est l'utilité de la commande git clone?
Répondre: La clone git crée une copie du référentiel Git central existant sur votre machine locale.
Q # 27) Quand la commande git config est-elle utilisée?
comment convertir char en int en c ++
Répondre: La git config La commande est utilisée pour définir les options de configuration de votre installation Git.
Par exemple, après avoir téléchargé Git, vous devez utiliser ci-dessous les commandes de configuration pour configurer respectivement le nom d'utilisateur et l'adresse e-mail de validation dans Git:
$ git config –global user.name «»
$ git config –global user.email ''
Ainsi, principalement, des éléments tels que le comportement du référentiel, les informations utilisateur et les préférences peuvent être configurés à l'aide de cette commande.
Q # 28) Comment identifierez-vous si la succursale est déjà fusionnée dans master?
Répondre:
En exécutant les commandes ci-dessous, vous pouvez connaître l'état de fusion des branches:
- git branch - maître fusionné: Cela listera toutes les branches qui ont été renommées en master.
- git branch –merged: Cela listera toutes les branches qui ont été fusionnées dans HEAD.
- git branch –no-merged: Cela listera toutes les branches qui ne sont pas encore fusionnées.
Par défaut, cette commande indique le statut de fusion des branches locales uniquement. Si vous souhaitez connaître l'état de fusion des succursales locales et distantes, vous pouvez utiliser -à drapeau. Si vous souhaitez vérifier uniquement les branches distantes, vous pouvez utiliser -r drapeau.
Q # 29) Que sont les Hooks dans Git?
Répondre: Les hooks Git sont certains scripts que Git exécute avant ou après un événement tel que commit, push, update ou receive. Vous trouverez le dossier ‘hooks’ dans le répertoire .git de votre référentiel local. Vous trouverez les scripts intégrés ici pré-commit, post-commit, pré-push, post push.
Ces scripts sont exécutés localement avant ou après l'occurrence d'un événement. Vous pouvez également modifier ces scripts en fonction de vos besoins et Git exécutera le script lorsque cet événement particulier se produira.
Q # 30) Quelle est l'utilité de git fork? En quoi le forking est-il différent du clonage?
Répondre: Forcer un projet signifie créer une copie distante côté serveur du référentiel d'origine. Vous pouvez renommer cette copie et commencer à faire un nouveau projet autour de cela sans affecter le projet d'origine. Le fork n'est pas le concept de base de Git.
L'opération de fork est utilisée par le workflow Git et cette idée existe plus longtemps pour les logiciels libres et open source comme GitHub. En règle générale, une fois que vous avez forké le projet, vous contribuerez rarement à nouveau au projet parent.
Par exemple, OpenBSD est un système d'exploitation open source de type Unix qui a été développé en forçant NetBSD, un autre système d'exploitation open source de type Unix.
Cependant, dans le fork, une connexion directe existe entre votre copie forkée et le référentiel d'origine. À tout moment, vous pouvez contribuer au projet d'origine à l'aide des pull requests.
Dans la copie fourchue, toutes les données principales telles que les codes et les fichiers sont copiées à partir du référentiel d'origine, cependant, les branches, les demandes d'extraction et d'autres fonctionnalités ne sont pas copiées. Le fork est un moyen idéal pour la collaboration open source.
Le clonage est essentiellement un concept Git. Un clone est une copie locale de tout référentiel distant. Lorsque nous clonons un référentiel, l'ensemble du référentiel source ainsi que son historique et ses branches sont copiés sur notre machine locale.
Contrairement au forking, il n'y a pas de connexion directe entre le référentiel cloné et le référentiel distant d'origine. Si vous souhaitez effectuer des pull requests et revenir au projet d'origine, vous devez vous faire ajouter en tant que collaborateur dans le référentiel d'origine.
Le clonage est également un excellent moyen de créer une sauvegarde du référentiel d'origine car la copie clonée a également tout l'historique des validations.
Q # 31) Comment découvrirez-vous ce que tous les fichiers ont été modifiés dans un commit Git particulier?
Répondre: En utilisant la valeur de hachage du commit particulier, vous pouvez exécuter la commande ci-dessous pour obtenir la liste des fichiers qui ont été modifiés dans un commit particulier:
git diff-tree -r {hachage}
Cela listera tous les fichiers qui ont été modifiés, ainsi que les fichiers qui ont été ajoutés. L'indicateur -r est utilisé pour lister les fichiers individuels avec leur chemin au lieu de les réduire dans leurs noms de répertoire racine uniquement.
Vous pouvez également utiliser la commande ci-dessous:
git diff-tree –no-commit-id –name-only -r {hash}
–No-commit-id entraînera de nouveau les numéros de hachage de validation à entrer dans la sortie. Alors que, -name exclura les chemins de fichiers et ne donnera que les noms de fichiers dans la sortie.
Q n ° 32) Quelle est la différence entre git checkout [nom de la branche] et git checkout -b [nom de la branche]?
Répondre: La commande git checkout [nom de la branche] passera d'une succursale à une autre.
La commande git checkout -b [nom de la branche] créera une nouvelle branche et y basculera également.
Q # 33) Qu'est-ce que SubGit?
Répondre: SubGit est un outil utilisé pour la migration SVN vers Git. Il est développé par une société appelée TMate. Il convertit les référentiels SVN en Git et vous permet de travailler simultanément sur les deux systèmes. Il synchronise automatiquement le SVN avec Git.
[image la source ]
Vous pouvez créer un miroir SVN || Git en utilisant cet outil. SubGit doit être installé sur votre serveur Git. Il détectera tous les paramètres de votre référentiel SVN distant, y compris les révisions, branches et balises SVN, et les convertira en commits Git.
Il préserve également l'historique, y compris le suivi des données de fusion.
Q # 34) Pouvez-vous récupérer une branche supprimée dans Git?
Répondre: Oui, vous pouvez. Pour récupérer une branche supprimée, vous devez connaître le SHA par le haut de votre tête. SHA ou hash est un ID unique que Git crée à chaque opération.
Lorsque vous supprimez une branche, vous obtenez le SHA affiché sur le terminal:
Branche supprimée (était)
Vous pouvez utiliser la commande ci-dessous pour récupérer la branche supprimée:
git checkout -b
Si vous ne connaissez pas le SHA du commit au bout de votre branche, vous pouvez d’abord utiliser le aller reflog pour connaître la valeur SHA, puis appliquer la commande d'extraction ci-dessus pour restaurer votre branche.
Q # 35) Qu'est-ce que git diff commander? En quoi est-ce différent de statut git?
Répondre: Git diff est une commande multi-usage qui peut être exécutée pour afficher les différences entre deux commits arbitraires, les changements entre l'arbre de travail et un commit, les changements entre l'arbre de travail et un index, les changements entre deux fichiers, les changements entre l'index et un arbre, etc.
La état git La commande est utilisée pour inspecter un référentiel. Il montre l'état du répertoire de travail et de la zone de transit. Il répertorie les fichiers qui ont été mis en scène, qui n’ont pas été mis en scène et les fichiers qui ne sont pas suivis.
Q # 36) Que contient un objet Commit?
Répondre: L'objet de validation contient le hachage de l'objet d'arborescence de niveau supérieur, le parent valide le hachage (le cas échéant), les informations sur l'auteur et le validateur, la date de validation et le message de validation.
Vous pouvez voir cela à travers le journal git commander.
Exemple:
[image la source ]
Q # 37) Qu'est-ce que git cherry-pick? Quels sont les scénarios dans lesquels git cherry-pick peut être utilisé?
Répondre: Sélection de cerises Git est une commande puissante pour appliquer les changements introduits par un ou plusieurs commits existants. Il vous permet de choisir un commit dans une branche et de l'appliquer à une autre.
git cherry-pick commitSha est la commande utilisée pour le cherry-picking. commitSha est la référence de commit.
Cette commande peut être utilisée pour annuler les modifications. Par exemple, si par erreur vous avez fait un commit sur une mauvaise branche, alors vous pouvez vérifier la bonne branche et choisir le commit à l'endroit où il devrait appartenir.
Il peut également être utilisé en collaboration d'équipe. Il peut y avoir des scénarios où le même code doit être partagé entre deux composants du produit. Dans ce cas, si un développeur a déjà écrit ce code, l'autre peut choisir le même.
La sélection de cerises est également utile dans les correctifs de bogues où un commit de correctif peut être sélectionné directement dans la branche principale pour résoudre le problème dès que possible.
Q # 38) À quoi sert «git reset»? Quel est le mode par défaut de cette commande?
Répondre: Réinitialiser Git est une commande puissante pour annuler les modifications locales de l'état d'un dépôt Git. Cette commande réinitialise la HEAD actuelle à l'étape spécifiée.
Il réinitialise à la fois l'index et le répertoire de travail à l'état de votre dernier commit. Git reset a trois modes, à savoir soft, hard et mixed. Le mode de fonctionnement par défaut est mixte.
Q # 39) Quelle est la différence entre «HEAD», «working tree» et «index»?
Répondre: L'arborescence de travail ou l'espace de travail est le répertoire contenant les fichiers source sur lesquels vous travaillez actuellement.
L'index est la zone de préparation dans Git où les commits sont préparés. Il se situe entre le commit et votre arbre de travail. L'index Git est un gros fichier binaire qui répertorie tous les fichiers de la branche actuelle, leurs noms, les sommes de contrôle sha1 et les horodatages.
Ce fichier est présent sur /.git/index. HEAD est la référence ou le pointeur vers le dernier commit dans la branche d'extraction actuelle.
Q # 40) Quelle est la différence entre le rebase et la fusion? Quand faut-il rebaser et quand fusionner?
Répondre: Les commandes rebase et merge sont utilisées pour intégrer les modifications d'une branche à une autre, mais d'une manière différente.
Comme on le voit dans les deux images ci-dessous, supposons que vous ayez des validations (c'est avant la fusion / rebase). Après la fusion, vous obtiendrez le résultat sous la forme d'une combinaison de validations. Il lie les historiques des deux branches et crée un nouveau «commit de fusion» dans la branche de fonctionnalité.
D'autre part, le rebase déplacera toute la branche de fonctionnalité pour commencer à la pointe de la branche principale.
[image la source ]
Les validations ressembleront à:
Le rebasage n'est pas recommandé pour les branches publiques car il crée des référentiels incohérents. Cependant, le rebasage est une bonne option pour les succursales privées / les développeurs individuels. Il n'est pas très adapté au mode branche par fonction. Mais si vous avez un modèle de branche par développeur, le rebasage ne fait aucun mal.
De plus, le rebase est une opération destructrice, votre équipe de développement doit donc être suffisamment qualifiée pour l'appliquer correctement. Sinon, le travail engagé peut être perdu.
De plus, il est plus facile d'annuler une fusion que d'annuler un rebase. Donc, si vous savez qu'il peut y avoir des possibilités de restauration requises, vous devez utiliser la fusion.
Merge persévère l'histoire telle qu'elle est alors que rebase réécrit l'histoire. Ainsi, si vous voulez voir l'historique complètement tel qu'il s'est produit, vous devez utiliser la fusion.
Q # 41) Quelle est la syntaxe du rebasage?
Répondre: La syntaxe de la commande rebase est git rebase [nouveau-commit]
Q # 42) Comment allez-vous supprimer un fichier de Git sans le supprimer réellement de votre système de fichiers local?
Répondre: Vous pouvez utiliser l’option «mis en cache» pour cela:
git rm -rf - $ FILES en cache
Cette commande supprimera les fichiers de votre référentiel sans les supprimer de votre disque.
Q # 43) Quel est le modèle de branchement courant dans Git?
Répondre: Le modèle de branchement commun est basé sur le git-flow. Il a deux branches principales à savoir le maître et le développement.
- La branche principale contient le code de production. Tout le code de développement est fusionné dans la branche principale à un moment donné.
- La branche de développement contient le code de pré-production. Lorsque les fonctionnalités sont terminées, elles sont fusionnées dans la branche principale, généralement via un pipeline CI / CD.
Ce modèle a également quelques branches de support qui sont utilisées pendant le cycle de développement:
- Branches de fonction / Branches de sujet: Ils sont utilisés pour développer de nouvelles fonctionnalités pour les versions à venir. Il peut bifurquer de la branche de développement et doit être fusionné dans la branche de développement. Généralement, ces branches n'existent que dans les référentiels de développeurs et non à l'origine.
- Branches de correctifs: Ils sont utilisés pour une version de production non planifiée lorsqu'il est nécessaire de corriger immédiatement tout bogue critique dans la version de production en direct. Ils peuvent bifurquer de master et doivent être fusionnés à nouveau dans develop et master.
- Branches de sortie: Ils sont utilisés pour la préparation d'une nouvelle version de production. La branche Release vous permet de corriger des bogues mineurs et de préparer les métadonnées pour la publication. Ils peuvent bifurquer du développement et doivent être fusionnés à nouveau dans master et se développer.
Conclusion
Nous avons parcouru les questions importantes qui sont généralement posées lors des entretiens Git dans ce didacticiel.
Cela vous aidera non seulement à vous préparer pour les entretiens à venir, mais clarifiera également vos concepts git.
Tout le meilleur pour votre entretien!
lecture recommandée
- Questions et réponses d'entrevue
- Quelques questions d'entretien intéressantes sur les tests de logiciels
- Top 40 des questions et réponses d'entrevue de programmation C
- Top 40 des questions et réponses d'entrevue J2EE les plus populaires à lire
- Questions et réponses d'entrevue de test ETL
- Plus de 20 questions et réponses d'entrevue de départ les plus fréquemment posées
- Questions d'entretien les plus fréquentes sur Oracle Forms and Reports
- Quelques questions et réponses difficiles sur les tests manuels