Skip to content

GitLab

Start using Git on the command line

Git is an open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. GitLab is built on top of Git.

While GitLab has a powerful user interface from which you can do a great amount of Git operations directly in the browser, you’ll eventually need to use Git through the command line for advanced tasks.

For example, if you need to fix complex merge conflicts, rebase branches, merge manually, or undo and roll back commits, you'll need to use Git from the command line and then push your changes to the remote server.

This guide will help you get started with Git through the command line and can be your reference for Git commands in the future. If you're only looking for a quick reference of Git commands, you can download GitLab's Git Cheat Sheet.

For more information about the advantages of working with Git and GitLab:

TIP: Tip: To help you visualize what you're doing locally, there are Git GUI apps you can install.

Requirements

You don't need a GitLab account to use Git locally, but for the purpose of this guide we recommend registering and signing into your account before starting. Some commands need a connection between the files in your computer and their version on a remote server.

You'll also need to open a command shell and have Git installed in your computer.

Command shell

To execute Git commands in your computer, you'll need to open a command shell (also known as command prompt, terminal, and command line) of your preference. Here are some suggestions:

  • For macOS users:
    • Built-in: Terminal. Press ⌘ command + space and type "terminal" to find it.
    • iTerm2, which you can integrate with zsh and oh my zsh for color highlighting, among other handy features for Git users.
  • For Windows users:
    • Built-in: cmd. Click the search icon on the bottom navbar on Windows and type "cmd" to find it.
    • PowerShell: a Windows "powered up" shell, from which you can execute a greater number of commands.
    • Git Bash: it comes built into Git for Windows.
  • For Linux users:

Install Git

Open a command shell and run the following command to check if Git is already installed in your computer:

git --version

If you have Git installed, the output will be:

git version X.Y.Z

If your computer doesn't recognize git as a command, you'll need to install Git. After that, run git --version again to verify whether it was correctly installed.

Configure Git

To start using Git from your computer, you'll need to enter your credentials (user name and email) to identify you as the author of your work. The user name and email should match the ones you're using on GitLab.

In your shell, add your user name:

git config --global user.name "your_username"

And your email address:

git config --global user.email "[email protected]"

To check the configuration, run:

git config --global --list

The --global option tells Git to always use this information for anything you do on your system. If you omit --global or use --local, the configuration will be applied only to the current repository.

You can read more on how Git manages configurations in the Git Config documentation.

Basic Git commands

Start using Git via the command line with the most basic commands as described below.

Initialize a local directory for Git version control

If you have an existing local directory that you want to initialize for version control, use the init command to instruct Git to begin tracking the directory:

git init

This creates a .git directory that contains the Git configuration files.

Once the directory has been initialized, you can add a remote repository and send changes to GitLab.com. You will also need to create a new project in GitLab for your Git repository.

Clone a repository

To start working locally on an existing remote repository, clone it with the command git clone <repository path>. By cloning a repository, you'll download a copy of its files to your local computer, automatically preserving the Git connection with the remote repository.

You can either clone it via HTTPS or SSH. If you chose to clone it via HTTPS, you'll have to enter your credentials every time you pull and push. You can read more about credential storage in the Git Credentials documentation. With SSH, you enter your credentials only once.

You can find both paths (HTTPS and SSH) by navigating to your project's landing page and clicking Clone. GitLab will prompt you with both paths, from which you can copy and paste in your command line.

As an example, consider this repository path:

  • HTTPS: https://gitlab.com/gitlab-org/gitlab.git
  • SSH: [email protected]:gitlab-org/gitlab.git

To get started, open a terminal window in the directory you wish to clone the repository files into, and run one of the git clone commands as described below.

Both commands will download a copy of the files in a folder named after the project's name. You can then navigate to the new directory and start working on it locally.

Clone via HTTPS

To clone https://gitlab.com/gitlab-org/gitlab.git via HTTPS:

git clone https://gitlab.com/gitlab-org/gitlab.git

You'll have to add your password every time you clone through HTTPS. If you have 2FA enabled for your account, you'll have to use a Personal Access Token with read_repository or write_repository permissions instead of your account's password.

