Creating new Features
Fork the Mojaloop repository into your own personal space. Ensure that you keep the
master branch in sync.
Refer to the following documentation for more information: https://help.github.com/articles/fork-a-repo/
- Clone repo using Git Fork button (refer to the above documentation for more information)
- Clone your forked repo:
git clone https://github.com/<your_username>/<forked_repo>.git
Synchronise your forked repo with Mojaloop
Add a new upstream repo for Mojaloop
$ git remote add mojaloop https://github.com/mojaloop/<original_repo>.git
You should now see that you have two remotes:
git remote -v origin https://github.com/<your_username>/<forked_repo>.git (fetch) origin https://github.com/<your_username>/<forked_repo>.git (push) mojaloop https://github.com/mojaloop/<original_repo>.git (fetch) mojaloop https://github.com/mojaloop/<original_repo>.git (push)
To sync to your current branch:
git pull mojaloop <current_branch>This will merge any changes from Mojaloop's repo into your forked repo.
- Push the changes back to your remote fork:
git push origin <current_branch>
Creating a Branch
Create a new branch from the
master branch with the following format:
issue# can be attained from the Github issue, and the
issueDescription is the issue description formatted in CamelCase.
- Create and checkout the branch:
git checkout -b <branchType>/<issue#><issueDescription>
- Push the branch to your remote:
git push origin <branchType>/<issue#><issueDescription>
<branchType> can be one of the following:
|feature||Any new or maintenance features that are in active development.|
|hotfix||A hotfix branch is for any urgent fixes.|
|release||A release branch containing a snapshot of a release.|
|backup||A temporary backup branch. Used normally during repo maintenance.|
Open a Pull Request (PR)
Once your feature is ready for review, create a Pull Request from you feature branch back into the
master branch on the Mojaloop Repository. If you're new to GitHub or Pull Requests, take a look at this guide for more information.
Pull Request Titles
Mojaloop uses Conventional Commits to help our automated tooling manage releases and deployments. Your Pull Request title _must_conform to the conventional commits specification to pass the CI/CD checks in CircleCI.
By adopting Conventional Commits + Semantic Versioning we can automatically release a new version for a given component and increment the
BUGFIX versions based soley on the PR titles, and auto generate rich changelogs. (See this example of an auto generated changelog)
When merging (and squashing) a PR, GitHub uses the title of the PR for the git commit message. This means that to specify a breaking change, you must use the
"If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change."
Examples of good PR titles
- feat(api): add ability to handle
- fix: update outdated node modules
- feat(models)!: change database schema
- chore: tidy up readme