What Is GitLab?
Author: Domeny.ForSale editorial team Published
In brief: GitLab is a platform for storing code, collaborating on changes and automating application tests and deployments. It uses Git, a system that records the history of changes to files, but adds tools for organising work and controlling quality. You can use the GitLab.com service or run GitLab on your own infrastructure.
What is GitLab used for, and how does it differ from Git?
Git lets you track who changed files and when, compare versions and restore an earlier state of a project. It also works locally on your computer, without an account on any service. GitLab, by contrast, is a platform that provides a shared workspace for people using Git.
At the heart of a project is a repository: a collection of files together with their change history. GitLab lets you browse the repository in a web browser, manage access and discuss proposed changes. Besides code, you can store documentation, server configuration or a website’s text files in it.
GitLab is not a code editor or a content management system like WordPress. Developers usually write code in their own editor and then push changes to the repository. The platform helps review those changes and deliver them to the environment where the application runs.
How does collaboration on changes work?
Working in GitLab does not have to involve directly changing the main version of a project. A team member creates a branch, a separate line of code development, and records changes in it as commits — sets of modifications with a description. This makes it possible to prepare a new feature without immediately affecting the version others are using.
A completed proposal is submitted as a merge request, a request to merge changes into a selected branch. Other people can compare the code, leave comments and suggest corrections. Once the agreed conditions are met, the changes are merged; the required approvals and access rules depend on the configuration and available features.
For example, an agency is improving a contact form on a client’s website. A developer prepares the change in a separate branch, another person checks the error handling, and an automated test verifies that data is submitted correctly. Only after these checks does the team merge the fix into the main version and deploy it to the website.
Issues are used to report bugs and plan tasks. Each issue includes a description, a discussion and a person responsible for it. Linking an issue to a merge request makes it easier to trace not only what changed, but also why.
What does CI/CD automation offer?
CI/CD stands for continuous integration and continuous delivery or deployment of changes. Continuous integration involves frequently combining the team’s work and automatically checking the code. Delivery prepares software for release, while deployment may also automatically publish it to the target environment.
In GitLab, these activities are usually defined in a .gitlab-ci.yml file stored in the repository. They form a pipeline, a set of jobs executed according to specified rules. The jobs are run by a runner — a program that executes commands on the infrastructure assigned to it.
A simple pipeline for a website might:
- Check code syntax and formatting.
- Run tests.
- Build files ready for publication.
- Send them to a test server and, after manual approval, to a production server as well.
Simply placing a project in GitLab does not start a complete deployment process. You need to configure jobs, provide an available runner and grant the necessary permissions. Passwords and access keys should not be stored in the code; use appropriately secured CI/CD variables or a secrets management system instead. Automated tests detect only problems within their scope, so a green result does not guarantee the absence of bugs.
GitLab.com or your own installation?
GitLab.com is a service maintained by the provider. You do not need to install the platform, update it or administer its server. However, you are still responsible for project settings, user accounts, permissions and protecting access credentials.
Your own installation, known as GitLab Self-Managed, gives you greater control over the infrastructure and where data is stored. In return, it requires updates, monitoring, backups and system security measures. Running it on a company server does not automatically mean greater security.
For a small team without a system administrator, a hosted service is usually a more practical starting point. Your own installation may make sense if you have particular network, integration or data requirements. Before choosing, check GitLab’s official documentation and pricing for current storage limits, CI/CD job billing rules and the availability of the features you need in a given plan.
GitLab versus GitHub, and getting started
GitLab and GitHub are different platforms that use Git. Both support repository storage, change reviews, issue tracking and workflow automation. In GitHub, the equivalent of a merge request is a pull request, and automation tools include GitHub Actions.
It is best to base your choice on the integrations and permissions you need, automation costs and your team’s experience. Moving the Git repository itself can be relatively straightforward, but migrating issues, discussions and deployment configurations requires separate preparation.
To get started, create a private project with a README file describing its purpose. Then prepare a small change in a separate branch and open a merge request. This trial will help you learn the basic workflow before adding automation and access to servers.
Read also