If you don't have 2FA enabled, use your account's password.

TIP: Troubleshooting: On Windows, if you entered incorrect passwords multiple times and GitLab is responding Access denied, you may have to add your namespace (user name or group name) to clone through HTTPS: git clone https://[email protected]/gitlab-org/gitlab.git.

Clone via SSH

To clone [email protected]:gitlab-org/gitlab.git via SSH:

git clone [email protected]:gitlab-org/gitlab.git

Switch to the master branch

You are always in a branch when working with Git. The main branch is the master branch, but you can use the same command to switch to a different branch by changing master to the branch name.

git checkout master

Download the latest changes in the project

To work on an up-to-date copy of the project (it is important to do this every time you start working on a project), you pull to get all the changes made by users since the last time you cloned or pulled the project. Use master for the <name-of-branch> to get the main branch code, or the branch name of the branch you are currently working in.

git pull <REMOTE> <name-of-branch>

When you clone a repository, REMOTE is typically origin. This is where the repository was cloned from, and it indicates the SSH or HTTPS URL of the repository on the remote server. <name-of-branch> is usually master, but it may be any existing branch. You can create additional named remotes and branches as necessary.

You can learn more on how Git manages remote repositories in the Git Remote documentation.

View your remote repositories

To view your remote repositories, type:

git remote -v

The -v flag stands for verbose.

Add a remote repository

To add a link to a remote repository:

git remote add <source-name> <repository-path>

You'll use this source name every time you push changes to GitLab.com, so use something easy to remember and type.

Create a branch

To create a new branch, to work from without affecting the master branch, type the following (spaces won't be recognized in the branch name, so you will need to use a hyphen or underscore):

git checkout -b <name-of-branch>

Work on an existing branch

To switch to an existing branch, so you can work on it:

git checkout <name-of-branch>

View the changes you've made

It's important to be aware of what's happening and the status of your changes. When you add, change, or delete files/folders, Git knows about it. To check the status of your changes:

git status

View differences

To view the differences between your local, unstaged changes and the repository versions that you cloned or pulled, type:

git diff

Add and commit local changes

You'll see any local changes in red when you type git status. These changes may be new, modified, or deleted files/folders. Use git add to first stage (prepare) a local file/folder for committing. Then use git commit to commit (save) the staged files:

git add <file-name OR folder-name>
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"

Add all changes to commit

To add and commit (save) all local changes quickly:

git add .
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"

NOTE: Note: The . character means all file changes in the current directory and all subdirectories.

Send changes to GitLab.com

NOTE: Note: To create a merge request from a fork to an upstream repository, see the forking workflow

To push all local commits (saved changes) to the remote repository:

git push <remote> <name-of-branch>

For example, to push your local commits to the master branch of the origin remote:

git push origin master

Delete all changes in the branch

To delete all local changes in the branch that have not been added to the staging area, and leave unstaged files/folders, type:

git checkout .

Note that this removes changes to files, not the files themselves.

Unstage all changes that have been added to the staging area

To undo the most recently added, but not committed, changes to files/folders:

git reset .

Undo most recent commit

To undo the most recent commit, type:

git reset HEAD~1

This leaves the changed files and folders unstaged in your local repository.

CAUTION: Warning: A Git commit should not usually be reversed, particularly if you already pushed it to the remote repository. Although you can undo a commit, the best option is to avoid the situation altogether by working carefully.

Merge a branch with master branch

When you are ready to make all the changes in a branch a permanent addition to the master branch, you merge the two together:

git checkout <name-of-branch>
git merge master

Synchronize changes in a forked repository with the upstream

Forking a repository lets you create a copy of a repository in your namespace. Changes made to your copy of the repository are not synchronized automatically with the original. Your local fork (copy) contains changes made by you only, so to keep the project in sync with the original project, you need to pull from the original repository.

You must create a link to the remote repository to pull changes from the original repository. It is common to call this remote the upstream.

You can now use the upstream as a <remote> to pull new updates from the original repository, and use the origin to push local changes and create merge requests.