|
| 1 | +# **Contributing** |
| 2 | + |
| 3 | +When contributing to this repository, please first discuss the change you wish to make via issue, |
| 4 | +email, chat, or any other method with the owners of this repository before making a change. |
| 5 | + |
| 6 | +## Git Flow |
| 7 | + |
| 8 | +The project uses the Git Flow branching model. The main branches are `main` and `develop`. The `main` branch is the production-ready branch, and the `develop` branch is the integration branch. |
| 9 | + |
| 10 | +The branches are used as follows: |
| 11 | + |
| 12 | +* From Feature to Feature: squash and merge |
| 13 | +* From Feature to Develop: squash and merge |
| 14 | +* From Develop to Main: fast-forward merge |
| 15 | +* From Main to Develop: fast-forward merge |
| 16 | +* From Hotfix to Main: fast-forward merge |
| 17 | + |
| 18 | +It's important to follow this flow to keep the project organized and to avoid conflicts. |
| 19 | + |
| 20 | +Every time a feature is merged into the `main` branch, a new release should be created with the version number following the [Semantic Versioning](https://semver.org/) guidelines. |
| 21 | + |
| 22 | +Also, the project uses pre-commit hooks to ensure the code quality. You should install them with `pre-commit install`. |
| 23 | + |
| 24 | +## Commits |
| 25 | + |
| 26 | +The project uses the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. This is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history. This convention dovetails with [SemVer](https://semver.org/), by describing the features, fixes, and breaking changes made in commit messages. |
| 27 | + |
| 28 | +Each commit message should be conceptually unique and should be able to be understood by itself. It should only contain changes related to the name of the commit. If you need to make a commit with multiple changes that are independent (conceptually), you should split it into multiple commits. |
| 29 | + |
| 30 | +## Pull Request Process |
| 31 | + |
| 32 | +### Features |
| 33 | + |
| 34 | +1. Create your Feature Branch (`git checkout feature/{issue-number}-AmazingFeature`) |
| 35 | +2. Check that you have installed pre-commit hooks with `pre-commit install`. |
| 36 | +3. Check that your branch is up to date with `git pull` and merge if it's necessary with `git merge origin develop`. |
| 37 | +4. Commit your Changes (`git commit -m 'Add some AmazingFeature'`) |
| 38 | +5. Push to the Branch (`git push`) |
| 39 | +6. Open a Pull Request to the `develop` branch or to the main epic branch if there's one defined. |
| 40 | + |
| 41 | +### Bug Fixes |
| 42 | + |
| 43 | +Same as Features, but the branch name should be `bugfix/{issue-number}-FixingSomething`. |
| 44 | + |
| 45 | +### Hotfixes |
| 46 | + |
| 47 | +Same as Features, but the branch name should be `hotfix/{issue-number}-FixingSomething`. And the Pull Request should be opened to the `main` branch. |
| 48 | + |
| 49 | +## Issue Report Process |
| 50 | + |
| 51 | +1. Go to the project's issues. |
| 52 | +2. Select the template that better fits your issue. |
| 53 | +3. Read the instructions carefully and write within the template guidelines. |
| 54 | +4. Submit it and wait for support. |
| 55 | + |
| 56 | +## GitHub Projects |
| 57 | + |
| 58 | +You can use GitHub Projects to manage the project's tasks. It's a good way to keep track of the issues and pull requests. |
0 commit comments