Les bonnes manières de Git

Voici une procédure/un workflow à suivre pour le versionning Git parmi tant d’autres.

Git, on peut l’utiliser dans tous les sens. Comme partout, il y a des bonnes façons de faire. Nous allons voir quelques bonnes méthodes à suivre pour développer son projet avec Git.

Il y a plusieurs façon d’utiliser Git. Voici une manière utilisée par beaucoup de projet. Vous pouvez consulter des dépôts Github comme ceux de Mozilla Firefox, Jquery ou d’autres grands projets open source. Vous verrez que ces projets suivent approximativement cette méthode ou des dérivées de cette méthode. Ça permet d’être mieux organisé. Ne pas oublier que c’est une façon parmi tant d’autres.

Ces « manières » de procéder sont parfois appelées des « modèles de développement ».

Les bonnes manières de Git

Cette méthode utilise cinq grands groupes de branches Git qui ont chacune un but spécifique :

• Master : Elle contient le code source reflétant celui en production, donc fonctionnel.
• Develop : Elle contient le code en développement.
• Feature : Elle contient le développement des nouvelles –grosses– fonctionnalités.
• Release : Elle contient les versions de votre application.
• Hotfix : Elle contient les bugs/failles urgents à résoudre en production.
• Peut-être d’autres suivants les cas de développement

Les branches « master » et « develop » sont les seules qui vivent indéfiniment. Les autres branches ont une durée de vie limitée.

Branche « master »

La branche « master » représente le code actuellement en production. Personne ne commit sur cette branche.

A chaque fois que des modifications seront appliquées sur la branche « master », ça sera une nouvelle version de notre application.

Branche « develop »

Le groupe de branches « develop » représente le code en développement. Personne ne commit directement sur cette branche.

Pour tout développement, même le moindre petit développement, on crée une branche « develop-bug_user » qui dérive de « develop ». Une fois le développement terminé, on merge la branche du développement dans la branche « develop ».

Une fois que vous avez assez développé pour publier l’état actuel de votre application, vous pouvez appliquer la branche « develop » sur la branche « master ».

Branche « feature »

Le groupe de branches « feature » permet de développer les grosses fonctionnalités sans gêner les autres développements. Par exemple, vous tenez un site, et vous voulez y ajouter un forum, mais vous ne voulez pas déranger les autres codeurs qui continuent d’améliorer l’espace membre ou le chat de votre site, vu que c’est une grosse fonctionnalité qui va vous prendre du temps, vous créer une branche « feature-forum » afin d’y développer votre fonctionnalité, sans se soucier de ce qui est en cours de développement, et sans que les développeurs de la branche « develop » ne se soucie de ce que vous développez. Encore une fois, c’est une façon de faire, rien ne vous empêche de développer cette fonctionnalité dans une branche « develop-forum ».

• La branche doit provenir de « develop ».
• La branche doit être merger dans « develop ».
• La branche doit s’appeler « feature-* » où « * » représente le nom de la fonctionnalité à développer.

Pour créer la branche :

$ git checkout -b feature-forum develop // On crée la branche « feature-forum »

Vous développez. Une fois fini, pour merger la branch « feature-forum » dans « develop » :

$ git checkout develop // On se positionne sur la branche « develop »
$ git merge --no-ff feature-forum // On « aspire » les commits de la branche « feature-forum » dans la branche « develop »
$ git branch -d feature-forum // On supprime la branche « feature-forum » qui ne sert plus à rien
$ git push origin develop // On pousse les modifications sur le dépôt

Il vaut mieux utiliser « git merge –no-ff » pour merger les branches afin de ne pas perdre les informations liées à la branche qui a été créée. Sans le paramètre « --no-ff », les commits de la branche « feature-forum » aurait été incorporé dans la branche « develop » et on aurait perdu les informations liées à la branche « feature-forum ». Le schéma montre le résultat des deux commandes :

Branche « release »

Le groupe de branches « release » contiendra toutes les releases de votre application. Avant le déploiement de la release, on peut, dans cette branche, préparer les métadonnées comme le nom de la version, la date de publication…. Après le déploiement de la release, on peut éventuellement corriger les petits bugs découverts.

Le moment idéal pour créer une branche « release-* » est quand la branche « develop » reflète les fonctionnalités désirées pour la prochaine version.

• La branche doit provenir de « develop ».
• La branche doit être merger dans « develop » et « master ».
• La branche doit s’appeler « release-* » où « * » représente le nom de la release.

Pour créer la branche « release-1.2 » :

$ git checkout -b release-1.2 develop // On crée la branche « relrease-1.2 »
$ git commit -a -m "Bumped version number to 1.2" // On fait un petit commit pour savoir où on en est

On peut préparer la release : changer les dates, les numéros de version sur le site ou réparer des petits bugs.

Quand la release est prête à être publiée :

$ git checkout master // On se positionne sur la branche « master »
$ git merge --no-ff release-1.2 // On “aspire” les commits de la branche “release-1.2” dans la branche « master »
$ git tag -a 1.2 // Et on tag la release

Si on a eu des bugs, il faut appliquer les corrections dans la branche « develop » :

$ git checkout develop // On se positionne sur la branche « develop »
$ git merge --no-ff release-1.2 // On aspire les commits de la branche « release-1.2 » dans la branche « develop »

Vous pouvez laisser la branche vivre le temps que vous désirez. Une fois que l’application a été développée et que cette release se fait vieille, on supprime la branche :

$ git branch -d release-1.2 // On supprime la branche « release-1.2 »
$ git push origin develop // On pousse les modifications sur le dépôt

Branche « hotfix »

