Git local vers Git collaboratif 🤝

Jusqu'à présent, votre connaissance de Git s'est construite dans l'environnement de votre machine locale. Cette fondation constitue la base du développement professionnel, mais elle ne représente qu'une facette de l'écosystème Git. En effet, le développement avec Git repose sur la collaboration d'équipe et la synchronisation distribuée avec des dépôts distants. Dans un environnement professionnel, votre code doit être partagé, révisé, intégré et déployé en coordination avec vos collègues.

La gestion des dépôts Les plateformes cloud (GitHub, GitLab, Azure Repos) ne sont pas de simples espaces de stockage, mais des écosystèmes complets qui orchestrent les workflows de développement, automatisent les processus de validation et facilitent la revue de code. Cette transition implique de connaître de certains concepts et pratiques : le transfert de modifications entre votre machine et les serveurs distants, la collaboration sur des branches partagées avec gestion des conflits et les revues de code structurées.

Git : Client vs Serveur

Git fonctionne selon un modèle distribué qui combine autonomie locale et collaboration centralisée. Sur votre machine, l'installation Git opère comme un client autonome complet, archivant l'historique intégral de votre projet dans le répertoire caché .git qui encapsule toutes les métadonnées de versionnement, chaque utilisateur possède ainsi une réplique complète et fonctionnelle du dépôt sur son poste. Parallèlement, les plateformes de dépôts distants (GitHub, Azure Repos, entre autres) agissent comme des dépôts distants serveurs centralisés servant de "source de vérité" commune, orchestrant la synchronisation entre tous les développeurs de l'équipe.

Git permet à chaque développeur de travailler de manière autonome avec l'historique complet, puis de se synchroniser avec le serveur distant uniquement quand nécessaire, offrant ainsi flexibilité, performance et résilience dans le workflow collaboratif.

Au-delà de la collaboration, le dépôt distant offre une sécurité renforcée grâce à la sauvegarde automatique et continue de l'ensemble du code source. Cette protection contre la perte de données locales (panne matérielle, erreur humaine ou tout autre incident) assure la pérennité du travail de développement.

Le paysage des plateformes de dépôts distants est dominé par plusieurs acteurs clés, chacun proposant des spécificités adaptées à différents contextes organisationnels. GitHub s'impose comme le leader du marché, fort de son rachat par Microsoft et de son écosystème open source de référence qui attire des millions de développeurs à travers le monde.

GitLab propose une alternative pour les entreprises cherchant une solution tout-en-un. Sa force réside dans l'intégration native de fonctionnalités DevOps avancées, permettant de gérer l'intégralité du cycle de vie des applications depuis une interface unique, de la planification jusqu'au déploiement en production.

Bitbucket, développé par Atlassian, est utilisé dans les environnements d'entreprise grâce à sa synergie avec l'écosystème Atlassian. Cette intégration avec JIRA pour la gestion de projet et Confluence pour la documentation technique crée un environnement de travail optimisé pour les équipes déjà investies dans ces outils.

Azure Repos complète cette offre en tant que plateforme d'entreprise intégrée à Azure DevOps, offrant une solution native pour les organisations déjà engagées dans l'écosystème Microsoft Azure. Cette intégration permet une continuité entre le développement, l'intégration continue et le déploiement dans l'infrastructure cloud Microsoft.

Dans la section suivante, nous verrons comment connecter un dépôt Git local à GitHub, et comment maîtriser les workflows collaboratifs essentiels pour travailler efficacement au sein d’une équipe.

Configurer l'authentification avec GitHub

Vous avez créé votre commit local, mais celui-ci existe uniquement sur votre ordinateur. Pour le sauvegarder en ligne et le partager avec d'autres développeurs, vous devez push votre commit, c'est à dire, l'envoyer vers un dépôt distant. Dans ce guide, nous utiliserons GitHub comme plateforme d'hébergement.

Méthodes de connexion

Avant d'effectuer votre premier git push, il est essentiel de comprendre comment votre ordinateur communiquera de manière sécurisée avec GitHub. Trois méthodes principales d'authentification sont disponibles : GitHub CLI, SSH et HTTP avec PAT (Personal Access Tokens)

