- Git terminology
- Clone a repository
- Create a branch
- Switch to a branch
- View differences
- View the files that have changes
- Add and commit local changes
- Send changes to GitLab.com
- Delete all changes in the branch
- Unstage all changes that have been added to the staging area
- Undo most recent commit
- Merge a branch with default branch
- Advanced use of Git through the command line
- Synchronize changes in a forked repository with the upstream
Git is an open-source distributed version control system. GitLab is built on top of Git.
You can do many Git operations directly in GitLab. However, the command line is required for advanced tasks, like fixing complex merge conflicts or rolling back commits.
For a quick reference of Git commands, download a Git Cheat Sheet.
For more information about the advantages of working with Git and GitLab:
- Watch the GitLab Source Code Management Walkthrough video.
- Learn how GitLab became the backbone of the Worldline development environment.
To help you visualize what you’re doing locally, you can install a Git GUI app.
If you’re familiar with Git terminology, you might want to skip this section and go directly to prerequisites.
In GitLab, files are stored in a repository. A repository is similar to how you store files in a folder or directory on your computer.
- A remote repository refers to the files in GitLab.
- A local copy refers to the files on your computer.
Often, the word “repository” is shortened to “repo”.
In GitLab, a repository is contained in a project.
When you want to contribute to someone else’s repository, you make a copy of it. This copy is called a fork. The process is called “creating a fork.”
When you fork a repo, you create a copy of the project in your own namespace. You then have write permissions to modify the project files and settings.
For example, you can fork this project, https://gitlab.com/gitlab-tests/sample-project/, into your namespace.
You now have your own copy of the repository. You can view the namespace in the URL, for example
Then you can clone the repository to your local machine, work on the files, and submit changes back to the
To create a copy of a remote repository’s files on your computer, you can either download or clone the repository. If you download it, you cannot sync the repository with the remote repository on GitLab.
Cloning a repository is the same as downloading, except it preserves the Git connection with the remote repository. You can then modify the files locally and upload the changes to the remote repository on GitLab.
After you save a local copy of a repository and modify the files on your computer, you can upload the
changes to GitLab. This is referred to as pushing to the remote, because you use the command
When the remote repository changes, your local copy is behind. You can update your local copy with the new
changes in the remote repository.
This is referred to as pulling from the remote, because you use the command
To start using GitLab with Git, complete the following tasks:
- Create and sign in to a GitLab account.
- Open a terminal.
- Install Git on your computer.
- Configure Git.
- Choose a repository.
To execute Git commands on your computer, you must open a terminal (also known as command prompt, command shell, and command line). Here are some options:
- For macOS users:
- For Windows users:
- For Linux users:
- Built-in Linux Terminal.
Determine if Git is already installed on your computer by opening a terminal and running this command:
If Git is installed, the output is:
git version X.Y.Z
If your computer doesn’t recognize
git as a command, you must install Git.
After you install Git, run
git --version to confirm that it installed correctly.
To start using Git from your computer, you must enter your credentials to identify yourself as the author of your work. The username and email address should match the ones you use in GitLab.
In your shell, add your user name:
git config --global user.name "your_username"
Add your email address:
git config --global user.email "firstname.lastname@example.org"
To check the configuration, run:
git config --global --list
--globaloption tells Git to always use this information for anything you do on your system. If you omit
--local, the configuration applies only to the current repository.
You can read more on how Git manages configurations in the Git configuration documentation.
Before you begin, choose the repository you want to work in. You can use any project you have permission to access on GitLab.com or any other GitLab instance.
To use the repository in the examples on this page:
- Go to https://gitlab.com/gitlab-tests/sample-project/.
- In the top right, select Fork.
- Choose a namespace for your fork.
The project becomes available at
You can fork any project you have access to.
When you clone a repository, the files from the remote repository are downloaded to your computer, and a connection is created.
This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.
Clone with SSH when you want to authenticate only one time.
- Authenticate with GitLab by following the instructions in the SSH documentation.
- Go to your project’s landing page and select Clone. Copy the URL for Clone with SSH.
- Open a terminal and go to the directory where you want to clone the files. Git automatically creates a folder with the repository name and downloads the files there.
Run this command:
git clone email@example.com:gitlab-tests/sample-project.git
To view the files, go to the new directory:
Clone with HTTPS when you want to authenticate each time you perform an operation between your computer and GitLab.
- Go to your project’s landing page and select Clone. Copy the URL for Clone with HTTPS.
- Open a terminal and go to the directory where you want to clone the files.
Run the following command. Git automatically creates a folder with the repository name and downloads the files there.
git clone https://gitlab.com/gitlab-tests/sample-project.git
- GitLab requests your username and password:
- If you have 2FA enabled for your account, you must 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.
To view the files, go to the new directory:
Access deniedmessage appears, add your namespace (username or group) to the path:
git clone https://firstname.lastname@example.org/gitlab-org/gitlab.git.
You can initialize a local folder so Git tracks it as a repository.
- Open the terminal in the directory you’d like to convert.
Run this command:
.gitfolder is created in your directory. This folder contains Git records and configuration files. You should not edit these files directly.
- Add the path to your remote repository so Git can upload your files into the correct project.
You add a “remote” to tell Git which remote repository in GitLab is tied to the specific local folder on your computer. The remote tells Git where to push or pull from.
To add a remote to your local copy:
- In GitLab, create a project to hold your files.
- Visit this project’s homepage, scroll down to Push an existing folder, and copy the command that starts with
git remote add.
On your computer, open the terminal in the directory you’ve initialized, paste the command you copied, and press enter:
git remote add origin email@example.com:username/projectpath.git
To view your remote repositories, type:
git remote -v
-v flag stands for verbose.
To work on an up-to-date copy of the project, you
pull to get all the changes made by users
since the last time you cloned or pulled the project. Replace
with the name of your default branch
to get the main branch code, or replace it with 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 the name of your
default branch, 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.
A branch is a copy of the files in the repository at the time you create the branch.
You can work in your branch without affecting other branches. When
you’re ready to add your changes to the main codebase, you can merge your branch into
the default branch, for example,
Use branches when you:
- Want to add code to a project but you’re not sure if it works properly.
- Are collaborating on the project with others, and don’t want your work to get mixed up.
A new branch is often called feature branch to differentiate from the default branch.
To create a feature branch:
git checkout -b <name-of-branch>
Branch names cannot contain empty spaces and special characters. Use only lowercase letters, numbers,
-), and underscores (
All work in Git is done in a branch. You can switch between branches to see the state of the files and work in that branch.
To switch to an existing branch:
git checkout <name-of-branch>
For example, to change to the
git checkout main
To view the differences between your local unstaged changes and the latest version that you cloned or pulled:
When you add, change, or delete files or folders, Git knows about the changes. To check which files have been changed:
When you type
git status, locally changed files are shown in red. These changes may
be new, modified, or deleted files or folders.
To stage a file for commit:
git add <file-name OR folder-name>
Repeat step 1 for each file or folder you want to add. Or, to stage all files in the current directory and subdirectory, type
git add ..
Confirm that the files have been added to staging:
The files should be displayed in green text.
To commit the staged files:
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
As a shortcut, you can add all local changes to staging and commit them with one command:
git commit -a -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
To push all local changes to the remote repository:
git push <remote> <name-of-branch>
For example, to push your local commits to the
main branch of the
git push origin main
Sometimes Git does not allow you to push to a repository. Instead, you must force an update.
To discard all changes to tracked files:
git checkout .
This action removes changes to files, not the files themselves. Untracked (new) files do not change.
To unstage (remove) all files that have not been committed:
To undo the most recent commit:
git reset HEAD~1
This action leaves the changed files and folders unstaged in your local repository.
You can learn more about the different ways Git can undo changes in the Git Undoing Things documentation.
When you are ready to add your changes to the default branch, you merge the feature branch into it:
git checkout <default-branch> git merge <feature-branch>
In GitLab, you typically use a merge request to merge your changes, instead of using the command line.
To create a merge request from a fork to an upstream repository, see the forking workflow.
For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.
To create a copy of a repository in your namespace, you fork it.
Changes made to your copy of the repository are not automatically synchronized with the original.
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 repository the