A GitLab server earns its keep on the day the first real project lands on it. Here is that first project - created properly, shared with the whole team at once, and cloned the password-free way.
Order matters here. Create a Group first - it is your team's shared home, and its member list flows into every project you put inside it. Then create the project inside the group. Do it the other way around and you will be inviting the same people, one project at a time, forever. After the project exists, one more piece of setup pays for itself every single day: SSH keys, so nobody types a password to push code ever again.
👆 Same project, two doors. The SSH door is the one your team should walk through daily - the next cards unlock it.
From the menu, choose New group and name it after your team, with visibility set to Private. A group is more than a folder: it holds members, and every project created inside inherits that member list. Now, inside the group, choose New project and create a blank project. Give it a clear name, keep it Private, and tick the option to initialise it with a README file. That last tick matters more than it looks: an initialised project can be cloned immediately, while a completely empty one refuses with a confusing error that wastes a beginner's first hour.
Open the group, go to Members, and invite each developer using the account you created for them. Assign roles honestly: Developer for people who write and push code, Maintainer for the one or two leads who manage branches and settings. Resist making everyone a Maintainer - roles are how you keep an enthusiastic junior from rewriting shared history by accident. Because membership lives at group level, every future project in this group is shared correctly from birth. Nobody files a ticket saying they cannot see the new repository, and nobody gets access to a project they should never have seen.
An SSH key pair is a lock and a key that are manufactured together. The public key is the lock: it goes into GitLab, under your avatar, Preferences, then SSH Keys, where you paste it once. The private key is the actual key: it stays on your own PC and is never shared, uploaded or emailed - treat it like the key to the office, not like a file. Generate one pair per person per PC; on your PC, your Git tools can create it with ssh-keygen -t ed25519, accepting the default location. From then on, GitLab recognises your machine itself. No password prompts, no tokens to paste, just push and go.
Copy the SSH address from the project page and clone it: git clone [email protected]:dev-team/first-project.git - your own address will show your server's IP and your group and project names. Work normally, commit, push. Two honest notes. First, HTTPS cloning also works, but it asks for credentials, and once two-factor authentication is on, Git over HTTPS wants a personal access token instead of your password - one more reason the team standard should be SSH. Second, the very first connection from a new PC asks you to confirm the server's fingerprint. That prompt is the security system working: confirm it once, ideally against the address the admin gives you, then accept.
Watch the first users and projects being created in the video, then set up your group and keys in the same order.
▶️ Watch Full VideoSSH, once your key is added: no passwords, no tokens to rotate, and it keeps working smoothly with two-factor authentication switched on. HTTPS is fine for a quick one-off look at a project.
You almost certainly cloned using the HTTPS address. Check which address your local copy is using and switch its remote to the SSH address shown on the project page - the password prompts will stop.
No - one key pair per PC. It costs two minutes per machine, and it means a stolen laptop can be revoked in seconds without locking you out of your other machines.