Git - GitLab



GitLab is an open-source Git server. Unlike GitWeb it is a more complex solution which is needed to work with and manage the Git repositories.

  • Among all the Git servers, GitLab is a well-liked solution with a plenty of capabilities that surpass those of GitWeb.

  • GitLab offers a complete set of tools for managing Git repositories, although it is more complicated to install and manage than GitWeb.

Installation

Because GitLab is an online application that depends on a database, its installation is more complicated than that of certain other Git servers.

But there is ample documentation and support for this procedure.

GitLab advises using the official Omnibus GitLab package since it makes setup easier by combining all required parts and dependencies into a single package.

Other installation options for GitLab include:

  • GitLab Helm chart: Designed for deployment on Kubernetes.

  • Dockerized GitLab packages: Suitable for use with Docker containers.

  • From source files: Allows for a custom installation from GitLab's source code.

  • Cloud providers: Available on platforms like AWS, Google Cloud Platform, Azure, OpenShift, and DigitalOcean.

Administration

GitLab is administered using its online interface.

  • Start by launching a web browser and entering our GitLab server's IP address or hostname.

  • Enter as the root user. If we are using the Omnibus GitLab package, the initial password will be generated automatically and kept for a minimum of 24 hours in /etc/gitlab/initial_root_password.

  • Once we have logged in, click the Admin area icon in the interface's upper-right corner to view the administration options.

Users

Every user in GitLab needs to have an account, which holds login credentials and personal data.

A namespace that contains all of the user's projects is part of their user accounts.

  • For instance, the URL for Alice's project with the name website would be http://yourserver/alice/website.

  • In the same way, http://yourserver/bob/api-docs would be the URL for Bob's project api-docs.

  • Projects can be more easily managed and located by using the namespace to help organize them by user.

There are two ways to delete a user account from GitLab:

  • Blocking a User: This stops the user from accessing GitLab, but it preserves all of their data.

    Their email-linked projects and commits are still available, and their profile data is kept safe.

  • Destroying a User: This removes the user from the disk and database forever.

    It's a more severe and permanent step because any projects, data, and groups they owned are deleted. Because this approach is permanent, it is rarely required.

Groups

In simple terms, a GitLab group is a collection of connected projects that controls user access.

Similar to user namespaces, every group has its own namespace.

  • For example, if the group training has a project named materials, the URL would be http://server/training/materials.

  • Users are given several levels of authorization inside each group, which determines their access to and authority over the settings and projects of the group.

  • From Guest (see issues and engage in chat) to Owner (complete authority over the group, its members, and its projects), there are many levels of permission available.

  • GitLab offers instructions for a comprehensive list of these permissions on the administrator panel.

Projects

Typically, a single Git repository is represented by a GitLab project.

A namespace, which might be a person or a group, is linked to every project.

  • A user who owns a project has access control over who can access it.

  • If the project is part of a group, access is controlled by the user-level permissions within the group.

Additionally, a project's visibility setting establishes who is allowed to access its pages and repository:

  • Private: The project can only be viewed or interacted with by people who have been given specific permission by the project owner.

  • Internal : Open to any GitLab user with a valid login.

  • Public : Accessible to everyone, even if they are not logged in.

The project's online interface and repository access are both impacted by this visibility setting.

Hooks

GitLab allows for system and project hooks, which enable the server to send HTTP POST requests containing JSON data in response to predefined events.

GitLab can be integrated with other development tools, including as deployment systems, chat programs, and continuous integration (CI) servers, by using this capability.

  • Parts of the development cycle are possible to simplify and automate with the use of hooks, which allow for automatic interactions and notifications based on repository activity.

  • We can improve the performance and connectivity of our GitLab environment by configuring these hooks.

Basic Usage

We must first click the + symbol on the toolbar to start a new project in order to use GitLab.

The project name, namespace (user or group), and visibility level (Private, Internal, or Public) must be entered when prompted.

The project's parameters allow for future adjustments, so these are not set in stone.

The project will be created once we select Create Project.

  • We can link the newly established project to a local Git repository.

  • The URLs for SSH and HTTPS access are provided by GitLab and are located at the top of the project webpage.

  • We'll set up a Git remote using these URLs to synchronize our local repository with GitLab.

We use these commands to deal with an existing GitLab repository:

Adding a Remote : Use this command to add the remote gitlab if we wish to link our local repository to a GitLab project:

git remote add gitlab https://server/namespace/project.git

Here, https://server/namespace/project.git is the URL of our GitLab project.

Cloning a Repository : We can clone a repository straight from GitLab using the following method if we don't already have a local copy of it:

git clone https://server/namespace/project.git

This command sets up the default remote called origin to the GitLab URL and generates a local copy of the repository.

Views in the Web UI : GitLab's web interface offers multiple views in the repository.

Recent activity is shown on the project's home page, and we can access the project's files and commit log via the navigation links at the top.

We can more efficiently manage and review the repository because to these features.

Working Together

We can use merge requests or offer direct push access to work together on a GitLab project.

  • Direct Push Access : By giving users access level of Developer or above through the Members area, we can grant them direct push access to commits and branches.

  • Merge Requests : If a user does not have push access, they can still contribute by forking the project or by making branches and sending merge requests.

    The project owner selects which contributions are accepted using this method, which allows for controlled integration of modifications.

  • Discuss and Review : With tools for allocating responsibilities and classifying work into milestones, merge requests and issues support in-depth discussions and code reviews.

Project wikis and maintenance tools are among the extra features that GitLab provides.

The majority of administration can be done via the web interface, which reduces the requirement for direct server settings.

Advertisements