Last Updated on July 13, 2024 by Asfa Rasheed
It doesn’t matter if you are at the beginning of your programming adventure or you are an expert, for sure at least once in your lifetime, you came across version control systems, and likely it was a Git. Nowadays, all developers should have experience in that system. But not only this one – expertise in GitLab, GitHub and Bitbucket are also one of typical requirements in nearly all job advertisements.
Table of Contents
Git repository and its architecture
Let’s start with a basic knowledge of Git and its architecture. It’s a distributed version control system. It means that every copy is mapping the whole repository. So theoretically, all copies are equal. How does it look in practice? Well, there is usually one repository in a project that is called “origin”. It serves as a single-source-of-truth – that’s what everyone integrates with. The origin is always the most actual version and is downloaded to further work on a particular project.
So basically cloning is all about downloading the whole project with all history and commits fetched. So the local copy will be the same as the origin version. When the repo is cloned in a correct way, you do not need to do it again and again to work on the project. Push and pull – those are functions for this.
Git clone in GitLab – how does it work?
The clone, like most functions in Git, can have many parameters. They change its default behavior. Please note that most of the parameters are optional. Required is only the address of the remote repo (origin) as well as the local directory, so the place where you want to host your copied project. By default this function looks as follows:
git clone <repo_address> <directory>
What is the address? Usually it’s the HTTPS address of the project website. Example? The Inkspace project, available at: https://gitlab.com/inkscape/inkscape.
When entering this page for sure you can find the Clone button. It allows us to clone a GitLab repository. When you click on this button, this is the window that will open:
As you can see, there are two options available:
- Git clone with SSH
- Git clone with HTTPS
So the question is – is a GitLab clone with SSH different? What is the difference between a clone with HTTPS? Technically they differ very much as two completely different protocols. However, from the git clone point of view, there is barely any difference. In the case of a Git clone with SSH, it is essential to generate a key pair as well as put this public key in the GitLab account settings. When it’s done, you can call the clone function as always – by providing the appropriate address for your protocol.
Third-party GitLab backup solution
Whether you use git clone or not, please bear in mind that for many reasons this function itself can not be considered as a backup. This is this aspect of security that according to every shared responsibility model lies on your side. There is a lot of information about the GitLab backup repository in the official documentation. So you can prepare your own scripts – one for backup and one for restore. It seems quite difficult and requires hours of work and some constant maintenance. That is why it is usually recommended to use third-party GitLab backup software such as https://gitprotect.io/gitlab.html to save time, money and accelerate development with peace of mind. Especially, as it gives a 100% recoverability guarantee.
