Afficher l'historique des modifications d'un fichier à l'aide de versioning Git

Comment puis-je consulter l'historique des modifications d'un fichier individuel dans Git, les détails complets de ce qui a changé?

J'ai autant que:

git log -- [filename]

qui me montre la validation de l'histoire du fichier, mais comment puis-je obtenir le contenu de chaque fichier changements?

Je suis en train de faire la transition à partir de MS SourceSafe et utilisé pour être un simple right-click → show history.

Le lien ci-dessus n'est plus valide. Ce lien est aujourd'hui: Git Community Book
Le lien ci-dessus (posté par Chris) n'est plus valide. Ce lien est aujourd'hui: git-scm.com/book/en/v2

InformationsquelleAutor Richard | 2008-11-10

git git-log

2186

Pour cela je voudrais utiliser:
```
gitk [filename]
```
ou suivre le nom de fichier passé renomme
```
gitk --follow [filename]
```
- Mais je préfère encore avoir un outil qui combine le dessus avec git "faute' me permettant de parcourir la source d'un fichier de l'évolution dans le temps...
- GitWeb est la réponse à cette question.
- Malheureusement, cela ne permet pas de suivre l'histoire du fichier passé renomme.
- J'étais également à la recherche de l'histoire de fichiers qui ont été précédemment renommé et trouvé ce fil le premier. La solution est d'utiliser la commande git log --suivre <nom de fichier>" comme Phil l'a souligné here.
- L'auteur était à la recherche d'un outil de ligne de commande. Alors que gitk est livré avec GIT, ce n'est ni une application en ligne de commande, ni particulièrement bon GUI.
- Astuce sympa. Dans ma machine (git v1.7.10) j'ai eu à utiliser gitk -- [filename].
- Était-il à la recherche d'un outil en ligne de commande? "clic droit -> afficher l'historique" n'est certainement pas à sous-entendre.
- Attention les utilisateurs de Windows... Le nom du fichier chemin d'accès est sensible à la casse
- montre l'histoire du fichier passé renomme. Il n'affiche pas le contenu du fichier de modifications avant le changement de nom, cependant. Voir this réponse.
- si ce fichier est supprimé, et vous voulez savoir qui le supprimer, il est recommandé d'utiliser git log -- [filename]
- -1, si c'est gitk, alors il n'est pas git?
- ne cherche pas pour rien d'autre que git, cela ne devrait pas être accepté de répondre à
- gitk ne fait pas partie de la base de git paquet. Vous avez besoin de télécharger le paquetage tk utiliser gitk. @VolkA la réponse est mieux, git log -p filename fonctionne sans dépendances.
- La question était: "Afficher l'historique des modifications d'un fichier à l'aide de versioning Git". C'est exactement ce que gitk n'. Il regarde le git commit l'histoire pour les changements. Je ne m'inquiète pas si elle est partie de la base de git emballage aussi longtemps que il fait le travail dans une manière simple et rapide.
- Parce que le demandeur a estimé que cette réponse a été le plus utile lui.
- gitk fonctionne comme un charme. il m'a aidé à vérifier l'historique d'un fichier unique, exactement ce dont j'avais besoin.
- bash: gitk: command not found
- L'on a accepté la réponse devrait utiliser git pas gitk.
- Est-il possible de faire cela en utilisant gitGUI?
- downvote en raison de l'utilisation d'un autre outil, une meilleure utilisation de la norme de la cli de la réponse stackoverflow.com/a/278242/1700569
- L'on a accepté la réponse doit prendre en compte le monde n'a pas gitk installé sur leur système. Si j'étais dans un CLI-seulement de l'environnement il n'y aurait pas d'interface graphique disponible. OP demandé d'utiliser le "git" de commande. À l'aide de gitweb, gitk, ou tout ce qui est la même chose que de dire "il suffit d'aller à GitHub et de vérifier l'histoire".
- Cette réponse ne devrait pas être accepté par l'un de l'omi. Personnellement, j'utilise Gitx, pas Gitk, mais je ne veux pas d'un Gitx spécifique de la réponse. Le git log -p réponse ci-dessous est beaucoup plus applicable à une majorité d'utilisateurs.
- indépendamment de ce que l'on a accepté la réponse devrait être, +1 pour faciliter gitk esprit soufflé action
- Suis-se commande pas trouvé la moindre idée?
- Ce qui est gitk ?
- git outil de visualisation
- pourquoi cette réponse marques comme droit, si elle suggère d'utiliser un utilitaire tiers? le droit de réponse reste en dessous ( @DanMoulding est l'auteur)
InformationsquelleAutor Claudio Acciaresi
2042

