Il y a quelques jours, j'ai réalisé un truc qui m'a un peu stressée : ma réunion de la semaine 4 avec ma mentor Endah Bongo approchait, et le programme prévoyait Linux et Git. Sauf que... je ne maîtrisais pas encore les différentes commandes utilisées. Plutôt que de paniquer, j'ai décidé de prendre les choses en main et de tout pratiquer en direct, une commande à la fois, jusqu'à ce que ça fasse sens.

Voici ce que j'ai appris, dans l'ordre où je l'ai découvert.

Se repérer dans un terminal Linux

La toute première chose à comprendre avec Linux, c'est qu'on est toujours "quelque part" dans une arborescence de dossiers. Trois commandes suffisent pour s'orienter :

  • pwd (print working directory) affiche l'endroit exact où on se trouve
  • ls liste le contenu du dossier courant
  • cd permet de se déplacer d'un dossier à l'autre

Avec cd ~, on revient direct dans son dossier personnel. Une astuce toute simple, mais qui change la vie quand on découvre le terminal.

Créer et organiser des fichiers

Une fois qu'on sait se déplacer, l'étape suivante c'est de manipuler des fichiers et dossiers :

  • mkdir crée un nouveau dossier
  • touch crée un fichier vide
  • ls -la permet de tout voir en détail, y compris les fichiers cachés et les permissions

C'est là que j'ai découvert les permissions Linux (ce fameux -rw-r--r-- qu'on voit à côté de chaque fichier), qui déterminent qui peut lire, écrire ou exécuter un fichier.

Entrer dans le monde de Git

Une fois les bases Linux en poche, place à Git. Première étape : configurer son identité, une seule fois pour toutes les utilisations futures.

git config --global user.name "Ton nom"
git config --global user.email "[email protected]"

Enter fullscreen mode Exit fullscreen mode

Ensuite, j'ai transformé mon dossier de test en dépôt Git avec git init, puis j'ai découvert le cycle de base que tout développeur utilise au quotidien :

  1. Modifier un fichier
  2. git add pour l'ajouter à la zone de préparation (staging)
  3. git commit -m "message" pour valider les changements

Entre les deux, git status est devenu mon meilleur ami : il indique en permanence ce qui est suivi, modifié, ou prêt à être validé.

Les branches, pour ne pas tout casser

La partie qui m'a le plus parlé, c'est le principe des branches. Avec git branch nom-de-branche puis git checkout nom-de-branche, on peut travailler sur une fonctionnalité sans toucher au code principal (master). Une fois le travail terminé et validé, git merge permet de fusionner les changements.

C'est un principe simple sur le papier, mais qui prend tout son sens quand on l'exécute soi-même dans le terminal.

Direction GitHub

Dernière étape : connecter mon dépôt local à un dépôt GitHub, pour que le code existe aussi en ligne.

git remote add origin https://github.com/mon-utilisateur/mon-repo.git
git push -u origin master

Enter fullscreen mode Exit fullscreen mode

git remote add crée le lien entre le dépôt local et son adresse en ligne, et git push envoie les commits vers GitHub. Simple sur le principe, mais ça m'a fait comprendre concrètement la différence entre travailler "en local" et publier son travail pour de vrai.

Ce que je retiens

Cette session improvisée m'a appris une chose essentielle : on ne comprend vraiment un outil qu'en le pratiquant, commande par commande, jusqu'à ce que chaque résultat affiché à l'écran ait un sens. Je suis arrivée à la réunion avec Endah bien plus à l'aise, capable d'expliquer le cycle complet modifier → add → commit → push, et prête à aller plus loin.

Prochaine étape : approfondir les scripts et automatiser certaines de ces tâches. À suivre !

Et toi, c'est quoi ta première commande Git ou Linux qui t'a vraiment fait "cliquer" ? Ou si tu débutes toi aussi, quelle est la partie qui te fait le plus peur pour l'instant ? Dis-le-moi en commentaire, je suis curieuse de savoir si mon parcours ressemble au tien 👇