Skip to content

Git#

Branches#

Git Branches are used to structure the developments and improvements.
It is recommended to activate suitable GitHub Branch protection rules.

Permanent Branches#

  • production - includes the current stable (latest) version
  • develop - includes all current developments

Temporary Branches#

  • bug - includes bugfixes and typos
  • enhance - includes enhancements and improvements
  • feature - includes a new feature that will be implemented
  • hotfix - includes small improvements before a release, should be branched from a release branch
  • release - includes the current version to be released

The majority of the development will be done in enhance and feature branches.

Branch protection#

Branch protection rules help safeguard the code by enforcing workflows and permissions on specific branches.
The level of protection should correspond to the number of active developers and the importance of the package.
The production branch should have
- Require a pull request before merging with Require approvals and 1 other developer. - Require status checks to pass before merging

Gitignore#

This file specifies intentionally untracked files to ignore.
It is copied from a collection of .gitignore templates.
For more information about how 📝 .gitignore files work,
see the Ignoring Files chapter of the Pro Git book.

Issue Templates#

Issue Templates offer specific functions and default configurations for new issues.

Pull Request (PR) Template#

The Pull Request Template is used for all PR, because it is only possible to create a single one.
It includes all needed information to merge branches and release new versions.

GitHub Projects#

GitHub Projects help to organise and manage the issues and PR across different repositories.
It can be used for the release procedure, research projects, and complex developments.

GitHub Labels#

GitHub Labels are used to organize Issues and PR.
Colours and emoticons improve presentation, see:
📝 github-labels.json

GitHub Workflows (Actions)#

GitHub Actions are used to automate processes of the repository.
Main use-cases are building and publishing the documentation and run automated tests.

Code coverage with codecov#

Codecov is a code coverage and quality test for the repository.
A login and token is needed to implement the codecov badge for the README.rst.

Documentation with gh-pages#

The develop branch is directly updated using mike and mkdocs.
The included git fetch ensures that the released main versions are not deleted.

Publish on Test PyPI#

This workflow releases the package on PyPI using build.
The token has to be added to the GitHUb Secrets.

Publish on PyPI#

This workflow releases the package on PyPI using build.
The token has to be added to the GitHUb Secrets.

License test with REUSE#

The REUSE action does a full compliance check of all files of the repository.
It uses the REUSE.toml and file headers and provides a badge.

Automated tests with tox#

Tox automates and standardizes testing for the repository.
It builds the packages with different environments and versions.
The file tox.ini configures tests: pytest, coverage and ruff.

Pre-commit#

Pre-commit is a tool to easily setup and run pre-commit hooks for your git repository.
See the best-practice documentation of pre-commit or the official documentation for further information.
It is used to improve auto-format code, do linting and run tests before every commit.

Install#

Install the required package in a python environment.
💻 pip install pre-commit Install pre-commit
💻 pre-commit install Install pre-commit

Setup#

The hooks are configured in the file 📝 .pre-commit-config.yaml.
List of implemented hooks:

  • Pre-commit-hooks - Out-of-the-box hooks
  • Black - Python code formatter
  • isort - Sort Python imports
  • Ruff - Fast Python linter, written in Rust
  • Flake8 - Python linter with PyFlakes and pycodestyle
  • mypy mirror - Added static types to Python
  • mirrors-prettier - Formatting for other files then python scripts
  • reuse - License and copyright information

Use#

All commits will trigger the hooks automatically.
💠 git commit file -m "Commit message #IssueNr" Commit with message

Commit without running the hooks.
💠 git commit --no-verify file Commit without hooks

Line endings

There can be problems with file line endings on Windows, CRLF is used on Windows and LF is used on Linux.

To run the hooks on all files in your repository use:
💻 pre-commit run --all-files Run pre-commit hooks

Markdown files / Admonitions

If the hook is applied to markdown files that include special formatting, (for example 📝 mkdocs.yml), this can introduce incorrect changes. This effects admonitions boxes for MkDocs.

Used Icons

🐙 GitHub | 💠 git | 📝 File | 💻 Command Line