Archives de catégorie : Développement

Logo Git

Tips to dig into git log

Publié dans Développement | Laisser un commentaire

I am a regular user of git dag <sourcefilepath> to check all commits applying on a single source file. You can also do it with gitk <sourcefile> but I always find git dag more convenient.

git dag interface

Recently, I had to check the changes made on a specific line of a source file. I started digging into 7 years of commits… and obviously it was time to search for a better option 🙂

Fortunately, git log is really powerful.

First you can list commits with an impact on a specific function using the -L option. The diff are display immediately which is pretty handy. For example: git log -L:sendTcpRequest:src/evcc/Evcc.cpp. The -L option be used for numerous other stuff, please check git log --help.

This was still listing dozen of diff. The -G option allows to directly search on all the diffs and list related commit. For example git log -G "flush" Evcc.cpp was listing me 3 commits with a diff containing the word « flush ».

The Rules of Life

Règle #2 – Changelogs & Release notes

Publié dans Développement | Laisser un commentaire

Une bonne pratique de taille pour fiabiliser le développement logiciel, c’est de toujours garder une liste « humaine » des changements apparus de versions en versions.

On peut noter 3 degrés d’historique :

  • Git history : pour le développeur
    • git log, gitk
    • Moi je me suis créé un alias Git pour afficher joliment les derniers commits dans ma ligne de commande: git lasts
      • Ajouter l’alias suivant dans le fichier ~/.gitconfig: lasts = log -35 --pretty=tformat:"%C(red)%h%x20%C(magenta)%ad%C(auto)%d%x20%C(green)%s%C(white)%x20-%x20%an%C(auto)" --date=short --abbrev-commit --graph --decorate
  • Changelogs : pour l’utilisateur averti, pour le validateur
  • Release notes : pour le client, pour le « non technique »
    • Format à définir avec les personnes concernées
    • Focus sur les fonctionnalités et les changements visibles

The Rules of Life

Règle #1 – Numéro de version

Publié dans Développement | Laisser un commentaire

Règle #1 pour livrer du logiciel : définir un numéro de version !

Quel numéro choisir ?

Le must du must est d’utiliser et de suivre le Semantic versioning. C’est-à-dire, d’utiliser trois chiffres :

MAJOR.MINOR.PATCH

  • MAJOR : incompatible API / ABI changes,
  • MINOR : functionality added in a backwards-compatible manner
  • PATCH : backwards-compatible bug fixes

Ce qui implique que si je trouve un bug dans ma bibliothèque v3.1.2, que je corrige ce bug, je vais publier ce correctif dans une nouvelle v3.1.3 uniquement si je n’ai pas fait de changements bloquants (c’est-à-dire que mon soft qui tournait avec la v3.1.2 de cette bibliothèque pourra utiliser v3.1.3 sans rien changer). Si mon correctif implique des changements bloquants (pas de bol), il faut changer le numéro de version majeur (v4.0.0), eh oui.

Trouver le numéro de version

Il n’y a rien de pire que de faire tourner un soft et de ne pas savoir quelle est la version qui tourne. Avoir un numéro de version c’est bien beau, mais il faut aussi l’afficher quelque part :

  • Au démarrage du soft
  • Dans un log
  • Sur l’IHM
  • Dans l’API

N’importe où, mais quelque part !

Modifier le numéro de version

Un autre corollaire de cette règle #1, c’est qu’il faut pouvoir modifier facilement ce numéro de version. Il doit être défini en un unique endroit. Par exemple :

  • Qt : Le fichier .qmake.conf est inclue au début de chaque fichier .pro et .pri, c’est le candidat idéal
  • PHP / Symfony : app/config/config.yml

Selon son architecture de développement, on peut aussi s’assurer qu’un tag Git vient préalablement mettre à jour le numéro de version dans le code.