Git’s great, and I am a bit obsessive about finding new things out about it. I am a stickler for a well-kept change history, even for personal projects as I feel it creates good habits.
A few things I try to do, this takes Rails as an example but can be applied more generally.
- When implementing a new feature in Rails for example I’ll first do commits for the models and corresponding tests, then work on the controllers/views, and lastly the routes. Point being that each layer warrants its own commits.
- Often you’ll have to go back and fix something that was not correct. If possible squash this in the commit where it should have been in the first place. Reading a commit history should not be about reading all your typos and fixups.
- I dislike the ‘Fix specs/tests for something’ It should have been the other way around, the specs determine the specification and the application code should follow.
- File changes that are generated like ‘schema.rb’ and ‘Gemfile.lock’ should be put in a separate commit. They are generated so their diffs are not of any interest to me usually, and if they are I can easily find them. The actual changes are in the migrations or Gemfile respectively, and those diffs should not be cluttered.
- Git guidelines prescribe that you use a present tense in the commit message. I think this is a good guideline to follow but more importantly is that whatever you use is consistent.
- Use standardized commit messages for repetitive commits I don’t care about. ‘Update schema’/’Update Gemfile.lock’ etc.
- Don’t be funny in commit messages or in committed code, you are probably not.
- Pushed branches that I know I am the sole contributor to I do force push every now and then to clean them up and/or rebase onto master. Usually these are marked as [WIP].