Vous pouvez utiliser
```
git log -p filename
```
laisser git générer des taches pour chaque entrée de journal.

Voir
```
git help log
```
pour plus d'options, peut effectivement faire beaucoup de belles choses 🙂 Pour obtenir juste le diff pour un commit, vous pouvez
```
git show HEAD 
```
ou de toute autre révision par leur identifiant. Ou utiliser
```
gitk
```
pour parcourir les changements visuellement.
- git show TÊTE d'affiche tous les fichiers, savez-vous comment suivre un fichier individuel (comme Richard l'a cherché)?
- vous utilisez: git show <révision> -- filename, qui permettra de montrer les diff de cette révision, dans le cas où existe un.
- --stat est également utile. Vous pouvez l'utiliser avec d'-p.
- Ce qui est excellent. gitk ne pas bien se comporter lors de la spécification des chemins qui n'existent plus. J'ai utilisé la commande git log -p -- chemin .
- Plus gitk dirait qu'il a été construit par le boogie monster. C'est une excellente réponse et est adapté au mieux à la question d'origine.
- l'ajout de --follow également envisager de fichier renomme.
- Il y a une meilleure réponse à cette question, qui utilise le --follow drapeau
- J'aime @ghayes' réponse :p Et +1 pour cette réponse, je sens une bonne terminal peut montrer la diff beaucoup plus clairement que l'outil visuel.
- la commande git log --suivez -p file_path doit être accepté de répondre à
- -p = Generate patch = afficher diff à l'exception de commettre description
InformationsquelleAutor VolkA
1361

git log --follow -p -- path-to-file

Cela permettra de montrer ensemble l'histoire du fichier (y compris de l'histoire au-delà de renomme et avec des diffs pour chaque changement).

