DEV Community

loading...

Discussion on: Git Workflow: How much change is too much change for one commit for you?

Collapse
jcbente_32 profile image
Juan Bente

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.

Collapse
daveskull81 profile image
dAVE Inden Author

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?