Référencer un commit
Dans la manipulation de l’historique ou des commits, on a souvent besoin de désigner un commit.
On peut évidemment référencer un commit par son SHA. Mais il existe d’autres nommages bien pratiques :
-
HEADdésigne le commit en tête de l’historique, celui sur lequel est positionné le pointeur de l’état courant du repository. C’est en général le dernier commit, donc, sauf si on déplace le HEAD pour revenir en arrière par exemple. -
HEAD^désigne le commit précédentHEAD(l’avant dernier en général) -
HEAD~ndésigne le n-ième commit avant le HEAD. Cette syntaxe permet donc de remonter dans la chronologie des commits sans avoir à manipuler leur SHA.
Lister les commits
git log
git log permet de lister les commits du repository.
Dans notre premier article, nous avons installé des raccourcis pratiques, et notamment git lg qui intègre par défaut des options de git log.
On utilisera dans la suite, indifféremment git lg ou git log selon les cas.
Un certain nombre d’options pratiques de git log sont à mentionner :
-
git log --onelineaffiche seulement la première ligne du commit. Cette option est intégrée dans le raccourcigit lg -
git lg --allpermet d’afficher les commits de toutes les branches, avec un graphe -
git lg --author='xxx@xxx'permet de filtrer les log en fonction de l’auteur -
git lg -Nlimite le nombre de logs affichés aux N derniers -
git log -pdonne le patch de chaque commit
On peut ici aussi cibler les révisions par date :
-
git lg --since='{1 hour ago}'liste les commits datant de moins d’une heure -
git lg --until='{1 hour ago}'liste les commit d’il y a plus d’une heure
On peut désigner également la révision par le début de son message de commit :
-
git lg :/debutmessage
Enfin, il est possible de rechercher dans les logs avec une expression régulière pour retrouver un commit donné :
-E pour utiliser une vraie expression régulière étendue (et pas du type glob)-i pour être insensible a la casse
git reflog
git reflog affiche l’historique de position du HEAD, ce qui permet de retrouver n’importe quel commit, y compris si plus rien ne pointe dessus
Exemple d’un retour en arrière :
On voit que le commit 32ccd84 qui n’apparait plus dans le log continue à être référencé dans le reflog où on peut encore aller le chercher en cas de besoin.
Afficher les diff
git diff
git diff permet d’afficher un diff, mais compte tenu des 3 états possibles d’une modification, qui peut être dans le répertoire de travail (working directory), dans l’index (staging area) ou dans le repository, il faut toujours faire attention a ce qu’on compare :
-
git diffdonne le diff de ce qui est modifié mais pas encore dans l’index. C’est donc le diff entre le répertoire de travail et l’index. Dès qu’on faitgit addsur un fichier modifié, il n’apparait plus dans le diff donné par cette commande. -
git diff --cacheddonne le diff entre l’index et le repository. Ça donne donc le diff de ce qui est prêt à commit. -
git diff HEADdonne le diff de l’état courant par rapport au HEAD,
donc inclue tout ce qui est tracked (staged et unstaged). C’est le diff de tout ce qui est versionné, entre le répertoire de travail et le repository. -
git diff HEAD^donne le diff entre le HEAD et la révision précédente. Ce sont les modifications du dernier commit, donc (sauf déplacement du HEAD entre temps).
Quelques options utiles pour git diff :
-
git diff -bpermet d’ignorer les différences d’espaces et d’identation -
git diff -wpermet d’ignorer les différences d’espaces et identation au sein de la même ligne, mais indique quand même les lignes vides ajoutées ou supprimées -
git diff --statdonne les statistiques de modification par dossier.git diff --stat HEAD~4donne les statistiques de modification entre e HEAD et 4 commits avant. -
git diff --dirstatdonne les statistiques de modification reparties par dossiers. C’est utile pour avoir un aperçu de l’impact d’un lot de commit, sans entrer dans le détail.
De manière générale, les options de git diff et de git log sont interchangeables.
git show
git show permet d’afficher le diff correspondant a un commit
-
git show fichiertel qu’il est dans le working tree -
git show :0:fichiertel qu’il est dans l’index -
:1:à:3:permettent de cibler l’état dans une opération de merge-
git show :1:fichieraffiche l’ancêtre commun a la fusion -
git show :2:fichieraffiche son fichier avant le merge -
git show :3:fichieraffiche le fichier externe avant le merge
-

Vos commentaires
# Le 31 juillet 2012 à 15:16, par belote
En réponse à : GIT c’est facile (2)
Merci pour vos explications très explicite.
# Le 26 janvier 2013 à 00:02, par Ben
En réponse à : GIT c’est facile (2)
Pour fusionner des branches c’est par ici http://git-scm.com/book/fr/Les-branches-avec-Git-Brancher-et-fusionner%C2%A0%3A-les-bases
# Le 6 mai 2013 à 17:05, par Max
En réponse à : GIT c’est facile (2)
Très bon tuto j’ai quand même mit du temps a bien comprendre les manipulations à faire (je ne suis pas doué pour le code), mais cela répond bien a ce que je cherchais aujourd’hui. En plus le lien de « Ben » est bien pratique aussi.
Max
Vos commentaires
Suivre les commentaires :
|
