Je viens vous parler ici d’un retour d’expérience sur l’installation et l’utilisation de Git et du GitFlow pour la gestion de projets de développement. Les postes de développement étant sous Windows (avec des serveurs sous Debian et Ubuntu). Le client choisi pour gérer le GitFlow est SourceTree qui l’intègre nativement. Git est venu remplacer SVN en tant que gestionnaire de source pour différents projets. Il a apporté un confort indéniable dans la gestion de nos développements.

Installation d’un dépôt Git référent local

L’idée est d’installer un dépôt principal (on ne parle pas vraiment de serveur avec Git) en local, afin d’héberger nos sources, et ne pas faire appel à un dépôt extérieur, comme via GitHub par exemple. Nous avons donc installé Git sur un des serveurs. L’installation est assez simple, vous trouverez un pas à pas ici par exemple. Ce dépôt servira à faire la passerelle entre les git installés sur les postes de développement, qui pousseront les modifications de code, et la production qui sera liée au git (les mises en production se faisant en demandant à rapatrier le master, nous y reviendrons plus loin).

Chargement d’un premier projet sur Git

Nous allons maintenant charger un premier projet sur le dépôt référent. Ce projet existe, mais il n’est pas encore versionné au travers de Git. Pour cela, il faut suivre les étapes suivantes :

• création d’un dépôt vide
• chargement des sources dans ce dépôt

Pour le premier point, c’est assez simple, il faut se rendre sur la machine hébergeant le dépôt référent Git et taper la commande suivante :

git init --bare monProjet

qui aura pour effet de créer un dépôt vide nommé « monProjet ».

Pour charger les sources dans ce projet, il faut cette fois ci se rendre dans le dossier qui contient les sources et taper les lignes suivantes (il faudra installer le paquet Git sur cette machine si ce n’est pas déjà fait) :

git init
git add .
git remote add origin ssh://git@monServeurGit:22/git/repository/monProjet
git commit -m 'commit initial'
git push -u origin master

La première instruction permet d’initialiser Git. La deuxième d’ajouter tout le contenu au gestionnaire de version. La troisième de faire la connexion au dépôt référent (ici appelé monServeurGit, à remplacer par le nom ou l’IP). La quatrième de commiter et la dernière de faire le push vers le dépôt référent. Une fois le push fait, le dépôt référent contient maintenant les sources du projet.

Utilisation du GitFlow avec SourceTree

Une fois le dépôt créé, vous allez pouvoir le charger dans SourceTree via le bouton « Clone / New ». Vous arrivez alors sur une première fenêtre. Elle vous demande l’url de votre dépôt et le dossier local (celui sur votre poste que vous chargerez ensuite en tant que projet dans votre IDE). L’url de dépôt sera celle créé dans le chapitre précédent.

Vous pouvez alors cliquer sur « Clone » pour finaliser le rattachement. Ensuite, il va falloir charger le GitFlow, et cela va se faire avec le bouton dédié dans le ruban. On premier clic sur ce bouton, vous allez paramétrer les différentes branches. En permanence dans votre projet vous aurez deux branches :

• develop (branche de développement)
• master (branche de production)

Se rajouteront ensuite à ces branches celles que vous créerez au cours de vos développements (nous allons y revenir). Normalement, vous n’avez pas à faire de modifications directes dans les branches develop et master. Pour modifier le code et l’intégrer ensuite à la production vous avez à disposition les différents éléments du GitFlox :

• Feature
• Hotfix
• Release

Feature

Une feature correspond à une nouvelle fonctionnalité dans le projet, dont le développement va nécessiter plusieurs commits (donc pas une modification immédiate mais un développement à court ou moyen terme, nous reviendrons également plus tard sur la notion de commit). Pour créer une feature, il faut passer par le bouton « GitFlow », « Start new feature ». Une boîte de dialogue s’ouvre :

Il suffit de donner un nom à cette feature (essayez d’être le plus explicite possible par rapport au développement que vous avez à faire). Quand vous cliquez sur Ok, vous la verrez apparaître dans la liste des branches, sous le dossier feature.

Il est possible de créer plusieurs features en parallèle, d’en ouvrir et de les supprimer par exemple pour faire un essai. On passe d’une feature à l’autre en double cliquant dans la liste des branches sur la feature qui nous intéresse. A savoir que si vous modifiez ensuite un fichier, il sera modifié dans la feature sélectionnée (donc le positionnement dans la bonne feature est très important avant de coder). Pour coder, vous utilisez toujours votre IDE habituel.

Il est possible ainsi d’avoir plusieurs features qui travaillent sur les mêmes fichiers, en passant d’une feature à l’autre vous retrouverez l’état du fichier telle qu’il a été modifié dans la feature (très pratique donc). A noter que pour des accès concurrents à un même fichier modifié dans deux features, il vous faudra pour pouvoir basculer d’une feature à une autre commiter ou stasher le ou les fichiers en question (nous y reviendrons un peu plus loin).

