Skip to content

Working with pull requests

Markus Schneider edited this page Apr 24, 2014 · 40 revisions

Use of pull requests within the deegree project

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!

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.

Checklist for pull requests

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.
Clone this wiki locally