GitHub CLI est l'outil en ligne de commande officiel de GitHub qui simplifie l'authentification. Au lieu de configurer des clés SSH ou de générer des tokens (PAT), GitHub CLI vous authentifie via votre navigateur web en quelques clics avec la commande gh auth login. C'est la solution idéale pour débuter avec GitHub, car elle ne nécessite qu'une installation simple. Pour plus d'informations et les instructions d'installation officielles, consultez : https://github.com/cli/cli#installation

Les PAT (Personal Access Tokens) sont principalement utilisés dans des contextes spécifiques. Un PAT est un token généré depuis votre compte GitHub qui sert de mot de passe sécurisé. Ces tokens sont essentiels pour l'automatisation, notamment dans les pipelines CI/CD (Intégration Continue/Déploiement Continu) , les scripts automatisés et les environnements serveur où SSH n'est pas approprié. Vous devez, cependant, définir des permissions spécifiques et des dates d'expiration pour chaque token.

Le protocole SSH (Secure Shell) est un protocole qui établit une connexion sécurisée entre votre machine et GitHub grâce à un système de clés cryptographiques. L'avantage principal de SSH est qu'une fois la configuration initiale effectuée, vous n'aurez plus besoin de saisir vos identifiants pour communiquer avec GitHub. Chaque action sera automatiquement authentifiée grâce à vos clés. Pour générer une nouvelle clé SSH et l'ajouter à l'agent SSH, consultez : https://docs.github.com/fr/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent ou regardez ce tutoriel vidéo : https://www.youtube.com/watch?v=7K7xt0VJg5s

Dans ce guide, nous privilégions SSH pour l'authentification GitHub. Même si d'autres méthodes sont plus simples à configurer, SSH est la méthode standard qui fonctionne avec tous vos outils de développement et ne demande aucune intervention une fois configuré.

Mise en pratique : De Git local à GitHub

Une fois votre authentification configurée (SSH est recommandé pour ce guide), vous êtes prêt à synchroniser votre code avec GitHub. Cette section vous guide à travers les trois cas d'usage essentiels que vous rencontrerez dans votre pratique quotidienne du développement collaboratif. Chaque cas d'usage est accompagné de commandes commentées pour une mise en œuvre immédiate.

Les trois cas d'usage couverts :

  • Cloner un projet existant - Rejoindre une équipe ou utiliser un template
  • Créer un nouveau dépôt - Démarrer un projet from scratch
  • Migrer un projet local - Publier un projet existant sur GitHub
Cas d'usage 1 : Cloner un projet existant

Contexte : Vous rejoignez un projet en cours ou souhaitez utiliser un template (dépôt distant) d'équipe déjà hébergé sur un dépôt distant (GitHub ou autre).

git clone https://organisation@dev.azure.com/org/projet/_git/nom-du-depot

Ce que fait cette commande :

  • Télécharge l'intégralité du dépôt distant (historique, branches, tags)
  • Crée automatiquement un dossier local portant le nom du dépôt
  • Crée automatiquement un remote nommé « origin ».

Après le clonage :

cd nom-du-depot          # Entrer dans le dossier projet
git status               # Vérifier l'état du dépôt
git branch -a            # Afficher toutes les branches (locales et distantes)
Cas d'usage 2 : Créer un nouveau projet de zéro

Contexte : Démarrage d'un nouveau projet que vous souhaitez héberger sur un dépôt distant (GitHub ou autre).

Étape 1 :Création du dépôt sur GitHub

  1. Via l'interface web GitHub (github.com) :
    • Connexion à GitHub avec votre compte
    • Cliquez sur le bouton "+" en haut à droite de la page
    • Sélectionnez "New repository" (Nouveau dépôt)
  2. Configuration du dépôt :
    • Repository name : Nom du dépôt (utilisez des tirets pour les espaces)
    • Description : Description optionnelle du projet
    • Visibilité : Public (visible par tous) ou Private (accès restreint)
    • Important: Ne cochez PAS "Add a README file" (nous le créerons localement)
  3. Cliquez sur "Create repository"
  4. Copiez l'URL de connexion fournie (SSH ou HTTPS selon votre configuration)
