1. Gitflow vs Trunk-Based Development : Le choix architectural

L’organisation des branches conditionne directement la vélocité et la cadence de livraison logicielle :

  • Gitflow : Modèle traditionnel reposant sur de multiples branches à longue durée de vie (main, develop, feature/*, release/*, hotfix/*). Bien qu’adapté aux cycles de distribution périodiques sur supports physiques, il génère des « enfers de fusion » (Merge Hell) et ralentit les livraisons continues.
  • Trunk-Based Development : Standard absolu du DevOps moderne. Tous les ingénieurs fusionnent régulièrement (au moins une fois par jour) de courtes branches de fonctionnalités (durée de vie < 24-48h) directement dans le tronc principal (main). Les fonctionnalités en cours de développement sont masquées aux utilisateurs finaux grâce aux Feature Flags (ou toggles).

2. Maîtrise du rebase interactif (git rebase -i)

Avant de soumettre une branche à la relecture, le développeur professionnel assainit son historique de travail local :

# Réorganiser et fusionner les 4 derniers commits locaux
git rebase -i HEAD~4

# Interface interactive de sélection :
# pick 3a1b2c4 feat: ajout de la validation IBAN suisse
# squash b5c6d7e fix: correction d'une faute de frappe
# squash e8f9a0b test: ajout des tests unitaires manquants
# reword 1f2e3d4 docs: mise à jour du swagger de l'API

# Sauvegarder et fermer pour obtenir un commit unique et atomique

3. Récupération chirurgicale de commits : git cherry-pick

Lorsque vous devez importer un correctif critique présent sur une branche de test vers la branche de production sans intégrer les fonctionnalités annexes :

# Basculer sur la branche de destination
git checkout production

# Appliquer le commit spécifique identifié par son hash SHA-1
git cherry-pick 7f4a9b2

# En cas de conflit, résoudre le fichier et poursuivre
git add .
git cherry-pick --continue

Règle d’or de l’historique : Ne faites jamais de git push --force sur une branche partagée publique (main, master). Si un renvoi forcé est indispensable sur votre branche personnelle après un rebase, utilisez impérativement git push --force-with-lease pour ne pas écraser le travail d’un pair.

PreviousNext