Guide simple de git

Pourquoi Git est devenu indispensable

Git est un système de contrôle de version distribué. Il enregistre l’historique d’un projet et permet de retrouver, comparer et valider les changements dans le temps.

Concrètement, Git sert a :

  • Tracer qui a modifie quoi, quand et pourquoi
  • Collaborer a plusieurs sans se bloquer mutuellement
  • Tester des idées dans des branches sans risquer la version stable
  • Revenir en arrière en cas de régression
  • Structurer un processus d’équipe (revue de code, pull request, intégration continue)

Sans outil de versioning, les projets finissent souvent avec des copies du type site-final-v2-bis.zip, difficiles a maintenir et risquant de perdre des corrections importantes.

Un peu d’historique

Git a été crée en 2005 par Linus Torvalds (créateur de Linux). A l’époque, la communauté Linux avait besoin d’un outil :

  • Très rapide
  • Fiable sur de gros volumes de code
  • Distribué (chaque développeur dispose d’un historique complet en local)

Ce positionnement a fait de Git le standard de fait de l’industrie, adopte ensuite massivement par les plateformes comme GitHub, GitLab et Bitbucket.

Installation

Windows

Téléchargez Git depuis git-scm.com puis suivez l’assistant d’installation.

macOS

Installez Git via Homebrew ou les outils de développement Apple.

Linux

Installez Git via le gestionnaire de paquets de votre distribution (apt, dnf, pacman, etc.).

Configuration initiale

La première étape consiste à définir votre identité Git (nom et e-mail). Elle sera associée aux commits et facilitera le suivi des auteurs.

Notions essentielles à connaître

Dépôt local et dépôt distant

  • Le dépôt local est votre copie de travail sur la machine.
  • Le dépôt distant (souvent sur GitHub/GitLab) centralise le partage avec l’équipe.

Zone de travail, staging, commit

  • Working directory : vos fichiers modifiés.
  • Staging area : les changements sélectionnés pour le prochain commit.
  • Commit : un point d’historique avec un message explicite.

Branches

Une branche est une ligne de travail isolée. Elle permet de développer une fonctionnalité, corriger un bug, puis fusionner proprement dans main après validation.

Flux de travail recommandé

  1. Créer une branche de fonctionnalité.
  2. Faire des changements petits et cohérents.
  3. Commiter régulièrement avec des messages clairs.
  4. Synchroniser avec la branche principale pour limiter les conflits.
  5. Ouvrir une Pull Request pour revue.
  6. Fusionner après validation et tests.

Bonnes pratiques

  • Faire des commits fréquents et atomiques
  • Écrire des messages de commit précis (contexte + action)
  • Éviter les commits trop volumineux
  • Faire un pull avant un push
  • Protéger la branche main (revue obligatoire, CI verte)
  • Utiliser .gitignore pour exclure les fichiers non versionnables

Exemples courants dans .gitignore : node_modules/, .env, *.log, dist/, .DS_Store.

Points de vigilance

  • git reset --hard est destructif et doit être utilisé avec précaution.
  • Un push --force peut écraser l’historique distant d’autres collaborateurs.
  • En cas de doute, privilégiez les commandes non destructives (restore, nouvelle branche, revert).

Exemples

# 1) Définir son identité (une seule fois sur la machine)
git config --global user.name "Prenom Nom"
git config --global user.email "prenom.nom@entreprise.com"

# 2) Cloner le projet puis entrer dans le dossier
git clone https://github.com/organisation/mon-projet.git
cd mon-projet

# 3) Créer une branche de travail et s'y placer
git checkout -b feature/formulaire-contact

# 4) Vérifier l'état du dépôt, ajouter les modifications et commiter
git status
git add .
git commit -m "Ajout du formulaire de contact avec validation"

# 5) Récupérer les derniers changements de la branche principale
git checkout main
git pull origin main

# 6) Revenir sur la branche feature et pousser les commits
git checkout feature/formulaire-contact
git push origin feature/formulaire-contact

# 7) Ouvrir une Pull Request, puis consulter l'historique local
git log --oneline -5