Après avoir migré sur Git, le workflow de développement évolue. La gestion de Git et de SVN (notamment) est différente. Je vais expliquer comment j’ai adapté mon workflow de développement en local.

Pour information, j’entends par « workflow de développement » l’ensemble des étapes de la gestion du versionning des sources durant de vos développements.

Dans l’ensemble de l’article j’utiliserai la branche master comme base de développement.

Workflow de dev

Avant de procéder à la migration de nos dépôts, j’ai testé Git un peu plus amplement. La première chose que j’ai remarqué est que la gestion des conflits peut amener à un historique Git chaotique. Pour simplifier cette gestion et éviter les commits inutiles, je me suis renseigné et j’ai fini par définir nouveau un workflow de dev. Ci-dessous un schéma illustrant le workflow que je vais expliquer.

Dans un premier temps, avant de commencer un développement je conseille de toujours créer une branche et de travailler sur cette dernière. On s’isole du master et si un bug urgent apparaît, il est très simple de repasser sur le master, le mettre à jour et faire le hot fixe demandé (dans une autre branche bien entendu).

# créer et passer sur la branche my_modification_name
git checkout -b my_modification_name

Un petit tips : Utilisez des noms de branche très simple pour vous faciliter la vie, par exemple le numéro de l’anomalie ou le nom du use case sur lequelle vous travaillez.

Vous avez fait les modifications nécessaires et les avez commité. Avant de le partager à tous les développeurs, vous devez maintenant mettre à jour votre code, tester vos modifications dans la dernière version du code pour valider le bon fonctionnement.

Pour cela, dans un premier temps, on retourne sur le master afin de récupérer les dernières modifications des collègues.

# Passer sur la branche master
git checkout master
# Mettre à jour le code depuis le serveur distant
git pull

Ensuite, on incorpore ces modifications avec un rebase dans notre branche de développement , cela permet de:

• gérer les conflits éventuelles
• structurer correctement l’historique de git
• vérifier que dans la dernière version du code, tout continue de fonctionner comme prévu

# Passer sur la branche my_modification_name
git checkout my_modification_name
# Déplacer l'origine de la branche pour le dernier commit du master
git rebase master

Quand tout cela est vérifié, on rebascule sur le master pour vérifier que rien n’a été mis sur le serveur pendant nos manipulations précédentes.

Si un développeur a commit entre temps, il faut alors recommencer l’incorporation des modifications de code dans votre branche de développement.

Sinon le reste est un jeu d’enfant, on merge les modifications de notre branche développement dans le master avant de les partager avec les collègues et de supprimer notre branche.

# Passer sur la branche master
git checkout master
# Récupérer les éventuelles modifications faites entre temps
git pull
# Intégrer dans la branche master les modifications que l'on a fait dans la branche
git merge my_modification_name
# Partager les modifications sur le serveur
git push
# Supprimer la branche
git branch -d my_modification_name

Pourquoi faire un rebase ?

Pour expliquer ce que fait le rebase rien de vaut un petit schéma. Les conditions initiales de ce schéma sont les suivantes :

• En utilisant le workflow défini au-dessus nous avons fait plusieurs commits (les 3 en bleus) sur notre branche de développement en local
• Nos collègues eux aussi continué à travailler  deux commits (en rouge) sont apparu sur la branche master lors du pull

Pour faire simple, le rebase déplace le commit d’origine de la branche pour le dernier commit de la branche passé en paramètre (le master dans l’illustration). Les deux commits de vos collègues se retrouvent donc à la fois sur le master et dans la branche. Le rebase importe bien sûr les modifications de code des deux commits, il faudra donc régler les conflits éventuels.

Dans l’exemple illustré, la branche a été créé à partir du commit 2. Sur la branche, il y a eu les commits 3, 4 et 7 alors que nos collègues ont pendant ce temps fait les commit 5 et 6.

L’objectif est d’intégrer proprement les commits de nos collègues  avec le rebase. Le rebase va permettre de changer l’origine de la branche du commit 2 au commit 6. Ainsi les changements effectués par les collègues seront intégrés à la branche, et les commits de la branche de dev seront regroupés ensemble dans l’historique lors du merge de la branche de dev avec le master.

Pour conclure

Ce petit workflow de dev est assez simple à suivre et permet beaucoup de flexibilité. Son gros avantage est de permettre plusieurs tâches en parallèle à partir d’une même branche de code.

Au-delà d’avoir une bonne gestion local des branches pour s’autoriser le plus de flexibilité possible, il faut également une bonne gestion de branches sur le dépôt. Cela n’est pas le sujet de l’article, je vous invite à vous renseigner sur le github flow et sur le git flow qui sont les flows les plus connus et communément utilisés.

 

Merci Amaury et Mathieu pour vos relectures !

Partager l'article :