Make those changes in an own commit, or keep it to files you already have to touch.

When using git and are working on a feature, and suddenly want to work on something else, you can use git stash so git remembers your changes and is able to restore them when you are done. There is also git add -p this allows you to stage only certain lines of a file, this allows you to keep commits to a single feature if you already did another change that you didn't commit (this is kind of error prone, since you have to make sure that the commit includes exactly the things that you want it to include, so this solution should be avoided). But the easiest way is when you get the feeling that you have completed a certain task towards your goal and that you can move on to another task, to commit. But if you fail you can also change the history in git, so if you haven't pushed yet, you can move the commits around or, if you really need to, edit past commits and break them into multiple.

Do you have ADHD?

I tell my young developers - the primary goal in software engineering is maintainability. Code reuse, encapsulation, abstraction, and myriad other concepts all contribute to ease of maintaining source code over the long term. Maintainability allows for easier, predictable feature addition and removal, with fewer changes, and by different people. You're also a different person than the one you were months or years ago when it comes to software.

I'm the same way. Chasing code changes through the codebase then fighting with an edit rebase stack trying to explode them into less-interlocked changes.

It doesn't always work, sometimes I am just committing a giant blob of changes at work on my project I near-solo maintain 💀

Very relatable. Especially when it's less effort to make the change than it is to try and ignore it. But it's understandably harder for those who are reviewing your work.

It could be!

But part of working as a professional on a team is communicating and achieving consensus. Just trying to make a change like that out of the blue is poor form.

Also consider the opportunity cost: we had planned on getting XYZ done this week, and instead he spent a few hours on this and dragged a few people into a "do we want to change to poetry right now?" conversation

I think it's definitely a thing most people grow out of when they gain experience.

My boss told me about how when he was new he rewrote a whole chunk of the front end. His boss gave him a talking to about how you can't just go and do that when you're working with a team.

At an old job I just opened a PR to apply a code formatter to an internal project I wasn't even a routine contributor to. PR was rejected and I learned a valuable lesson about talking and getting buy-in before making sweeping changes.