Hacking:Making pull requests: Difference between revisions
→Working with feature development
(13 intermediate revisions by the same user not shown) | |||
Line 1:
__TOC__
The intended audience for this page is anyone who wants to contribute to the open source project and is not a member of the core development team. To be added to the core development team requires special privileges and access that can be granted by the repository owner. If you wish to become a member of the core team, please make a request on the [https://forum.seamly.net/c/developer forum].
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.
Line 10 ⟶ 12:
* ''develop'' - branch that contains a code for the next major release. Code in this branch good enough for testing and sharing among developers.
* ''release-x.x.x'' - used for feature freeze state before the next major release. And for preparing the next minor release.
* ''feature-issue#'' - branch that contains a code for unfinished, new, or improved features. Merge to develop. (e.g. feature-155 to name your fix for issue #155)
* ''hotfix-x.x.x'' - Create from develop and master. Contains a quick fix. Merge to master (or release) and develop.
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.▼
* 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.▼
* Make all your commits in '''develop/release''' branch. This mean all your changes in your local repository will be only in '''develop/release''' branch.▼
* Don't forget each day sync your repository with ours and merge new code in '''develop/release''' branch -> to your '''develop/release''' branch. Fix all merge conflicts.▼
* You can push your '''develop/release''' 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 push your '''develop/release''' branch to the upstream repository.▼
* If we ask you to fix some issues related to your changes continue commit them to the '''develop/release''' 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.
NOTE: INSERT UPDATED, GIT BASED, WORKFLOW EXAMPLE HERE
* As open source community we try to be open as possible. This mean if your changes fix something,
* It is easiest for others to understand your intent if you follow naming conventions. Please use a convention of creating a branch to save your work in the github repository
* Please start your changes from
▲== Working with feature development ==
* Please make commit back to the develop branch only if you have finished a step. There is no reason to make a commit for a partially finished step today. You can continue tomorrow. The interim code may be stored in your cloned copy of the repository or in a feature branch.
▲* Each commit should be small as possible and contain one logical step of developing a feature. This will help us better understand your code.
* Before a commit is made, the code should be successfully compiled.
▲* Make all your commits in your local '''develop
▲* Don't forget each day sync your repository with ours and merge new code
▲* You can push your '''develop
▲* When you will decide that all were done create a pull request. In settings set to push your '''develop/release''' branch to the upstream repository.
▲* If we ask you to fix some issues related to your changes continue commit them to the '''develop/release''' branch and push them to
|