...

• Once ticket has passed all the reviews and has no additional comments, a committer should apply the latest patch to the master branch.
• A comment should be added to the ticket stating that the patch has been applied to master.
• Move ticket to CLOSED state. 

Git Process

Overview

Ignite development is split into 2 week sprints. However, duration may be longer or shorter. Preferably, each sprint should end with a public release.

After development is finished, QA cycle starts, then release procedure follows.

...

• Master should become the development branch for the next release.
• Whenever current release goes to QA, new branch should be created from master. This way master can be used to develop functionality of the next release. All release fixes get merged to release branch and then to master.
• All individual ticket/features development happen in separate repositories (either local or forks of GitHub mirror - https://github.com/apache/ignite) . Firm rule: ticket/feature branches should never be pushed to repo. 
• Development  branches should be created off of the master branch (or release branch if one exists - in this case changes get merged to release branch and then to master branch). Changes get merged to master branch of the project Git via process described at Workflow.
• Git tag should be created for every release.
• All CI tests must pass before the merge of ticket branches to the master (or release) branch.

...

Instructions on how to build source and binary releases can be found at DEVNOTES.txt. Please see "Ignite Release Instructions" section.

Workflow

There are 3 way how you can make contribution

...