Continuous merge

Qu’est-ce que c’est ?

Le feature branching et intégration continue ne fonctionnent pas bien ensemble. Effectivement, l’intégration continue ne peut utiliser une branche correspondant à la combinaison des développements en cours. L’idée de git-octopus est de réconcilier le feature branching et l’intégration continue.

Le modèle de branche

L’implémentation la plus simple du modèle de branching est d’avoir une branche principale, nommée par exemple master, et des features branches en plus du master, ce qui suffit pour faire du continuous delivery.

  • La branche master est systématiquement dans un état « prêt-à-livrer ». Personne ne commit directement dessus.
  • Les branches features contiennent des modifications, aussi petites que possibles, qui peuvent être livrées indépendamment et mergées dans le master

Ce modèle implique que chaque modification est faite dans une branche feature. Idéalement il faut travailler avec plusieurs branches, par exemple avec une branche par nouvelle fonctionnalité. Il est aussi préférable de garder les branches indépendantes entre elles, ce qui permet la livraison de l’une d’elle à n’importe quel moment.

Feature branch

Le workflow

Le modèle git-octopus permet de merger toutes les branches features à n’importe quel moment afin d’obtenir le résultat du travail en cours, et éventuellement faire une intégration continue sur cette fusion. Ceci permet entre autre de :

  • Valider en continu que les branches fusionnent entre elles : nous détectons tôt les problèmes de merge
  • Exécuter l’intégration continue sur la fusion : nous détectons tôt les effets de bord entre features
  • Construire des environnements de staging qui comprennent plusieurs features : nous pouvons valider rapidement le contenu

L’usage le plus basique de git octopus est d’avoir un job dans l’intégration continue, se déclenchant lors d’un push, exécutant cette commande :

# Fusion des branches features et du master
git octopus origin/features/* origin/master 
# Push du commit résultant sur une branche nommée octopus
git push origin +HEAD:octopus

Ce job fusionne les branches grâce au pattern de nommage, puis push le résultat sur une branche octopus sur le dépôt origin. Ce nouveau commit de merge sur la branche octopus devrait alors déclencher la compilation, les tests, le déploiement, etc. À noter que le commit de merge de l’octopus est un commit jetable et que nous le poussons de manière forcée (git push --force) à chaque fois.

Lorsqu’une feature branche est validée sur l’environnement de test, vous pouvez la fusionner sur le master.

Merge continue

Gérer les conflits

Lorsque git octopus échoue, il s’exécute branche par branche afin de localiser la paire de branche en conflit et l’emplacement de celui-ci. Un exemple d’octopus en conflit :

AMX-11701_pc_cleanup_garanties has conflicts with :
	refs/remotes/features/BUG-6883_Bug_ouverture_BP_pour_les_mauvais_reseaux
OCTOPUS FAILED

Il y a plusieurs manière de résoudre les conflits, entre autre :

  • Essayer d’éviter le conflit en modifiant le code problématique sur l’une des branches
  • Utiliser git conflict pour enregistrer une résolution de conflit et la pusher sur le dépôt
  • Enlever temporairement une des branches en attendant que l’autre soit mergée dans le master
  • Rebaser ou merger l’une branche dans l’autre, à éviter puisque vous perdez l’indépendance des branches

Correction octopus

Contenu du projet git-octopus

git octopus

Étend git merge avec la possibilité de passer des patterns de nommage. Voir git-octopus(1).

# Fusionne toutes les branches nommée features/* dans la branche courante
git octopus features/*

git conflict

Permet d’enregistrer des résolutions de conflit que git octopus peut réutiliser. Les résolutions de conflit sont des refs git qui peuvent être pushée et fetchée. Voir la section « Gestion des conflits » et voir git-conflict(1).

# Démarre la résolution de conflit avec la branche en conflit
git conflict features/BrancheConflit
# Résoudre le conflit normalement
git mergetool
# Terminer la résolution de conflit pour récupérer la refs de résolution à pusher
git conflict --continue

Installation

Prérequis

  • git : version 1.8 et plus
  • shasum : la plupart des systèmes unix l’ont déjà installé, à installer sur Windows

Packages

Pour Homebrew, Debian et RPM des packages git-octopus sont disponibles, voir la documentation d’installation.

Sources

Télécharger la dernière release ou cloner ce dépôt, dans le répertoire exécuter :

# Installation
make install
# Vérification de l'installation
git octopus -v

Communautée

Nous avons un Google Group et nous organisons des meetups git-octopus. Venez discuter avec nous ! Vous pouvez aussi nous envoyer un email à git-octopus@googlegroups.com ou sur notre twitter @BeastieFurets.