Les bonnes pratiques avec git

Quelques bonnes pratiques lorsque l'on utilise git.

Lors de la création d'un nouveau dépôt

Placer un fichier README.md à la racine du dépôt. Celui-ci contiendra toute les informations relatives au projet (description de l'application, installation, paramétrage, utilisation ...). La rédaction se fait en Markdown.

En travaillant à plusieurs sur un dépôt distant

Avant de travailler penser à mettre à jour les sources locales :

git pull

Envoyer régulièrement son travail sur le dépôt distant pour éviter les conflits de fusion :

git add -A
git commit -m 'new feature'
git push

Lors du commit

Ecrire un message clair et concis qui explique les modifications que vous avez apportées. Ca ne sert a rien de préciser les fichiers modifiés car un git diff permettra de le savoir ...
Utiliser la même syntaxe d'écriture de message de commit que toute l'équipe. Voici des exemples de règles à appliquer lors de la rédaction d'un message de commit :

  • écrire en anglais (bien que parfois il vaut mieux un bon français qu'un mauvaise anglais)
  • le sujet est une description succinte (il ne doit pas dépasser 50 caractères, avoir une majuscule à la première lettre, ne pas se terminer par un point et utiliser des verbes à l'impératif)
  • séparer le sujet du corps par une ligne vide
  • le corps du message doit expliquer la raison du changement (il faut utiliser des verbes à l'impératif et chaque ligne ne doit pas dépasser 72 caractères - 4 espaces d'indentation et 68 caractères). Il ne faut pas entrer dans les détails techniques du code

Il peut être intéréssant de préfixer le sujet des commits par un type :

  • Feat : nouvelle fonctionnalité
  • Fix : correction de Bug
  • Docs : un changement dans la documentation
  • Style : un changement qui n'affecte pas le sens du code (ex: une indentation)
  • Test : un ajout de test
  • Perf : une amélioration de performance
  • Refactor : un changement qui n'est ni une correction de Bug ni un ajout de fonctionnalité

Ou simplement par un ID correspondant à un ajout de fonctionnalité ou une remontée de bug (ex : #2513:). Celui-ci permettra de rapidement retrouver le descriptif sur la forge logiciel (BugTracker). Voici des exemples de sujet de message :

# New Feature
git commit -m 'Allow users to delete old posts'
# BugFix
git commit -m '#2513: Résolution des dépendances Maven'
# Code review
git commit -m 'Refactor comment module for readability'

Versionner un projet

Le versionning couplé aux branches permettent de faciliter le travail des développeurs. Il aide a instaurer des timelines, permet de décrire l'état d'une application par rapport à sa version (fonctionnalités, bugs, correctifs ...), facilite le travail collaboratif, permet de revenir dans un état antérieur, permet de rendre les versions indépendantes les unes des autres (par exemple : BugFix sur une ancienne version d'un logiciel sans impacter la dernière version) ...

Généralement les versions suivent la syntaxe suivante : X.Y.Z. Ou X, Y et Z sont des entiers :

  • X : version majeur - refonte "total" de l'application (exemple : changement de framework)
  • Y : version mineur - ajout de fonctionnalités (exemple : ajout d'un connecteur LDAP)
  • Z : version BugFix - correction de Bugs (exemple : génération d'un message d'erreur à destination de l'utilisateur qui l'informe d'une mauvaise saisie au lieu d'enregistrer une donnée érronée)

Un exemple de version 2.1.0 qui se traduit sous git par :

# ajouter un tag avec une annotation, ici '2.1.0'
git tag -a 2.1.0 -m 'New release 2.1.0'

De plus grâce aux tags il devient facile de revenir sur une ancienne version pour corriger des Bugs :

# se positionner sur une version precise en creant une nouvelle branche
git checkout -b 'v1' 1.5.4
By @Mikael FLORA in
Tags : #système,