21–30 of 287 posts
I use it to find more detail about a particular line. Often knowing when something was added, who added it and what was the commit message helps me understand the reasoning behind some particularly weird or legacy code. In some projects this can lead you to a pull request link, with even more context.
I push to master infrequently. I keep a series of topic branches off of master, one per project phase. For changes that affect other developers, I pull those out and PR them to master, then rebase the topic branch chain once the PR completes. When I switch projects I use git reflog to remember where I was working.
Basically I take advantage of git rebase and use it like time travel constantly. Somehow I stay sane..
Though we stand on shoulders of midgets usually, you still get a better view.
"git blame" (or the p4 equivalent) is my usual archaeologic tool in this context, but "git bisect" has been very helpful in others. For the first, it should be easy to look at your current codebase in SVN and see how far back the history goes in any particular area. I've found that bisection is most useful for relatively recent history, because I usually have wanted to build or run the software to test for a bug or something - beyond some point in history that becomes impractical.
Moving from SVN to git shouldn't require losing history though...
It's called software archeology. It's not important if you keep exactly the same people working on the same project and they have perfect memory. But if you, say, move people between different teams, or lose people, or hire people, it's a gold mine.
Especially if I have written them since when someone asks me how something works or why it's written that way I can read the commit body and explain it to them/refer them to the message (otherwise my answer is, I don't remember!)
Additionally if you choose your changes well and don't squash commits it can be a good guide to what else touches the thing I'm looking at.
As a DBA, I use git blame to see who wrote slow queries. Then I assign a jira to them. :)
We just switched from Perforce to git at work, and about the first 2/3 of a project I work on got squashed together. It took me less than a week to bump in to that "initial commit" when trying to figure out why a bit of code is the way it is. "git blame" (or the p4 equivalent) is my usual archaeologic tool in this context, but "git bisect" has been very helpful in others. For the first, it should be easy to look at y…