4eme journée d’apprentissage. On continue avec GIT et ce sera jusque mardi prochain. Il y a pas mal de redondant que je connaissais déjà mais il y a des trucs cool que j’ai appris. Voyons tout cela.

Au fait, j’ai décidé de créer chaque jour, un visuel simple sur PICO-8 https://www.lexaloffle.com/pico-8.php, une console de jeu imaginaire. Ceci pour deux choses essentiellement.

Premièrement par ce que j’ai toujours voulu créer un jeu vidéo depuis tout petit et que m’y donner à plein temps n’est pas faisable donc j’explore un petit concept chaque jour sur quelque chose qui est simple. Deuxièmement cela m’aide à partager un peu avec toi mon parcours chaque jour.

# Apprentissage du jour

3 blocs super intéressants ☺️

## Git Merge

Important à savoir, lorsqu’on veut effectuer un merge, il faut se positionner dans la branche qui va recevoir le merge, donc si je veux merge dev dans main, je dois me positionner dans main.

En cas de conflit, le merge ne se fait pas et il est nécessaire de résoudre ces conflits et ce de 3 manières:

• On aborte le merge avec la commande –abort

  Attention si l’on aborte pas le merge et l’on commit juste après, l’on se retrouve avec des artefacts dans les fichiers et il faudra aller dans chaque fichier les modifiers

• On adapte manuellement chaque fichier avec conflits et on effectue un git add <nom du fichier> dès que l’on a résolu le conflit
• On utilise un outil externe pour effectuer la résolution de conflit (vscode, vim, etc)
  • il existe une commande pour utiliser les outils graphiques git mergetool --tool=code(code pour vscode)

Un conflit en git est une modification de texte sur la même ligne et dans le même fichier et ce dans les deux branches. Etant donné que git ne sait pas quelle est la modification à garder, il s’arrête et demande notre aide.

Très important! Il y a plusieurs stratégies afin de diminuer les risques de conflits:

• Garder les lignes très courtes
• créer des commits atomiques (voir l’article de hier)
• Eviter de ajouter/modifier/supprimer des espaces, tabulations ou lignes si ce n’est pas nécessaire.

Dernièrement, git merge est utile en cas ou l’on veut mettre à jour une branche de développement avec des nouveaux ajouts de la branche main par example, cela s’appelle faire du tracking sur la branche. Pourquoi c’est utile? Cela permet de réduire les potentiels gap et conflit lorsqu’on veut fusionner les deux branches en fin de développement.

## Git Reset

Il existe 3 types de reset

### Point d’attention:

• si l’on effectue un soft reset et que l’on veut retourner en arrière, l’on doit réxécuter à nouveau un soft reset afin de retourner à l’état initial. Si l’on fait un mixed et ensuite un soft sur HEAD, on a pas le même résultat, attention donc

# on récupère la liste des commit via git log
# la commande pour avoir ceci est la suivante=
git log --oneline --graph --all --decorate

* 62a8529 (HEAD -> main) Merge branch 'cloned_main'
* 7bab2ad Add empty folder in the repo
* c274c27 Start tracking congif.txt
* 5b1828d Excludes files folder but not config in .gitignore
* 3b8b39c Revert "excludes logs folder except config in .gitignore"
* dc1b7cf excludes logs folder except config in .gitignore
* ef048cd Reapply "add file2.txt to the repository"
* 7dc17df Revert "add file2.txt to the repository"
* a251b56 Fix the error in the words on text
* 0619e96 add file2.txt to the repository
* a161657 ajout de gitignore au repos
* ddcac5d supppression du DS_Store du repo

git reset --soft 3b8b39c # il s'agit de la ou l'on veut être 

git reset --soft 62a8529 # il s'agit du point de départ en considérant que l'on veut revenir à HEAD

## Git stash

J’avais déjà utilisé stash dans quelques projets, via l’interface graphique de VScode mais je n’avais pas compris tout son pouvoir.

Git stash est très pratique si l’on doit changer rapidement de contexte dans un projet mais que l’on en veut pas perdre le travail en cours. Il agit comme une réserve ou cachette afin de garder le code pour y revenir plus tard. Il agit comme une pile, le dernier élément à y entrer est placé tout au dessus.

Avant aujourd’hui, mon approche était de sauver le travail en cours dans un commit (même si partiel), corriger et commit et, ensuite reprendre le travail en cours dans un nouveau commit… What a noob! (je l’ai entendu oui 😅)

Ceux plus expérimentés pourraient vouloir créer une branche avec les commit, ensuite switch de branche et travailler sur l’urgence par exemple et ensuite revenir sur cette nouvelle branche…

Ceux qui ont suivi la formation feront plutôt:

git stash push #l'on met de côté le travail actuel
# on corrige du code, on le teste
# on commit les corrections par exemple

# et l'on revient à ce que l'on fesait avant avec les commandes pop ou apply
git stash pop #sans la ref, il reprend celui en haut de la pile et le supprime de la pile
git stash apply #sans la ref, il prend le premier de la pile mais garde la reference dans la pile

# Et ils continueront à travailler

# Autres commandes utiles
git stash drop <ref> # il supprime la ref de la pile
git stash clear # il supprime tout de la pile

Dans la doc l’on parle aussi de git stash push --stagedqui permet de garder les fichiers dans l’index. Prenons l’exemple que l’on travaille sur une partie du code mais l’on identifie un fix assez rapide sur une autre partie du code qui n’est pas dans le scope actuel. Au lieu de laisser le fix pour une prochaine fois, l’on peut corriger le fix et le mettre dans la pile, comme ça il pourra être ressorti plus tard. A garder en tête pour sur ☺️.

A demain.