Version Control =============== Setting up Git -------------- Initialize Git to use your username and PSI email address, for example:: git config --global user.name kaminski_k git config --global user.email kai.kaminski@psi.ch Gitlab server ------------- We use the `PSI-internal Gitlab server `_ to host our repositories. Groups ------ Currently, all of our repositories are in the repository group ``linux-infra``. Setting up a repository ----------------------- Repositories containing code are configured along the following lines: 1. Only fast-forward merges are allowed, no merge commits. 2. Merge requests require at least one approval (by someone other than the requester). Workflow -------- Changes to repositories containing **only** documentation can simply be pushed to the repository in question. Changes to repositories containing code, SPEC files, or anything else that is not pure documentation, need to be reviewed - even if the change in question only changes documentation. To implement a change, follow these steps: 1. Create an issue on GitLab. 2. Create a feature branch with name starting with `issue-n-description`. 3. Assign the issue to yourself when you start working on it. 4. Commit the change to the feature branch and push it. 5. Create a merge request mentioning the issue in the commit message or in the merge request (see `this `_ for the syntax). 6. Wait for **someone else** to approve and apply the merge request. Commit messages ~~~~~~~~~~~~~~~ A commit message follows the well-known `50/72 format `_: 50 characters for the first line of the commit message, followed by a blank line, which is then followed by zero or more paragraphs with a maximal line-length of 72 characters. If the commit fixes an issue recorded on Gitlab (which it should), the commit message must start with ``Fix #N:``, where ``N`` is the number of the issue. This will automatically close the issue when the commit is merged into master. Code reviews ~~~~~~~~~~~~ During a code review be sure to check for at least the following: 1. adherence to the guidelines described in this document,e.g. PEP8-compliance for Python code 2. solid implementation: edge cases and failures are considered and handled appropriately, etc. Non-obvious bits are explained. 3. documentation has been written or changed as appropriate