GitLab using Git commands

Source

What is Git?

Code versions are maintained using “Version Control.” And one of the best version control software is Git. Git is an open-source version-control system used for managing source codes having different versions.

Benefits:

• Developers in a team can review, comment, and improve each other’s code and assets.
• Have the option to branch codes, make changes, and merge commits faster.
• Collaboration of teams fosters higher release build and release patterns.

Branches in Git

Branching is the concept where you continue developing your source code without messing up the original one. To do this, we use the concept of the fork; will be discussed in the coming topics.

What is Master in Git?

Master is nothing but a naming convention for a branch. But the name ‘master’ does not exist anymore as it got changed to ‘main’ in 2020.

After cloning (downloading) a project from a remote server, the resulting local repository has a single local branch: the so-called “main” branch. This means that a “main” is a repository’s “default” branch.

Creating a branch using Git commands

Step 1: Use the ‘cd’ command to choose the repository you want to create a branch.

Step 2: Enter the command:

> git checkout -b “the_name_of_the_branch_you_want_create”

Step 3: Now, you have created and switched to the new branch.

Switching to an existing branch

Step 1: Use the ‘cd’ command to choose the repository you want to create a branch.

Step 2: Enter the command:

> git checkout “the_name_of_the_branch_you_want_to_switch_to”

Step 3: Now, you have created and switched to the new branch.

Fork

A fork is a copy of a repository. Forking a repository allows you to make changes without actually affecting the original project. We use this concept for bug fixing.

Forking a repository

Step1: Login to GitLab account & go to project

Step2: Click on the Fork Button located at the right corner.

Step3: If you get a message: “No available namespace to fork the project”.

• Click on the menu button, as shown above, select groups → your groups → create a new group. (skip this step if the above message doesn’t pop up)

Now, when you go back to “Project” and click on fork, your project is successfully forked.

After forking a project, we can make changes in the project without actually affecting the original one.

Clone :

Cloning a git repository means that you create a copy of the repository in a new directory, at another location.

Difference between Fork and Clone

Forking only creates a copy of the original repository in your remote server. Whereas, cloning means downloading a copy of the original repository to another location (local or remote).

For example, A developer wants to work on a new feature on another developer’s code.

• He can fork the repository to his remote server such that he doesn’t have to request a merge every time he makes a commit in the repository.
• Next, to work on the features, he can download a copy of the forked repository to his local system.
• He can now work on his feature and make any number of commits as he likes to the forked repository.

Cloning a repository using git commands

Step 1: Make sure you always log in to your repository before cloning a repository to your desired location.

Commands:

> git config — global user.name “your_username”
> git config — global user.email “your_email_id”

Step 2: Choose the directory of where you will be storing your repository.

> cd “your_directory_name”

Step 3: go to the remote repository -> click on clone -> copy the http address.

Step 4: enter the clone command shown below in git bash and click enter.

> git clone “http_copied_id”

You have successfully cloned a remote repository to your desired directory.

Now you can access the contents of this repository using the command below:

> cd “url_path_of_the_cloned_repository/”

Deploying code from Git to GitLab

Using the Git console is the most efficient method to commit your changes to the remote repository rather than doing it manually every time you want to make a commit. Let us have a look at how this process works.

Source : Git to GitLab

The above diagram shows us the entire process of how Git works.

Step 1: Clone the repository from remote to the working directory (cloning discussed previously)

Step 2: Work on your project and make necessary changes to your code.

Step 3:

Staging

Staging in Git allows us to keep making changes to the working directory. It allows us to replace staged files of other versions, remove changes from staging, etc. By separating staging and committing, you will be able to customize what goes into the commit.

Git command:

> git add “file_name”

To stage all files:

> git add .

Step 4:

Committing changes to your local repository

Commit command or committing is used to save our changes to the local repository.

Git command:

> git commit -m “a short description”

Note: It is not necessary to stage the file and then commit. You can make a commit without going through the staging area.

> git commit -a -m “commit message”

Step 5:

Pushing to remote

After committing all the changes to your local repository, you are finally ready to push your changes to the remote repository.

Git command:

> git push origin “name_of_the_branch_you’re_pushing_to”

After committing all the changes to the remote repository, what if you find a mistake in it and you want to revert the changes, perhaps even remove it from the commit history.

This is where revert and reset commands come into play.

