Contributing
Setup Development Environment
Git User
Tell Git who you are
Version Control
Master
The master
branch should be considered the most up-to-date stable version of the software. No active development should take place on directly master
and the latest commit should always be tagged to a release.
Hotfix should be branched off of
master
Next
The next
branch should be considered the most up-to-date development version of the software. No active development should take place on directly on next
.
All development should be branched off of
next
next
should be rebased withmaster
after a hotfix
Branches
All development should happen on a branch off of next
. Branch names should include a ticket number if possible: TICKET-##-couple-words
or my-update
.
Branches should be rebased with
next
if they get out of date.Branches should be merged into
next
when they are completed.
Hotfix
A hotfix is a branch that uses master
as a base instead of next
.
Commits
Commit messages should make it easy for some one to scan through a commit log and understand the current state of the code.
When only changing documentation, include
[ci skip]
in the commit descriptionConsider starting the commit message with an applicable emoji:
:tada:
:tada:
for the initial commit:green_heart:
:green_heart:
when fixing the CI build:white_check_mark:
:white_check_mark:
when adding tests:arrow_up:
:arrow_up:
when upgrading dependencies:arrow_down:
:arrow_down:
when downgrading dependencies:shirt:
:shirt:
when removing linter warnings:recycle:
:wrench:
when refactoring:wrench:
:wrench:
when updating tooling
start with one of the following emojis to add your commit to the change log:
:racehorse:
:racehorse:
when improving performance:sparkles:
:sparkles:
when adding a new feature:bug:
:bug:
when fixing a bug:books:
:books:
when adding documentation:globe_with_meridians:
:globe_with_meridians:
when adding internationalization
you can use multiple emojis but only with first will be considered when generating the change log
you can look at gitmoji for inspiration
Examples
Commits have the following structure:
Examples of valid commits:
Code Review
All branches should be pushed to Github for code review.
All branches need to be reviewed and signed-off before they can be considered complete.
Any branches containing significant changes will also need to be QA'ed.
Merge Branch
After a branch has been reviewed it can be merged.
When merging use the Squash and Merge
option:
Before merging you are free to squash commits locally if you want more control over the commit message.
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Squashing-Commits
https://github.com/blog/2141-squash-your-commits
Your First Pull Request
clone the repo
create a new branch
do some work
commit your changes
push changes to Github for review
repeat as necessary
rebase next into your branch and deal with any conflicts.
get someone to review and sign-off on your branch
wait for the CI system to test your branch
References:
Heavly inspired by other repositories on github
Last updated