La formation GIT est terminée. Ready pour la prochaine.

Voici le dernier jour de la formation GIT, en tout 7h30 de formation théorique en 7 jours. J’ai organisé la pratique en sessions de 1 à 2h par jour ce qui m’a permis de bien réviser chaque partie. J’ai aussi reproduit de petits questionnaires à choix multiples sur chaque sujet à la fin du cours. Me voilà armé avec des compétences supplémentaires sur GIT mais le plus important est de pouvoir les exploiter pendant toute la durée de la formation.

# Apprentissage du jour

## Petite astuce sur macOS (non, ce n’est pas du Git)

Afin d’afficher les fichiers cachés sur macOS, il faut utiliser la combinaison suivante : Command+Shift+. dans le Finder

## GIT Rebase

Alternative à la commande merge qui doit être utilisée avec parcimonie, surtout lorsqu’on travaille en équipe. La règle d’or est de ne l’utiliser qu’en local avec des branches qui ne seront pas partagées avec tes collègues.

Rebase est utilisé afin de récupérer un ou plusieurs commits pour les transposer sur une autre branche. Alors que merge va créer un commit pour réunir les informations, rebase va quant à lui récupérer les informations et les ajouter à la suite.

git rebase upstream branch

## Interactive rebase

Il est possible d’effectuer un rebase de manière interactive, il sera dès lors possible de choisir ce que l’on fait avec chaque commit avant de finaliser le rebase.

On a les possibilités suivantes :

• pick : ajoute le commit au rebase
• drop : exclut le commit
• reword : afin de pouvoir changer le message du commit
• edit : afin de pouvoir changer le commit (–amend)
• squash : qui permet de fusionner des commits afin d’en avoir qu’un seul
• fixup : équivalent à squash mais qui ne garde pas les messages du commit

Attention, le rebase est une action destructive donc comme mentionné plus haut, à n’utiliser qu’en cas de réel besoin lorsqu’on collabore avec d’autres personnes !!

git rebase -i <sha>

## Pull rebase

Permet de récupérer des données et rebase en même temps (alternative à git pull qui lui merge).

## Investigation

Les deux commandes suivantes sont super intéressantes et sont utilisées en conjonction avec git log afin de diagnostiquer les problèmes que l’on aurait dans le code.

### Blame

Permet de connaître dans un fichier quels ont été les changements apportés à une ligne de code.

git blame file.txt
# Diverses options
-w # ignore les changements des espaces blancs
--date=short # permet de changer le format de la date
-s # montre que les informations du commit
-L # permet de cibler des zones par exemple 
-L 100,125 # affiche les lignes de 100 à 125
-L 100,+15 # affiche 15 lignes à partir de la ligne 100

### Bisect

Bisect est la commande de diagnostique suprême car elle permet de naviguer dans les commits afin de trouver quand un changement a été fait. Généralement on utilise git bisect lorsqu’on investigue des problèmes complexes et que l’on veut connaître quand un bug a été introduit dans l’historique.

Pour ce faire on a les commandes suivantes :

git bisect start # lance l'analyse
git bisect bad # permet d'indiquer que le commit actuel ou celui analysé par bisect contient le problème
git bisect good # permet d'indiquer que le commit actuel (si pas de commit donné) ou le commit passé en argument ne contient pas le bug

Ce que bisect va faire concrètement, il va calculer le nombre de commits entre la bonne version connue et la mauvaise version connue et va recharger des commits de manière structurée que tu pourras tester ou recompiler. À chaque fois que tu auras identifié si le commit contient ou ne contient pas le bug, bisect va proposer une nouvelle option. À chaque fois qu’on va dire si le bug existe ou non, bisect réduira de plus en plus les possibilités et finalement proposera le commit qui sera le plus susceptible d’avoir introduit le bug. C’est la rolls pour les experts 😅