Version control
---------------

We use the internal `PSI Gitlab server <https://git.psi.ch/>`_ for version
control. On this server we use a single repository group (``linux-infra``) for
all infrastructure-related repositories, because this way a number of things
have to be configured only once, e.g. members. In addition milestones and labels
are group-wide concepts in Gitlab, and it is very useful to have those apply to
all repositories. Finally it is easy to see all issues and merge requests for a
repository group.


Repositories
~~~~~~~~~~~~

Our repositories are configured in the following way:

The ``puppet`` repository
.........................

- Fast-forward merges only

  This keeps the history linear without merge commits, which makes it easier to
  read.

- Merges to ``prod`` or ``preprod`` require one approval

- Approval is revoked when further changes are pushed to an already approved
  merge request.

- The default branch is called ``prod``. There is no ``master`` branch.
- The ``prod`` branch is protected.
- The ``preprod`` branch is protected.


Hiera repositories
..................

These repositories contain Hiera data. There is exactly one repository per sysdb
environment. The repository for environment ``foo`` is called ``data-foo``.

Access is granted to the owner and admins of the corresponding sysdb environment.


Development workflow
~~~~~~~~~~~~~~~~~~~~

We steer development through Gitlab issues.

For every change, be it a new feature, bug fix, or improvement, we create an
issue on the relevant repository. Issues that have broader implications and do
not naturally belong to a code repository, go into the ``org`` repository. An
example would be a change of the development workflow or repository
authorization.

When starting work on a change, the developer first assigns the issue to
themselves.

Once the developer has finished development and tested the change, they rebase
their changes to the ``prod`` branch, push the changes to a new branch, and
opens a merge request to the ``preprod`` branch. Each issue ``#N`` being fixed
must be mentioned at the start of the commit message in the form ``Fix #N``.

Other developers will review the merge request. If they approve it, either the
approving or the original developer may accept it, which will trigger the actual
merge.
