Me voici en semaine 2. C’est une semaine à cheval entre 2 cours.

On termine doucement Git aujourd’hui et demain, et ensuite on passe à Uxcel - Mobile Design.

Avant d’aborder la partie documentation, j’ai appris à mes dépens qu’il n’est vraiment pas malin d’activer iCloud sur son Mac quand tu as des répertoires avec des dépôts Git actifs et synchronisés avec GitHub.

J’ai quelques dépôts où des fichiers ont disparu. Ce n’est pas très grave puisqu’on a un backup sur GitHub, mais le problème c’est quand tu as ignoré des fichiers avec .gitignore : les fichiers .env ne sont pas sauvegardés sur GitHub… Du coup, s’ils ne sont ni sur GitHub ni sur iCloud (je n’arrive pas à retrouver les fichiers cachés sur l’interface Cloud 😔), j’ai dû recréer tous mes fichiers .env.

J’ai passé une petite demi-heure pour analyser la situation et ensuite me résigner à recréer toutes les configs de zéro.

# Apprentissage du jour

Les concepts abordés aujourd’hui sont pour la plupart des commandes que l’on utilise peu souvent, voire plus du tout, mais l’instructeur a bien fait de les mentionner car si tu comptes contribuer à de vieux dépôts, il faudra sans doute les connaître. Il y a également les commandes tag, patch et cherry-pick qui, elles, correspondent davantage à une utilisation moderne.

## Git Tag

Comprendre les tags Git permettent de marquer des points importants dans l’histoire de ton projet. Il existe deux types de tags qui répondent à des besoins différents.

Les tags légers fonctionnent comme de simples marque-pages. Le tag est créé mais, mis à part la relation avec le commit, il ne stocke aucune autre information. C’est rapide et efficace pour un marquage temporaire.

Les tags annotés sont plus riches en informations. Le tag est créé et stocke des informations importantes qui pourront être consultées à posteriori, comme par exemple qui a créé le tag, quand il a été créé, et le message d’information du tag. Un tag annoté pourra être également signé et vérifié si nécessaire, ce qui est particulièrement utile pour les versions officielles d’un logiciel.

Un point important à retenir : les tags ne sont pas poussés automatiquement vers les dépôts distants. Il faut utiliser la commande push de manière explicite.

# Créer un tag (léger par défaut)
git tag <tagname> <sha>

# Créer un tag annoté avec message
git tag -a <tagname> -m "Message du tag" <sha>

# Lister tous les tags
git tag

# Filtrer les tags avec un pattern
git tag --list "v1.*"

# Supprimer un tag localement
git tag -d <tagname>

# Pousser un tag spécifique vers le dépôt distant
git push origin <tagname>

# Pousser tous les tags vers le dépôt distant
git push origin --tags

# Supprimer un tag sur le dépôt distant
git push -d origin <tagname>

### Dans quel cas utilise-t-on les tags ?

Le cas le plus logique est lorsqu’on veut étiqueter un commit comme étant une version spécifique (exemple v1.0.0). Il est dès lors possible sur GitHub (par exemple) de configurer des releases basées sur ces tags, permettant aux utilisateurs de télécharger des versions stables de ton logiciel.

## Git Patch

Le concept de patch dans Git te permet de faire quelque chose d’assez remarquable : commiter seulement une partie d’un fichier. Imagine que tu as modifié un fichier pour corriger deux bugs différents, mais que tu veux créer deux commits séparés pour une meilleure traçabilité. C’est exactement ce que permet le patching via la mise à l’index interactive.

### Comment fonctionne le patching ?

Lorsque tu veux patcher un fichier, l’éditeur va te proposer de revoir des morceaux de fichiers où sont identifiés des changements. Ces blocs sont appelés Hunk. C’est comme si Git découpait tes modifications en petites sections logiques.

Quand des modifications dans un Hunk sont séparées par des lignes non modifiées, il est possible de diviser ces derniers en Hunks plus petits. Si deux modifications qui ne sont pas nécessairement liées dans le code doivent être séparées, la possibilité de diviser automatiquement un Hunk ne sera pas proposée par Git, mais il sera possible de passer en mode édition afin de bien identifier ce qui doit être ajouté à l’index ou non.

L’interface interactive peut paraître déroutante lors de la première utilisation, mais elle devient rapidement intuitive. Voici les points importants à retenir :

# Lancer le mode interactif
git add -i

# Dans la console interactive
p    # pour lancer le patching

# Choisir les fichiers à patcher (1, 2, etc.)

# Dans la navigation d'un fichier que l'on modifie
?    # afficher l'aide complète
y    # ajouter le hunk à l'index
n    # ne pas ajouter le hunk à l'index
s    # diviser le hunk en parties plus petites
e    # passer en mode édition manuelle

## Cherry-pick

La commande cherry-pick est comme un copier-coller intelligent entre branches. Elle permet de copier un commit spécifique d’une branche vers une autre, sans avoir besoin de merger toute la branche. C’est particulièrement utile quand tu veux récupérer un correctif important qui a été fait sur une autre branche.

# Copier un commit spécifique vers la branche courante
git cherry-pick <sha>

# Copier une série de commits
git cherry-pick <sha-debut>..<sha-fin>

## Patching avancé

Cette partie concerne des fonctionnalités qui étaient plus utilisées avant l’avènement de plateformes comme GitHub, mais qui restent utiles dans certains contextes de collaboration.

### Diff Patch

Il est possible d’exporter le résultat de la commande diff afin de pouvoir le partager avec des collaborateurs externes. Cette approche était courante quand les développeurs collaboraient principalement par email. Tu peux également réimporter ces modifications dans un autre dépôt local.

# Exporter les différences entre deux commits
git diff fromcommit..tocommit > output.diff

# Importer les différences dans un dépôt local
# Attention : les changements ne sont pas indexés automatiquement
git apply output.diff

### Patching structuré

Il est également possible de créer un patching structuré, qui représente une évolution plus sophistiquée du concept précédent. L’avantage principal de cet export est de pouvoir réimporter dans un autre dépôt local toutes les informations exportées avec leurs métadonnées complètes. La seule chose qui ne sera pas conservée est l’identifiant SHA-1 des commits, car le commit parent ne sera plus le même dans le nouveau contexte.

À l’inverse de la commande précédente, le patching structuré applique directement les commits dans l’ordre et ils peuvent être immédiatement consultés grâce à la commande git log. C’est comme si tu transférais une série complète de commits d’un dépôt à un autre.

# Exporter chaque commit dans un fichier .patch numéroté
git format-patch fromcommit..tocommit -o folder

# Exporter tous les commits dans un fichier unique
git format-patch fromcommit..tocommit --stdout > output.patch

# Appliquer le patch à un dépôt local
git am folder/*.patch

Cette méthode était particulièrement utilisée pour la contribution à des projets open source via des listes de diffusion, avant l’adoption massive des pull requests sur les plateformes web.