1. Tell Git who you are
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
1. Install GPG Tools -- do a customized install and deselect GPGMail.
2. Tell Git to use the gpg2 that comes with GPG Tools
git config --global gpg.program /usr/local/MacGPG2/bin/gpg2
3. Generate a GPG key using Applications/GPG Keychain
4. Tell Git to use your new GPG Key and auto-sign all commits
git config --global user.signingkey KEY_ID_FROM_STEP_3
git config --global commit.gpgsign true
5. Add Keys to Github
https://help.github.com/articles/adding-a-new-gpg-key-to-your-github-account/
https://help.github.com/articles/generating-a-new-gpg-key/
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
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 -
nextshould be rebased withmasterafter a hotfix
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.
git checkout -b TICKET-11-my-feature
-
Branches should be rebased with
nextif they get out of date. -
Branches should be merged into
nextwhen they are completed.
A hotfix is a branch that uses master as a base instead of next.
-
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 description -
Consider starting the commit message with an applicable emoji:
- 🎉
:tada:for the initial commit - 💚
:green_heart:when fixing the CI build - ✅
:white_check_mark:when adding tests - ⬆️
:arrow_up:when upgrading dependencies - ⬇️
:arrow_down:when downgrading dependencies - 👕
:shirt:when removing linter warnings - ♻️
:wrench:when refactoring - 🔧
:wrench:when updating tooling
start with one of the following emojis to add your commit to the change log:
- 🐎
:racehorse:when improving performance - ✨
:sparkles:when adding a new feature - 🐛
:bug:when fixing a bug - 📚
:books:when adding documentation - 🌐
: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
Commits have the following structure:
:icon: [TICKET-1,TICKET-2] one line description
Longer description
- list of changes
- one more thing
Examples of valid commits:
:sparkles: [TICKET-1,TICKET-2] adds new page to that page
Adds new feature to do that thing that we wanted to do:
- That one thing it does
- that other thing it does
:bug: [TICKET-1] fixes bug with thing
:racehorse::wrench: better production mode
:shirt: fixes eslint in tests
-
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.
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