Skip to content

GitHub Workflow

This page describes the GitHub workflow that contributors should follow.

Issues and pull requests

Contributing to Fybrik is done following the GitHub workflow of Pull Requests.

You should usually open a pull request in the following situations:

  • Start work on a contribution that was that you’ve already discussed in an issue.
  • Submit trivial fixes (for example, a typo, a broken link or an obvious error).

A pull request doesn’t have to represent finished work. It’s usually better to open a draft pull request early on, so others can watch or give feedback on your progress.

Here’s how to submit a pull request:

  • Fork the main repository
  • Clone the forked repository locally. Connect your local to the original “upstream” repository by adding it as a remote.
    git clone$(git config
    git remote add upstream
    git remote set-url --push upstream no_push
  • Pull in changes from “upstream” often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely.
    git fetch upstream master
    git checkout master
    git merge upstream/master
    git push origin master
  • Create a branch for your edits from master. Note that you should never add edits to the master branch itself.
    git checkout -b <branch name>
  • Make commits of logical units, ensuring that commit messages are in the proper format.
  • Push your changes to the created branch in your fork of the repository.
  • Open a pull request to the original repository.
  • Reference any relevant issues or supporting documentation in your PR (for example, “Closes #37.”)

As always, you must follow code style, ensure that all tests pass, and add any new tests as appropriate.

Thanks for your contribution!

Normalize the code

To ensure the code is formatted uniformly we use various linters which are invoked using

make verify

Format of the Commit Message

The project follows a rough convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why.

Every commit must also include a DCO Sign Off at the end of the commit message. By doing this you state that you certify the Developer Certificate of Origin. This can be automated by adding the -s flag to git commit. You can also mass sign-off a whole PR with git rebase --signoff master.

Example commit message:

scripts: add the test-cluster command

this uses tmux to setup a test cluster that you can easily kill and
start for debugging.

Fixes #38

Signed-off-by: Legal Name <>

The format can be described more formally as follows:

<subsystem>: <what changed>
<why this change was made>

The first line is the subject and should be no longer than 70 characters, the second line is always blank, and other lines should be wrapped at 80 characters. This allows the message to be easier to read on GitHub as well as in various git tools.