Setting up the team repository

The team's GitLab project on szofttech.inf.elte.hu is created for you; this guide turns it into a project that enforces the workflow: protected branches, merge request rules, labels, a board, milestones and a wiki. Do it in the first weeks – before M2 – and do it once. Everything has a GitHub equivalent, listed at the end, if your team mirrors the project there or reuses the setup later.

The six steps

Most settings need the Maintainer role in the project. One member does steps 1–5; the smoke test at the end involves everyone (Fig. 1). Menu paths below follow the current GitLab interface – if a name differs slightly on the server, look for the same idea nearby.

Copy the template

Clone the team repository and copy the course's template into it (without the template's .git folder). It brings the contribution rules, the issue and MR templates, the git hooks, the CI pipelines per stack, .editorconfig and .gitattributes. Then replace the placeholder key with your project's 2–5 letter key:

# in the root of your clone, after copying the template in (without its .git folder)
grep -rl "KEY-" --exclude-dir=.git . | xargs sed -i "s/KEY-/ABC-/g"
# macOS: sed -i "" "s/KEY-/ABC-/g"

Choose your CI stack (one include line, see milestone 3), rewrite the README for your game, and keep the line-ending rules – they save a mixed Windows/Linux team from diffs where every line looks changed:

# .gitattributes – one line-ending rule for a mixed Windows / Linux / macOS team
* text=auto eol=lf
*.bat text eol=crlf
*.sh  text eol=lf
*.png binary

Branches and protection

git add .
git commit -m "chore: add project template"
git push origin main                 # the last direct push to main
git switch -c develop
git push -u origin develop           # from now on, everything goes through merge requests

Settings → Repository → Branch defaults
  Default branch:        develop
  Branch name template:  feature/ABC-%{id}-%{title}

With develop as the default branch, merge requests target it automatically and a fresh clone lands on it. The branch name template makes the issue page's Create branch button produce names like feature/ABC-12-implement-save-load.

Also protect tags matching v* (Protected tags), so a tag is only created as part of a release. The effect is simple: the only way into a protected branch is a merge request (Fig. 2).

Merge request rules

The MR template in .gitlab/merge_request_templates/Default.md is applied automatically to every new merge request; the issue templates in .gitlab/issue_templates/ appear in the Choose a template list. Both are read from the default branch – another reason it must be develop.

Labels, board, milestones, wiki

Labels (Manage → Labels)

Board (Plan → Issue boards)

Add three lists from the status:: labels: Todo, Doing, Review. Open and Closed stay at the edges. Dragging a card switches its label; merging an MR with Closes #12 closes the issue and moves it to Closed.

Milestones (Plan → Milestones)

Four milestones – M1 Requirements and design, M2 Prototype I, M3 Prototype II, M4 Final product – each due on the session of week 4, 7, 10 and 13 of your semester's calendar. Every issue gets one. The milestone page shows progress; look at it before every demo.

Wiki

Make sure the wiki is enabled (Settings → General → Visibility, project features, permissions) and that its home page links to the design pages of milestone 1.

CI settings and badges

• —Settings → CI/CD → Runners: the course server has shared runners. If there is no green dot, tell your instructor.
• —Settings → CI/CD → Variables: only for secrets, such as a Unity licence. Never put secrets in the repository.
• —Secret push protection, if the server offers it: the server then rejects a push that contains a password or token.

Two badges in the README show the state of develop at a glance:

[![pipeline](https://szofttech.inf.elte.hu/<group>/<project>/badges/develop/pipeline.svg)](https://szofttech.inf.elte.hu/<group>/<project>/-/pipelines)
[![coverage](https://szofttech.inf.elte.hu/<group>/<project>/badges/develop/coverage.svg)](https://szofttech.inf.elte.hu/<group>/<project>/-/pipelines)

The smoke test

A setup isn't done until one issue has travelled the whole path. This also teaches every member the workflow on something harmless:

1. New issue "Setup check" from the Feature template, milestone M1, assigned to you   → #1
2. On the issue: Create merge request → Create branch   → feature/ABC-1-setup-check
3. git fetch && git switch feature/ABC-1-setup-check, edit the README,
   git commit -m "verify workflow setup"   → the log shows "ABC-1: verify workflow setup"
4. Push, open the MR into develop with "Closes #1", name a reviewer
5. The pipeline runs; the reviewer approves; the author merges
6. The branch is gone, issue #1 is closed, the board card moved by itself
7. git push origin main  → rejected. That is the correct answer.

Every member, once

git clone <repo-url>
cd <repo>
./setup-hooks.sh                        # Windows cmd / PowerShell: .\setup-hooks.bat
git config user.email                   # must print the address of your GitLab account

The hooks are what add the issue key to every commit message; without them, commits are rejected by nobody and look different from everyone else's. The e-mail check matters for grading: GitLab attributes a commit to the account whose address is in it.

The same on GitHub

The course works on GitLab, but every piece has a GitHub counterpart – useful if you mirror the project or build your next team project there.

On GitHub, turn off squash and rebase merging, enable Automatically delete head branches, and in the ruleset require one approval, conversation resolution and the CI checks. Branch protection on a private repository needs a paid plan or the student pack.