Comment votre entreprise effectue-t-elle la fusion (merge) ou la rebase (réécriture de l'historique) dans le système de contrôle de version?

Dans notre équipe, nous suivons un flux de travail basé sur Git. Pour intégrer des modifications, nous utilisons deux approches principales : merge et rebase, en fonction de la situation et du type de branche.

Merge :

• S'applique généralement pour fusionner des branches de longue durée, par exemple dev dans main, ou pour intégrer des branches de fonctionnalités dans dev.
• Crée un commit de fusion qui montre clairement quand l'intégration des changements a eu lieu.
• Conserve toute l'histoire des commits, y compris toutes les bifurcations.

git checkout dev  // Passer à la branche cible
git merge feature/nouvelle-fonctionnalité  // Fusionner la branche de fonctionnalité

Rebase :

• Utilisé pour maintenir une histoire propre et linéaire dans les branches de fonctionnalités jusqu'à leur intégration (habituellement dans dev).
• Transfère les commits de la branche courante au sommet de la branche cible (dev), réécrivant effectivement l'histoire.
• Simplifie l'histoire, évitant les commits de merge pour chaque petite fonctionnalité ou correction.
• Important : Ne jamais faire de rebase sur des branches publiques sur lesquelles travaillent d'autres développeurs, car cela peut créer des conflits lors du pull des changements.

git checkout feature/nouvelle-fonctionnalité  // Passer à la branche de fonctionnalité
git rebase dev  // Transférer les commits de la branche de fonctionnalité au sommet de dev
// Résoudre les conflits si nécessaire
git push --force-with-lease  // Utiliser --force-with-lease pour un push sécurisé après rebase

Notre flux de travail standard :

1. Une nouvelle fonctionnalité ou correction est développée dans une branche séparée (feature/..., fix/...).
2. Périodiquement (avant une demande de tirage ou pour synchroniser avec dev), la branche de fonctionnalité est rebasée sur la version actuelle de dev. Cela aide à résoudre les conflits à un stade précoce.
3. Après avoir terminé le développement et la revue de code, la branche de fonctionnalité est fusionnée dans dev avec no-ff (pas en avance rapide), pour conserver l'information de la fusion. Ou, moins fréquemment, elle est squashée en un seul commit avant la fusion dans dev pour des changements très petits ou des corrections.
4. Depuis dev, des versions sont périodiquement déployées dans main (branche de production), toujours par merge.

Ainsi, nous équilibrons la conservation de l'historique des commits (merge) avec le maintien d'une branche de développement propre (rebase des branches de fonctionnalités).