GitLab tracks issues and projects by turning every unit of work into an issue you can assign, label, estimate, and drop onto an issue board, then rolling those issues up into milestones, iterations, and epics for sprint and release planning — all linked directly to merge requests and CI/CD pipelines so one tool covers planning, code, review, and delivery.
That tight loop between planning and code is why GitLab works so well for agile teams and QA: an issue's status, comments, time logs, and the merge request that closes it all live in one place, with full traceability from a requirement to the deploy that shipped it.
Key takeaways
- Issues are the atomic unit of work — bugs, features, tasks, or test cases — each with assignees, labels, due dates, weights, and threaded discussion.
- Issue boards turn labels, milestones, or assignees into drag-and-drop Kanban or Scrum columns, so the board is your live workflow.
- Milestones, iterations, and epics scale tracking from a single sprint up to a multi-quarter roadmap.
- Quick actions — slash commands like
/assign,/label,/estimate, and/spend— update issues without leaving the description or a comment. - Closing keywords such as
Closes #142in a merge request auto-close the linked issue the moment the MR merges, keeping the board honest. - Because issues, merge requests, and CI/CD pipelines share one application, you get end-to-end traceability with no integration glue to maintain.
How do GitLab issues work?
An issue is GitLab's atomic unit of work — a bug report, feature request, task, question, or test case. Every project has an Issues list (under Plan → Issues), and you create one with the New issue button, from a comment, from an incoming email, or straight from a failing pipeline.
Each issue carries the metadata your team needs to plan and track:
- Title and description — the description supports Markdown, task-list checkboxes (
- [ ]), tables, and/quick actions. - Assignees — unlike the single-assignee limit of years past, modern GitLab supports multiple assignees, so pair work and reviews stay visible.
- Labels — categorize by type (
~bug,~feature), priority, or workflow stage. - Milestone — ties the issue to a release or a date range.
- Iteration — places it in a fixed-length sprint.
- Weight, due date, and health status — for estimation and at-a-glance risk.
- Linked items — block or relate other issues, link merge requests, and reference epics.
You can set almost any of these without touching the form by typing quick actions in the description or a comment:
/assign @maria # assign the issue (use /assign me for yourself)
/label ~bug ~"high priority" # add one or more labels
/milestone %"v2.0" # attach to a release milestone
/iteration *iteration:current # add to the current sprint
/estimate 2d # set a time estimate (2 days)
/spend 3h # log 3 hours already worked
/due 2026-07-15 # set a due date
/relate #142 # link a related issue
/close # close the issueHow do issue boards and labels organize work?
Labels are the backbone of organization in GitLab. A label is a colored tag (project- or group-scoped) you attach to issues and merge requests. Most teams run a few label families:
- Type:
~bug,~feature,~chore,~spike - Workflow:
~"To Do",~Doing,~"In Review",~Done - Priority / severity:
~P1,~"S1::critical" - Scoped labels use a
key::valuesyntax (~workflow::doing) so an issue can hold only one value per key — ideal for board columns.
An issue board turns those labels (or milestones, assignees, and iterations) into drag-and-drop columns. Dragging a card from To Do to Doing swaps the scoped label automatically, so the board stays the single source of truth for status. You can run several boards over the same issues — for example a team Kanban board grouped by workflow label and a release board grouped by milestone.
| Board grouping | Each column is | Best for |
|---|---|---|
| Workflow (scoped labels) | workflow::todo → workflow::done |
Day-to-day Kanban |
| Milestone | a release or sprint | Release planning |
| Assignee | a team member | Balancing load |
| Iteration | a timebox | Scrum sprint view |
How do milestones, iterations, and epics plan releases?
GitLab gives you three planning containers that stack from small to large:
- Milestones group issues and merge requests toward a release or date range. A milestone page shows a burndown/burnup chart and a completion percentage calculated automatically from issue status — progress is measured, not hand-updated.
- Iterations are fixed-length, repeating timeboxes (sprints) organized into iteration cadences. They answer "what are we doing this sprint" independently of which release the work belongs to.
- Epics group related issues — and even child epics — across multiple projects and milestones, giving you a roadmap view for multi-sprint initiatives.
Used together: an epic spans a quarter, milestones mark the releases inside it, and iterations are the two-week sprints your team actually commits to.
| Container | Scope | Time-boxed? | When to use |
|---|---|---|---|
| Issue | One unit of work | No | The actual task, bug, or test case |
| Iteration | A sprint of issues | Yes (fixed length) | "What we commit to this sprint" |
| Milestone | A release of issues + MRs | Optional date range | Grouping work toward a version or launch |
| Epic | Many issues across projects | No | A large feature or initiative on the roadmap |
A note on tiers: issues, labels, milestones, boards, and time tracking are available in GitLab Free, while epics, iterations, roadmaps, and issue weights are part of the paid Premium and Ultimate tiers — choose on the capabilities you actually need.
How do issues link to merge requests and CI/CD?
This is where GitLab's single-application model pays off. From an issue you can click Create merge request, which spins up a branch named after the issue (for example 142-fix-pagination) and a draft MR already linked back to the issue. Work, review, and merge all happen against that branch.
The real glue is closing keywords. Put one in the MR description (or a commit message) and GitLab auto-closes the linked issue when the MR merges into the default branch:
Closes #142,Fixes #142,Resolves #142— close one issueCloses #142, #98— close several at onceRelated to #77— link without closing
Because the same pipeline config (.gitlab-ci.yml) runs on that merge request, the issue, the code, the review, and the CI/CD pipeline results all hang off one thread. Reviewers see test and build status right on the MR; QA sees exactly which issues a release pipeline shipped. For the full pipeline setup, see our guide to CI/CD with GitLab and Docker, and if you publish images, setting up a GitLab container registry on your own domain.
A typical merge-request description that ties everything together:
## Summary
Fix dashboard pagination that skipped the last page of results.
## Changes
- [x] Correct off-by-one in the paginator
- [x] Add regression test
Closes #142
Related to #98
/assign me
/reviewer @priya
/label ~bug ~"workflow::in review"
/milestone %"v2.1"GitLab Issues vs Jira vs GitHub Issues
All three track issues well; the difference is how much of the delivery lifecycle lives in one place.
| Capability | GitLab Issues | Jira | GitHub Issues |
|---|---|---|---|
| Issue boards (Kanban/Scrum) | Built in | Built in | Projects (boards) |
| Epics & roadmaps | Built in (paid tiers) | Built in | Roadmaps in Projects |
| Native SCM + merge/pull requests | Yes (same app) | No (integrates Bitbucket/GitHub) | Yes (pull requests) |
| Built-in CI/CD | Yes (.gitlab-ci.yml) |
No (Bamboo / third-party) | Yes (GitHub Actions) |
| Time tracking | Built in (/estimate, /spend) |
Built in | Via apps/extensions |
| Self-host / single tenant | Yes (self-managed) | Yes (Data Center) | Yes (Enterprise Server) |
| Best for | One tool from plan to deploy | Heavy agile/portfolio process | Open-source & GitHub-centric teams |
If your team already commits, reviews, and deploys in GitLab, keeping issues there removes the integration plumbing you would otherwise maintain between a separate tracker and your repository.
How do you track time and report progress?
GitLab has lightweight time tracking built into every issue and merge request — no plugin required. Set an estimate and log spent time with quick actions:
/estimate 1w 2dsets the estimate (it acceptsmo,w,d,h,m)./spend 3hadds time;/spend -1hsubtracts it;/spend 2h 2026-06-08backdates it./remove_estimateand/remove_time_spentreset them.
The issue then shows estimate vs. spent, and milestone burndown charts roll that up for the whole sprint. For agile delivery and QA this is gold: you can spot scope creep early, watch a release milestone trend toward done, and tie every fixed bug to the merge request and pipeline that shipped it. Testing should gate that flow — here is why we test before delivering a project.
Tracking work cleanly is only half the job — the other half is making sure what you ship actually works. If you want a delivery process where GitLab issues, boards, CI/CD, and a real QA strategy work together, MicroPyramid has spent 12+ years and 50+ projects building exactly that for startups and enterprises. Explore our software testing services to see how we wire quality into the pipeline.
Frequently Asked Questions
How do I create and assign an issue in GitLab?
Go to Plan → Issues in your project and click New issue, then add a title, description, assignee, labels, and milestone. You can also create issues from a comment, an incoming email, or a failing pipeline. To assign without opening the form, type a quick action like /assign @username (or /assign me) in the description or any comment — GitLab supports multiple assignees, so you can add several people to one issue.
What are GitLab quick actions?
Quick actions are slash commands you type in an issue or merge-request description or comment to update it instantly — for example /assign @user, /label ~bug, /milestone %"v2.0", /estimate 2d, /spend 3h, /due 2026-07-15, and /close. They run when you submit the comment and are stripped from the visible text, so you can triage and update work without clicking through the UI.
How do issue boards work in GitLab?
An issue board is a drag-and-drop Kanban or Scrum view where each column maps to a label, milestone, assignee, or iteration. Moving a card between columns automatically updates its scoped label (for example workflow::todo to workflow::doing), so the board stays in sync with each issue's real status. You can keep several boards over the same issues — say, a team workflow board and a release board grouped by milestone.
What is the difference between a milestone, an epic, and an iteration?
A milestone groups issues and merge requests toward a release or date range and shows automatic burndown progress. An iteration is a fixed-length, repeating timebox — a sprint — used to plan what the team commits to right now. An epic groups many related issues (and child epics) across projects and milestones to track a large initiative on the roadmap. Issues are the work; iterations and milestones organize it by time and release; epics organize it by initiative.
How do I automatically close a GitLab issue when code is merged?
Add a closing keyword that references the issue in your merge-request description or a commit message — Closes #142, Fixes #142, or Resolves #142. When that MR merges into the project's default branch, GitLab closes the referenced issue (or issues, e.g. Closes #142, #98) automatically. Use Related to #77 instead when you want to link an issue without closing it.
Is GitLab issue tracking free, and how does it compare to Jira?
GitLab's core tracking — issues, labels, milestones, boards, and time tracking — is available in the Free tier, while advanced planning like epics, iterations, roadmaps, and issue weights sits in the paid Premium and Ultimate tiers. Compared with Jira, the biggest difference is that GitLab keeps planning, source code, merge requests, and CI/CD in one application, so you do not maintain integrations between a separate tracker and your repository. Jira offers deeper portfolio-management process; GitLab offers tighter code-to-deploy traceability.