QCM sur GIT – Gestionnaire de version – Partie 13

De plus en plus d’entreprises et d’organisations abandonnent les systèmes de contrôle de version centralisés SVN, au profit des systèmes distribués comme GIT, de nombreux développeurs découvrent leur première introduction sur Git, GitHub et GitLab. Ces 10 questions vous aident à tester vos connaissances sur divers sujets, notamment l’utilisation des commandes Git de base, l’historique, etc…
 
 

1. Après avoir apporté des modifications à un référentiel local, vous exécutez la commande suivante. Qu’est-ce que cela va faire ?
git commit -a -m "Refactoriser la base de code"

A Rien, vous ne pouvez pas utiliser plusieurs options dans la même commande.

B Ajoute tous les nouveaux fichiers à la zone de transit (staging area ou index)

C Commite tous les nouveaux fichiers avec un message

D Ajoute tous les fichiers modifiés à la zone de transit (staging area ou index), puis les commite avec un message

D
Ajoute tous les fichiers modifiés à la zone de transit (staging area ou index), puis les commite avec un message

 

2. Où sont stockés les fichiers avant qu’ils ne soient transférés dans le référentiel local ?

A Fichiers archivés

B Documents git

C Zone de transit (staging area ou index)

D Le cache git

C
Les fichiers sont stockés dans la zone de transit (staging area ou index) avant qu’ils ne soient transférés dans le référentiel local.

 

3. Quelles commandes utiliseriez-vous pour forcer l’écrasement de vos fichiers locaux par la branche master ?

A

git pull --all
git reset --hard origin/master

B

git pull -u origin master
git reset --hard master

C

git pull origin master
git reset --hard origin/myCurrentBranch

D

git fetch --all
git reset --hard origin/master
D
La commande pull est fetch suivie de merge ou rebase (dans ce cas, merge). Nous ne voulons pas fusionner. Fusionner serait une action sur notre référentiel. Nous voulons juste écraser nos fichiers locaux.

 

 
 

4. Vous constatez que votre projet possède un tag et une branche tous deux nommés push-feature, ce qui crée une certaine confusion lorsque vous essayez d’afficher une référence donnée. Comment pouvez-vous spécifier la branche que vous souhaitez consulter ?

A utiliser $ git show refs/push-feature

B utiliser $ git show push-feature

C utiliser $ git show heads/refs/push-feature

D utiliser $ git show refs/heads/push-feature

D
Utiliser $ git show refs/heads/push-feature.

 

5. Votre chef d’équipe a besoin d’une liste de tous les commits qui seront déplacés avant d’effectuer un rebase. Quelle commande pouvez-vous utiliser pour accéder à cette information ?

A $ git rebase -log

B $ git rebase -i

C $ git rebase -verbose

D $ git rebase -all

B
$ git rebase -i <commit> Ajoutez un hash de commit et une liste de tous les commits jusqu’au dernier commit sera affichée.

 

6. Que fait l’opération à partir des commandes Git ci-dessous ?
git bisect start
git bisect bad 54b723ceabc538666f209d911017c592
git bisect good 536cbb6268350295550de7d5d240801

A Il exécute une fusion d’un bon commit découvert à l’aide d’un mauvais commit connu et d’un bon commit connu.

B Il marque un commit pour suppression en utilisant un bad commit connu et un good commit connu pour déterminer quel commit a introduit un bogue.

C Il définit un mauvais commit et réinitialise le HEAD à l’aide d’un bad commit connu et d’un good commit connu.

D Il effectue une recherche binaire en utilisant un mauvais commit connu et un bon commit connu pour déterminer quel commit a introduit un bogue.

D
Il effectue une recherche binaire en utilisant un mauvais commit connu et un bon commit connu pour déterminer quel commit a introduit un bogue.

 

 
 

7. Dans une situation où vous avez plusieurs commits pour une seule tâche, quelle est la manière la plus efficace de restructurer votre historique de commits ?

A Choisir les commits liés à la tâche dans une autre branche.

B Supprimer les commits de la tâche et recommencer avec un nouveau message.

C Rassembler les commits liés en un seul commit cohérent.

D Stocker les commits liés sous un nouveau hash.

C
Dans Git, le terme « squash » signifie que l’on combine plusieurs commits en un seul. Vous pouvez le faire à tout moment (en utilisant la fonction « Rebase interactive » de Git), bien que cela soit le plus souvent fait lors de la fusion de branches.

Veuillez noter qu’il n’existe pas de commande git squash autonome. Le squash est plutôt une option lors de l’exécution d’autres commandes Git comme le rebasement interactif ou la fusion.

 

8. Quelle affirmation est vraie à propos de la commande git push ?

A Par défaut, un push n’envoie pas de tags au dépôt distant.

B Les commits ne peuvent être taggés que lorsqu’ils sont créés.

C Les tags sont poussés vers le dépôt distant avec leurs commits respectifs.

D Seules les tags annotés sont automatiquement poussés vers le dépôt distant avec un commit.

A
Par défaut, un push n’envoie pas de tags au dépôt distant.

 

9. Après avoir poussé des commits vers le dépôt distant pour la première fois à l’aide de la commande ci-dessous, quelle commande abrégée pouvez-vous utiliser à l’avenir ?
git push -u origin master

A $ git push master

B $ git push origin

C Même chose que précédemment, $ git push -u origin master

D $ git push

D
La commande abrégée que vous pouvez utiliser à l’avenir est $ git push.

 

 
 

10. Comment créer un raccourci ou une commande personnalisée dans votre environnement Git ?

A Exécutez $ git hotfix avec le nom du raccourci.

B Attribuer un raccourci ou une commande à l’aide du fichier d’options git.

C Utilisez la commande $ git custom-key.

D Créer un alias à l’aide de la commande $ git config.

D
Vous pouvez utiliser la commande $ git config pour créer un alias de commande dans GIT.

 

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *