How to Set Up A Git Repository within GitLab

Efficiency is key to a good DevOps strategy, and GitLab was designed with efficiency in mind. GitLab is an open source project that was created to bring the entire DevOps software development life cycle into a single, unified platform. Without a tool like GitLab, your team will need to spread their work across many different applications, resulting in unnecessary overhead for integration, management, and configuration. All of this overhead slows your team down, making them less productive and less agile. In addition to the increased productivity of a singular platform for DevOps, GitLab makes it possible for the entire team to work remotely just as smoothly as if they were working in person.

Today, we’re going to tell you how you can begin to take advantage of this popular tool, by starting at the beginning: setting up a Git repository. But first, let’s get some frequently asked questions out of the way so that everyone is on the same page when we get into the details. If you already understand the basics, feel free to skip to the section on how to set up a repository in GitLab.

What is a Git Repository?

To understand the process of setting up a repository, we must first define what a repository is. Many people who are new to version control systems confuse the terms ‘repository’ and ‘project.’ These are actually similar, but ultimately different, terms. Your project is the actual software application that you’re working on. It’s the code and resources needed to make the application work. A repository is a copy of those resources. It could be a local repository, that individual developers are working on, or it could be the remote repository, that contains the merged work of all developers.

Repositories are a central component in how version control works. Each developer works on their own local copy of a repository and can make change without effecting the master branch that is stored remotely. When the developer is finished with their work, they can send, or ‘push,’ their changes to the master branch, where the maintainer of the project can check for conflicts and approve the changes. This allows many developers to all work on the same project without ever stepping on each other’s toes or overwriting each other’s changes. You can even create separate branches within the remote repository to help keep things further separated and make maintaining the project easier.

What Is the Difference Between GitLab and GitHub?

When people think of version control, particularly version control using Git, they almost immediately think of GitHub. The brand is a huge name in version control and is far and way the most popular choice for hosing Git repositories. So what is the difference between GitHub and GitLab, and what makes GitLab a better choice for your DevOps team?

As their name suggests, the Git repository is a central feature of both GitHub and GitLab. The similarities largely stop there, however. GitHub will allow you to host your remote repositories, allow developers to work on their own local repositories, and will provide you with a way of tracking issues that need to be resolved in the code or creating simple documentation. The site’s feature set stops there. Unlike GitLab, GitHub is not meant to be a one-stop platform for the entirety of your DevOps needs.

In addition to giving you important tools for enterprise use, such as assigning different permission levels to different roles, GitLab has many features tailored to a DevOps environment. The software has built-in support for Continuous Integration/Delivery, whereas GitHub requires you to use a third-party provider. GitLab also allows you to easily import or export projects to and from other version control platforms and track the time that was spent on an issue or merge request to make project management easier.

How to Set up a Local Repository for GitLab

Those of you familiar with Git will likely already know that there are two ways to create a new repository. You can push your code to a Git repository from an existing code base, or you can clone an existing repository into your own version of it, called a fork. Because GitLab is a full stack solution for your DevOps needs, it also offers a third way to create a new repository: by creating a new project right from within GitLab. When you do this, a repository is automatically created for you. In the sections below, we’ll take you step-by-step through the exact process used for each of these methods. But first, you’ll need to create a new project, which is the first step to create a repository with any of the below methods. This is a simple 2-step process.

1. Go to your dashboard and look for the green button labeled “New Project.” Alternatively, you can use the plus icon in the navigation bar. Either one of these buttons will open the “New Project” page.
2. From the “New Project” page, you’ll be given the option to create a blank project, create a project from templates, import a project from a different repository, or run CI/CD pipelines for external repositories. See the sections below for further information on the specifics of each of these.

Creating a New Repository within GitLab

As already mentioned, repositories are created by default when you create a new project in GitLab. This is because version control is one of the core features of the software. By default, a local repository is created, though it’s an easy process to connect this local repository to a remote one to enable your whole team to work remotely and benefit from the fact that remote repositories serve as a backup to your important data. Let’s look at the steps involved in creating a new project in GitLab.

Blank projects

