If you have a local clone of the repository that **predates Feb. 19th, 2025, you must absolutely make a new clone**.
...
...
@@ -23,7 +15,7 @@ The procedure depends on if you have local unpushed changes.
All contributions are welcome. To start coding :
- 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
- clone or fork the repository (contributions via the forking workflow ([see e.g. Gitlab Docs about Forks](https://docs.gitlab.com/user/project/repository/forking_workflow/)) are accepted, provided all push rules are followed ; continue reading the guide for more details).
- 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 !
...
...
@@ -430,4 +422,4 @@ When creating a new modules, class, method or function, add a [docstring](https:
-**NEVER** add "all files" to git's tracked files (i.e. DO NOT use `git add .` or `git add -A` or `git add -A .`), for 2 reasons :
- either it adds many modified or newly created files, making it hard to distinguish meaningful changes in a commit
- either it will miss files intended to be tracked just because their extension is listed in .gitignore (e.g. if you create a new csv file that is required to run a simulation, `git add .` and similar commands will miss it)
- regularly pull `main` and `develop` branches from remote so you have the latest changes on your computer
\ No newline at end of file
- regularly pull `main` and `develop` branches from remote so you have the latest changes on your computer
