Git et la gestion de versions dans le développement mobile : définition, commandes de base et fonctionnement

Gestion de versions et Git : qu'est-ce que c'est ?

Git est un système de gestion de versions distribué (VCS) créé par Linus Torvalds en 2005 pour le développement du noyau Linux. Contrairement aux systèmes centralisés (SVN, CVS), Git stocke une copie complète de l'historique du projet sur chaque ordinateur du développeur. Cela signifie que vous pouvez effectuer des commits, parcourir l'historique et créer des branches même sans connexion Internet.

Git fonctionne avec des instantanés (snapshots) — chaque commit enregistre l'état de tous les fichiers du projet au moment de l'enregistrement. Si un fichier n'a pas changé, Git crée une référence à la version précédente, économisant de l'espace. Selon une analyse GitHub (2025), le dépôt moyen contient 1 200 commits et 15 branches.

Chez IT Sectr, nous utilisons Git depuis 2017 dans tous nos projets. Notre expérience montre qu'une configuration correcte de Git dès le premier jour fait gagner à l'équipe jusqu'à 30 % de temps sur les fusions et la résolution de conflits. Git est devenu le标准 de fait — il est pris en charge par tous les IDE modernes (Android Studio, Xcode, VS Code) et les systèmes CI/CD.

# Configuration de base de Git
git config --global user.name "Votre Nom"
git config --global user.email "votre@email.com"

# Création d'un nouveau dépôt
git init my-project
cd my-project

# Ajout de fichiers et commit
git add README.md
git commit -m "Initial commit"

# Travail avec un dépôt distant
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Le code ci-dessus montre la séquence de base : initialisation d'un dépôt, premier commit et publication sur un serveur distant. La commande git init crée un dossier caché .git qui stockera tout l'historique du projet. Chaque git commit crée un point de restauration auquel vous pouvez revenir à tout moment.

Concepts de base : Repository, Branch, Commit

Comprendre les trois concepts de base — Repository, Branch et Commit — est essentiel pour travailler avec tout système de gestion de versions. Un dépôt est un conteneur pour l'ensemble du projet. Un commit est un état sauvegardé des fichiers. Une branche est une ligne de développement distincte.

Repository (dépôt) peut être local (sur votre ordinateur) ou distant (sur un serveur GitHub, GitLab). Chaque développeur clone le dépôt distant sur sa machine et travaille avec une copie locale. Les modifications sont synchronisées via push (envoyer) et pull (récupérer). Dans la gestion de versions distribuée, chaque développeur stocke une copie complète de l'historique.

Branch (branche) est un pointeur vers l'un des commits. Les branches permettent le développement parallèle : un développeur travaille sur une nouvelle fonctionnalité (feature branch), un autre corrige un bug (hotfix branch), un troisième prépare une version (release branch). Selon GitLab Flow (2025), le projet moyen a 3 à 5 branches actives simultanément.

Commit est une unité de modification. Chaque commit contient un hachage unique (SHA-1), un message, un auteur et un horodatage. Une bonne pratique consiste à faire des commits petits et significatifs avec des messages descriptifs — cela simplifie la Code Review et l'annulation des modifications. La gestion de versions via les commits vous donne l'historique complet du projet.

Feature Branch

Feature Branch (branche de fonctionnalité) est une branche temporaire créée à partir de develop ou main pour développer une tâche spécifique. Après avoir terminé le travail, la branche est fusionnée via Pull Request et supprimée. Cette pratique permet d'isoler les modifications sans perturber la stabilité de la base de code principale.

Flux de travail typique : créer la branche feature/add-login → faire plusieurs commits → créer une Pull Request → passer par la Code Review → fusionner dans develop. Chez IT Sectr, nous utilisons exactement cette approche : chaque tâche Jira correspond à une branche de fonctionnalité distincte. Cela simplifie le suivi des modifications et l'annulation si nécessaire.

Rebase vs Merge

Merge crée un commit de fusion qui combine deux branches. Il préserve l'historique complet, y compris les lignes de développement parallèles. Rebase réécrit l'historique : il prend les commits d'une branche et les "réapplique" sur une autre, créant un historique linéaire.

Merge est mieux adapté aux branches publiques et aux grandes équipes où la chronologie est importante. Rebase est pratique pour les branches de fonctionnalité personnelles avant de créer un PR — il rend l'historique plus propre et plus compréhensible. Cependant, rebase ne doit jamais être appliqué aux branches sur lesquelles d'autres développeurs travaillent, car il réécrit l'historique.

# Création et basculement vers une feature branch
git checkout -b feature/add-login main

# Travail dans la branche
git add login-screen/
git commit -m "Add login screen layout"

# Rebase sur le main le plus récent avant PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push vers le dépôt distant
git push origin feature/add-login

Cet exemple montre un flux de travail typique : créer une branche de fonctionnalité depuis main, plusieurs commits et rebase pour obtenir un historique linéaire propre avant l'envoi pour révision. Cette approche minimise les conflits de fusion.

Git Flow vs Trunk-Based Development

Git Flow et Trunk-Based Development sont les deux principales stratégies de gestion de versions qui déterminent comment une équipe organise le travail avec Git. Le choix dépend de la taille de l'équipe, de la fréquence des versions et des exigences de stabilité.

Git Flow est un modèle strict avec plusieurs branches permanentes : main (code de version), develop (développement actuel), feature/* (nouvelles fonctionnalités), release/* (préparation de version) et hotfix/* (correctifs urgents). Ce modèle convient aux projets avec des cycles de version clairs (par exemple, applications mobiles avec versions 1.0, 2.0).

Trunk-Based Development est une approche avec une seule branche principale (trunk/main) où tous les développeurs fusionnent leurs modifications plusieurs fois par jour. Des indicateurs de fonctionnalité sont utilisés pour masquer les fonctionnalités incomplètes. Cette approche est populaire dans le développement web et les startups où la rapidité de livraison est importante.

Git Flow

Git Flow, proposé par Vincent Driessen en 2010, reste l'un des modèles les plus populaires. Son principal avantage est la séparation stricte du code par étapes du cycle de vie. La branche main contient uniquement le code de version, develop contient le développement actuel et les branches de fonctionnalité isolent les nouvelles fonctionnalités les unes des autres.

Les branches hotfix sont créées à partir de main pour les correctifs urgents et après fusion sont fusionnées à la fois dans main et develop. Les branches release sont créées à partir de develop lorsque l'équipe est prête pour une version. Seules les corrections de bugs et les métadonnées (version, build) y sont ajoutées. Après la version, la branche release est fusionnée dans main et develop. Selon une enquête JetBrains (2024), 37 % des équipes utilisent Git Flow. Ce modèle de gestion de versions reste la norme pour les projets avec des versions fixes.

# Exemple Git Flow : début du travail sur une version
git checkout -b release/1.2.0 develop

# Correction de bugs dans la branche release
git commit -m "Fix login button crash"

# Achèvement de la version — fusion dans main et develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Suppression de la branche release
git branch -d release/1.2.0

Le code illustre la création d'une branche release, sa stabilisation et sa fusion dans les branches principales. Le flag --no-ff garantit un commit de fusion, préservant l'information que les modifications proviennent de la branche release.

Pull Request et Code Review

Pull Request (PR) est un mécanisme par lequel un développeur propose des modifications de sa branche vers la branche principale. La PR est un élément clé de la gestion de versions dans le travail d'équipe — ce n'est pas seulement un moyen de fusionner du code, mais un processus de discussion, de révision et de contrôle qualité. Dans GitLab, le mécanisme similaire est appelé Merge Request (MR), mais l'essence est la même : informer l'équipe des modifications et obtenir l'approbation.

Une bonne PR doit être petite (jusqu'à 300 lignes de code), concentrée sur une seule tâche et contenir une description de ce qui a été fait et pourquoi. Selon une étude Google (2025), les PR de plus de 400 lignes prennent deux fois plus de temps à réviser et la probabilité de détecter des bugs diminue de 30 %. La Code Review est la vérification du code par un autre développeur avant la fusion.

Chez IT Sectr, nous pratiquons la Code Review obligatoire pour chaque PR. Cela améliore non seulement la qualité du code, mais aide également à diffuser les connaissances au sein de l'équipe. La Code Review vérifie : si le code suit les principes architecturaux, s'il y a des bugs, s'il y a suffisamment de tests, si les variables sont correctement nommées. Tous les commentaires sont discutés dans la PR jusqu'à la fusion.

Plateformes : GitHub, GitLab, Bitbucket

Git est un protocole, mais pour la collaboration, vous avez besoin d'une plateforme de gestion de versions qui fournit une interface web, une gestion des accès, des CI/CD et des outils de révision. Trois plateformes dominent le marché : GitHub, GitLab et Bitbucket.

GitHub est la plus grande plateforme avec plus de 56 millions de développeurs. Appartenant à Microsoft, elle propose Actions (CI/CD), Pages (hébergement), Discussions et Copilot. Le forfait gratuit comprend des dépôts privés illimités pour les équipes jusqu'à 3 personnes. GitHub est populaire dans la communauté open-source.

GitLab est une plateforme DevOps complète avec CI/CD intégré, registre de conteneurs et gestion d'infrastructure. Contrairement à GitHub, GitLab peut être installé sur votre propre serveur (Self-Managed). Bitbucket d'Atlassian est étroitement intégré à Jira et Confluence, ce qui en fait le choix pour les équipes utilisant déjà l'écosystème Atlassian.