this post was submitted on 30 Dec 2023
77 points (81.3% liked)
Programmer Humor
19147 readers
1209 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Become a professional, then you'll commit every time you make a small bit of functionality. If you're doing massive changes like this, you haven't broken something after multiple days of code enough. When you do that and you have no idea what you broke it with and when, it conditions you towards small iterable chunks.
I learned this the hard way, I forgot to commit for a single day and got burned really bad when my regression tests failed and I could not trace the issue(it is called source control for a reason). I declared it was more efficient to revert back to the last commit than spend time fixing broken code that I had no fucking clue where it was and the only thing I had to go by was that it happened between two commits with a whole work day between.
I work a lot with the local history of the IDE, where I can also set labels to a current state. In addition, it creates its own labels like last time all tests were green etc.
Still, in one of my last project that really lived TDD, they made a good point that I should just push as often as I label, since that also triggers all sorts of other tests which I usually don't run locally, or not as often.
I had "rearrange code" checked once for a commit, and fortunately, it had automatically saved the exact state before that.