Version control is a system that records changes to a file or set of files over time. It allows multiple developers to work on the same codebase at the same time.
We use Git as our version control system. The best place to learn about Git is the official website.
We use Bitbucket to store all our remote repositories. You can request access to a project by emailing info@multiplestates.co.uk with your Bitbucket username.
Version Numbering
We define our version numbers for a project as follows:
Version MAJOR.MINOR.MICRO
MAJOR constitutes a major rebuild, re-design or addition of a major feature in the site. This is usually made up of a few MINOR changes.
MINOR constitutes a minor update or the addition of a minor feature to the site.
MICRO constitutes a bug fix or minor update.
Branch Naming
Below outlines the way we name branches within the studio.
Master
The master branch is the stable version of the project and matches what is on the live website.
Version Master
Each Version of the site has a master branch named 0.1.0_master (change the version number to match).
This branch is the development branch for that version. Once the version is ready for launch it will be merged into the master branch.
Version sub-branches
For each feature or issue there will be a branch named with the version number, the developer’s initials, the issue number and/or a keyword, as in: 0.1.0_wm_issue37_mainnav.
This branch is where a developer will work on an issue or task. Try to keep to one task only per version sub-branch. This makes the story of the project easier to understand for others.
Commits
Commits are one of the most important things when using a version control system. It is good to keep our commits common across the studio by sticking to the following guide. The bulk of the points below are credited to Caleb Thompson and his article 5 useful tips for a better commit message.
- The first line should always be 50 characters or less and it should be followed by a blank line.
- Wrap your commit messages to 72 columns.Add the following code to your ~/.vimrc file to do this.
autocmd Filetype gitcommit setlocal spell textwidth=72 - The commit message should tell people why the change is nessessary.
- Cross reference (provide links to) external resources within your message.This could be issues or other commits. Anything that will help someone figure out why the commit was nessessary.
- Rebase your commits before submitting a pull requestCheck if any of your previous commits can be combined to make the project history cleaner and more logical.