# Création du dossier projet local
mkdir mon-nouveau-projet

# Accéder au dossier
cd mon-nouveau-projet

# Initialisation Git
git init

# Création du fichier README
echo "# Mon Nouveau Projet" > README.md

# Ajout de contenu au README
echo "Description du projet et instructions d'installation" >> README.md

# Ajout de README au suivi Git
git add README.md

# Premier commit
git commit -m "docs: initialisation du projet avec README"

Étape 3 : Configuration de la branche principale

git branch -M main

Étape 4 : Connexion au dépôt distant

git remote add origin https://organisation@dev.azure.com/org/projet/_git/nom-du-depot

Étape 5 : Synchronisation initiale

git push -u origin main
Cas d'usage 3 : Migrer un projet existant vers Azure Repos

Contexte : Vous disposez d'un projet Git local fonctionnel que vous souhaitez héberger sur un dépôt distant (GitHub).

  1. Prérequis : Création du dépôt vide sur Github (sans README, .gitignore)
  2. Depuis votre dossier projet existant :
# Accéder au dossier projet
cd mon-projet-existant

# Initialisation Git (si pas déjà fait)
git ini

# Vérification de l'état du dépôt
git status

# Affichage des branches existantes
git branch -a

# Configuration de la branche principale (si besoin)
git branch -M main

# Connexion au dépôt distant
git remote add origin https://organisation@dev.azure.com/org/projet/_git/nom-du-depot

# Vérification de la connexion distante
git remote -v

# Pousser la branche principale
git push -u origin main

# Pour pousser toutes les branches et tags
git push origin --all
Gestion multi-remote

Par défaut, lorsque vous clonez ou initialisez un dépôt Git, vous travaillez avec un seul dépôt distant (remote) appelé origin. Cependant, Git vous permet de configurer plusieurs remotes pour un même projet local. Cette fonctionnalité est particulièrement utile dans plusieurs situations professionnelles :

  • Miroir de sécurité : Sauvegarder votre code sur plusieurs plateformes (GitHub, GitLab, Bitbucket).
  • Migration progressive : Transférer un projet d'une plateforme à une autre sans interruption.
  • Collaboration multi-plateforme : Travailler avec des équipes utilisant différents services Git.
  • Backup automatique : Assurer une redondance de votre code source.

Imaginons que votre projet principal est hébergé sur GitHub, mais vous souhaitez également le sauvegarder sur GitLab. La gestion multi-remote vous permet de gérer tout cela depuis votre dépôt local unique.

# Vérifier les remotes existants                                      
git remote -v

# Ajouter GitLab
git remote add gitlab https://gitlab.com/username/repository.git

# Vers GitHub (origin)
git push origin main

# Vers GitLab
git push gitlab main
Maintenir votre dépôt local à jour avec git pull

Après avoir cloné un projet, vos collègues continueront d'y apporter des modifications. Pour récupérer ces changements et garder votre version locale synchronisée, utilisez git pull. Cette commande télécharge les nouvelles modifications depuis le dépôt distant et les fusionne automatiquement dans votre branche locale. 

# Récupère et fusionne les modifications de main                   
git pull origin main

La commande git pull permet de :

  • Télécharger les nouvelles modifications du dépôt distant (fetch).
  • Les fusionner automatiquement dans votre branche locale (merge).

Le workflow quotidien recommandé est le suivant:

# Avant de commencer à travailler
git pull origin main        # Récupérer les dernières modifications

# Développer vos fonctionnalités
git add .
git commit -m "feat: nouvelle fonctionnalité"

# Envoyer vos modifications
git push origin main

git pull est en réalité un raccourci qui combine deux commandes :

git fetch origin           # Télécharge les modifications sans les fusionner
git merge origin/main      # Fusionne les modifications téléchargées

# Équivalent à :
git pull origin main
    💡 Bonne pratique : Effectuez un git pull avant chaque session de travail et avant chaque git push pour éviter les conflits.

Les workflows Git

