Interactive GitLab Demo
Walk through an interactive demo of GitLab, a single application that covers source control, code review, CI/CD pipelines, and issue tracking. See how a change moves from a merge request to a deployed build without switching tools.
What is GitLab?
GitLab is a DevOps platform that puts source control, code review, CI/CD, and issue tracking inside one application. Most teams reach for separate tools at each stage of shipping software, then spend time wiring those tools together. GitLab's pitch is that you don't have to: the repository, the pipeline, and the planning board all live in the same place and share the same data.
At its core is Git hosting, so the day-to-day work of branching, committing, and opening merge requests feels familiar to anyone who has used Git before. Around that, GitLab adds a built-in CI/CD engine driven by a .gitlab-ci.yml file in the repo, which means your pipeline definition is version-controlled alongside the code it builds. Issues, milestones, and boards handle planning, and the merge request is where review, discussion, pipeline status, and approvals all converge before a change lands.
GitLab comes in a few forms. There's the SaaS version at gitlab.com, and a self-managed edition you can run on your own infrastructure, which is part of why regulated industries and large enterprises tend to use it. There's also a free open-source Community Edition. For teams documenting how their internal tools or release processes work, an interactive Supademo walkthrough embedded in a GitLab wiki or README gives new engineers something they can click through instead of a wall of setup steps.
How to get started with GitLab
- 1
Create an account or pick your edition
The fastest start is signing up at gitlab.com, which is the hosted SaaS version with a free tier. If your organization needs to keep code on its own servers, the self-managed edition is the other path, though that involves a real installation. For learning the workflow, the hosted free tier is enough.
- 2
Create a project and push your code
A project in GitLab is your repository plus everything attached to it: issues, pipelines, wiki, and settings. You can create an empty project and push an existing repo with standard Git commands, or import from GitHub or another Git host. Once code is in, the project page becomes the hub for the rest of the work.
- 3
Work in branches and open a merge request
Create a branch for a change, commit to it, and open a merge request back into the main branch. The merge request is where reviewers leave inline comments, where approvals are tracked, and where pipeline results show up. It stays open until the change is reviewed and the checks pass.
- 4
Add a CI/CD pipeline
Add a .gitlab-ci.yml file to the repo to define your pipeline: the stages, the jobs, and what runs in each. Every push triggers the pipeline, and the results attach to the commit and the merge request. Because the file lives in the repo, changing the pipeline goes through the same review as any other code change.
- 5
Plan work with issues and boards
Use issues to track tasks and bugs, group them with milestones, and arrange them on a board to see status at a glance. Issues link to the branches and merge requests that close them, so the planning side and the code side stay connected without a separate project tool.
Who is GitLab most useful for?
GitLab fits a broad range of teams, but a few get clear value from having everything under one roof.
Engineering teams that want to cut down on tool sprawl are the obvious fit. If your repo lives in one product, your pipelines in another, and your tickets in a third, GitLab collapses that into a single login with consistent permissions. The merge request becomes the one place where review and pipeline results sit together, which removes a lot of context-switching during code review.
Platform and DevOps engineers lean on GitLab because the CI/CD configuration is code. Pipelines defined in YAML can be reviewed, reused across projects, and rolled back like anything else in the repo. For teams running self-managed GitLab, that same control extends to runners, infrastructure, and where the data physically sits, which matters in finance, healthcare, and government.
Product and engineering managers use the issues, boards, and milestones to plan work next to the code itself, so a ticket links directly to the branch and merge request that resolve it. Open-source maintainers and smaller teams use the free tiers to host public projects with full CI included. Across all of these, teams building developer tools or internal platforms often embed a Supademo demo in their docs so users can experience a feature hands-on rather than reading a step list.
GitHub is the better-known platform and the default home for most open-source projects, which matters if discoverability and contributor reach are priorities. Its Actions CI is widely used and has a deep marketplace of pre-built workflows. The main difference is philosophy: GitHub leans on integrations to round out the DevOps lifecycle, while GitLab tries to ship those pieces itself.
View demo →
Jira isn't a code host, so it competes only on the planning side of what GitLab does. Where it pulls ahead is the depth of its boards, workflows, and reporting, which large project teams rely on. Plenty of teams pair Jira for planning with a separate Git host, and that combination is the real alternative to GitLab's all-in-one approach.
View demo →
Bitbucket makes the most sense if your team already runs on Jira and Confluence, since the integration between them is close and well-supported. It includes Bitbucket Pipelines for CI. It doesn't aim to be a full single-application DevOps platform the way GitLab does, so teams outside the Atlassian ecosystem often find less reason to pick it.
Azure DevOps bundles repos, pipelines, boards, and artifacts, and it's a natural choice for organizations already invested in Azure and Visual Studio. It's capable but feels like a suite of connected services rather than one unified product. GitLab tends to win when a team wants a single coherent interface instead of several Microsoft modules.
FAQs on GitLab
Commonly asked questions about GitLab. Have more? Reach out and our team will be happy to help.
Is GitLab free to use?
GitLab does have a free tier, and it's genuinely useful. The free plan on gitlab.com includes unlimited public and private repositories with CI/CD minutes included, which covers a lot of solo and small-team work. There's also a free open-source Community Edition you can self-host. Paid tiers add things like advanced security scanning, deeper compliance controls, and more CI minutes.
What is the difference between GitLab and GitHub?
GitLab and GitHub both host Git repositories and handle code review, so the day-to-day work overlaps a lot. The difference is scope. GitLab ships CI/CD, security scanning, and planning as part of one application, while GitHub often relies on integrations and its marketplace to cover the same ground. GitHub also has the larger open-source community, which can matter for public projects.
Can I host GitLab on my own servers?
Yes, self-hosting is one of GitLab's defining features. The self-managed edition runs on your own infrastructure, whether that's a private cloud or on-premise hardware, which gives you full control over where code and data live. That's why regulated industries and large enterprises often choose it over the SaaS version. Running it does mean you handle the installation, upgrades, and maintenance yourself.
Do I need to know CI/CD to use GitLab?
No, you can use GitLab purely for Git hosting, code review, and issue tracking without ever writing a pipeline. CI/CD is there when you want it, configured through a .gitlab-ci.yml file in the repo. Many teams start with just repositories and merge requests, then add pipelines once they're comfortable. The CI engine is built in, so there's nothing extra to install when you do.
Can I migrate from GitHub to GitLab?
Yes, GitLab has a built-in importer for moving projects from GitHub. It can bring over repositories along with issues, merge requests, and other metadata, not just the code history. Larger or more complex migrations take some planning, and pipeline configuration has to be rewritten since GitHub Actions and GitLab CI use different formats. For most repos the importer handles the bulk of the work.
How does GitLab handle security scanning?
GitLab includes security scanning that runs inside your CI/CD pipelines, covering things like static analysis, dependency scanning, and container scanning. Results show up directly in the merge request, so a reviewer sees flagged issues before approving a change. The most advanced scanning and the security dashboards are part of the higher paid tiers rather than the free plan.
Is GitLab good for non-developer teams?
GitLab is built around code, so it's strongest for engineering teams, but the issues, boards, and wiki can be used by non-developers working alongside them. Designers, product managers, and writers often use it to track work or maintain documentation in the same place as the code. It isn't a general-purpose project management tool, so teams with no connection to a codebase usually find a dedicated tool fits better.
What is a merge request in GitLab?
A merge request is GitLab's term for proposing that one branch be merged into another, usually a feature branch into the main branch. It's where code review happens: reviewers leave inline comments, approvals are tracked, and the pipeline results for that change are displayed. If you've used pull requests on GitHub, a merge request is the same concept under a different name.