En d'autres termes, si le fichier nommé bar était autrefois appelé foo, puis git log -p bar (sans le --follow option) affiche le fichier de l'histoire jusqu'au point où il a été rebaptisé -- il n'affiche pas le fichier de l'histoire quand il était connu comme foo. À l'aide de git log --follow -p bar affichera le fichier de toute l'histoire, y compris toute modification du fichier quand il était connu comme foo. Le -p option permet de s'assurer que les diffs sont inclus pour chaque changement.
- Je trouve ça un peu bizarre, mais vous ne pouvez pas utiliser -CC drapeau avec log --follow file ou il ne trouve rien (git 1.7.0.4).
- --stat est également utile. Vous pouvez l'utiliser avec d'-p.
- Je suis d'accord c'est la VRAIE réponse. (1.) --follow assure que vous consultez le fichier renomme (2.) -p assure que vous voyez la façon dont le fichier est changé en (3.) il est en ligne de commande uniquement.
- Ajouter un -- avant votre file, et ce serait absolument la meilleure réponse!
- Wow. Il fonctionne pour moi. stackoverflow.com/a/1321962/3034747 et stackoverflow.com/a/5493663/3034747 ne l'est pas. Je ne sais pas pourquoi.. je suis sous ubuntu et GIT version 2.0.2
- "fatal: ambigu argument "my_file_name': inconnu révision ou le chemin d'accès pas dans l'arbre de travail."
- J'ai remarqué que la -- a été ajouté, mais je ne sais pas pourquoi cela fait-il mieux? Qu'est-ce qu'il fait?
- Le -- option indique à Git qu'il a atteint la fin des options et que tout ce qui suit -- doit être considéré comme un argument. Pour git log cela ne fait aucune différence si vous avez un nom de chemin d'accès qui commence par un dash. Dire que vous avez voulu savoir sur l'histoire d'un fichier qui a le triste nom de "--suivre": git log --follow -p -- --follow
- Normalement, le -- est utile parce qu'il peut également se prémunir contre tout revision un nom correspondant au nom de fichier que vous avez entré, qui peuvent être réellement effrayant. Par exemple: Si vous aviez à la fois une direction et un fichier nommé foo, git log -p foo montrer le git log de l'histoire jusqu'à foo, pas de l'histoire pour le fichier foo. Mais @DanMoulding est juste que depuis le --follow commande ne prend qu'un seul nom de fichier comme argument, c'est moins nécessaire car il ne peut pas être un revision. Je viens d'apprendre que. Peut-être vous avez eu raison de le laisser hors de votre réponse; je ne suis pas sûr.
- C'est fou comment loin en bas de la longue page de documentation git log a lire avant de la section "Génération d'patchs avec -p". Cette réponse fait un excellent travail en expliquant --follow il serait utile d'expliquer -p trop.
- en fait @JohnLawrenceAspden ramené un bon point dans sa réponse), afin d'inclure des --all de voir l'historique d'un dossier dans toutes les branches. peut être utile dans certains cas.
- Attention à ne pas taper le nom du fichier à tort (j'ai oublié un "s" à la fin de mon nom de fichier), Vous verrez un message dans la commande git log, skipping... suivie par une série de tildes ~ (sans doute un pour chaque commit/ je ne sais pas).
- Qu'advient-il si cette commande ne donne aucun résultat?
- Jeter erreur. fatal: unrecognized argument: --folow. Mais la commande git log -p <file/to/the/path> travaillé.
- Parce que c'est --follow, avec 2 L...
InformationsquelleAutor Dan Moulding
159

Si vous préférez rester à la base de texte, vous pouvez utiliser tig.

D'Installation Rapide:
- apt-get: # apt-get install tig
- Homebrew (OS X): $ brew install tig
L'utiliser pour afficher l'historique sur un seul fichier: tig [filename]

Ou parcourir détaillée des pensions de l'histoire: tig

Similaire à gitk mais à base de texte. Prend en charge les couleurs dans le terminal!
- Excellent outil textuel, grande réponse. J'ai flippé quand j'ai vu les dépendances pour gitk de l'installation sur mon serveur headless. Serait upvote de nouveau Un+++
- Vous pouvez regarder des fichiers spécifiques avec tig trop, c'est à dire tig -- path/to/specific/file
InformationsquelleAutor Falken
110

git whatchanged -p nom de fichier est également équivalent à git log -p nom de fichier dans ce cas.

Vous pouvez aussi voir quand une ligne de code spécifique à l'intérieur d'un fichier a été modifié avec git blâmer le nom de fichier. Cela permet d'imprimer un court commettre id, l'auteur, timestamp, et pour terminer la ligne de code pour chaque ligne dans le fichier.
Ceci est très utile lorsque vous avez trouvé un bug et vous voulez savoir quand il a été introduit (ou qui en est responsable).
- +1, mais filename n'est pas une option dans la commande git blame filename.
- "Les nouveaux utilisateurs sont encouragés à utiliser git-journal de la place. (...) La commande est maintenue principalement pour des raisons historiques;"
InformationsquelleAutor farktronix
96

SourceTree utilisateurs

Si vous utilisez SourceTree de visualiser votre référentiel (c'est gratuit et assez bon), vous pouvez cliquer-droit sur un fichier et sélectionnez Journal Sélectionné

L'écran (ci-dessous) est beaucoup plus convivial que de gitk et la plupart des autres options disponibles. Malheureusement (à l'époque) il n'est pas facile pour le lancement de ce point de vue à partir de la ligne de commande — SourceTree de la CLI actuellement ouvre juste repos.
- J'aime particulièrement l'option "Suivre les fichiers renommés", qui vous permet de voir si un fichier a été renommé ou déplacé.
- mais si je ne me trompe (s'il vous plaît laissez-moi savoir!), on ne peut que comparer les deux versions à la fois dans l'interface? Existe-il des clients qui ont une interface élégante pour la comparaison de différentes versions, à la fois? Peut-être avec un zoom de la vue comme dans Sublime Text? Ce serait vraiment utile je pense.
- Si je comprends bien, vous voulez comparer trois différents s'engage? Ce qui ressemble à un three-way merge (le mien, le vôtre, base) généralement, cette stratégie est utilisée pour résoudre les conflits de fusion pas nécessairement la comparaison de trois arbitraire s'engage. Il existe de nombreux outils qui prennent en charge trois fusionne stackoverflow.com/questions/10998728/... mais le truc, c'est l'alimentation de ces outils spécifiques révisions gitready.com/intermediate/2009/02/27/...
- Merci Mark Fox, c'est ce que je veux dire. Savez-vous de toutes les applications qui le fera?
- Vous sauver ma vie. Vous pouvez utiliser gitk pour trouver le SHA1 de hachage, puis ouvrez SourceTree pour entrer Log Selected.. basé sur la trouvé SHA1.
- C'est l'idéal. J'ai cherché la solution sur ATLASSIAN Communauté community.atlassian.com/t5/Sourcetree-questions/...
- De quoi avez-vous besoin de la SHA pour si vous avez déjà le nom de fichier? (De toute façon, si vous avez besoin de la SHA, vous pouvez le trouver avec SourceTree trop.)
- Je ne me souviens pas pourquoi j'ai besoin de la SHA à l'époque. Ahaha.
InformationsquelleAutor Mark Fox
62

Pour montrer ce que la révision et l'auteur de la dernière modification de chaque ligne d'un fichier:
```
git blame filename
```
ou si vous souhaitez utiliser le puissant blâmer GUI:
```
git gui blame filename
```
InformationsquelleAutor yllohy
45

Résumé des autres réponses après avoir lu à travers eux et de jouer un peu:

L'habituelle ligne de commande serait
```
git log --follow --all -p dir/file.c
```
Mais vous pouvez également utiliser les deux gitk (gui) ou tig (texte de l'interface utilisateur) pour donner beaucoup plus lisible façons de voir les choses.
```
gitk --follow --all -p dir/file.c

tig --follow --all -p dir/file.c
```
Sous debian/ubuntu, la commande d'installation pour ces beaux outils est comme prévu :
```
sudo apt-get install gitk tig
```
Et je suis actuellement en utilisant:
```
alias gdf='gitk --follow --all -p'
```
de sorte que je peux tout type gdf dir pour obtenir un concentré de l'histoire de tout dans le sous-répertoire dir.
- Je pense que c'est une excellente réponse. Peut-être que vous arent obtenir voté ainsi parce que vous répondez à d'autres moyens (à mon humble avis mieux) pour voir les changements, c'est à dire via gitk et tig en plus de git.
- Juste pour ajouter à la réponse. Recherchez le chemin d'accès (dans le git de l'espace, jusqu'à ce qui existe dans le référentiel encore). Puis utiliser la commande indiquée ci-dessus "git log --suivez-tous -p <folder_path/file_path>". Il y a peut être le cas, que le filde/dossier aurait été retirée au cours de l'histoire, donc localiser le maximum de chemin qui existe encore, et essayer de les extraire de son histoire. œuvres !
- --all est pour toutes les branches, le reste est expliqué dans @Dan réponse
- Oh, l'homme, après un si long temps à la recherche de la bonne solution pour le suivi de fichiers au-delà de renomme, enfin, je l'ai trouvé ici. Fonctionne comme un charme! Merci!
InformationsquelleAutor John Lawrence Aspden
24

Ajouter cet alias pour votre .gitconfig:
```
[alias]
    lg = log --all --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'\n--abbrev-commit --date=relative
```
Et utiliser la commande comme ceci:
```
> git lg
> git lg -- filename
```
La sortie, l'air presque exactement le même que le gitk de sortie. Profitez de.
- Après j'ai couru que lg raccourci, je l'ai dit (et je cite): "Magnifique!". Cependant, notez que le "\n" après "--graph" est une erreur.
- Peut aussi être utilisé git lg -p filename - il renvoie une belle diff de dossier recherché.
InformationsquelleAutor Palesz
20

Dernièrement, j'ai découvert tig et l'a trouvé très utile. Il y a certains cas, je souhaiterais avoir il n'A ou B, mais la plupart du temps, c'est plutôt soignée.

Pour votre cas, tig <filename> peut-être ce que vous cherchez.

http://jonas.nitro.dk/tig/
- sur centos yum install tig
InformationsquelleAutor lang2
15

J'ai écrit git-lecture pour cet objectif précis
```
pip install git-playback
git playback [filename]
```
Cela a l'avantage à la fois de l'affichage des résultats dans la ligne de commande (comme git log -p) tout en laissant de l'étape à chaque commit en utilisant les touches fléchées (comme gitk).

InformationsquelleAutor Jian
13

Ou:

gitx -- <path/to/filename>

si vous utilisez gitx
- Pour une raison quelconque, mon gitx ouvre vide.
- vous devez vous assurer que vous êtes à la racine de votre dépôt git
InformationsquelleAutor George Anderson
9

Si vous voulez voir l'ensemble de l'histoire d'un fichier, y compris sur tous les autres branches utilisation:
```
gitk --all <filename>
```
InformationsquelleAutor Adi Shavit
7

Avec l'excellent Git Extensions, vous aller à un moment de l'histoire où le fichier existait encore (si il a été supprimé, sinon il suffit d'aller à la TÊTE), passez à la File tree onglet, cliquez-droit sur le fichier et choisir File history.

Par défaut, il suit le fichier par le biais de la renomme et la Blame onglet permet de voir le nom à une révision.

Il a quelques petites erreurs, comme montrant fatal: Not a valid object name dans le View onglet en cliquant sur la suppression de la révision, mais je peux vivre avec ça. 🙂
- Intéressant de noter que c'est uniquement pour Windows.
- pas exacte, via mono on peut utiliser GitExtension aussi sur Linux, nous l'utilisons sur ubuntu et tout à fait heureux w/ elle. voir git-extensions-documentation.readthedocs.org/en/latest/...
InformationsquelleAutor PhiLho
7

Si vous utilisez git GUI (sur Windows) dans le Référentiel de menu, vous pouvez utiliser le bouton "Visualiser maître de l'Histoire". Mettez en surbrillance un commit dans le volet supérieur et d'un fichier en bas à droite et vous verrez la diff pour qui s'engagent dans le coin inférieur gauche.
- Comment est-ce répondre à la question?
- Eh bien, l'OP n'a pas de spécifier la ligne de commande, et le déplacement de la SourceSafe (qui est une interface graphique (GUI), il semble pertinent de souligner que vous pouvez faire à peu près la même chose que vous pouvez faire dans VSS dans le Git GUI sous Windows.
InformationsquelleAutor cori
5

SmartGit:
1. Dans le menu permet d'afficher les fichiers inchangés: Affichage /Afficher les fichiers inchangés
2. Clic droit sur le fichier et sélectionnez "ouvrir une session" ou appuyez sur "Ctrl-L'
InformationsquelleAutor Antonín Slejška
5

Vous pouvez également essayer ce qui énumère la liste des commits qui a changé une partie spécifique d'un fichier (mis en œuvre dans Git 1.8.4).

Résultat retourné serait la liste des commits qui a modifié cette partie en particulier. Commande :
```
git log --pretty=short -u -L <upperLimit>,<lowerLimit>:<path_to_filename>
```
où upperLimit est le start_line_number et lowerLimit est le ending_line_number du fichier.

Plus de détails à https://www.techpurohit.com/list-some-useful-git-commands

InformationsquelleAutor jitendrapurohit
4

La réponse que je cherchais, qui n'était pas dans ce thread c'est de voir les modifications dans les fichiers que j'avais mis en scène pour la validation. c'est à dire
```
git diff --cached
```
- Si vous souhaitez inclure local (unstaged) les modifications, j'ai souvent courir git diff origin/master pour afficher entièrement les différences entre votre succursale locale et la branche master (qui peut être mise à jour à distance via git fetch)
- -1, C'est un diff, pas un changement de l'histoire.
InformationsquelleAutor Malks
4

Si vous utilisez TortoiseGit vous devriez être en mesure de faire un clic droit sur le fichier et ne TortoiseGit --> Show Log. Dans la fenêtre qui s'affiche, assurez-vous que:
- 'Show Whole Project' option n'est pas cochée.
- 'All Branches' option est cochée.
- TortoiseGit (et Eclipse, Git en tant que bien) en quelque sorte, manque révisions du fichier sélectionné, ne comptez pas sur elle!
- Je n'ai pas rencontré ce problème, je ne peux donc pas vérifier si votre proposition est correcte.
- Mon erreur, cela arrive seulement dans Eclipse, mais dans TortoiseGit, vous pouvez voir toutes les révisions d'un fichier si décocher l'option "afficher tous les projet" + vérification "toutes les branches" (dans le cas où le fichier a été commis sur une autre branche, avant elle a été fusionnée à la branche principale). Je vais mettre à jour votre réponse.
InformationsquelleAutor user3885927
3

git diff -U <filename> vous donner un diff unifié.

Il doit être de couleur rouge et vert. Si ce n'est pas, exécutez: git config color.ui auto premier.

InformationsquelleAutor Lukasz Czerwinski
2

Si vous utilisez eclipse avec le plugin git, il a une excellente vue de comparaison avec l'histoire. Clic droit sur le fichier et sélectionnez "comparer avec"=> "histoire"
- Qui ne vous permettra pas de trouver un fichier supprimé toutefois.
- La comparaison de deux versions d'un fichier est différent de la Visualisation de l'historique des modifications d'un fichier
InformationsquelleAutor AhHatem
0

Vous pouvez utiliser vscode avec GitLens, c'est un outil très puissant.
Après avoir installé GitLens, allez à la GitLens onglet, sélectionnez FILE HISTORY et vous pouvez le parcourir.

InformationsquelleAutor foxiris

Vous devez vous connecter pour publier un commentaire.

SourceTree utilisateurs