...

• Master should become the development branch for the next release (current sprint).
• Whenever current release (sprint) 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 patch validation process described at  at Contribution ways.
• 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.

...

Each sprint development goes in master branch in project's git repo. At the moment build goes to QA release branch is created out of master, for example: ignite-1.3.0.

Normally, project repo should contain only master branch and , very few branches for ongoing releases and commiter's branches ready to be reviewed. Committers and PMC members are in charge to make everyone follow this rule.

...

Contribution ways

There are 2 3 way how you can make contribution

1. GitHub pull-request
2. Patch-file
3. Ticket Branch (only committers)

1. GitHub pull-request

 +------------+             +---------------+            +-----------------+

...

So, in case, if a patch can't be applied without conflicts on the HEAD of master and the patch has been created by scripts/git-format-patch.sh then a commiter can apply the patch to master by a revision hash, review changes and resolve the conflicts by yourself.

3. Ticket Branch (only committers)

 It is legal to create 'ready to be reviewed' branch ignite-XXXX, where XXXX is the number of the JIRA ticket.

Branch should be deleted in case successful or unsuccessful review. Commiters in charge of deleting it's branches.