We use git as our version control system. These guidelines describe how we work with git.
In this excellent tutorial by Atlassian some frequently used workflows are described and compared.
Our workflow is very similar to the Gitflow workflow. The differences are outlined below.
Our historical branches have other names:
- master is called stable
- release is called testing
- development is called master
We encourage the use of feature branches, but don't have strict rules about them. That allows teams to design their own branching strategy, tailored to their needs.
In practice all teams use some form of feature branches, but sometimes changes are committed to a historical branch without a feature branch.
A commit should be small and represent one logical change. This makes it easy to review the commit and (sometimes) cherry-pick and revert the change.
A commit should not leave a branch in an inconsistant state. This makes bisect and revert harder.
You should split off non-functional changes (refactoring, boy scouting) to separate commits.
We spend way more time reading code than writing code. Part of reading code is understanding the history: how and why did this code become what it is?
Commit messages can help if they're good. Read this excellent article on good commit messages.