I'm getting used in working with git at the moment. And I'm touching an issue that is unclear to me.I feel compelled, if I think of commiting after a change and making a documenting description. I don't know exactly when I should commit, because that's very relative and there's always something under construction.I tend to commit, when I fear to hose something. But then the summaries look like Backup before trying this and that or just Backup.What do you do? Is there a better way, or is my practise common?
When and how to commit?
git;documentation;backups
You can do whatever is socially acceptable with your fellow programmers on the project you are working on. There are no rules really.Personally I commit very often to keep change-sets really small and make sure they only do one thing, and then may or may not rearrange / squash those before publishing to the team.When you realize you have git rebase -i to hand, it becomes less important how often you commit initially.In terms of comments, I think it can be important that your commits are well described so that you can manage the changes you are working on.