-
-
Notifications
You must be signed in to change notification settings - Fork 99
Working with pull requests
To make best use of GitHub's [fork and pull development model] (https://help.github.com/articles/using-pull-requests#fork--pull), we use the following procedure:
- No major changes are pushed into the main repositories of the deegree group directly
- Everybody is invited to fork the deegree repositories on GitHub
- If you want a code enhancement to be included, please [prepare a pull request] (https://help.github.com/articles/using-pull-requests)
- deegree's technical management committee (TMC) will review pending pull requests and merge the ones that are ready to go into the main repository. This is part of the biweekly TMC meetings.
- Everybody is invited to join the [TMC meetings] (http://wiki.deegree.org/deegreeWiki/TmcMeeting) to talk about the pull requests, especially the actual implementers!
In order to create a pull request for a new feature or a bugfix it is advisable to follow these steps:
-
Create your own fork on GitHub
-
Add the original deegree repository as remote to your local clone, eg.
git add remote deegree git://github.com/deegree/deegree3.git
for the deegree3 repository -
create a feature branch based on the current deegree master:
git checkout deegree/master
git checkout -b <my-new-branch-name>
-
Implement what you want to implement within your new branch
-
Create a pull request from that branch to the deegree master
If the deegree master is changed during your implementation phase, it might be a good idea to merge these changes into your branch from time to time using git merge deegree/master
. Make sure you've previously fetched the remote changes using git fetch --all
.
Any pull request must meet the following base requirements, before it is considered for inclusion:
- It must compile without errors and must not break any existing unit or integration tests. [Here's a description] (Building-deegree3) for checking this yourself.
- New features that add configuration files / options need to include corresponding documentation updates for the webservices handbook.
- A pull request for stable must come with a corresponding pull for master, or otherwise guarantee that the bugfix/improvement is not lost in the next version.