No, this is not a relationship or life guide; it’s only meant for software, specifically Version Control Software, short VCS. I also only use Git; the principle should apply to all of them nonetheless.
I like neat and tidy things, so I’m wary of when and what I commit. Work in progress rarely makes it into Git history because I am sure I will work on it tomorrow and so I can save myself the hassle of a non-compiling, ugly commit. Obviously, this doesn’t always work out, and there’s a single big commit after quite some time, if ever. Sometimes, though, it’s the other way around; I add feature after feature so quickly that I don’t stop to commit in between and end up with a massive changelog. Neither is great, I too think commits should be
logical units of change GitHub’s Git Guides
Force-pushing is an option to literally rewrite history, but it causes other problems. Every single repository clone
needs to adapt, making this option unfeasible for projects developed together with others. Even if it’s a hobby project
and I’m the only contributor, there are still often two clones, one on my laptop and another on my PC. This then
requires “force pulling”, git fetch --all && git reset --hard origin/main,
which I not only have to look up how to do (had, thanks to this post) but also leaves me uncertain what potentially
significant changes and local files I will lose.
Resetting Git is not an operation one should do every day.
Some might solve this problem by creating feature branches and subsequentially squashing, leaving a single, self-contained, and well-tested commit. Maybe I should try this sometime, but despite this obviously not fit for more than one developer approach, I like the simplicity of having a single branch: no merge conflicts (at least in theory) and not having to specify branch names for Git commands. You might have guessed what I’m hinting at, yes, I do push (sometimes even force-push 😲) directly to the main branch.
Committing often helps me restore examples or give seemingly failed options another try. It also makes changes from templates or generated code visible, which is a good indicator for the intended outcome and thus helps in updating. Paying the small price of a less-than-perfect history is the price I can hopefully convince myself to pay. Software isn’t perfect either, so why should its development be? No one’s going to count commits; some might even interpret higher numbers as better.
Coming to the only logical conclusion after all of this, I just committed this post. Have a great day and a cat:
Comments