Hacking:Making pull requests

This page describes how to create a pull request. We highly recommend you to read this page before you will decide to send us your changes.

Note: this is not a mercurial tutorial. For more information about mercurial see our page about Hacking:Tools.

Branch model

First you should know little bit about our workflow. Right now we work with several named branches.

• default - used only for releases.
• develop - branch that contains a code for the next major release. Code in this branch good enough for testing and sharing among developers.
• feature - branch that contains a code for unfinished features.
• release - used for feature freeze state before the next major release. And for preparing the next minor release.

These are the main branches you should know about. There are several long term task specific branches in repository too. But we will not discuss them in this document.

Working with feature

• Make a feature step by step and save your progress.
• Make commit only if you have finished a step. Don't need to make commit for unfinished step today. You can continue tomorrow.
• Each commit should be small as possible and contain one logical step of developing a feature. This will help us better understand your code. Sometimes we see changes per each commit separately.
• Compiler should successfully build each commit you made.
• Make all your commits in feature branch. This mean all your changes in your local repository will be only in feature branch.
• Don't forget each day sync your repository with ours and merge new code in develop branch -> to your feature branch. Fix all merge conflicts.
• You can push your feature branch to bitbucket. This will help us watch your progress and leave comments. We recommend don't hide your code until the end.
• When you will decide that all were done create a pull request. In settings set to merge your feature branch with our develop or release branch. See which branch is parent for your branch.
• If we ask you to fix some issues related to your changes continue commit them to the feature branch and push them to bitbucket. It will automatically update your pull request.

General recommendations

There are several things you should know for successful creating a pull request.

• Normally you are not allowed create named branch with name except feature. Instead you will use so called anonymous heads, see a Guide to Branching in Mercurial. In short a name of a named branch show us developing process only, we don't care contains it issue ticket number or not. Named branches only for long term task specific changes.
• Please start your changes from develop or release head commit. For this run command hg update name_of_branch. Which branch to select depend on in which state the code base is now. See section Branch model. If you are not sure, please, ask for help.
• Before starting committing your changes open your feature branch head. For this run command hg branch -f feature.
• Now you are ready to begin work. Make some changes and commit them with command hg commit -m "Commit comment.".
• When you are ready open new pull request. Please, read carefully official tutorial from Atlassian Making a Pull Request. This tutorial will help you understand how to work with bitbucket web site. But don't forget to return to this page and read it all. We have warned you.
• If your changes related to issue you can control an issue status by creating a commit with special description like this "Resolved (or Fixed) issue #XXX. <Text of an issue description>". Where XXX is a number of an issue in the Issue Tracker. Read more about Resolving issues automatically when push code.
• Don't forget to add your changes to file ChangeLog.txt. But only if these changes brings new feature or fix a bug. For example fixing building of the source code is not enough reason to update a changelog.
• Don't need to close a named branch.
• If you want to make several pull requests per time return to develop branch and open another feature branch head. Repeat all previous steps.

Little bonus. You can find all successfully merged pull requests here. These are good example if you want to find how look correctly made pull requests.