Version Control

All our projects use Git, mostly with a repository hosted on GitHub. Since we're a small team, and most projects have less than 3 people working on it simultaneously, we have pretty loose Git guidelines since we rarely bump into conflicts.

Repo naming conventions

If the repo contains the source code of the a site its name should be the main naked domain name of that site. It should be lowercased.

Sites that are hosted on a subdomain may use that subdomain in their name

If the repo concerns something else, for example a package, its name should be kebab-cased.

Branches

If you're going to remember one thing in this guide, remember this: Once a project has gone live, the master branch must always be stable. It should be safe to deploy the master branch to production at all times. All branches are assumed to be active; stale branches should get cleaned up accordingly.

Projects in initial development

Projects that aren't live yet have at least two branches: master and develop. Avoid committing directly on the master branch, always commit through develop.

Feature branches are optional, if you'd like to create a feature branch, make sure it's branched from develop, not master.

Live projects

Once a project goes live, the develop branch gets deleted. All future commits to master must be added through a feature branch. In most cases, it's preferred to squash your commits on merge.

There's no strict ruling on feature branch names, just make sure it's clear enough to know what they're for. Branches may only contain lowercase letters and hyphens.

Pull requests

Merging branches via GitHub pull requests isn't a requirement, but can be useful if:

Merging and rebasing

Ideally, rebase your branch regularly to reduce the chance of merge conflicts.

Commits

There's not strict ruling on commits in projects in initial development, however, descriptive commit messages are recommended. After a project has gone live, descriptive commit messages are required. Always use present tense in commit messages.

Ideally, prefer granular commits.

Git Tips

Creating granular commits with patch

If you've made multiple changes but want to split them into more granular commits, use git add -p. This will open an interactive session in which you can choose which chunks you want to stage for your commit.

Moving commits to a new branch

First, create your new branch, then revert the current branch, and finally checkout the new branch.

Don't do this to commits that have already been pushed without double checking with your collaborators!

git branch my-branch
git reset --hard HEAD~3 # OR git reset --hard <commit>
git checkout my-branch

Resources