|
| 1 | +# Contributing |
| 2 | + |
| 3 | +There are multiple different workflows with different advantages and disadvantages. |
| 4 | +The most common workflows are: |
| 5 | + |
| 6 | +- [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) |
| 7 | +- [GitHub Flow](https://githubflow.github.io/) |
| 8 | +- [GitLab Flow](https://about.gitlab.com/blog/2014/09/29/gitlab-flow/) |
| 9 | + |
| 10 | +## GitHub Flow (How we want to work) |
| 11 | + |
| 12 | +GitHub Flow is very lightweight (especially compared to GitFlow). |
| 13 | +This workflow uses only two kinds of branches: |
| 14 | + |
| 15 | +- Feature branch |
| 16 | +- Main branch (previously called master) |
| 17 | + |
| 18 | +The `feature` branches are used to develop new features as well as fixes. |
| 19 | +These branches are usually created out of main. |
| 20 | + |
| 21 | +Anything in the `main` branch is deployable. |
| 22 | +The `main` branch is expected to be deployed regularly and is considered stable. |
| 23 | + |
| 24 | +### How to work with GitHub Flow |
| 25 | + |
| 26 | +For more Information see [GitHub Flow](https://githubflow.github.io/) |
| 27 | + |
| 28 | +TL;DR |
| 29 | + |
| 30 | +1. anything in the main branch is deployable |
| 31 | +2. create descriptive branches off of main |
| 32 | +3. push to named branches constantly |
| 33 | +4. open a pull request at any time |
| 34 | +5. merge only after pull request review |
| 35 | +6. deploy immediately after review |
| 36 | + |
| 37 | +### Why not GitLab Flow or GitFlow |
| 38 | + |
| 39 | +Both `GitLab Flow` and `GitFlow` are to complex for our use case. |
| 40 | + |
| 41 | +## Working with The Community / Working with Forks |
| 42 | + |
| 43 | +Our current continuous integration workflow makes it very hard to work on own forks of the SecureCodeBox because CI tests cannot be executed outside of our repository. We are aware of that problem and are working on a solution. |
| 44 | + |
| 45 | +## Working with Issues |
| 46 | + |
| 47 | +`GitHub Flow` does not enforce you to use Issues but it is highly encouraged. |
| 48 | +It is recommended to use an Issue for every Task taking longer than 1h (See [GitLab Flow](https://about.gitlab.com/blog/2014/09/29/gitlab-flow/)). |
| 49 | + |
| 50 | +## How to Write Commit Messages |
| 51 | + |
| 52 | +For more Information see [here](https://chris.beams.io/posts/git-commit/). |
| 53 | + |
| 54 | +TL;DR |
| 55 | + |
| 56 | +1. Separate subject from body with a blank line |
| 57 | +2. Limit the subject line to 50 characters |
| 58 | +3. Capitalize the subject line |
| 59 | +4. Do not end the subject line with a period |
| 60 | +5. Use the imperative mood in the subject line |
| 61 | +6. Wrap the body at 72 characters |
| 62 | +7. Use the body to explain what and why vs. how |
0 commit comments