Re:Git is my buddy: Effective Git as a solo developer
by mr_mitm on Wednesday February 24, 2021 @04:12AM
(#26248115)
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/
Re:Git is my buddy: Effective Git as a solo developer
by lamontcg on Friday February 26, 2021 @12:29PM
(#26277331)
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.
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.