I'm curious about how you all manage your git commits when working on large features in solo projects. When implementing a feature that's complex enough to be a single cohesive unit, I often find myself making multiple micro commits like:
* `implement part A`
* `implement part B`
* `implement part C`
Each of these commits leads towards the final goal, but the feature doesn't actually work until all parts are done. Do you prefer making several of these partial commits and later squashing them into one clean commit like `feat: implement complex unit`, or do you leave them as they are? I know in team projects, we'd typically handle this in a PR with a squash, but I'm interested in your thoughts on solo work!
5 Answers
When working on a major feature, I believe every commit should represent a complete piece of code that runs and builds. Following the Linux kernel's approach, it's important that any commit you make can stand alone, which allows for easier debugging and tracking of changes. It's less about how you structure your work during the development phase and more about the story your commit history tells when you look back on it.
That sounds like a solid principle! But what if your final commit is huge, like 1000 lines? Shouldn't it still be fine as long as it represents a single atomic unit of work?
I think if you're breaking down a big feature, you should structure it so that each sub-feature is somewhat standalone with its own tests. That way, instead of having a bunch of partial commits that don’t do anything until they're all there, you can actually test parts of it. A focus on creating coherent units is key, especially for larger features.
But what if you're working on something that’s inherently complex, like an AVL tree? Wouldn't it make more sense for that to be a single commit saying `feat: Implement AVL tree` rather than splitting it into smaller parts?
Great point! It really depends on how modular each piece can be. The idea is always to commit logical units, even if they don’t feel complete alone.
I prefer more granular commits that clearly describe the pieces I’ve worked on, but ultimately, it’s about what works for you. Whether squashing or keeping a long list of commits, do what feels right and helps you track your own thought process the best!
Honestly, I just don't stress about intermediate commits for solo work. I typically develop in a branch, make as many commits as I want, then squash everything when I merge back to main. It’s easier for me, and having a cleaner history isn’t a priority. If I do make big changes, I might isolate them with a feature flag instead of worrying about individual commits.
That makes sense! The individual commit messages probably aren’t too important in solo projects since you know your workflow and how things progress.
Right? I find that as long as you have a good summary at the end, it doesn't matter how messy the interim commits are.
For my own projects, I stick to doing PRs too and squashing commits. It keeps everything simple and makes merging less of a hassle. My commits are primarily for my reference later anyway, so I like to have them neatly packaged into one final commit when I push to main.
Exactly! If each part of the feature is functional independently, I say that it's okay to squash them into one comprehensive commit in the end.