I'd be very hesitant with "commit often". Each commit should represent a finished bit of a bigger feature.. Each commit should compile (...generally. With exceptions). Commits that fix spelling, or change some spacing issues end up cluttering the history and making it hard to see what's being actually done. When someone looks over your code they should see things like:
commit1: he/she added some methods
commit2: refactored some code
commit3: he/she plugged in the methods created into the refactored code
etc.
The branch as a whole should be a finished feature. Keep the features small-ish. Try not to have a branch that living on it's own for a long time. You can merge the master branch into it, however you'll slowly be out of sync with your team b/c they don't really know what you're up to.
The only thing I absolutely detest in Git, is that is no quick method to change history on local changes. Say I add a method and make a commit - then I do a bunch of other work and 10 commits later I realize that the method I had written needed to be const. Instead of be able to edit that commit and add the const labels, I end up having to make another commit that no one cares about and no one really should have to look at. It just makes the history incredibly cluttered and make it a lot harder to find the commits I'm interested in.
The workaround is to make a new branch and cherry pick changes - but it's a huge PITA and easy to mess up
Aside:
Does anyone know what diff tool is best for working in C++? The diffs I commit (using kdiff) can sometimes be mind-boggling hideous b/c the diff program parsed things in some strange way.
The only thing I absolutely detest in Git, is that is no quick method to change history on local changes. Say I add a method and make a commit - then I do a bunch of other work and 10 commits later I realize that the method I had written needed to be const. Instead of be able to edit that commit and add the const labels, I end up having to make another commit that no one cares about and no one really should have to look at. It just makes the history incredibly cluttered and make it a lot harder to find the commits I'm interested in.
Thanks for the pointer. In truth, I use a GUI (gitExtentions). I like it a lot more than the command line. Hopefully this is implemented somewhere. I'll look into it!
commit1: he/she added some methods
commit2: refactored some code
commit3: he/she plugged in the methods created into the refactored code
etc.
The branch as a whole should be a finished feature. Keep the features small-ish. Try not to have a branch that living on it's own for a long time. You can merge the master branch into it, however you'll slowly be out of sync with your team b/c they don't really know what you're up to.
The only thing I absolutely detest in Git, is that is no quick method to change history on local changes. Say I add a method and make a commit - then I do a bunch of other work and 10 commits later I realize that the method I had written needed to be const. Instead of be able to edit that commit and add the const labels, I end up having to make another commit that no one cares about and no one really should have to look at. It just makes the history incredibly cluttered and make it a lot harder to find the commits I'm interested in.
The workaround is to make a new branch and cherry pick changes - but it's a huge PITA and easy to mess up
Aside:
Does anyone know what diff tool is best for working in C++? The diffs I commit (using kdiff) can sometimes be mind-boggling hideous b/c the diff program parsed things in some strange way.