GitLab offers services that allow hosting projects on a remote repository and it also has additional features (managing, sharing, documenting, bug tracking …) to help SDLC (Software Development Life Cycle) and CI/CD (Continuous integration and continuous delivery/deployment).
Why we use GitLab
As mentioned before there exists other web-based remote repositories servers. But we use GitLab for our developments projects for the following reasons:
- GitLab allows us to locate a repository inside our organization server and to connect to it via our intranet using the free plan.
- GitLab is less expensive for private repositories (unlimited number of private repositories).
- GitLab strongly supports the CI/CD lifecycle with more flexibility.
Getting started on GitLab
To create a new project on GitLab you just need to click on the create New project button in the top sub-menu:
Then a form will show up in which you can specify the information related to your project:
Once your project is created you will be rendered to your new repository interface where GitLab provides you with some Git commands that you can run to connect the remote repository to your local repository or simply create a new repository.
If we were to clone this new repository locally we can simply run:
Your local Git will ask for credentials to get access to the remote repository like:
or via a command-line interface like:
$ git clone http://gitlaburl/gitlab/username/my-first-project-on-gitlab.gitCloning into ‘my-first-project-on-gitlab’…
Username for ‘http://gitlaburl': *****
Password for ‘http://gitlaburl': *****
warning: You appear to have cloned an empty repository.
With a warning that indicates that the cloned repository is empty.
Add SSH key
When you first use GitLab you may come upon this warning message “You won’t be able to pull or push project code via SSH until you add an SSH key to your profile”.
GitLab uses the SSH (Secure Shell) protocol to securely communicate with Git. SSH is a cryptographic network protocol that allows users to securely perform several network services over an unsecured network. SSH keys provide a more secure way of logging into a server with SSH than using a password alone. While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone. Generating a key pair provides you with two long strings of characters: a public and a private key. You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key. When the two matches up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.
When you use SSH keys to authenticate to the GitLab remote server, you don’t need to supply your username and password each time as we showed in the previous paragraph. So let’s see how we can integrate a key to our GitLab account. Skip this part if you already have a pair of public and private keys, by simply adding your public key to GitLab.
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\yourName/.ssh/id_rsa):
Created directory ‘C:\Users\aicha.yourName/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\aicha.fatrah/.ssh/id_rsa.
Your public key has been saved in C:\Users\yourName/.ssh/id_rsa.pub.
You can choose the directory in which you wanna store the key. Entering the passphrase is optional so you can skip it by simply hitting Enter. Under the directory
C:\Users\yourName/.ssh you will find two files created
id_rsa the private key (identification) and
id_rsa.pub the public key.
Now we need to add the public key to your GitLab account, to do so go to
Settings/SSH keysand copy/cast the content of
id_rsa.pub, and add a title of your choice:
Once the key added you will be able to see it in the list:
And you will receive an email confirming the addition of the key into your GitLab account.
In your local you can configure your private key in your machine, we usually use some tools like putty, add the private key to Pageant (putty authentication agent). Pageant holds your private keys in memory so that you can use them whenever you are connecting to a server, in this case, the GitLab server.
If you’re on a Linux machine make sure you put your private key corresponding to your public key you added to GitLub under
~/.ssh/ the directory. If you tried to clone the repository using SSH and you got an error due to permission like:
$ git clone git@gitlab****/my-first-project-on-gitlab.git
Cloning into 'my-first-project-on-gitlab'...
The authenticity of host 'gitlab.*****' can't be established.
ECDSA key fingerprint is SHA256:**********.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'gitlab.*****' (ECDSA) to the list of known hosts.
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
Permissions 0644 for '/home/aicha/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/aicha/.ssh/id_rsa": bad permissions
git@gitlab******: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.Please make sure you have the correct access rights
and the repository exists.
In this case, you need to simply change the rights like:
$ sudo chmod 400 id_rsa
This will solve the error and you will be able to clone your remote repository with no problems.
$ git clone git@gitlab.****:****/my-first-project-on-gitlab.git
In a previous article, we talked about Branching strategies, we can configure GitLab to strict the respect of the Branching rules.
You cannot create new branches when your project is empty, for this reason, let’s add README to fill the project with some content.
Then add some content to your file:
and then confirm ‘commit changes’ bellow:
Once done you will notice that you will get a new option in the left menu
This will allow us to add new branches to our project. Let’s start by creating the
develop branch since the
master exists by default.
Repository->Bracnhes Click on ‘New branch’ and choose the name of your branch and branch from which you want to create it.
Fill the input with ‘develop’ and confirm:
develop is gonna be the most active branch so let’s first designated as the default branch for our project:
Now we need to protect our main branches
master , we need to make sure that:
- prevent their creation, if not already created, from everybody except Maintainers
- prevent pushes from everybody except Maintainers
- prevent anyone from force pushing to the branch
- prevent anyone from deleting the branch
Luckily GitLab has this option configurable,
master is protected by default so we just need to apply it for
GitLab has community members each has their specific roles and responsibilities:
- Maintainer: accepts merge requests on several GitLab projects.
- Reviewer: performs code reviews on MR (merge requests).
- Developer: has access to GitLab internal infrastructure & issues (e.g. HR-related).
- Contributor: Can make contributions to all GitLab public projects
It is also possible to create other rules if needed. We can also protect the
Merge requests and code review
To show how we create MR (merge requests) and review the code, we cloned the remote directory that we created above into our local machine and then create a branch that we called
develop , we added an HTML
index.html file and added some content to it, then we added a commit and pushed the changes.
$ git checkout -b feature/ui develop
$ git add index.html
$ git commit -m "feat : first ui"
$ git push origin feature/ui
Now back to your GitLab account you will be able to see a new line to create a merge request as well as an increase in the number of Branches of your project. When you click on the ‘Create merge request’ and you ‘Submit merge request’.
The merge request will be added and then you can add comments to the commit changes:
We can also assign the tasks to specific developers, in this example I assigned it to my self:
Not that on top right I have a new task in my todos list.
Now that we added a new comment stating the requested changes, from our local machine let’s add a new commit in response to the comments.
As a reviewer, you can compare with the previous version to check if the requested changes are done. If so we can merge the MR and delete the branch if it won’t be needed in the future.
Once the MR is complete, you will notice that the changes are added and we no longer have MR.
You can always go back to old MR under the
Merged section in the
Merge Requests in the menu.