Sorry I wasn't able to decide whether this question belongs to stackoverflow or not, here it is.
I was wondering if it should be a good idea or not to commit frequently, even if in my case would mean submitting non-working code.
I am refactoring a whole application to change to a new library, and I'm worried if I do not commit frequently.
I have a separate branch to work on the feature to avoid breaking the code on master (using Git).
Can you provide better solutions, and possibly some examples why this would be good/bad and, if there are, alternatives?
My usual workflow is: I commit a lot of non-working code onto a branch that can clearly be identified as such, e.g., a branch tmp/bart/working-on-feature-X. I also push it a lot to the remote (where basically, I am using the remote as a backup).
Whenever my code is in a good (publishable) state, I rebase: squashing all commits that belong togheter into one commit with a meaningful message, push to a new branch on the remote and create a pull request