Au fur et à mesure du développement, vous pouvez commiter vos modifications. A noter que le commit n’affecte que la feature en cours. Vous pouvez commiter plusieurs fois un même fichier dans une feature au fur et à mesure de son développement. Le commit dans ce cadre là est une photo du fichier dans la feature. Si vous venez de SVN, oubliez la notion de commit telle que vous la connaissez donc. Le fait de commiter n’a pas pour effet de pousser votre code sur le dépôt distant, cela reste exclusivement local.

Pour suivre les modifications et commiter, il faudra passer par l’onglet « File Status » de SourceTree :

 

Dans cet onglet, vous verrez vos fichiers créés (point d’interrogation bleu), modifiés (trois points jaunes) ou supprimés (rouges) dans la partie « unstaged files » (zone 1). Cette partie rassemble pour la feature ou le hotfix courant tous les fichiers qui ont été modifiés et pour lesquels aucune action n’a été faite encore. Si vous souhaitez commiter ou stasher (correspond au fait de les mettre de côté pour l’instant, ce sont des fichiers dans un état pas encore prêt à être commité, mais dont les modifications souhaitent être conservées, cela sera à faire par exemple pour passer d’une feature à une autre avec des modifications concurrentes non commitées) vous devrez les cocher (cela aura pour effet de les faire passer dans la zone 2) et de cliquer sur le bouton commit ou stash. Il faudra alors dans la zone basse entrer un commentaire de commit et cliquer sur le bouton.

Si vous ne souhaitez pas conserver les modifications faites, vous pouvez faire un clic droit sur le fichier et choisir « Discard » qui aura pour effet de le faire revenir à l’état antérieur. La zone 3 indique d’ailleurs les modifications faites au fichier.

Quand vous aurez terminé votre feature, en étant positionné sur celle-ci (elle doit donc être en gras), vous pourrez via le bouton « GitFlow » choisir « Finish feature ».Le fait de finaliser la feature aura deux effets :

• cela basculera les modifications sur la branche develop (locale)
• cela supprimera la feature

Si vous avez une erreur au moment de fermer la feature, il y a de fortes chances que cela vienne d’un fichier non commité, ou d’un conflit.
Une fois la feature finalisée, vous aurez donc les modifications dans votre branche develop locale. Vous pourrez alors faire un « push » pour pousser ces modifications à la branche develop distante. A ce moment-là, les modifications ne sont pas en prod, elles pourront passer avec une release.

Hotfix

Un HotFix correspond à une correction de bug en production, ou un ajout rapide de fonctionnalité qui ne nécessite qu’un commit. Le Hotfix se crée via le bouton « GitFlow », « Start new hotfix ». De la même manière que pour une feature, vous allez ensuite pouvoir développer, commiter les modifications et fermer le hotfix (via le bouton « GitFlow », « Finish Hotfix »).

Les impacts de la finalisation du hotfix sont différents de la clôture d’une feature. Car les modifications sont basculées directement sur la branche master. Du coup, en poussant (push) les modifications cela va les pousser sur la branche master distante (ainsi que sur la develop).

Release

Une release va permettre d’intégrer à la branche master les features terminées et intégrées à la branche develop. Il suffit d’ouvrir la release (via le gitflow) en lui donnant un nom (du type 1.1.0) et de fermer la release. Il suffit ensuite de pousser sur le master distant les modifications.

Mise en production

Pour mettre en production votre projet, il faut que sur le serveur de production Git soit installé et que les sources soient liées au dépôt. La production est dans ce cas liée à la branche master distante.

Une fois ces pré-requis de départ bons, vous pouvez du coup faire vos développements en utilisant des features ou hotfix. Vous intégrez le tout dans la branche master locale, et poussezr sur le distant (via push). Une fois tout sur le distant, la production peut charger la branche master distante avec cette simple commande (à jouer à la racine du projet) :

git pull origin master

Mise à jour de son environnement

Pour mettre à jour son environnement avec les modifications qui se trouvent sur les branches distantes, on peut faire un « fetch ». Il va vérifier s’il y a des choses à récupérer, mais c’est fait en automatique régulièrement. Et un « pull » pour récupérer effectivement les modifications.

Mise à jour d’une feature

Si une feature est longue à développer, il peut être intéressant de régulièrement la mettre à jour en intégrant les modifications du develop. Cela évitera un trop grand gap entre les deux et des conflits possibles résultant de cet écart. Pour cela, en étant positionné sur la feature à mettre à jour (elle est en gras donc), il faut cliquer une fois sur develop, faire un clic droit et choisir « Merge develop into current branch ».

Résumé des actions par type

Résumé du passage d’un hotfix

Start new hotfix…développement…passage des fichiers de « unstaged files » à « Staged files »…commit…finish hotfix…push sur SourceTree.
git pull origin master en prod

Résumé du passage d’une feature

Start new feature…développement…passage des fichiers de  » unstaged files  » à « Staged files »…commit…finish feature…push sur SourceTree.
Il faudra ensuite faire une release incluant cette feature (avec d’autres éventuellement) pour la passer en production.

Résumé du passage d’une release

La release va faire passer le develop dans le master. Du coup, il faut faire un new release, fermer la release et faire un push, puis un git pull origin en prod.