[lamontcg]

Yeah I'm 13,000 lines into a solo side project and haven't bothered with a single branch+merge. I've got a bunch of tests, but I don't test everything, I don't make sure every commit has tests. Commits are mostly checkpoints of when major feature achieve some kind of initial stability where I want to be able to diff back to last-known-working. I try to do better commits than "WIP" but they're something like "such and such feature now seems to actually work (lots of buggy edge conditions)". I'll throw in a lot of unrelated code cleanup that happens into single commits as well. I focus on moving the needle on the end results though and not having perfect process. Many bits of code that I have which work well enough don't have any tests at all. As I hit bugs I drill into code and fill out the tests that I didn't do. Simple code that is used all over the place and doesn't cause issues may not have any formal tests at all. I rarely actually bother to go back into my own git history, mostly I just use it like a quicksave in case I wind up dying at the next bossfight.

I think what'll get you in trouble more than having perfect process is writing spaghetti code that violates separation of concerns. If things are separated well, you should be able to come back and test it easily if it causes issues. Test the stuff that is complicated and obviously will cause issues if its not perfect. Test the stuff that is found to be buggy or needs to be proven to be not buggy in order to track down bugs. Don't bother with perfectly testing everything.

I've been adding a threaded AVL tree implementation lately. I definitely tested that extensively and did a savegame when the AVL tree was written and passing tests properly, and then added threads and did another couple of savegames. I'm going to build on top of that, and I need to be able to trust it without falling back into debugging it. I've got a Clamp01 function though which takes a double and ensures it is within 0 <= x <= 1 and I don't have that one tested. I'm pretty confident it works though.

[mr_mitm]

Sounds exactly like what I'm doing.

What I wondered was if and when other developers deviate from that workflow. After the first release? After the first collaborator has joined? Never?

Are there textbook developers who use a strict strategy like the one Daniel Stenberg [1] is following from day 1?

[1] https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/

[lamontcg]

I do think that after you release and more or less go "1.0" (even if you don't call it 1.0) you should start treating master as always-releasable. At that point if you have a lot of work to do and need checkpoints, do it on a branch. Same with major breaking change features. Keep master always ready so that you can release for bumping your upstream deps, releasing security fixes, or other interrupt driven housekeeping to stay current.