---
# System prepended metadata

title: How to read this documents
tags: [dev, guide]

---

###### tags: `dev` `guide`
<div style="display: flex; justify-content: space-between;">
  <span>Version 1.0.0</span>
  <span>2020/11/23</span>
</div>
<div style="height:30em"></div>
<div style="text-align:center">
	<h1 style="font-size:3.5em;line-height: 2.5;border: none;">Back to Basics - How to Dev</h1>
	<div>
Jules Lefebvre <a href="mailto:jules.lefebvre@epita.fr">&lt jules.lefebvre@epita.fr&gt;</a>
    </div>    
</div>
<div style="height:30em"></div>

----

[TOC]

----
# How to read this documents
This document use the world **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, **MAY** define in the [RFC 2119](https://tools.ietf.org/html/rfc2119).

# Project Management

## Chef
Each project **MUST** have a **chef**. He will be responsible for the progress of the project and need to have a general vision of it, how it works (in general) and what his team does.

## Trello
We will use [Trello](https://trello.com) to manage the organization and the progress of the project.<!-- TODO -->

## Documentation
Because developer can't bring support in a long periode of times, due to the limited time we are in the organization. So project **MUST** have a documentation.

The documentation **MUST** to include the next points:
- **Install guide :** an explained list of operations to install and build the project
- **Features :** the list of all features and how to use it and where the been implemented
- **Usage :** a kick guide off how to use the project 

Each Projet **MUST** have a `README.md`.

# ✏️ Coding style

You **SHOULD** use the [**EPITA's C coding style**](https://ceph.assistants.epita.fr/public-documents.assistants.epita.fr/coding-style-epita.pdf).

:warning:Except the `2.3 braces.indent` rule : We **MUST NOT use a 4 spaces indentation** but **MUST use 2 spaces indentation**

:heavy_plus_sign: All  code **MUST** be commented, otherwise you change can't be accepted and merged

You **MAY** need to adapt the epita coding style in function of your programming language. In this case, you **MUST** provide a document detailing the changes.

# 🔀 Git/Gitlab
All project **MUST** be versioning using git and store on the EPITA github in a sub url of https://gitlab.cri.epita.fr/associations/back-to-basics/dev/

## #️⃣ Versioning
The project **MUST** be versioning using the [Semantic Versioning](https://semver.org/) : `MAJOR.MINOR.PATCH`:

- `MAJOR` was incremented every **rewrite**
- `MINOR` was incremented every **new feature**
- `PATCH` was incremented every **new fix/patch**

Please modify each file containing the project version after each version change.


## 🌳 Branch structure

### Master
It's the main branch and the deployment branch.


⚠️ branch name **MUST** match this regex:
```regex
^master$
```

🛑 you **MUST NOT** make and push any commit on it
🟢 you **MAY** make a **pull request** from the [version branch](#Version)
⚠️ all feature **MUST** work **completely**


### Version
For each new release you need to create a version branch.

Each version branch follow this format :
```
version/1.0.0
```
Where `1.0.0` is the version number. :arrow_right: see [Versioning](##️⃣-Versioning)

The branch name need to match this regex:
```regex
^version/(?P<version>(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*))$
```

🛑 you **MUST NOT** make and push any commit on it
🟢 you **MAY** make a **pull request** from the [code branch](#Code)
⚠️ all feature **MUST** work 
⚠️ this type of branch **MUST** derivate from the [master branch](#Version)
⚠️ new branch **MUST** have a version number nerver used

### Code
It is in this branch that you can make modification and write code.

Each code branch as this format :
```
1.0.0/feature/feature_name
```
- `1.0.0` is the version number of the linked version. :arrow_right: see [Versioning](##️⃣-Versioning).
- `feature` is the key word to specify what type of change is make in this branch.
  exemple :
  - `feature`
  - `fix`
  - `documentation`
  - ...
- `feature_name` an explicite name of the modification. exemple `user_database`, `freeze_command`.

⚠️ this type of branch **MUST** derivate from the [version branch](#Version) with the same version number
⚠️ the branch **MUST** match this `regex`:
```regex
^(?P<version>(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*))/(?P<type>[a-z]+)/(?P<name>\w+)$
```

🟢 you **MUST** push all you commit on this type of branch
🟢 all feature **MAY** not work 

## 📝 Commit

Each commit **SHOULD** follow this patern :
```markdown
ACTION: title

desciption

**ACTION_1:**
- `path/to/file1`: modification
  second line comments
- `path/to/file2`: modification

**ACTION_2:**
- `path/to/file2`: modification
```
`desciption` is optional

Where `ACTION` can be :
- `INIT`
- `ADD`
- `MODIFY`
- `FIX`
<!-- Maybe add DELETE -->

Your commits **MUST** match the following regex:
```regex
^(?:(?P<title>(?P<title_type>INIT|ADD|MODIFY|FIX|MOVE): (?P<title_name>.+)))(?:

(?P<description>.+(?:
.+)*))?
(?P<changes>(?:
\*\*(?:INIT|ADD|MODIFY|FIX|MOVE):\*\*
- `[/\w.-]+`: .+(?:
  .+)*)+)$
```

**Exemple:**
```markdown
ADD: mask object lib

add a lib to manage 1 channel images.
and other thing

**ADD:**
- `src/image/mask.c`: the implementation of the `s_mask` struct
- `src/image/mask.h`: the definition of the `s_mask` struct

**MODIFY:**
- `Makefile`: add `image/mask` header and source file to


  compilation

**FIX:**
- `Makefile`: create the parent forlder if not exist in `.o` file
```

<!-- Maybe add a section for Issues and Pull Requests -->