Team events - WetinDeySup API
Live link is at https://example.com/api
Redoc docs at https://example.com/redoc/
Markdown docs at DOCUMENTATION.md
Before setting up the project locally, ensure you have the following prerequisites installed:
- Python (>=3.11.4)
- Django
- Django Rest Framework
- A Database System (e.g., PostgreSQL, MySQL, SQLite) - Django Database Installation
-
Clone the repository:
git clone https://github.com/hngx-org/events-be-python.git -
Change into the parent directory:
cd events-be-python -
Set up a virtual environment:
python3 -m venv venv -
Activate your virtual environment:
source venv/bin/activate -
Install the Python dependencies:
pip install -r requirements.txt -
Create a .env file and set necessary secret keys below:
-
Apply migrations to create the database schema:
python3 manage.py migrate -
Start the development server:
python3 manage.py runserver
The API should now be running locally at http://localhost:8000/.
- dev -> pr this branch for everything
backendrelated - main -> dont touch this branch, this is what is running in production.
Team_Romulus_Zuri_MarketPlace is open to contributions, but I recommend creating an issue or replying in a comment to let us know what you are working on first that way we don't overwrite each other.
- Clone the repo
git clone https://github.com/hngx-org/events-be-python.git. - Open your terminal & set the origin branch:
git remote add origin https://github.com/hngx-org/events-be-python.git - Pull origin
git pull origin dev - Create a new branch for the task you were assigned to, eg
TicketNumber/(Feat/Bug/Fix/Chore)/Ticket-title:git checkout -b ZA-001/Feat/Sign-Up-from - After making changes, do
git add . - Commit your changes with a descriptive commit message :
git commit -m "your commit message". - To make sure there are no conflicts, run
git pull origin dev. - Push changes to your new branch, run
git push -u origin feat-csv-parser. - Create a pull request to the
devbranch notmain. - Ensure to describe your pull request.
-
If you've added code that should be tested, add some test examples.
Under any circumstances should you merge a pull request on a specific branch to the dev or main branch
| Type | Description | |
|---|---|---|
| feat | Features | A new feature |
| fix | Bug Fixes | A bug fix |
| docs | Documentation | Documentation only changes |
| style | Styles | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.) |
| refactor | Code Refactoring | A code change that neither fixes a bug nor adds a feature |
| perf | Performance Improvements | A code change that improves performance |
| test | Tests | Adding missing tests or correcting existing tests |
| build | Builds | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
| ci | Continuous Integrations | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
| chore | Chores | Other changes that don't modify, backend or test files |
| revert | Reverts | Reverts a previous commit |
Sample Commit Messages
chore: Updated README file:=choreis used because the commit didn't make any changes to the frontend or test folders in any way.feat: Added plugin info endpoints:=featis used here because the feature was non-existent before the commit.