|
|
|
---
|
|
|
|
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**.
|
| ... | ... | @@ -257,12 +258,16 @@ At the end of the branch development, the merge will occur through a Merge reque |
|
|
|
The Gitlab [documentation on merge requests](https://docs.gitlab.com/user/project/merge_requests/) states that :
|
|
|
|
> A merge request (MR) is a proposal to incorporate changes from a source branch to a target branch.
|
|
|
|
|
|
|
|
If you followed the instructions on this page correctly, you should have created a MR directly related to the issue and branch supporting the new feature.
|
|
|
|
If you followed the instructions on this page correctly, you should have created the MR related to the issue and branch supporting the new feature at the same time you created the branch.
|
|
|
|
You can consult this MR at anytime to have an overview of all the commits pushed within that MR's scope, as well as all the changes between the latest commit and the branching commit.
|
|
|
|
The MR interface will be used for review by peers, to give feedback and ask questions about the proposed changes.
|
|
|
|
|
|
|
|
## Approval
|
|
|
|
Approval by one member of the DEAL lab is currently mandatory.
|
|
|
|
|
|
|
|
Approval by one Owner of the project is currently mandatory (see [Contact page](contact)).
|
|
|
|
For clarity, only assign a reviewer to your MR when the work is ready for review, i.e. you have finished development of the new feature and have tested that the code behaves as intended.
|
|
|
|
This makes it easier to distinguish between MR that are "work in progress" vs "ready for review".
|
|
|
|
When assigning a reviewer, you can also send an e-mail to explain the context of the MR.
|
|
|
|
|
|
|
|
Approval will be granted if your changes:
|
|
|
|
- meet the criteria listed under [Good practices](#good-practices)
|
| ... | ... | @@ -271,6 +276,9 @@ Approval will be granted if your changes: |
|
|
|
|
|
|
|
## Merging
|
|
|
|
Once an MR is approved, you can prepare to merge it in the target branch (typically, feature branches merge into develop).
|
|
|
|
Depending on the situation, the merge should be handled by :
|
|
|
|
- `feature -> develop`: the developer of the feature/branch
|
|
|
|
- `release -> main` : case-by-case because this operation is both more sensitive and less frequent
|
|
|
|
|
|
|
|
You can :
|
|
|
|
- check "Delete source branch"
|
| ... | ... | |
