I like to treat commits as the end of a task. I split a feature or bugfix into very small, actionable tasks, like creating a new entity,creating or refactoring a function,implementing or updating a new dependency, etc. Each one of those tasks will be a single commit, as it allows me to roll back to any point in time, and this atomicity also helps keep concise and clear commit messages, as only a few lines change, so it's easy to describe what the commit does in a few characters.
Once the feature is done or the bug is fixed, I squash rebase onto dev/master, keeping the feature/hotfix branch for the commits history for faster searching.
I like to treat commits as the end of a task. I split a feature or bugfix into very small, actionable tasks, like creating a new entity,creating or refactoring a function,implementing or updating a new dependency, etc. Each one of those tasks will be a single commit, as it allows me to roll back to any point in time, and this atomicity also helps keep concise and clear commit messages, as only a few lines change, so it's easy to describe what the commit does in a few characters.
Once the feature is done or the bug is fixed, I squash rebase onto dev/master, keeping the feature/hotfix branch for the commits history for faster searching.
I like this. Treating commits like checking off a todo list is an interesting way to look at it. Do you actually list out the things to do somewhere?