Honestly, for personal projects where I'm the sole developer, I only use git nominally. I mean, it's there, and sure, I commit; but it's not like I'm spawning feature branches or anything like that. It's a rather linear set of commits, functionally almost equivalent to having a zip of the source every now and then. I'm sure many people are the same.
Even for small personal projects, for me the real killer feature is commit messages. Otherwise, it's almost impossible to remember which numbered folder has the change I want, and looking through commit messages is often a good way to get back up to speed on a project I haven't touched in a while.
I've used git for so long and so deeply that it's ingrained in the way I think about code - I break things into atomic commits, and regularly traverse and edit the commits in the feature branch that I'm working on. That doesn't change when I'm working solo, nor do my commit message style rules. I find it very useful to be able to investigate the history of a piece of code, even as it moves across multiple files, and figure out what happened and why.
That said, when I'm working on a team I generally don't care how many concurrent branches are being worked on - it's not a problem at all if the threaded view is n levels deep. When I'm working alone I tend to have a linear (single threaded) history, with tags for each release or deploy.
This is something that I struggle with. And it sets me apart from the apparent majority of (younger) programmers.
At best, once I've baked something enough that I'm satisfied, I can go back and break up the work. But then what's the point?
From my perspective, the agile/scrum mindset (velocity!) leads to spamming the code base with poorly reasoned trivial changes, frequently just kicking the can down the road, happily accumulating technical debt like an accretion disk.
Alas. I think the youngsters are more correct. Code bases are now so short lived that anything more than the bare minimum is just wasted effort.
I miss the days of product development and burning CD-ROM gold masters and people at least tried to hammer nails straight.
This is how many large teams do software development, including most of Google (see e.g. my team's project at https://nomulus.foo ). It's totally sufficient for personal programming, and that's what I do too.
You're still using git for real even if you only ever have one branch.
Hear hear! That said, it's pretty damn useful to have a log of my changes. Commit often, and it's even more useful! IntelliJ IDEs have pretty nice ways of viewing the diffs over time per file, and many other tools exist for doing this. Super useful!
I don't use branches either, but what I do like to use every now and then is stash. Sometimes you program yourself into a corner, or you realize that you need to take a step back. Or to quickly check what caused that regression you just noticed.
What if you decide to implement a new feature/big refactoring and don't finish it for some reason? This is where feature branches shine, you can just switch back to master and start working on something else.
