Skip to content

Guide for Contributors (Forks and Pull Requests)

Reinhard Budde edited this page Nov 10, 2021 · 4 revisions

Workflow for Forking and creating Pull Requests

Have a look at the github documentation. There is a lot written about clone, fork, pull requests. In the internet there are many resources easy to google, too. Anyhow:

  • first you fork the openroberta-lab repository on github: open the repository page and in the top-right corner of the page, click Fork. You get a fork on github with URL https://github.com/<username>/openroberta-lab.git
  • clone this repository to get a local copy of it. You should work on a feature branch (e.g. feature/myAdditions) derived from develop:
     git clone https://github.com/<username>/openroberta-lab.git
     cd openroberta-lab
     git checkout develop
     git checkout -b feature/myAdditions
  • add the upstream repository to your local clone, because you want to synchronize on that repository and submit a pull request against it
git remote add upstream https://github.com/OpenRoberta/openroberta-lab
  • now you can make changes in your feature branch, commit them and push them to your personal repository on github. Please write (more) tests and execute them often. Please use the formatter we supply in the Resources folder. This makes collaboration easy. Follow clean coding rules like KISS (keep it simple and stupid), DRY (don't repeat yourself), use meaningful names, ...
  • from time to time you should integrate changes from upstream into your feature branch. This is called rebasing. Sometimes you have to resolve conflicts, sometimes you are lucky and a fast-forward takes place (there is a special page explaining rebasing). After a rebase, if you push to your personal repository on github, you have to force the push:
     git checkout feature/myAdditions
     git fetch --all
     git rebase upstream/develop
     git push --force-with-lease
  • after you have finished your work, you can create pull request to ask for integration of your work into the upstream repository.
  • You must rebase immediately before you do that!
  • You should squash your commits to one or only few. If you prefer to have more than one commit: they should never describe ongoing work (20% of the change, 40% of the change, ...). They should relate to clearly separated aspects of your changes.
  • On the github web page of your personal repository click the Pull request button on the upper left side, select the right branches and follow the instructions.
  • if you continue to work and update your your personal repository on github by pushing local changes, this will update pending pull requests.

Git commit message conventions

Our development team agreed on some commit message conventions to unify the git tree

There are two formats, which should be used:

  1. Issue #[issue number]: [commit description](commit description lowercase)
  2. [Commit description] (commit description uppercase)

Each commit starts uppercase! (title)

Usually you and we work on issues to clarify why we change the lab. Thus format 1 is preferred.

Commit description

For the commit description (or the actual message) we agreed on the industry standards:

  • Use imperative (no past tense!) with descriptive verbs, e.g. add, implement, refactor, ... 
  • Use standard English spelling

(in general we agree with https://chris.beams.io/posts/git-commit/)

Clone this wiki locally