Hacking:Making pull requests: Difference between revisions

From Seamly
Content added Content deleted
No edit summary
No edit summary
Line 8: Line 8:
* ''develop'' - branch that contains a code for the next major release. Code in this branch good enough for testing and sharing among developers.
* ''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.
* ''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.
* ''release'' - used for feature freeze state before the next major release. And for preparing the next minor release (feature freeze state).


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.
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.
Line 16: Line 16:
* Normally you are not allowed create new named branches. You should use '''develop''', '''feature''' or '''release''' depend on a purpose.
* Normally you are not allowed create new named branches. You should use '''develop''', '''feature''' or '''release''' depend on a purpose.
* Be sure you use correct branch for your changes. '''This is the most popular mistake'''.
* Be sure you use correct branch for your changes. '''This is the most popular mistake'''.
** For very small/trivial patches (contains only one commit) use the '''develop''' named branch directly.
** For very small/trivial patches (contains only one commit) use the '''develop''' named branch directly. If it's your first pull request better do it in '''feature''' branch.
** For regular patches (contains several commits) you should use the branch '''feature''' ('''recommended way'''). Don't worry if repository already contains one. We can have as many as we need.
** For regular patches (contains several commits) you should use the branch '''feature''' ('''recommended way'''). Don't worry if repository already contains one. We can have as many as we need. See [[Hacking:Tools#Mercurial|Mercurial useful commands]].
* Add correct description for your pull request. It should contain string "Resolved (or Fixed) issue #XXX. <Text of an issue description>". Where XXX is a number of issue in the Issue Tracker. Read more about [https://confluence.atlassian.com/bitbucket/resolve-issues-automatically-when-users-push-code-221451126.html Resolving issues automatically when push code].
* Add correct description for your pull request. It should contain string "Resolved (or Fixed) issue #XXX. <Text of an issue description>". Where XXX is a number of issue in the Issue Tracker. Read more about [https://confluence.atlassian.com/bitbucket/resolve-issues-automatically-when-users-push-code-221451126.html Resolving issues automatically when push code].
* Don't forget to add your changes to file ChangeLog.txt.
* Don't forget to add your changes to file ChangeLog.txt.
Line 23: Line 23:
* In a pull request merge your '''develop'''/'''feature''' branch with our '''develop''' branch.
* In a pull request merge your '''develop'''/'''feature''' branch with our '''develop''' branch.
* Don't need to close a named branch.
* Don't need to close a named branch.
* If you want to update pull request (for example we have asked you to fix some issues) just push your changes to the same branch that was used in a pull request. Bitbucket will automatically update a pull request.
* If you want to make several pull requests per time return to develop branch and "reopen" another feature branch.
* For fixing merge conflicts merge new code in '''develop/release''' branch -> to your '''feature''' branch.

* If you want to make several pull requests per time return to develop branch and "reopen" another feature branch. Repeat all previous steps.
Most likely we will ask you to fix some issues in a code. In this case you will add your changes to the '''feature''' branch and update your pull request. No need to create new one each time.


''Little bonus. You can find all successfully merged pull requests [https://bitbucket.org/dismine/valentina/pull-requests/?state=MERGED here]. These are good example if you want to find how look correctly made pull requests.''
''Little bonus. You can find all successfully merged pull requests [https://bitbucket.org/dismine/valentina/pull-requests/?state=MERGED here]. These are good example if you want to find how look correctly made pull requests.''

Revision as of 08:24, 11 June 2016

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 a decent mercurial tutorial, try reading Mercurial: The Definitive Guide.

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 (feature freeze state).

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.

There are several things you should know for successful creating a 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.
  • Normally you are not allowed create new named branches. You should use develop, feature or release depend on a purpose.
  • Be sure you use correct branch for your changes. This is the most popular mistake.
    • For very small/trivial patches (contains only one commit) use the develop named branch directly. If it's your first pull request better do it in feature branch.
    • For regular patches (contains several commits) you should use the branch feature (recommended way). Don't worry if repository already contains one. We can have as many as we need. See Mercurial useful commands.
  • Add correct description for your pull request. It should contain string "Resolved (or Fixed) issue #XXX. <Text of an issue description>". Where XXX is a number of 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.
  • In the end push your changes to your fork, then create a pull request.
  • In a pull request merge your develop/feature branch with our develop branch.
  • Don't need to close a named branch.
  • If you want to update pull request (for example we have asked you to fix some issues) just push your changes to the same branch that was used in a pull request. Bitbucket will automatically update a pull request.
  • For fixing merge conflicts merge new code in develop/release branch -> to your feature branch.
  • If you want to make several pull requests per time return to develop branch and "reopen" another feature branch. 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.