• Contributing
  • GitHub Flow
    • How to work with GitHub Flow
  • Working with Forks and Pull Requests
  • Bugfixing and Security Fixing Released Features
  • Working with Issues - How to Contribute in Issues
  • How to Write Commit Messages
  • Code of Conduct
  • Developer Certificate of Origin and Licensing

For more information see GitHub Flow

GitHub Flow is very lightweight (especially compared to GitFlow). This workflow uses only two kinds of branches:

• Feature branch
• Main branch (previously called master)

The feature branches are used to develop new features as well as fixes. These branches are usually created out of main.

Anything in the main branch is deployable. The main branch is expected to be deployed regularly and is considered stable.

For more information see GitHub Flow

TL;DR

1. anything in the main branch is deployable
2. create descriptive branches off of main
3. push to named branches constantly
4. open a pull request at any time
5. merge only after pull request review
6. deploy immediately after review

Please make sure to sign all your commits (See: git-scm).

Please make sure to sign all your commits (See: git-scm).

If you want to contribute you will need to fork the project. To enable the use of our CI Pipeline you will need to add these GitHub secrets:

If you want early feedback feel free to open a Draft Pull Request. When you are done, you can convert it to a standard Pull Request (or create one if you did not create a Draft Pull Request).

Generally the secureCodeBox project follows the standard GitHub Pull request process.

Please make sure to sign all your commits (See: git-scm).

For bugfixes and security fixes of the current release please follow the following workflow:

• For the minor release
  • Checkout current minor release branch (e.g. v2.5.x) or create if not existent from latest git tag
  • Create a bugfix branch from release branch
  • Fix Bug
  • Create PR to release branch
  • Generate new semver release
• For the main branch:
  • Create a bugfix branch from main branch
  • Cherry-Pick Bugfix and commit to bugfix branch
  • Create PR to main branch

It is mandatory to open an issue, if the task takes longer than one hour. Before you open an issue please verify there is no existing one covering your issue.

For more information see Chris Beams article.

TL;DR

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

NOTE: Make sure you don't include @mentions or fixes keywords in your git commit messages. These should be included in the PR body instead.

NOTE: Make sure to add your signed-off-by tag as described in our contributors file.

Please have a look at our Code of Conduct before you write an Issue or make a PR.

We decided to use DCO instead of CLA as described in CLAs and using DCO clearly. The reason for that: We need to be sure that one submitting a contribution to this repository is allowed to do this and does not violates copyrights of someone else. For that purpose you have to do some steps to to fullfil our DCO requirements:

1. Read carefully our contributors file.
2. Open a pull request which adds you to the contributors file to agree the DCO.
3. Always add a signed-of tag to all your commits as described in the contributors file.
4. Add a SPDX license header to all files your contribution will create. You can use the reuse tool with our helper script.