I'm curious about how everyone here uses git commit history. I only use commit history for these use-cases:<p>1. When I'm trying to understand the context around a change that has been made to a file. usually the whole commit provides a better context.
2. When I want to revert a change that breaks the latest release.
3. Comparing branches for rebasing/merging<p>Are there any other use-case that people use git commit history for?<p>is commit history useful in other ways?
In Jetbrains IDEs, you can select several lines of code and view the commit history for just those lines: <a href="https://www.jetbrains.com/help/idea/investigate-changes.html#folder-history" rel="nofollow">https://www.jetbrains.com/help/idea/investigate-changes.html...</a><p>This is <i>extremely</i> useful for me when debugging something that I didn't write, to see who worked on it in the past – just those few lines – and what they changed. From there, then I can look at that whole commit and the ones right before/after it to get a better context if needed. But most of the time, just being able to see how those specific lines have changed really helps me understand the code, without the noise of an entire git history or even just file history, since often times it's other parts of the file that were changed. This feature limits it to only the lines I care about.<p>I wouldn't be able to work without this feature. VScode can do it too via the Gitlens extension. I don't think it's built-in to the git CLI, but you can kinda get a similar effect with some effort: <a href="https://stackoverflow.com/questions/10816578/can-git-show-history-for-selected-lines" rel="nofollow">https://stackoverflow.com/questions/10816578/can-git-show-hi...</a>.<p>Overall it's just much easier in Jetbrains (as many things are).
The git history is useful to find out:
* The why, who and when of some change to the code or configuration.
* Looking at older variants of code to see previous attempts to know what has already been tried.
* git blame and git bisect for automated troubleshooting.
1. seeing who originally wrote the file i'm working on, which can set up some expectations, eg i know a certain someone likely didn't test the code well, if at all, so i know that i'm going to spend time constraining the existing code with tests before i can even get into it properly
2. figuring out what i did today so i can fill in the absolutely pointless timesheet that i have to fill out every day, because we can't just assign hours to a trello card, no! we have to also blurb about it so someone else can gloss over it
Git history can find code that is changed often, has many developers changing it, or was mostly written by someone no longer with the organization. Looking at the evolution of the code over time can help identify problem code as well as find areas that are in need of more attention, either by refactoring or otherwise cleaning up.<p><a href="https://pragprog.com/titles/atcrime2/your-code-as-a-crime-scene-second-edition/" rel="nofollow">https://pragprog.com/titles/atcrime2/your-code-as-a-crime-sc...</a>
It's useful in hinting which commit I should use to blame a file. I use blame to trace back to the pull request that introduced the changes that I'm interested in seeing. Commit messages themselves are rarely helpful to me since git hosts put way more useful context around sets of changes
Occasionally I have to explain in detail what the hell I've been doing all month because of some business drama with the customer or whatever. I can barely remember what I've done the last week. So when someone asks I just open the git commit history to figure it out.
Mostly to get context, like ticket numbers, links to pull requests, all usually with the goal to understand the intentions of a specific piece of code.
same as word document with track changes enabled… you see entire document and with history exact why each piece of the document is there and when and who made it so