Pull Requests

This article is mostly aimed at the internal OpenSpace developers, but would be recommended practice for outside contributors as well.

Due to our branching model, all features for which Pull Requests are relevant will have been developed in a specific feature branch of the form feature/<feature-name>. Especially for independent features, we want to keep the number of commits in the Git history reasonably low but still allow for continuous commits during the development. To square this circle there are two methods:

  1. If the individual commits have not been pushed to the server, it is possible to squash the commits interactively (see here, then push one commit to the server and use that as the version for the Pull Request.
  2. If the individual commits have already been pushed to the server (the preferred way), it is better to merge all commits into a single new one in a separate branch and use that as the version for the Pull Request.

In both ways, if the feature branch was feature/<feature-name>, there should be a new branch from which the pull request is made called pr/<feature-name> that is based off the most recent develop branch. In case 1 it would be a simple new branch from the one squashed commit that is rebased towards the newest develop. For case 2, the following is advised:

  1. Create a new branch off develop called pr/<feature-name>
  2. Use the command git merge --squash feature/<feature-name> to squash all commits from the feature/<feature-name> branch into a single commit
  3. Commit and push those changes
  4. Create a Pull Request from the pr/<feature-name> branch

In any rate, the required fixes for the pull request should be fixed as one commit in the pr/<feature-name> branch, so that the final feature only consists of 1 or 2 branches.