- you have a distributed workflow
- you need to version files even when you’re offline
- you have a central “master” repo, but you still want git’s benefits
- speed, smaller repo size, ease of branching/tagging, etc
- many different branching models exist; use what works
- depends on: team size, collaboration model, release schedules and characteristics, etc
http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows
- keep commits granular for easy reverting/cherry-picking later on
- commits are atomic
- don’t mix unrelated changes in a single commit
- ideally, each commit should not break the build (even if it’s one of a series of related commits)
- commit messages are like entries in a CHANGELOG file
- ideally, the commit messages of your repo should document the history of the codebase
- compiled binary files
- very large binary files/assets
- if you need to version these, consider using Subversion instead
- text editor-/IDE-specific configuration files (if they’re located in the same directories as your code)
- even if you need to make sure your team is using the same configs, do not include them when committing – find a different strategy for keeping your configs synced