1 Start with a free GitLab.com account, not self-hosted
Self-hosting GitLab on your own server is a real option, but it requires 4GB of RAM minimum and ongoing maintenance. For most people — solo devs, small teams, freelancers — GitLab.com free tier gives you unlimited private repositories, CI/CD pipelines, and 5GB storage without touching a server. I spent three hours setting up a self-hosted instance before I realized the free cloud version did everything I needed. Create an account at gitlab.com, verify your email, and create your first project before buying anything else.
2 Install Git on your local machine before anything else
GitLab is a remote host for your code — Git is the tool that actually tracks changes on your computer. Without Git installed locally, you cannot push code to GitLab or pull it back down. On Windows, Git for Windows is the one to use. On Mac, running 'git --version' in Terminal will prompt an install automatically. The setup takes about five minutes and you only do it once.
3 Set up SSH keys so you stop typing your password on every push
Every time you push code to GitLab without SSH keys, you type your username and password. After the fourth time, this is enough to make someone quit. SSH keys are a one-time setup: you generate a key pair on your machine, paste the public key into GitLab under Settings > SSH Keys, and Git authenticates silently from then on. The whole process takes about ten minutes and the GitLab docs walk through it step by step.
4 Use GitLab CI/CD to automate at least one repetitive task
CI/CD sounds like an enterprise buzzword but it is just a text file in your repository that tells GitLab to run commands automatically when you push code. The most useful first pipeline is a simple one: run your tests, then deploy to your server or hosting provider. I set one up that deploys a static site to an S3 bucket on every push to main — it took about 45 minutes to configure and I have not manually deployed since. The .gitlab-ci.yml file lives in your repo and is version-controlled alongside your code.
5 Protect your main branch so no one pushes broken code directly
By default, anyone with access to your GitLab project can push directly to the main branch, which means one rushed commit can break a live site with no review. Go to Settings > Repository > Protected Branches and set main to require a merge request before any code lands there. This costs nothing and takes two minutes, and it forces even solo developers into a habit that prevents most late-night disasters. If you have a team, also enable required approvals so at least one other person reviews each merge request.
6 Back up your GitLab repos locally even though they live in the cloud
GitLab.com has had outages, and free tier accounts have had data incidents in the past. A local backup takes thirty seconds: clone each repository to an external drive once a month. If you have more than a handful of repos, a small script using the GitLab API can clone all of them at once. Florida power outages — which are common in Charlotte County during hurricane season — can corrupt a working local copy, so an external SSD in a different physical location is worth the cost.
GitLab will run your entire development workflow for free — the only thing standing between you and that is one afternoon with a decent course and the nerve to push your first commit.
isnotbadforyou.com/gitlab · A North Port neighbor's honest take
This page may contain affiliate links. If you buy something through them, we earn a small commission at no extra cost to you. We only recommend things we'd use ourselves.