Les commandes Git : se faciliter la vie (3/3)

Nous poursuivons la série d’article sur Git, vous pouvez retrouver les articles précédents à ces liens :

Il s’agit du dernier article de la série sur les commandes Git. L’objectif de ce dernier article est d’aborder certaines autres fonctionnalités de Git qui permettent de se faciliter la vie. Il présente certaines configurations comme les Git Ignores, la configuration de « mergetool » et l’ajout d’alias. Il abordera également les commandes Git « bisect », « stash » et « diff ».

Git Ignore

Cette fonctionnalité de Git permet de ne pas suivre certains fichiers avec le versionning de Git. Il est possible, par exemple, de dire à Git que l’ensemble des fichiers du répertoire « bin » ne doivent pas être suivis ou que le fichier « toto.txt » n’est pas à suivre non plus.

C’est extrêmement pratique dans pas mal de cas, par exemple pour ignorer :

les fichiers binaires ou fichiers compilés
les fichiers de propriétés personnalisés
les fichiers spécifiques à l’environnement de développement
les fichiers spécifications à votre OS
les fichiers de logs

Comment configurer Git Ignore ?

Git Ignore se base sur les fichiers nommés « .gitignore » dans votre projet Git. Lorsqu’un fichier « .gitignore » est créé, son paramétrage s’applique au dossier courant et ses sous-dossiers. De ce fait plusieurs Git Ignore peuvent s’appliquer sur un même dossier.

Imaginons un projet, composé de deux sous-dossiers :

le dossier « src » qui contient toutes les sources
le dossier « autres » qui contient tous les autres documents

Ainsi, si on créé un fichier « .gitignore » à la racine du projet, il va s’appliquer sur les deux sous-répertoires ainsi qu’à leurs contenus et sur les fichiers à la racine.

Puis on créé un autre fichier « .gitignore » dans le dossier « src », suite à cela les deux « .gitignore » s’appliquent sur le dossier « src » et seulement le premier s’applique sur le dossier « autres ».

Remplir le fichier .gitignore

Maintenant que les concepts sont posés, il faut paramétrer ce fameux fichier. Cela fonctionne avec des patterns, un pattern par ligne dans le fichier. Le plus simple est de montrer quelques exemples :

# ignorer le fichier toto.txt à la racine du projet
/toto.txt

# ignorer tous les fichiers .project de Eclipse du projet
.project

# ignorer tous les fichiers compilés java (.class) du projet
*.class

# ignorer tous les dossiers de configurations Eclipse ".settings" et leurs contenus
.settings/

# ignorer tous les fichiers dont l’arborescence termine par /docroot/WEB-INF/.gitignore
**/docroot/WEB-INF/.gitignore

Ce dernier exemple est un peu particulier. Un de mes plugins Eclipse me créé des fichiers « .gitignore » automatiquement que je ne souhaite pas embarquer dans mon versionning.

Il est possible de trouver plus d’informations à propos des Git ignores et des patterns sur le site de Git. On trouve beaucoup d’exemples grâce votre moteur de recherche favori (Qwant bien entendu !).

Git Ignore global

Il existe également la possibilité de configurer un fichier Git Ignore global. Ce dernier impactera l’ensemble de vos projets Git sur votre machine. Très pratique pour configurer les éléments relatifs à votre machine(OS, IDE ..).

# Définition du fichier .gitignore_global à la racine de l'utilisateur courant comme fichier Git Ignore global
git config --global core.excludesfile ~/.gitignore_global

Trouver l’origine d’un bug grâce à la commande bisect

Git peut nous aider à comprendre l’origine d’un bug. La commande « bisect » permet de retrouver le commit qui a déclenché un bug.

On commence la recherche du commit incriminé. Puis on indique à Git que la version courante contient le bug dont on cherche l’origine:

# lance la bisection
git bisect start
# Explique à git que la révision courante contient le bug
git bisect bad

Ensuite, il faut renseigner un numéro de commit où l’on est sûr que le bug n’existait pas :

git bisect good md5_bon_commit

Git va alors choisir un commit au milieu entre votre commit actuel et le commit que l’on vient d’indiquer pour que l’on vérifie si le bug est présent à ce moment-là. Il mettra le dépôt local à cette version et il faudra alors retester manuellement si l’erreur est déjà présente.

Si le bug est toujours présent, on l’indique à Git par la commande suivante :

git bisect bad

Git comprend qu’il faut remonter plus loin dans les commits. Il va sélectionner le milieu du nouvel intervalle incriminé comme nouvelle version à tester.

Si le bug n’est plus présent, on indique cela à git par :

git bisect good

Git comprend qu’il faut encore avancer dans les commits pour trouver l’origine de l’erreur. Il va sélectionner le milieu du nouvel intervalle incriminé comme nouvelle version à tester. .

On refait ce processus plusieurs fois jusqu’à ce que Git discrimine le commit à l’origine du bug (en procédant par élimination).

Quand Git a défini le commit incriminé, il faut terminer la bisection :

git bisect reset

Maintenant que l’on dispose du commit qui a produit la régression, il est plus facile d’analyser l’origine du problème.

Il est possible de trouver quelques d’explications supplémentaires et un exemple complet sur le blog Xebia.