Connaître Git et GitHub est important, mais ces outils seuls ne garantissent pas une collaboration efficace. La flexibilité de Git, qui permet de l'utiliser de multiples façons, peut devenir un piège : sans règles communes, chaque développeur risque d'adopter ses propres pratiques. C'est pourquoi il est crucial d'établir des normes d'utilisation partagées au sein de l'équipe. Cette section présente le concept de workflow : un ensemble de conventions et de bonnes pratiques qui encadrent l'utilisation de Git et GitHub dans un projet.

Un workflow établit le cadre de travail collaboratif en répondant aux questions : comment et quand créer de nouvelles branches, à quels moments les fusionner, où se trouve le code de production, quelles conventions adopter pour nommer branches et commits. Différents workflows ont émergé au fil du temps, offrant chacun des solutions adaptées à des contextes organisationnels variés.

Un workflow constitue un guide méthodologique pour l'utilisation optimale de Git et GitHub, définissant les règles que l'équipe adopte pour garantir une collaboration efficace. La philosophie de Git privilégie la flexibilité maximale, sans imposer de méthodologie particulière. Cette liberté place la responsabilité du choix entre les mains des équipes. Elles peuvent soit concevoir un workflow sur mesure pour leur projet, soit s'appuyer sur des modèles éprouvés par la communauté. Parmi ces modèles établis, cinq workflows se distinguent particulièrement : le Centralized Workflow, le Feature Branch Workflow, le Trunk Based Development, le GitFlow et le Forking Workflow. Chacun répond à des besoins et des contextes spécifiques.

Les cinq workflows Git essentiels
  1. Centralized Workflow : Tous les développeurs travaillent directement sur la même branche main.
  2. Feature Branch Workflow : Chaque fonctionnalité est développée dans sa propre branche avant d'être fusionnée dans main via une pull request.
  3. Trunk Based Development : Les développeurs fusionnent très fréquemment leurs modifications dans la branche principale, qui reste toujours déployable.
  4. GitFlow : Structure complexe avec des branches dédiées (main, develop, feature, release, hotfix) et des règles strictes de fusion entre elles.
  5. Forking Workflow : Chaque contributeur travaille sur sa propre copie (fork) du repository et propose ses modifications via une pull request au dépôt officiel.

    GitFlow structure le développement avec cinq types de branches (main, develop, feature, release, hotfix) et des règles strictes de fusion, offrant un contrôle rigoureux idéal pour l'open source ou l'encadrement de juniors, mais cette complexité ralentit les équipes agiles. Cependant, l’un des avantages de GitFlow est que vous pouvez faciliter sa mise en place et, surtout, y ajouter des commandes, en utilisant le plug-in GitFlow. Pour plus d'informations, consultez la documentation officielle de GitFlow.

    À l'inverse, Trunk Based Development mise sur des intégrations fréquentes directement sur la branche principale, s'alignant parfaitement avec les pratiques MLOps où l'expérimentation rapide, le versioning des modèles et les déploiements continus sont essentiels. Pour les projets ML, la simplicité du Trunk Based Development permet aux data scientists d'itérer rapidement, de tester des hypothèses et de maintenir une boucle de feedback courte entre l'entraînement et la production, faisant de cette approche le choix privilégié pour les équipes MLOps modernes.

Configuration de GitLens dans VS Code

Pour tirer pleinement parti de GitLens dans un environnement GitHub, configurez l'intégration native en utilisant la fonctionnalité "Connect an Integration". Cette configuration permet à GitLens d'accéder directement aux informations GitHub, enrichissant ainsi l'affichage avec :

  • Pull Requests associées : Visualisation des PR liées aux commits directement dans l'éditeur
  • Issues : Affichage des tickets GitHub connectés aux modifications de code
  • Informations contextuelles : Détails supplémentaires sur les workflows GitHub Actions, les déploiements et les reviews

Procédure d'activation :

  1. Après installation de GitLens, accédez à la palette de commandes (Ctrl+Shift+P / Cmd+Shift+P)
  2. Recherchez "GitLens: Connect an Integration"
  3. Sélectionnez "GitHub" dans la liste des intégrations disponibles
  4. Suivez les instructions d'authentification pour connecter votre compte GitHub

Cette intégration transforme GitLens en véritable centre de contrôle pour votre workflow de développement, centralisant toutes les informations directement dans votre VS Code.

Contents