|
|
If we are in a position where new developments or bug fixes need to be merged from a branch back to master, follow the rules defined here. If there is anything unclear also in specific cases, we can always discuss in our meetings.
|
|
|
|
|
|
It is very useful and will speed up the process described here if particular developments have already been discussed in meetings or gitlab Issues BEFORE a Merge Request or any development is started.
|
|
|
|
|
|
A merge request is not complete, if there are no Labels assigned.
|
|
|
|
|
|
- Select between: Bug, Feature, Development
|
|
|
- Specify, if needed: Critical (must be addressed immediately), Important (blocks other things)
|
|
|
- Describe the scope: Stack, Documentation, Processes, Testing, Style, ... (add further items if needed)
|
|
|
|
|
|
```mermaid
|
|
|
graph TD;
|
|
|
subgraph "Code contributor"
|
... | ... | @@ -7,13 +15,15 @@ graph TD; |
|
|
A000[Creating new MR] --> A001[Via existing gitlab Issue];
|
|
|
A000 --> A002[Via MR/Create new MR];
|
|
|
A000 --> A003[From existing branch, or fork];
|
|
|
A002 --> A004[Make sure the MR title starts with `WIP:`];
|
|
|
A002 --> A004[Make sure the MR title starts with `WIP:` to mark it as work in progress];
|
|
|
A003 --> A004;
|
|
|
A001 --> A004;
|
|
|
|
|
|
A001 --> A005[Use the MR template `New Merge Request`];
|
|
|
A004 --> A005;
|
|
|
A004 --> A005[Use the MR template `New Merge Request`];
|
|
|
A005 --> A006[If not automatic but possible: create link to Issue];
|
|
|
A006 --> A007[Assign labels. Check wiki here.];
|
|
|
|
|
|
A005 --> A0
|
|
|
A007 --> A0
|
|
|
|
|
|
A0[Working on MR/branch] -- Finished main work --> A2[Make sure all conditions for code review and approval are met];
|
|
|
A2 -- Ok --> A3[Remove WIP status];
|
... | ... | |