Garder temporairement ces changements non commité

Il arrive d’être interrompu dans une tâche pour devoir en faire une autre, alors que la première tâche n’est pas un dans un état « commitable ».
Dans ce cas, la commande stash permet de mettre de côté le développement en cours et de le reprendre plus tard. Les modifications ne sont pas perdues, elles sont stockées dans un espace temporaire de Git (le stash).

# Sauvegarde votre travail non commité sur une branche
git stash save
# Permet de voir ce qu'il y a dans le stash 
git stash show
# Récupérer vos modifications stockées dans le stash
git stash pop

On trouve une bonne vidéo explicative sur Openclassroom.

Voir les différences avec un autre état avec git diff

La commande diff permet de comparer deux versions d’un fichier. Cela permet de retrouver les modifications effectuées sur des révisions d’un fichier et, par exemple, analyser pourquoi un bug est apparu lors de notre dernière version.

Faire la différence entre le répertoire de travail et l’index :

git diff
# voir la différence pour le fichier monFichierSource.java
git diff src/main/java/monpackage/monFichierSource.java

Faire la différence entre l’index et le dépôt :

git diff --cached

Faire la différence entre l’état courant par rapport à la dernière version commitée :

git diff HEAD

Faire la différence entre la dernière version commitée et la révision précédente :

git diff HEAD^

Quelques exemples supplémentaires :

# permet d’ignorer les différences d’espaces et d’indentations
git diff -b
# permet d’ignorer les différences d’espaces et indentations au sein de la même ligne, mais indique les lignes vides ajoutées ou supprimées
git diff -w
# donne les statistiques de modification par dossier
git diff --stat  
# donne les statistiques de modification entre la dernière version commitée et 4 commits avant.
git diff --stat HEAD~4

Lister les modifications

Lister les commits qui ne sont pas encore push sur le dépôt central:

git log origin/master..HEAD

Lister les différences de fichiers depuis le dernier push sur le dépôt:

git diff origin/master..HEAD

Configurer et utiliser les outils de diff et de merge

Git permet d’installer des outils externes pour faciliter le diff et le merge. Par exemple, pour faciliter le merge, on peut configurer la commande mergetool avec le logiciel DiffMerge.

Le problème majeur de cette configuration est quelle est dépendante de l’outil et de l’OS. L’exemple ne conviendra donc pas à tous.

Configurations:

Configurer Git pour interagir avec DiffMerge sur MacOS X, pour la commande difftool:

git config --global diff.tool diffmerge 
git config --global difftool.diffmerge.cmd "/usr/bin/diffmerge \"\$LOCAL\" \"\$REMOTE\""

Configurer Git pour interagir avec DiffMerge sur MacOS X, pour la commande mergetool :

git config --global merge.tool diffmerge
git config --global mergetool.diffmerge.trustExitCode true
git config --global mergetool.diffmerge.cmd "/usr/bin/diffmerge --merge --result=\"\$MERGED\" \"\$LOCAL\" \"\$BASE\" \"\$REMOTE\""

Utilisations:

Le difftool est à utiliser comme le diff, le mieux est de l’utiliser sur un fichier ou un répertoire précis :

# Voir toutes les différences avec l'index, va proposer l'ouverture du diff tool pour chaque fichier modifié
git difftool
# Voir toutes les différences avec l'index du fichier monFichierSource.java
git difftool src/main/java/monpackage/monFichierSource.java

L’utilisation la plus commune de mergetool est de gérer les fichier en conflit après un merge/rebase:

# Merger les conflits sur le fichier monFichierSourceEnConflit.java
git mergetool src/main/java/monpackage/monFichierSourceEnConflit.java

Créer des alias pour git

Git possède énormément de commandes, mais dans son utilisation quotidienne certaines reviennent très régulièrement. Pour faciliter la tâche du développeur, Git possède son propre mécanisme d’alias.

Pour ajouter un alias deux solutions. La première grâce à la ligne de commande :

# créer l'alias "git co" pour "git checkout"
git config --global alias.co checkout
# créer l'alias "git p" pour "git push"
git config --global alias.p push

La seconde passe par l’édition du fichier .gitconfig présent à la racine du système de l’utilisateur et ajouter à la fin du fichier :

[alias]
    p = push
    co = checkout

Voici une liste d’alias assez commun :

[alias]
     p = push
     co = checkout
     b = branch
     st = status
     a = add
     ci = commit
     cim = commit -m

Pour conclure

Dans cette série d’article dédiée à Git, nous avons vu comment migrer un projet sur Git, l’adaptation du workflow de développement, les commandes de bases pour s’intégrer dans un workflow d’équipe et enfin certaines commandes et configurations un peu plus poussées.

Cet ensemble d’article permet à un développeur de commencer dans un environnement de développement dont l’outil de versionning est Git. Dans les jours qui viennent, suivra un article récapitulatif des commandes Git qui aura une forme de mémo sans explications. Puis un dernier qui regroupera l’ensemble des articles précédents.

Dans les prochains mois, d’autres articles suivront peut-être sur des sujets plus spécifiques de Git.

N’hésitez pas à laisser un commentaire pour, par exemple, suggérer des sujets d’articles autour de Git.

Sources: