Double Possible:
Afficher l'historique des modifications d'un fichier à l'aide de versioning GitParfois j'ai envie de faire une étape dans l'histoire d'un fichier particulier. Dans le passé j'ai utilisé P4V et cela a été très rapide et intuitive.
- Clic droit sur un fichier et sélectionnez historique.
- Faire défiler les dates et voir une belle diff de ce qui a été changé en que fichier sur cette date. Simple.
Le passage à git c'est maintenant une tâche éreintante.
- "git log nom de fichier"
- Regardez l'histoire et choisissez une date, une copie de hachage
- "git diff de hachage"
- Faites défiler diff pour les choses qui ont changé dans le fichier qui m'intéressent.
- Nope, ce n'est pas elle, permet d'essayer une autre date - retour à l'étape 2, rincer et répéter.
J'ai cherché SI, et j'en ai essayé quelques-uns des souvent suggéré d'interfaces graphiques: github, gitk, gitg, git-gui.
Ces tous supprimer la nécessité d'exécuter manuellement les commandes, mais le flux de travail est la même pour cela. Afficher l'historique du fichier; la vue de commettre l'infraction; recherche par le biais de diff de beaucoup de pertinence des fichiers. C'est lent et répétitif.
Toutes les données sont dans le repo donc je ne vois pas la raison de cette simple utilisation ne pouvait pas être plus simple.
Peut-on recommander un outil qui fait ça - ou d'une façon plus efficace d'utiliser la ligne de commande pour faire ce que je veux?
Merci pour toutes les suggestions.
Réponses
Trop de publicités?
git log -p permettra de générer de l'un patch (diff) pour chaque livraison sélectionné. Pour un seul fichier, utilisez git log --follow -p $file.
Si vous êtes à la recherche pour un changement particulier, utilisez git bisect pour trouver la variation en log(n) vues en divisant le nombre de commits dans la moitié jusqu'à ce que vous trouver où ce que vous êtes à la recherche pour changé.
Également envisager de regarder en arrière dans l'histoire, à l'aide de git blame à la suite de changements de la ligne en question, si vous savez ce que c'est. Cette commande affiche la révision la plus récente à affecter une certaine ligne. Vous pourriez avoir à revenir quelques versions de trouver le premier changement où quelque chose a été introduit si quelqu'un a peaufiné au fil du temps, mais qui pourrait vous donner un bon départ.
Enfin, gitk comme une interface graphique ne montre-moi le patch immédiatement pour toute commettre des que je clique sur.
Exemple 
:
La principale question pour moi, de quoi êtes-vous en train d'essayer de trouver? Êtes-vous essayer de savoir, qu'un certain nombre de modifications a été introduit dans ce fichier?
Vous pouvez utiliser git blame pour cela, il va anotate chaque ligne avec un SHA1 et une date à laquelle il a été changé. git blame pouvez aussi vous dire que lorsqu'une ligne a été supprimé ou où il a été transféré si vous êtes intéressé par ce.
Si vous essayez de trouver, lorsqu'un certain bug a été introduit, git bisect est un très puissant outil. git bisect va faire une recherche binaire sur votre histoire. Vous pouvez utiliser git bisect start pour commencer coupant, puis git bisect bad , marque de s'engager où le bug est présent et git bisect good marquer un commit qui n'a pas le bug. git va commander une s'engager entre les deux et demandez-vous si c'est bon ou mauvais. Vous pouvez généralement trouver le fautif s'engager dans un délai de quelques étapes.
Depuis que j'utilise git, je n'ai pratiquement jamais constaté la nécessité de rechercher manuellement par le biais de patch histoires à trouver quelque chose, puisque le plus souvent git me propose une manière simple de rechercher les informations dont j'ai besoin.
Si vous essayez de penser à de moins en moins de la façon de faire un certain flux de travail, mais plus dans ce que l'information dont vous avez besoin, vous aurez probablement de nombreux flux de travail qui (à mon avis) sont beaucoup plus simple et plus rapide.
