How do you organize version control systems in your projects?

Used Git as the main version control system.

The workflow was usually based on Gitflow, or its simplified model, depending on the team size and project complexity.

Main branches:

• main (or master): stable version ready for deployment or already in production.
• develop: integration branch for all features.

Additional branches:

• feature/feature-name: for feature development.
• release/version-number: for preparing a new release, fixing last bugs.
• hotfix/fix-name: for urgent fixes in production.

Development process:

1. Create a feature branch from develop.
2. Develop and commit locally.
3. Periodically rebase onto the current develop for synchronization.
4. Create a pull request (or merge request) into develop.
5. Code review by other team members.
6. Merge the feature branch into develop.

For version control of the application itself, used semantic versioning (Major.Minor.Patch).

• Major: incompatible API changes.
• Minor: added functionality with backward compatibility.
• Patch: bug fixes with backward compatibility.

The project version was stored in a file (e.g., __version__.py or setup.py) and updated during release preparation. Git tags were used to mark each released version.

Example versioning structure:

// __version__.py
__version__ = "1.2.3"

Git tag for this version: v1.2.3.

Tools like bumpversion or python-semantic-release could be used for automating versioning and creating tags.

Automated checks (CI) were run on each push and pull request to maintain code quality and detect conflicts early.

Example .gitignore:

// .gitignore
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# Distribution / packaging
.Python
env/
venv/
build/
develop-eggs/
dist/
eggs/
*.egg-info

# Editors
.idea/
.vscode/
*.swp