A practical guide to the features and practices available to students and instructors through the GitLab for Education program.
Git and version control are foundational skills, and GitLab gives students a professional environment to practice them — not a sandboxed simulation. The Merge Request (MR) is the central unit of collaboration: students commit to a branch, open an MR, and instructors leave inline comments on specific lines. This mirrors professional code review exactly.
Work on a named branch for each feature or task. Keeps the main branch clean and teaches isolated, reviewable changes.
Each commit is a record of what changed and why. GitLab's commit history makes this habit visible and easy to practice.
Submit work as a merge request and add the instructor as a reviewer. The diff view, inline comments, and approval workflow mirror real-world review practices.
Instructors can protect the main branch so all changes must go through a merge request — enforcing good workflow habits and preventing accidental direct pushes.
GitLab's CI/CD runs automatically every time code is pushed. Students get a green checkmark or red failure badge without running anything locally. Instructors get objective grading data generated automatically before opening a submission.
A pipeline is defined in a single file — .gitlab-ci.yml — which lives in the repository alongside the code.
Include a test suite in every assignment template. Students learn to write code that passes tests — a core professional practice.
Instruct students not to submit until their pipeline is green. This shifts responsibility for correctness to them and reduces manual grading effort significantly.
As students progress, introduce pipelines with multiple stages: lint, test, build. Teaches the real-world concept of quality gates before code is merged.
GitLab can display test results inline on merge requests — failed tests are highlighted by name, making it easy to see exactly what needs to be fixed.
One of the most significant advantages of Ultimate is access to GitLab's full suite of security scanners. These run automatically as part of the CI/CD pipeline and surface results directly on merge requests — security feedback appears the same way test failures do, as part of the normal development workflow.
| Scanner | What it finds | Teaching value |
|---|---|---|
| SAST | Vulnerabilities in source code — SQL injection, XSS, insecure functions | Shows students exactly which lines introduce risk, with remediation guidance |
| Secret Detection | Accidentally committed credentials — API keys, passwords, tokens | Catches a very common real-world mistake before it becomes a problem |
| Dependency Scanning | Known vulnerabilities in third-party libraries | Teaches students that security applies to code they didn't write too |
| Container Scanning | Vulnerabilities in Docker base images | Relevant for courses covering containerisation and deployment |
| DAST | Runtime vulnerabilities in running web applications | Useful for web development courses |
| IaC Scanning | Misconfigurations in Terraform, Kubernetes, etc. | Relevant for DevOps and cloud courses |
Enable secret detection in every assignment pipeline. Students learn never to commit credentials, and the scanner flags it immediately if they do.
For advanced courses, make the security dashboard part of the assessment. Require students to triage and remediate findings.
Use SAST findings in code review discussions. A scanner finding a SQL injection is a far more memorable teaching moment than a comment in a document.
Require students to check and address dependency scan findings before submission — mirrors real-world supply chain security practices.
Ultimate includes GitLab's full agile planning toolset — issues, epics, milestones, roadmaps, and boards. For team project courses, this transforms GitLab from a code repository into a complete project management environment. Epics group issues under a shared goal; the Roadmap shows all epics on a visual timeline.
Require teams to plan their project as issues before writing a line of code. Teaches decomposition — breaking a large problem into trackable tasks.
Group issues into milestones that correspond to sprint deadlines or grading checkpoints. Progress is visible without any additional reporting effort.
For semester-long projects, maintain a roadmap. It teaches students to communicate a plan visually — directly transferable to industry.
Set up a board with To Do, In Progress, and Done columns. Students learn Kanban workflow as part of the project rather than as a separate concept.
Ultimate includes configurable merge request approval rules — requiring a specific number of reviewers to approve before code can be merged. For team project courses, require that each MR is approved by at least one teammate. For security-focused courses, configure approval rules to require a reviewer whenever a scanner finds new vulnerabilities.
Configure a rule requiring at least one peer approval on every MR. Students learn to give and receive constructive code feedback — a skill that takes time to develop.
Configure approval policies that block merging when new vulnerabilities are introduced. Students must address or justify findings — they cannot be silently ignored.
Define a CODEOWNERS file to automatically assign reviewers based on which files are changed. In team projects this ensures the right people are always notified.
Value Stream Analytics measures how long each stage of the development process takes — from issue creation to deployment. It also surfaces DORA metrics — industry-standard measures of software delivery performance including deployment frequency and lead time for changes. For advanced DevOps courses, these give students measurable targets to optimise against rather than abstract principles to memorise.
GitLab Ultimate includes a browser-based Web IDE and remote Workspaces — fully-featured development environments that run on a server. Students on low-specification machines, Chromebooks, or iPads can participate fully without a powerful local setup, and it eliminates a whole class of "works on my machine" problems.
For introductory courses, students can start coding immediately in the browser — no Python installation, no conflicting packages, no platform differences.
Workspaces run in containers with a defined configuration, so every student works in an identical environment. This removes a major source of support overhead.
Every student's work in GitLab is real: real commits, real pipelines, real code reviews, real security findings addressed and resolved. Students who work through several courses on GitLab graduate with a genuine commit history, evidence of working in branches and merge requests, pipeline configurations they have written, and security findings they have addressed. This is portfolio material that directly demonstrates professional competencies to potential employers.
Protect the main branch on all student repositories so that direct pushes are blocked. All changes must come through a merge request. With Ultimate, configure merge request approval rules at the group level — they apply to every project in your course subgroup automatically.
The group-level Security Dashboard gives you a consolidated view of vulnerability findings across all student projects — you can see at a glance which students have open findings, what type they are, and how severe they are, without opening each project individually.
| Scanner | Best for |
|---|---|
| SAST | All coding courses — finds insecure patterns in source code |
| Secret Detection | Every course — prevents credential leaks from day one |
| Dependency Scanning | Courses using third-party packages (Python, Node, Java) |
| Container Scanning | DevOps and cloud courses covering Docker |
| DAST | Web development courses — tests the running application |
| IaC Scanning | Courses covering Terraform, Kubernetes, or cloud infrastructure |
For team project courses, Ultimate's agile planning tools let students manage their project in the same environment where they write their code. You can observe planning and execution without asking for separate status reports.
Before students write any code, require them to create issues for each feature. This surfaces their thinking and makes their plan reviewable before they start.
Map milestones to your grading checkpoints. Progress is visible in the UI — you can see what was completed by each milestone without waiting for a report.
Have data-driven conversations with teams about how they are working — not just what they have delivered.
Include a roadmap review as part of a mid-project check-in. Ask teams to show their roadmap and explain any changes to scope or timeline.
The Web IDE and Workspaces features mean students can code in their browser with no local setup. Workspaces run in a configured container, so every student works in an identical environment — removing a large category of "works on my machine" support requests.
The way you use Git in your coursework is the way professionals use it. Every merge request you submit and every code review conversation you participate in is direct experience you can talk about in a job interview.
Never commit directly to main. Create a branch for every feature or task, keep commits focused, and open a merge request when you are ready for review.
Treat commit messages as communication. A message like fix #12 — handle empty input in load_scores() is far more useful than fixed it.
When an instructor or peer leaves a comment on your MR, respond — ask a question if you don't understand, or push a fix and explain what you changed. This conversation is the actual learning.
Small, frequent commits give you a safety net and give your pipeline continuous feedback. They also demonstrate your working process to reviewers.
When you push code, GitLab automatically runs your pipeline — installing dependencies, running tests, and reporting the results. Don't wait until the night before the deadline — push early and often, watch the pipeline, and address failures as they come up.
GitLab Ultimate runs security scans on your code automatically. Security findings are not failures — they are learning opportunities. Getting hands-on experience with real scanner output is genuinely valuable preparation for industry, where security is increasingly every developer's responsibility.
API keys, passwords, and tokens should never appear in your code. Use environment variables or GitLab CI/CD variables instead. Secret detection will catch it if you forget.
When a scanner flags something, read the description. GitLab links to documentation explaining why the finding is a risk and how to address it — free, targeted security education.
If dependency scanning flags a library, look at what version is affected and whether a patched version exists. Updating a dependency is often a one-line fix with significant impact.
If you can't fix a finding, explain why in the merge request. Triaging vulnerabilities — deciding what to fix, defer, or accept — is a real professional skill.
The work you do in GitLab is real and verifiable. Your commit history, merge requests, pipeline configurations, and security findings are all recorded and can be shown directly to a potential employer.
By the time you graduate, you will have a commit history showing how you work, evidence of writing and using CI/CD pipelines, code review conversations demonstrating your ability to give and receive feedback, and experience with security tools that most graduates have never touched.