Keep commits small, they cost nearly nothing to make in git
- Allows you to easily revert a faulty commit without reverting working code at the same time
- You can easily get an idea of what happened to the project by simply reading the commit message titles in a history browser
- No more of those "committed some stuff" commits
Code new features in separate branches, they cost nearly nothing to make in git
- Allows you to easily return to the latest working state in the master branch when your client wants you to fix a bug discovered on your project's deployment day
- You can just leave your branch to "collect dust on the shelf", if it turns out that the feature was too time-costly to implement, and continue working on it at any point later
- Even the "minimal" tasks usually require more commits than you originally thought
Use no-fastforward when merging
- Because the merged branch groups commits its easier to see which commits belong to the same feature when observing the source history
- All the commits that make up the feature can be reverted in one step if the branch was found to be faulty
Use add -p to split up modifications into separate commits
- Related to keeping commits small
Corollary to "Code new features in separate branches"
- Don't develop directly in the master branch
Use a remote branch if you want to collaborate with other developers on a feature
- If a feature is too big for you to tackle alone, you should push it to your "main repository". The other developers can then pull it and contribute to it and when the large feature is done it can be merged into the master branch
