En échangeant avec des étudiant·e·s en informatique, je remarque qu’un bon nombre n’utilise pas ou peu Git dans le cadre de leurs projets scolaires. C’est dommage car c’est un outil qui facilite la vie lorsqu’on travaille à plusieurs sur un projet logiciel.

À travers cet article, je vais répondre aux questions que j’ai le plus souvent entendues et donner les bases minimales de ce merveilleux outil qu’est Git.

ℹ️ Disclaimer: J’utilise essentiellement Git par ligne de commande. Il existe aussi des interfaces (notamment Github Desktop, Sourcetree) qui font la même chose.

C’est quoi Git ?

Git est un gestionnaire de version. Il représente votre projet logiciel comme un arbre. Votre projet logiciel pousse et évolue comme un arbre.

Grâce à Git, vous pourrez :

  • Identifier des versions précises de votre projet
  • Collaborer à plusieurs sur un projet
  • Restaurer des versions précédentes de votre projet
  • Et bien plus encore !

Rares sont les équipes qui n’utilisent pas Git (ou un autre gestionnaire de version). C’est pourquoi j’ai souhaité démystifier à travers cet article les fonctionnalités principales à connaître sur Git.

Récupérer son projet

Soit on se trouve dans un cas de figure où on doit initialiser son projet. Il suffit de se placer à la racine du répertoire que l’on souhaite versionner et taper la commande suivante :

git init

Soit on récupère un projet existant.

git clone url-du-projet

Avec cette commande, vous pourrez juste récupérer le projet pas forcément y contribuer. Il faudra vous assurer d’avoir été ajouté en collaborateur par le gestionnaire du projet.

Les branches

Une branche est l’équivalent d’une “version” de l’application qu’on est sur le point de créer.

git checkout -b nom-de-ma-branche

Les noms de branche suivent généralement une nomenclature. On démarre généralement :

type-de-branche/numéro-ticket-feature

  • feature/PRP-101-add-button
  • fix/PRP-202-remove-bug
  • hotfix/PP-394-everything-down

Cela va dépendre de l’équipe projet que vous intégrez et des normes que vous décidez de vous imposer 😄

La branche main | master représente la version la plus stabilisée du projet, c’est la branche principale. Toutes les branches que vous créerez ont vocation à être “mergées” avec master.

“Merger une branche” avec master signifie déporter les modifications qui ont été faites sur la branche dans la branche principale du projet.

Cycle de développement

Quand on code, on va éditer des fichiers. Git détectera les modifications faites aux fichiers. Il est possible de visualiser les modifications courantes grâce à la commande

git status

Une fois notre développement prêt, on va pouvoir commit. Un commit est une “capture” de votre application à un instant donné.

Il va falloir ajouter les fichiers à son commit puis commiter.

git add fichier
git commit -m "message de commit"

💡 Il arrive parfois que des fichiers se trouvent dans notre arbre de modifications. J’évite soigneusement le git add . pour mieux maîtriser ce que j’envoie dans mon commit !

Il est recommandé de mettre un message le plus clair possible. Chaque équipe projet a ses habitudes mais nombreuses sont celles qui utilisent la convention de nommage Conventional Commits

Il m’arrive aussi de mettre des emojis dans mes messages de commit sur mes projets personnels.

Les relectures de code

Les Pull Request (ou Merge Request) permettent aux autres développeurs du projet de contribuer. Selon l’outil que vous utilisez (Github, Gitlab, Bitbucket…), l’ouverture d’une Pull Request sera différente mais l’objectif est le même : soumettre votre code à vos pairs afin qu’ils vous donnent des feedbacks.

Une bonne PR doit contenir :

  • L’objectif de la modification en quelques lignes dans le titre de la PR
  • L’issue liée: ça peut être une issue Github, un ticket Trello bref, ce qui peut aider votre reviewer à comprendre le contexte dans lequel le code que vous soumettez est nécessaire.
  • Les éventuels points d’attention à apporter via des commentaires au fil de votre PR.

Pour faciliter les relectures de code, Ségolène de la communauté Women on Rails a écrit un brillant article.

Merge vs Rebase

Une fois votre branche prête et approuvée par la team, vous avez deux options: merge ou rebase

Les deux commandes intégreront vos modifications dans la branche que vous souhaitez.

Une des différences majeures est quegit merge va préserver l’historique de vos commits à la différence de git rebase qui va les condenser en un commit.

git merge va créer un commit de merge lors du merge de deux branches, permettant ainsi de mieux identifier quand les branches ont été regroupées.

Les tags

Les tags sont rattachés à des commits. Ils sont utilisés pour “identifier” une version précise de l’application.

Dans un environnement d’intégration continue, on peut soit écouter les derniers commits sur master ou les derniers tags crées. Encore une fois, Git propose des fonctionnalités diverses mais chaque équipe choisit ses rituels de mise en production !

La différence entre Git et Github ?

Prenons un exemple.

  • Vous créez votre branche sur votre ordinateur, vous commitez sur la branche sans la pousser
  • Vous vous faites un petit goûter gourmand pour vous récompenser.
  • Un cambrioleur vole votre ordi en passant par la fenêtre de votre bureau.
  • Votre travail est perdu.

Github est donc une sorte d’hébergeur en ligne de projets Git, afin qu’ils ne soient jamais perdus. Leur responsabilité est d’héberger vos projets Git et de s’assurer ainsi qu’ils ne soient jamais perdus 🤞

À noter qu’il existe d’autres solutions conccurentes à Github : Gitlab, Bitbucket…

J’espère que cet article aura pû vous aider à éclaircir quelques points obscurs concernant Git !

Y a-t-il d’autres questions que vous vous posez sur Git ? Je serais ravie d’y répondre en commentaires !