1. Select “Blank Project” from the “New Project” page.
2. Enter the name of your project in the “Project Name” field. Special characters aren’t allowed, but anything else is fair game.
3. GitLab uses a project slug as the main URL path to your project. When you enter the project name, this “Project Slug” field will auto populate. If you don’t like the automatically chosen slug, you can change it manually.
4. Entering a project description will help others understand what your project is about. This field isn’t required, but it is recommended to make project management easier. You can enter a description for your project in the “Project Description” field.
5. Set the viewing and access rights for users in the “Visibility Level” section. This is where you decide which users will have access to which features. This is one of the distinguishing features between GitLab and more basic Git hosting services such as GitHub.
6. Check the “Initialize repository with a README” option. This is an optional selection, but is recommended because doing so will put an initial file in the repository, create a default branch for it, and initialize the repository.
7. Click on “Create Project” to finish the process.

Template-based projects

There are two types of templates available in GitLab: those that are built-in to the software and created by the GitLab team, and those they are created custom by administrators and users. Because the process for using both is similar, we’ll describe them together.

1. From the “New Project” page, select the “Create from template” tab.
2. If you want to use a built-in template, choose the “Built-in” tab from the page that opens. If you want to use a custom template, you can find them in the “Instance” or “Group” tab, depending on where the template resides.
3. After selecting the type of template you want to use, you’ll be presented with a list of the available templates. Find a template that interests you and click on the “Preview” button to get a look at the template source.
4. Once you’ve found the template that you want to use for your project, click on the “Use Template” button to begin creating a project based on that template.
5. Now you must enter the details of the project. Everything from here on is exactly the same as the steps for creating a blank project, detailed in the section above.

Creating a Repository from an Existing Project

When you first adopt GitLab, you’ll likely already have projects in the works. Thankfully, you can add these projects to the software very easily. Doing so involved pushing the project to a new Git repository, and then importing that repository to GitLab. After this one time set up procedure, you’ll have the full power of GitLab at your disposal while working on the project. The steps to perform this operation are listed below.

The first step is to push the project to Git. In order for this to work, you need to have access rights to the associated GitLab namespace. If you do, then GitLab will automatically create a new project under that namespace and set its visibility to private. Of course, you’ll be able to change the project’s visibility and the user access rights later in the project’s settings if you’d like. The commands to push to Git along with the GitLab namespace can be given using SSH or HTTPS.

## Git push using SSH
git push –set-upstream git@gitlab.example.com:namespace/nonexistent-project.git master

## Git push using HTTPS
git push –set-upstream https://gitlab.example.com/namespace/nonexistent-project.git master

Be sure that you change the text in those template commands to match your actual project information. You’ll need the address of the Git server, the Git namespace associated with the project, and the name of the project.

If the project is successfully pushed, you’ll be given a remote message indicated that the project with the name you gave it was created using the namespace you gave.

Cloning an Existing Repository

If you’re already using a Git solution when you adopt GitLab, you’ll already have a repository waiting to be pulled into the system. You may also find the need to fork someone else’s code and use it as a starting point of your own. Regardless of where this existing repository comes form, getting it up and running in GitLab is easy. Let’s go over the steps for cloning an existing Git repository. Like creating a project from scratch, this is a simple two-step process.

1. To fork a project on GitLab, you need to have permission to view it. Assuming that you do, you can navigate to the project’s home page and click on the “Fork” button in the top right corner.
2. Next, you’ll be shown a list of namespaces that you can fork to. You must have Developer or higher permissions for a namespace before you will be allowed to fork to it. After the fork is created, whichever permissions you have in the namespace are what you’ll have in the fork.

Once the project is forked, you can use repository mirroring feature of GitLab to keep it in sync with the upstream version automatically. Alternatively, you can choose to do it manually using the Git command line functions if you are comfortable doing so.

Conclusion

GitLab is designed to make DevOps easier for developers, and that extends to the creation of repositories. As you’ve learned, the software makes it easy to create a repository no matter what the origin of the project is. But setting up your repository in GitLab is just the first step to using this great tool. By learning all of GitLab’s tools for continuous development and project management, your DevOps team work more cohesively and complete projects faster.

We hope you’ve found this post informative and easy to follow along with, but there’s a lot more to learn. To take a closer look at how to use the tools that will make your DevOps operation run more smoothly, be sure to check out the other posts in this blog. We also produce a lot of great courses that go into far more depth than these blogs can. Our courses cover a wide variety of topics surrounding DevOps tools and management. To find out more about how Cprime can help your business navigate a changing technological landscape, please feel free to contact us today.