Branching strategies avec Git

Pourquoi Branching strategies avec Git ?

Contexte réel : pourquoi un dev a besoin de ca au quotidien

Un développeur professionnel utilise souvent Git pour collaborer en équipe, gérer des projets complexes et maintenir une historique précieuse du code. L'utilisation de différentes stratégies de branches permet de gérer efficacement ces projets, de prévenir les conflits, d'organiser le travail entre plusieurs membres de l'équipe et de garantir la qualité du code. En effet, chaque stratégie a ses avantages et est mieux adaptée à certaines situations.

Un cas d'usage concret en 2-3 phrases

Imaginez un projet de développement web où vous avez besoin de travailler sur des nouvelles fonctionnalités tout en corrigeant des bugs présents dans la version actuelle. La stratégie de branching Git Flow serait idéale car elle permet de maintenir une branche stable pour le code en production, une branche de développement principale pour les nouvelles fonctionnalités et plusieurs branches de feature pour travailler sur chaque fonctionnalité individuellement.

Prerequis

• Connaissances nécessaires :

  • Familiarité avec Git (commandes de base comme git init, git clone, git add, git commit, etc.)
  • Compréhension des concepts de base en versionnement
  • Travailler en équipe et comprendre la gestion du code source

• Outils à installer :

  • Git
  • Un IDE ou un éditeur de texte avec une bonne prise en charge de Git (Visual Studio Code, IntelliJ IDEA, etc.)

Concepts fondamentaux

Workflow Git Flow

Le Git Flow est une stratégie de branching très courante et largement utilisée. Il utilise plusieurs branches pour gérer différents aspects du développement.

## Diagramme de Git Flow

• master : La branche principale qui représente la version stable du code. Elle doit être déployée dans la production.
• develop : La branche de développement principale. Toutes les nouvelles fonctionnalités et correctifs doivent être basées sur cette branche.
• feature/* : Chaque nouvelle fonctionnalité est développée sur une branche feature. Par exemple, feature/user-authentication.
• release/* : Une branche release est créée lorsque la version de développement (develop) est prête à être testée. Elle permet de préparer et tester les modifications avant leur déploiement.
• hotfix/* : Une branche hotfix est utilisée pour corriger des bugs critiques dans la version en production. Elle est basée sur la branche master et elle doit être fusionnée avec master et develop.

Workflow GitHub Flow

Le GitHub Flow est une stratégie de branching plus simple qui utilise uniquement deux branches.

## Diagramme de GitHub Flow

• main : La branche principale qui représente la version stable du code. Elle doit être déployée dans la production.
• feature/* : Chaque nouvelle fonctionnalité est développée sur une branche feature. Par exemple, feature/user-authentication.

Workflow GitLab Flow

Le GitLab Flow est similaire au GitHub Flow, mais il utilise des règles spécifiques pour les branches de feature et de merge request.

## Diagramme de GitLab Flow

• main : La branche principale qui représente la version stable du code. Elle doit être déployée dans la production.
• feature/* : Chaque nouvelle fonctionnalité est développée sur une branche feature. Par exemple, feature/user-authentication.
• merge request : Les branches de feature sont soumises en tant que demandes de fusion (merge requests) qui sont revues et testées par les membres de l'équipe avant d'être fusionnées dans la branche main.

Mise en pratique : projet fil rouge

Nous allons créer un simple gestionnaire de tâches pour illustrer ces stratégies. Le projet sera basé sur le workflow Git Flow.

Étape 1 : Initialisation du projet

## Création d'un nouveau répository Git
mkdir task-manager
cd task-manager
git init

## Ajout de fichiers initiaux
echo "title: Task Manager\nversion: 1.0" > README.md

Étape 2 : Création des branches

## Création de la branche develop
git checkout -b develop

## Création d'une branche feature pour une nouvelle fonctionnalité
git checkout -b feature/add-task

Étape 3 : Développement

Créer un fichier task.py avec les fonctionnalités de base.

## task.py
class Task:
    def __init__(self, title, description):
        self.title = title
        self.description = description

    def display(self):
        print(f"Task: {self.title}\nDescription: {self.description}")

Ajouter les modifications et commit.

git add task.py
git commit -m "Add basic Task class"

Étape 4 : Fusionner la branche feature dans develop

## Retour à la branche develop
git checkout develop

## Fusion de la branche feature
git merge feature/add-task

## Suppression de la branche feature
git branch -d feature/add-task

Étape 5 : Création d'une release et fusionner dans main

## Création d'une branche release
git checkout -b release/v1.0

## Ajouter des modifications pour la version 1.0
echo "Version 1.0 released" >> README.md

## Commit
git add README.md
git commit -m "Release v1.0"

## Fusionner dans main
git checkout main
git merge release/v1.0

## Suppression de la branche release
git branch -d release/v1.0

Étape 6 : Corriger un bug en hotfix

## Création d'une branche hotfix pour corriger un bug
git checkout -b hotfix/fix-bug

## Ajouter le code pour corriger le bug
echo "Fixing bug" >> README.md

## Commit
git add README.md
git commit -m "Fix bug"

## Fusionner dans main et develop
git checkout main
git merge hotfix/fix-bug

git checkout develop
git merge hotfix/fix-bug

## Suppression de la branche hotfix
git branch -d hotfix/fix-bug

Erreurs frequentes et debugging

1. Problème : Faites un pull sur une branche et obtenez des conflits.

Code qui cause l'erreur :

git pull origin develop
## Des conflits apparaissent

Code corrige :

## Résolution de conflits manuelle
git add .
git commit -m "Resolve conflicts"

2. Problème : Essayez de fusionner une branche avec des modifications non commitées.

Code qui cause l'erreur :

git checkout develop
git merge feature/add-task
## Error: Your local changes to the following files would be overwritten by merge:
##   task.py

Code corrige :

git stash
git pull origin develop
git stash pop
git add .
git commit -m "Resolve conflicts"

3. Problème : Essayez de créer une branche existante.

Code qui cause l'erreur :

git checkout -b feature/add-task
## Error: A branch named 'feature/add-task' already exists.

Code corrige :

git branch --delete feature/add-task
git checkout -b feature/add-task

Pour aller plus loin

1. Stratégies de branching avancées

• GitLab Flow Extended : Utilise des règles spécifiques pour les branches de feature et de merge request.
• Trunk-Based Development : Fusionne régulièrement la branche principale avec le trunk (ou main).

2. Outils Git avancés

• Gerrit : Un outil pour la gestion du code source et des revues de code.
• GitLab CI/CD : Intégration continue et livraison continue avec Git.

3. Défi pratique

Créez un projet fictif utilisant le workflow GitHub Flow pour gérer les nouvelles fonctionnalités d'un site e-commerce. Incluez des branches de feature, des pull requests et la gestion des conflits.

Conclusion

La stratégie de branching avec Git est cruciale pour maintenir un code source propre, organisé et facilement modifiable. Le choix de la stratégie dépend du projet et de l'équipe, mais tous les workflows proposent des avantages significatifs en termes de gestion du développement et de collaboration. En pratiquant ces stratégies, vous pouvez améliorer votre productivité et garantir la qualité du code.