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