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 :
-
HEAD
dé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~n
dé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 --oneline
affiche seulement la première ligne du commit. Cette option est intégrée dans le raccourcigit lg
-
git lg --all
permet 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 -N
limite le nombre de logs affichés aux N derniers -
git log -p
donne 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 diff
donne 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 add
sur un fichier modifié, il n’apparait plus dans le diff donné par cette commande. -
git diff --cached
donne le diff entre l’index et le repository. Ça donne donc le diff de ce qui est prêt à commit. -
git diff HEAD
donne 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 -b
permet d’ignorer les différences d’espaces et d’identation -
git diff -w
permet 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 --stat
donne les statistiques de modification par dossier.git diff --stat HEAD~4
donne les statistiques de modification entre e HEAD et 4 commits avant. -
git diff --dirstat
donne 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 fichier
tel qu’il est dans le working tree -
git show :0:fichier
tel qu’il est dans l’index -
:1:
à:3:
permettent de cibler l’état dans une opération de merge-
git show :1:fichier
affiche l’ancêtre commun a la fusion -
git show :2:fichier
affiche son fichier avant le merge -
git show :3:fichier
affiche 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 : |