Gestion du code source

La gestion du code source (SCM) est la discipline qui consiste à suivre, enregistrer et coordonner chaque modification apportée au code source d'un projet au fil du temps. Cette page explique ce qu'est le SCM, pourquoi chaque équipe s'appuie dessus, comment Git s'y intègre, le flux de travail qu'il permet et les pratiques qui maintiennent l'historique d'un projet propre.

Qu'est-ce que la gestion du code source ?

La gestion du code source est la pratique consistant à suivre et à gérer les modifications apportées au code logiciel. Elle est presque toujours mise en œuvre avec un système de contrôle de version (VCS) — un outil qui enregistre chaque modification apportée à un dépôt, l'attribue à un auteur, lui appose un horodatage et vous permet de naviguer en avant et en arrière dans l'historique du projet.

Git est le VCS le plus utilisé aujourd'hui. Il est distribué, ce qui signifie que chaque développeur conserve une copie complète de l'historique du projet en local, de sorte que vous pouvez faire des commits, créer des branches et inspecter l'historique sans connexion réseau. D'autres systèmes existent (Subversion, Mercurial, Perforce), mais les concepts abordés sur cette page s'appliquent à tous.

SCM et VCS sont souvent utilisés de manière interchangeable. Strictement, le SCM est la pratique plus large (historique, branchage, politiques de collaboration, révision de code), et un VCS comme Git est l'outil qui le met en œuvre.

Si vous débutez avec Git, commencez par l'introduction à Git et apprenez à créer votre premier dépôt Git.

Pourquoi la gestion du code source est-elle importante ?

Un VCS résout des problèmes qui deviennent douloureux dès que plus d'une personne — ou plus d'une journée de travail — touche à une base de code :

• Suivi des modifications – Chaque modification est enregistrée automatiquement, attribuée à un auteur et documentée avec un message de commit, créant ainsi un historique consultable.
• Synchronisation – Les membres de l'équipe récupèrent le code le plus récent depuis un dépôt partagé, de sorte que tout le monde travaille à partir de la même base.
• Sauvegarde et restauration – Chaque commit étant un instantané complet, n'importe quel fichier peut être restauré à un état antérieur à tout moment.
• Annulation – Vous pouvez revenir à n'importe quel état antérieur, du commit le plus récent à une version créée il y a longtemps, sans perdre les étapes intermédiaires.
• Branchage et fusion – Le travail se déroule sur des branches isolées et est fusionné une fois révisé et approuvé.
• Détection des conflits – Lorsque deux personnes modifient les mêmes lignes, le VCS refuse d'écraser silencieusement l'une par l'autre ; il signale un conflit de fusion afin qu'un humain puisse le résoudre.

Sans SCM, les équipes ont recours à la compression de dossiers, à l'envoi de fichiers par e-mail et à des noms du type final_v2_REALLY_final.js — perdant l'historique et s'écrasant mutuellement le travail.

Le flux de travail SCM de base

La majeure partie du travail quotidien dans Git suit la même boucle : modifier des fichiers, les préparer, enregistrer un instantané et inspecter l'historique. L'exemple ci-dessous exécute un dépôt autonome afin que vous puissiez voir le cycle de bout en bout.

# Create and enter a fresh project
mkdir scm-demo && cd scm-demo

# 1. Turn the folder into a repository
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

# 2. Make a change
echo "console.log('hello');" > app.js

# 3. Stage the change, then record a snapshot (commit)
git add app.js
git commit -q -m "Add initial app"

# 4. Make a second change and commit it
echo "console.log('world');" >> app.js
git commit -q -am "Print world too"

# 5. Inspect the historical record
git log --oneline

L'historique contient désormais deux instantanés, le plus récent en premier (les courts hachages sur la gauche sont générés par commit, donc les vôtres seront différents) :

6524bb9 Print world too
88e2f34 Add initial app

Chaque git add déplace les modifications dans la zone de préparation (staging area), et chaque git commit fige le contenu préparé dans un instantané permanent et nommé. La sortie de git log est l'historique que le SCM vous offre — deux lignes ici, une par commit, chacune avec un court hachage et un message. À tout moment, vous pouvez exécuter git status pour voir ce qui est modifié, préparé ou non suivi.

Branchage et fusion

La fonctionnalité qui rend le SCM puissant pour les équipes est l'isolation grâce aux branches. Chaque développeur (ou chaque fonctionnalité) dispose d'une ligne de développement distincte ; une fois le travail révisé et prêt, il est fusionné dans la branche principale.

mkdir branch-demo && cd branch-demo
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

echo "line 1" > notes.txt
git add notes.txt
git commit -q -m "Start notes"

# Remember the main branch name (main or master)
main=$(git branch --show-current)

# Create a branch, switch to it, add work there
git switch -c feature
echo "line 2 from feature" >> notes.txt
git commit -q -am "Add feature line"

# Go back to the main branch and merge the feature in
git switch -q "$main"
git merge -q feature

cat notes.txt

Après la fusion, notes.txt contient le travail des deux branches :

line 1
line 2 from feature

La branche feature a permis à la nouvelle ligne de travail de progresser sans toucher à main, et git merge l'a réintégrée. Sur un projet partagé, vous utiliseriez également git clone pour cloner le dépôt et git pull avant de commencer, afin de construire sur le code le plus récent.

Bonnes pratiques

• Commitez fréquemment, en petites unités. Un commit est un instantané ; des commits petits et ciblés vous offrent de nombreux points de retour sûrs et rendent l'historique facile à lire. Des commits connexes peuvent être combinés ultérieurement pour garder le journal propre.
• Travaillez toujours à partir de la dernière version. Tirez (pull) ou récupérez (fetch) le code partagé avant de commencer afin de construire sur le travail actuel et de minimiser les conflits de fusion.
• Rédigez des messages de commit descriptifs. Un message clair qui explique ce qui a changé et pourquoi devient essentiel au fur et à mesure que le projet grandit et que d'autres personnes (y compris vous à l'avenir) lisent le journal.
• Révisez avant de committer. La zone de préparation vous permet de collecter et d'inspecter les modifications avant de les transformer en instantané — examinez le diff pour que chaque commit soit délibéré.
• Utilisez des branches pour l'isolation. Développez chaque fonctionnalité ou correction sur sa propre branche et fusionnez-la uniquement après révision, en gardant la branche principale stable.
• Convenez d'un flux de travail partagé. Établissez des conventions d'équipe pour le branchage, la révision et la fusion. Les modèles courants sont abordés dans les flux de travail Git.

Pratique