Working with pull requests

Use of pull requests within the deegree repositories

With GitHub, we have a lot more freedom to decide what should be added to deegree and what not. To make best use of this facility (see eg. https://help.github.com/articles/fork-a-repo) we use the following procedure.

• no major changes happen in the main deegree3 repository in the deegree group directly
• documentation changes/minor bugfixes are allowed (do we still want this?)
• every contributor is invited to fork the project 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
• every two weeks the TMC goes (quickly...) over the pull requests and decides if it goes into the main branch or not
• 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.