Skip to content

Working with pull requests

Jump to bottom
tfr42 edited this page May 25, 2017 · 40 revisions

Use of pull requests within the deegree project

To make best use of GitHub's fork and pull development model, 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
  • 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 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 be possible to merge it automatically.
  • It must compile without errors and must not break any existing unit or integration tests. Here's a description 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 the current version branch (current stable version) must come with a corresponding pull for master branch (current unstable version), or otherwise guarantee that the bugfix/improvement is not lost in the next version.
Clone this wiki locally