3 ms·

Sort of. 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

Sort of. 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.

specialist 8y ago
"I break things into atomic commits" 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. I know, I know, get off my lawn and all that.