Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/WorkTeam01/team-practice/llms.txt

Use this file to discover all available pages before exploring further.

This project follows Git Flow — all development happens on feature or bugfix branches created off dev, and main only receives stable merged releases. No contributor pushes directly to main; every change enters the codebase through a Pull Request that targets dev and passes code review.

​
Branch types

Each branch prefix signals the nature of the work it contains. Choose the prefix that matches what you are implementing.
Branch PrefixPurpose
feature/New functionality being added to the calculator
bugfix/Correcting a bug or unexpected behaviour
hotfix/Urgent correction applied directly against a production issue in main
release/Preparing and stabilising a new version for release

​
Branch naming

Branch names should be lowercase, hyphen-separated, and descriptive enough that teammates understand the work at a glance. 
feature/add-history
bugfix/fix-division-display
hotfix/critical-crash-fix
release/2.2.0

​
Step-by-step workflow

1

Create or claim an issue on GitHub

Before writing any code, open or assign yourself an issue that describes the work. This keeps the team aligned and avoids duplicated effort. Reference the issue number later with Closes #<number> in your PR description.
2

Sync your local dev branch

Always start from an up-to-date dev to avoid merge conflicts later.
git checkout dev
git pull origin dev
3

Create your feature branch

Branch off dev using the appropriate prefix and a short descriptive name.
git checkout -b feature/my-feature
4

Make changes and commit using Conventional Commits format

Every commit must follow the <type>: <short imperative description> format. See the Commit Conventions page for full details on types and examples.
git add .
git commit -m "feat: agregar soporte de historial de operaciones"
5

Run tests before pushing

All tests must pass locally before you push. The CI pipeline will also run them, but catching failures early saves review time.
pytest -v
6

Push your branch

Push the branch to the remote repository.
git push origin feature/my-feature
7

Open a Pull Request targeting dev

On GitHub, open a Pull Request from your branch into dev. Select the appropriate PR template (feature, bugfix, or release) — see the Pull Request templates section below. Fill in every section of the template, including the related issue reference (Closes #<number>).
8

Address review comments, receive approval, and merge

Respond to all review comments, push any requested changes to the same branch, and wait for at least one team member approval before merging. Do not force-push to a branch that already has an open PR.

​
Branch protection

Pull Requests must target dev as the base branch — not main. The only exception is hotfix/ branches, which address urgent production issues and merge directly into main. All other branch types (feature/, bugfix/, release/) always target dev. Merges from release/ branches into main are handled by maintainers as part of the release process.

​
Pull Request templates

The repository provides three PR templates that appear automatically when you open a Pull Request, depending on the branch type:
  • feature.md — used for feature/ branches. Covers description, related issue, implementation details, a Python code snippet for the new function, test results checklist, and a documentation checklist.
  • bugfix.md — used for bugfix/ branches. Covers the bug description, root-cause analysis, reproduction steps, fix verification commands, and a regression-test checklist.
  • release.md — used for release/ branches targeting main. Covers the list of included features and fixes, full test results, documentation checklist, and a pre/post-merge release checklist. This template requires approval from all team members before merging.
Fill in every section of the template. Incomplete PRs may be returned for revision before review begins.

​
Reporting issues

GitHub Issues use structured templates so that reports contain all the information maintainers need. Choose the template that best matches your situation:
TemplateWhen to use
reporte-errorA bug or unexpected behaviour in the calculator — include reproduction steps, expected output, and actual output.
funcion-calculadoraProposing a brand-new mathematical function to add to calculator.py — include function name, purpose, and the implementation/test tasks.
mejora-funcionImproving or extending a function that already exists — describe what changes and why.
sugerencia-generalOpen-ended ideas about project organisation, tooling, or team processes that do not map to a specific code change.
pruebas-unitariasAdding or improving test coverage for an existing function in test_calculator.py.
documentacionUpdating or correcting documentation in README.md, docstrings, or other project files.
gui_issueWork related to the tkinter GUI — new visual features, layout changes, or keyboard-shortcut improvements.

Build docs developers (and LLMs) love

Get started for freeTalk to us