3 ms·
I often do intermediary commits that don't compile or break something significant, only to make sure that I don't lose the code. When that happens I always squa
by simias 6y ago
I often do intermediary commits that don't compile or break something significant, only to make sure that I don't lose the code. When that happens I always squash my commit afterwards once the code is in a usable state.
The alternative is making bisecting harder which is not something that I want. I want every commit to compile and be testable individually. That definitely doesn't mean that I think it's a good idea to have "gargantuan" commits.
An ideal commit should contain a single, atomic change to the codebase. Not more, but also not less.
- rutthenut 6y agoI'm a bit confused on your comments here. You state "I often do intermediary commits that don't compile ... to make sure that I don't lose the code" And follow that with "I want every commit to compile and be testable individually."
- simias 6y agoI mean that I do many small "crap" commits while developing, once I'm ready to merge into the main branch I clean the history to get proper, atomic commits.
- StanLindsey 6y agoI'm the same as OP. I commit constantly when hitting a natural stop point or when taking a break and push up to my branch/pr. I hate having code locally that hasn't been pushed to the origin. But doing this means I have many commits that don't mean anything or are unfinished and in an uncompilable state. So I git rebase and massage the history to make more sense.