Skip to main content

Alessandros's Blog - Build with freedom. Share with purpose

23 Mai 2025 - GIT en équipe et un peu plus d’explication sur mon schéma de formation

Dernier jour de la semaine !

Voici déjà la fin de la première semaine de cette aventure. Une semaine facile avec très peu de contenu structuré l’après-midi. D’ailleurs, je me rends compte que je ne t’avais pas expliqué comment étaient structurées mes journées. Cela t’aidera à comprendre pourquoi je dis que le contenu de l’après-midi était non structuré.

Lors de l’établissement du plan de formation, j’ai identifié des points importants à travailler :

  • La théorie, essentielle
  • La pratique, plus qu’obligatoire
  • Le processus de mise en place de projets freelance/développeur, un must

Les 3 points sont importants lors d’une reconversion :

  • La théorie nous permet d’apprendre de nouveaux concepts
  • La pratique sert à les mettre en pratique
  • Le processus est quant à lui nécessaire car, après avoir appris à coder et avoir pratiqué, il faut vendre ou se vendre. Si l’on n’a pas pris le temps de travailler cet aspect, il se peut que l’on doive y consacrer du temps après la formation

Dans mon cas, le processus identifié dans ma réflexion tourne autour de la création d’un portfolio d’applications mais pas que 😉. Il est aussi important de pouvoir être capable de construire une étude de cas et de travailler sur les étapes importantes de la gestion d’un projet, voire un contrat en freelance.

Il est donc important de pouvoir effectuer ces 3 activités de manière régulière, mais je ne voulais pas laisser le processus à la fin. J’ai donc décidé de mettre les 3 dans une journée et ce jusqu’à la fin du parcours.

Voici comment j’ai planifié ma journée type (petite référence à Git 😅) :

# Journée Type

%%{init: {'gitGraph': {'mainBranchName': 'journee'} }}%%
gitGraph
    commit id: "00h00"
    branch journee_type
    checkout journee_type
    commit id: "8h : Théorie (1h)"
    commit id: "9h : Pratique (2h)"
    commit id: "11h : Activités physiques (1h)"
    commit id: "13h : Processus (4h)"
    commit id: "17h : Dev blog"
    checkout journee
    commit id: "18h : Quality Time"
    commit id: "23h59"

À cela, j’ai également ajouté un buffer de temps supplémentaire de 6 semaines afin d’être sûr de ne pas avoir la pression si je pars en vacances ou si je prends du retard sur un des 3 points cités plus haut.

Le but est d’arriver à la fin de la formation avec une fondation solide de théorie, pratique mais également un portfolio pour pouvoir commencer le plus rapidement à prospecter ou chercher un emploi (si vraiment nécessaire).


# Apprentissage du jour

## Les dépôts distants

Bien qu’ayant déjà une connaissance sur comment travailler avec des dépôts distants, les points les plus importants à retenir sont comment travailler avec la ligne de commande et non avec l’interface graphique de VSCode ou GitHub Desktop.

Et c’est là que j’ai appris des choses intéressantes 😁

### La notion de Tracking

Lorsqu’on travaille avec des dépôts distants, il est nécessaire de lier le dépôt local et distant lors du push avec le paramètre -u :

git push -u origin nombranche

### La collaboration

Lorsqu’on travaille en équipe, il est important de récupérer régulièrement les dernières informations du dépôt distant car ce processus n’est pas automatique dans git. Pour ce faire, il existe la commande fetch :

git fetch

Lorsqu’on récupère les dernières informations du dépôt distant, il est important d’intégrer ces informations dans la branche actuelle locale. Ce n’est là non plus une action automatique lorsqu’on utilise la commande fetch. Il faut alors utiliser la commande merge pour intégrer les mises à jour.

Mais git a également une commande qui permet de fetch et merge automatiquement :

git pull

Pourquoi les deux options existent ? Il est parfois nécessaire de savoir ce qui a été fait dans ce que l’on récupère afin de l’intégrer ou non. Dans bien des cas, la commande pull est suffisante.

Afin de pousser les informations après un commit vers le dépôt distant, il y a bien évidemment la commande :

git push

### Supprimer les branches distantes

Afin de supprimer les branches distantes, on utilise la commande push avec le paramètre -d :

git push -d origin branche_a_supprimer

Il est possible d’utiliser l’option -f mais c’est à éviter le plus possible lorsqu’on travaille en équipe car cela écrase les données des dépôts distants. Tes collègues risquent de ne pas être contents…

Cette commande va uniquement supprimer la branche distante et pas la branche correspondante en local. Il faudra également effectuer la commande suivante pour supprimer le dépôt local :

git branch -d branche_a_supprimer # la branche locale

### Branches obsolètes

Il est également possible de supprimer les branches qui sont obsolètes dans le dépôt local. Git met à disposition deux commandes :

git remote prune origin # utilise --dry-run pour voir ce qu'il se passerait avant de lancer la commande

# ou alors le faire lors du fetch
git fetch --prune

## Vrac

À la fin de la session de pratique, j’ai demandé à Gemini de me créer deux mini tests. Ceci est une super solution pour créer des mini tests à la volée pour tester tes connaissances. Je te joins mes résultats au test du professeur Gemini.

J’ai également appris qu’il était possible de créer des templates pour des Issues dans GitHub (ce n’était pas dans le cours). Il y a deux manières de créer des templates, soit via l’interface ou alors directement dans la codebase. Les détails sont ici.

## Rétrospective de la semaine

Je pense que le planning tient la route. Il y aura sans doute des retards et des adaptations à faire mais pour le moment, je suis satisfait.

J’ai juste peur que lorsque les projets de l’après-midi démarreront, je me retrouve face à un problème de timing pour l’écriture du post pour ce blog. Mais je tiens tout de même à avoir un post tous les jours. C’est un pré-requis durant cette période.

Une bonne fin de journée et un excellent week-end à toi.

Alessandro