Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add gitflow section to the developer guide #272

Merged
merged 1 commit into from
Dec 10, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion docs/development.rst
Original file line number Diff line number Diff line change
Expand Up @@ -21,10 +21,17 @@ The :mod:`highdicom` package can be installed in *develop* mode for local develo
Pull requests
-------------

Don't commit code changes to the ``master`` branch. New features should be implemented in a separate branch called ``feature/*`` and bug fixes should be applied in separate branch called ``bugfix/*``.
We encourage contributions from the users of the library (provided that they fit within the scope of the project).

If you are planning to make a contribution to the library, we encourage you to leave an issue first on the `issue tracker <https://github.com/ImagingDataCommons/higdicom/issues>`_ detailing your proposed contribution.
This way, the maintainers can vet your proposal, make sure it is within the scope of the project, and guide you through the process of creating a successful pull request.
Before creating a pull request on Github, read the coding style guideline, run the tests and check PEP8 compliance.

We follow a `gitflow <https://nvie.com/posts/a-successful-git-branching-model/>`_-like process for development.
Therefore, please do not commit code changes to the ``master`` branch.
New features should be implemented in a separate branch called ``feature/*``, and a pull request should be created with the target set as the development branch with the name of the *next* release (e.g. ``v0.22.0dev``).
Bug fixes that do not affect the public API of the project should be applied in separate branch called ``bugfix/*`` and a pull request should be created with targeted at ``master`` branch.

.. _coding-style:

Coding style
Expand Down