-
Notifications
You must be signed in to change notification settings - Fork 10
Repository Style Guide
I'm not trying to create some sort of sacred text that must be obeyed, these aren't rules they're more like... guidelines.
Github provides issues for a repository, however I am using them more like Jira Tickets. This means they don't have to relate to a problem but could also, for example, outline a new feature or feature improvement. I can then use them on the project board and reference relevant issues in branches, commits and pull requests to better organise and contextualise work.
I've decided to adopt a very loose version of Gitflow. The master branch will be the stable release branch and the dev branch will be used for development. Most of the work should take places on 'feature branches' that branch from dev and are linked to a Github issue.
Pull Requests should be made on Github to merge feature branches into dev and when merging dev into master. Nearly all merges into master should be releases and tagged accordingly.
Github offers multiple ways to achieve autolinked references but I've chosen GH-<reference> over #<reference> as '#' cannot be used in branch names and GH-<ref> is similar to Bitbucket/JIRA referencing.
I've decided branches that can be linked to Github Issues should be using the format GH-<reference>_short-description.
If there's no Github issue try to create one as it helps manage the repository work and history.
All commits where possible should be linked to a Github issue using the message format GH-<reference>: concise commit message to describe edits. This is useful to give extra context to the commit and means it will show up on the relevant issue in Github.
All pull requests where possible should follow a similar format to commit messages: GH-<reference>: title describing the desired changes.
I have decided to follow a very loose semantic versioning system for releases in the format v<major>.<minor>.<fix> where fix is for correcting a bug/issue but not adding anything new, minor is for editing a small piece of functionality and major is for a new feature or significant change.
Release tags should usually only be made on master after a merge, but a development release could be made using the format v<major>.<minor>.<fix>-dev.