Ce qu’on appelle un hotfix, c’est une résolution urgente d’un bug qu’on a découvert en production. On n’attend pas la prochaine version de l’application pour résoudre le bug car il est sensible pour l’application ou représente une faille.

On crée une branche « hotfix-bug_xxx » qui dérive de master ou du tag où le bug a été trouvé. On corrige le bug/la faille, on le test, et si les tests sont concluant, on applique la correction sur la branche « master » ET sur la branche « develop ». Sur la branche « develop » car ça serait bête de retrouver le bug sur la prochaine version de l’application.

• La branche doit provenir de « master ».
• La branche doit être merger dans « master » et « develop ».
• La branche doit s’appeler « hotfix-* » où « * » représente le nom du bug/de la faille à corriger.

Pour créer une branche « hotfix-1.2.1 » :

$ git checkout -b hotfix-1.2.1 master // On crée une branche « hotfix-1.2.1 »
$ git commit -a -m "Bumped version number to 1.2.1" // On écrit un commit pour savoir où on en est

On corrige le bug :

$ git commit -m "Fixed severe production problem"

Et pour finir le hotfix :

$ git checkout master // On se positionne sur la branche « master »
$ git merge --no-ff hotfix-1.2.1 // On applique les corrections de la branche « hotfix-1.2.1 » sur la branche « master »
$ git tag -a 1.2.1 // On tag la nouvelle version

Et on n’oublie pas d’appliquer les corrections aussi à la branche « develop » :

$ git checkout develop // On se positionne sur la branche « develop »
$ git merge --no-ff hotfix-1.2.1 // On applique les corrections de la branche « hotfix-1.2.1 » sur la branche « develop »

Attention, petite difficulté, si une nouvelle branche release était en cours, la correction doit peut-être lui être appliquée à elle aussi.

Quand on en a fini avec la branche, on la supprime :

$ git branch -d hotfix-1.2.1 // On supprime la branche « hotfix-1.2.1 »
$ git push origin develop // On pousse les modifications sur le dépôt

Exemple

Vous pouvez trouver un exemple de dépôt respectant cette méthode, semblable au schéma en introduction ici :
https://github.com/dada17xs/git-tactics\

Commencer un dépôt

git init // On initialise le dépôt git
git checkout –b develop master // On crée la branche « develop » qui provient de la branche « master »

// DEVELOPPEMENT
git checkout –b develop-customize_form develop // On crée une branche « develop-customize_form» qui provient de la branche « develop »
// On développe et on commit
git commit –a –m "end of form customize" // Dernier commit du développement
git checkout develop // On se positionne sur la branche « develop »
git merge –no-ff develop-customize_form // On aspire les modifications de la branche « develop-customize_form » dans la branch « develop »
git branch –d develop-customize_form // On supprime la branche
$ git push origin develop // On pousse les modifications sur le dépôt

// NOUVELLE FONCTIONNALITE
git checkout –b feature-forum develop // On crée une branche « feature-forum » qui provient de la branche « develop »
// On développe et on commit
git commit –a –m "end of forum feature" // Dernier commit du développement de cette fonctionnalité
git checkout develop // On se positionne sur la branche « develop »
git merge –no-ff feature-forum // On aspire les modifications de la branche « feature-forum » dans la branch « develop »
git branch –d feature-forum // On supprime la branche
$ git push origin develop // On pousse les modifications sur le dépôt

// NOUVEAU HOTFIX
git checkout –b hotfix-submit_button master // On crée une branche « hotfix-submit_button » qui provient de la branche « master »
// On développe et on commit
git commit –a –m "end of hotfix resolution" // Dernier commit du développement de cette fonctionnalité
git checkout master // On se positionne sur la branche « master »
git merge –no-ff hotfix-submit_button master // On aspire les modifications de la branche « hotfix-submit_button » dans la branch « master »
$ git push origin master // On pousse les modifications sur le dépôt
git checkout develop // On se positionne sur la branche « develop »
git merge –no-ff hotfix-submit_button develop // On aspire les modifications de la branche « hotfix-submit_button » dans la branch « develop »
git branch –d hotfix-submit_button // On supprime la branche
$ git push origin develop // On pousse les modifications sur le dépôt


// NOUVELLE RELEASE
git checkout –b release-0.1 develop // On crée une branche « release-0.1 » qui provient de la branche « develop »
git commit –a –m "end of preparation" // On prépare la release pour déploiement
git checkout master // On se positionne sur la branche « master »
git merge –no-ff release-0.1 // On aspire les modifications de la branche « release-0.1 » dans la branch « master »
git tag -a 0.1 // Et on tag la release
$ git push origin master // On pousse les modifications sur le dépôt

Mémento

Une fois que vous connaissez ces méthodes, si un jour vous ne vous souvenez plus des commandes à exécuter ou de leur ordre, vous pourrez consulter le mémento des bonnes procédures de Git.

Conclusion

Vous avez les clés en main pour avoir un dépôt Git propre. Maintenant, si vous êtes seul derrière votre projet, mettre tout ça en place vous prendra plus de temps que de vous en faire gagner. C’est à vous de juger ce qui est utile ou pas pour l’organisation de votre projet.

Si vous développer seul, vous pouvez très bien développer directement dans la branche « develop » sans créer de sous-branches « develop-something » et garder la branche « master » qui reflètera votre code en production. Ça sera déjà bien organiser pour une personne seule. Ces pratiques deviennent intéressantes quand vous êtes nombreux à développer un même projet.

Suppression d’une branches sur le dépôt

Pour supprimer la branche « branch » du serveur :

git push origin :branch