Working with pull requests

Use of pull requests within the deegree project

To make best use of GitHub's pull request facility (see eg. https://help.github.com/articles/fork-a-repo) we use the following procedure:

• No major changes happen in the main repositories of the deegree group directly
• Everybody is invited to fork the deegree repositories on GitHub (possibly on a per organisation basis, but personal forks are of course also welcome)
• Every contribution should be prepared as a pull request: https://help.github.com/articles/using-pull-requests
• The technical management committee (TMC) goes over the pull requests and decides if it goes into the main repository or not. This is part of the biweekly TMC meetings.
• Everybody is invited to join the TMC meetings (IRC channel #deegree on freenode) to talk about the pull requests, especially the actual implementers!

As noted on https://help.github.com/articles/using-pull-requests, we think that this follows the best practices for OpenSource projects.

Creating your own pull request

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.