|
|
|
---
|
|
|
|
title: Developer guide
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# IMPORTANT
|
|
|
|
|
|
|
|
If you have a local clone of the repository that **predates Feb. 19th, 2025, you must absolutely make a new clone**.
|
| ... | ... | @@ -19,12 +12,25 @@ The procedure depends on if you have local unpushed changes. |
|
|
|
|
|
|
|
# Joining the developers of PASE
|
|
|
|
All contributions are welcome. To start coding :
|
|
|
|
- read this developer guide completely for essential information and practices to follow
|
|
|
|
- either check the issues or get in touch with the team (see [Contact](contact) page) to join the collaboration
|
|
|
|
- read this developer guide **completely** for essential information and practices to follow
|
|
|
|
- either check the [issues](https://gitlab.uliege.be/deal-public/pase/-/issues) or get in touch with the team (see [Contact](contact) page) to join the collaboration
|
|
|
|
- clone or fork the repository
|
|
|
|
- use an existing branch or create one according to the [branching workflow](#branching-workflow)
|
|
|
|
- edit or add to the code, making sure to follow the [Push rules](#push-rules) and other guidelines from this wiki !
|
|
|
|
|
|
|
|
Here is a short summary of each step of the process of collaborating to the project:
|
|
|
|
|
|
|
|
| Step | Wiki section | Description | |
|
|
|
|
|------|-----------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|---|
|
|
|
|
| 1 | [Branching strategy : git-flow](#branching-strategy--git-flow) | Read about the collaborative branching strategy git-flow used for every branch in this repository. | |
|
|
|
|
| 2 | [Branching workflow](#branching-workflow) | Discover how to apply the branching strategy with Gitlab’s integrated tools : Issues, Branch and Merge Requests creation in Gitlab | |
|
|
|
|
| 2.1 | [Issue](#issue) | Create an Issue to describe a bug or a feature request. It is used to design the implementation before starting to code and is mandatory. | |
|
|
|
|
| 2.2 | [Creating Branch and Merge Request](#creating-the-branch-and-merge-request) | Once the issue is opened, a branch and corresponding merge request are created from the issue page on Gitlab. | |
|
|
|
|
| 3 | [Push rules](#push-rules) | The rules to follow to be able to push on the Gitlab repository. The repository will refuse any commits or branches that do not comply with these rules. | |
|
|
|
|
| 4 | [Start coding](#start-coding) | Suggestions when you start to code on the newly created branch. | |
|
|
|
|
| 5 | [Merge Requests](#merge-requests) | How and when to use Merge Requests | |
|
|
|
|
| 6 | [Semantic Versioning](#semantic-versioning) | How and when a new version is released | |
|
|
|
|
| 7 | [Good practices](#good-practices) | General advice and suggestions | |
|
|
|
|
|
|
|
|
# Branching strategy : git-flow
|
|
|
|
source : https://nvie.com/posts/a-successful-git-branching-model/
|
| ... | ... | |