Revert

Git revert is the forward-moving undo operation that is the safest method of undoing changes. A revert would create a new commit that inverses the specified changes instead of deleting or orphaning the commits in the commit history.

Source : Reverting

Fig1: The blue color is the new commit having specified changes.

From the above figure, we can understand that while reverting, changes made earlier are not lost. Let us take a look at how this concept is applied using Git.

Reverting a commit after staging and committing

Step 1: Check the log to see the commit made using the following command.

>git log

Step 2: Select and copy the id of the commit you want to revert.

Step 3: Enter the below command:

> git revert copied_id

Step 4: Now, when you check the log again, you can observe a revert commit created with the changes specified. This commit is now pushed back to the remote.

Step 5: The changes should be added to your remote repository as well. Use the command below to make this change.

> git push

Step 6: Now when you check the remote repository, you can see that the revert changes have been made.

Note:

Reverting a change before staging and committing

If you have not yet staged or committed yet, your changes can still be reverted. You need not go back to the file and undo the steps. All you have to do is enter the below command in the git bash console.

> git checkout — “file_name”

Reset

Git reset is a significant command used to undo local changes to the state of a Git repository. Unlike the revert command, reset is a much riskier command to use.

Never use the reset command after pushing the snapshots to a public repository. After publishing a commit, assume that other developers are reliant upon it. Removing a commit poses many issues for collaboration when the other team members continue to work on that commit. A chunk of the project history will look as if it has disappeared when these developers try to sync up with your repository.

Source: Resetting

Fig2: The blue color is the commit that gets reverted to its previously made changes.

Resetting a commit

Step 1: Check the log to see the commit made using the following command.

> git log

Step 2: Copy the id of the commit you want to remain as the head.

Step 3: Enter the below command:

> git reset copied_id

Step 4: When you check the log again, you can see a reset commit created with the changes specified. This commit can now be pushed back to the remote.

Step 5: The changes should be added to your remote repository as well. Use the command below to make this change.

> git push — force

Step 6: When you check the remote repository, you can see that the reset changes are successful.

Bug Fix while using reset command :

This bug might be faced by only some users. The bug occurs after resetting the commit while trying to push it to your remote repository. (Error as shown below)

If you get this type of error, all you have to do is follow the steps below:

Note: Only the maintainer of the repository would be able to make these changes.

Step 1: Sign-in to GitLab → Go to the repository → Settings → Repository.

Step 2: Click on Protected Branches → Select the branch you want access to → provide access as required.

Step 3: In the Git bash console, you can make the commits to the remote using:

> git push — force

Step 4: Your commits are now successfully made on the remote server.

Merge Request

In GitLab, the merge request is to combine two branches.

For example, If the team has to work on a project without making changes to the original one, first fork the project(make a copy of the project). Now, after working on this copy, we need to append these changes to the original project. This is where merge requests come into play.

Manual method

Step 1: In the forked project, click on Merge requests → New merge requests.

Step 2: Select the source branch and Target branch → Click on “Compare branches and continue” → fill in the details & click on “create merge requests”

Step3: Fill in the details. For example, the person who is supposed to approve this merge request.

Step4: Click on “create merge request.”

Now, the person you have assigned to approve the request would get a message. On approval, all the changes are made to the original project.

Using Git commands

Step 1: Make sure you’re working on a separate branch before creating a merge request.

> git checkout “name_of_exisiting_branch”

To create a new branch :

> git checkout -b “new_branch_name”

Step 2: Make the commits to your created branch and push it to the remote.

Step 3: Go to the commit history and copy the id of the commit you want to merge to the main branch.

> git log

Step 4: Switch your branch to main (the branch with which you want to merge)

Step 5: Enter the following command.

> git merge “the_copied_id”

Step 6: Your commit will now get merged.

Step 7: To make the changes to the remote repository, push the commit.

>git push

Your commit is now successfully merged with the main branch.

Conclusion:

This article has covered all the basics of how to operate GitLab using Git. There are many more commands yet to explore. Rounding off, we can say that working on GitLab is much simpler and efficient once you start using Git. You can make the commits to your local repository even when a network connection is unavailable and later push it to remote when the network is available.

I strongly recommend exploring on this topic and apply these concepts as there are many Git commands you can experiment with. I hope this article has helped you. You can reach me on LinkedIn.