- Configure Git
- Git authentication methods
- Git terminology
- Basic Git commands
- Create a branch
- Switch to the master branch
- Work on an existing branch
- View the changes you’ve made
- View differences
- 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 master 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 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 must use Git from the command line and then push your changes to the remote server.
This guide helps 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 the GitLab Git Cheat Sheet.
For more information about the advantages of working with Git and GitLab:
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.
To execute Git commands in your computer, you must open a command shell (also known as command prompt, terminal, and command line) of your preference. Here are some suggestions:
- For macOS users:
- For Windows users:
- For Linux users:
- Built-in: Linux Terminal.
Open a command shell and run the following command to check if Git is already installed in your computer:
If you have Git installed, the output is:
git version X.Y.Z
If your computer doesn’t recognize
git as a command, you must install Git.
After that, run
git --version again to verify whether it was correctly installed.
To start using Git from your computer, you must 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 "firstname.lastname@example.org"
To check the configuration, run:
git config --global --list
--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 is applied only to the current
You can read more on how Git manages configurations in the Git configuration documentation.
To connect your computer with GitLab, you need to add your credentials to identify yourself. You have two options:
- Authenticate on a project-by-project basis through HTTPS, and enter your credentials every time you perform an operation between your computer and GitLab.
- Authenticate through SSH once and GitLab no longer requests your credentials every time you pull, push, and clone.
To start the authentication process, we’ll clone an existing repository to our computer:
- If you want to use SSH to authenticate, follow the instructions on the SSH documentation to set it up before cloning.
- If you want to use HTTPS, GitLab requests your user name 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. Create one before cloning.
- If you don’t have 2FA enabled, use your account’s password.
If you’re familiar with the Git terminology, you may want to jump directly into the basic commands.
A namespace is either a user name or a group name.
For example, suppose Jo is a GitLab.com user and they chose their user name as
jo. You can see Jo’s profile at
jo is a namespace.
Jo also created a group in GitLab, and chose the path
test-group for their
group. The group can be accessed under
test-group is a namespace.
Your files in GitLab live in a repository, similar to how you have them in a folder or directory in your computer. Remote repository refers to the files in GitLab and the copy in your computer is called local copy. A project in GitLab is what holds a repository, which holds your files.
Often, the word “repository” is shortened to “repo”.
When you want to copy someone else’s repository, you fork the project. By forking it, you create a copy of the project into your own namespace to have read and write permissions to modify the project files and settings.
For example, if you fork this project, https://gitlab.com/gitlab-tests/sample-project/ into your namespace, you create your own copy of the repository in your namespace (
https://gitlab.com/your-namespace/sample-project/). From there, you can clone it into your computer,
work on its files, and (optionally) submit proposed changes back to the
original repository if you’d like.
To create a copy of a remote repository’s files on your computer, you can either download or clone. If you download, you cannot sync it with the remote repository on GitLab.
Cloning a repository is the same as downloading, except it preserves the Git connection with the remote repository. This allows you to modify the files locally and upload the changes to the remote repository on GitLab.
After you saved a local copy of a repository and modified its files on your computer, you can upload the
changes to GitLab. This is referred to as pushing to GitLab, as this is achieved by the command
When the remote repository changes, your local copy is behind it. You can update it with the new
changes in the remote repository.
This is referred to as pulling from GitLab, as this is achieved by the command
For the purposes of this guide, we use this example project on GitLab.com: https://gitlab.com/gitlab-tests/sample-project/.
To use it, log into GitLab.com and fork the example project into your
namespace to have your own copy to playing with. Your sample
project is available under
You can also choose any other project to follow this guide. Then, replace the example URLs with your own project’s.
If you want to start by copying an existing GitLab repository onto your computer, see how to clone a repository. On the other hand, if you want to start by uploading an existing folder from your computer to GitLab, see how to convert a local folder into a Git repository.
To start working locally on an existing remote repository, clone it with the
git clone <repository path>. You can either clone it via HTTPS
or SSH, according to your preferred authentication method.
You can find both paths (HTTPS and SSH) by navigating to your project’s landing page and clicking Clone. GitLab prompts you with both paths, from which you can copy and paste in your command line. You can also clone and open directly in Visual Studio Code.
For example, considering our sample project:
- To clone through HTTPS, use
- To clone through SSH, use
To get started, open a terminal window in the directory you wish to add the
repository files into, and run one of the
git clone commands as described below.
Both commands download a copy of the files in a folder named after the project’s
name and preserve the connection with the remote repository.
You can then navigate to the new directory with
cd sample-project and start working on it
https://gitlab.com/gitlab-tests/sample-project/ via HTTPS:
git clone https://gitlab.com/gitlab-tests/sample-project.git
Access denied, you may have to add your namespace (user name or group name) to clone through HTTPS:
git clone https://email@example.com/gitlab-org/gitlab.git.
firstname.lastname@example.org:gitlab-org/gitlab.git via SSH:
git clone email@example.com:gitlab-org/gitlab.git
When you have your files in a local folder and want to convert it into
a repository, you must initialize the folder through the
command. This instructs Git to begin to track that directory as a
repository. To do so, open the terminal on the directory you’d like to convert
This command creates a
.git folder in your directory that contains Git
records and configuration files. We advise against editing these files
Then, on the next step, add the path to your remote repository so that Git can upload your files into the correct project.
By “adding a remote repository” to your local directory you tell Git that the path to that specific project in GitLab corresponds to that specific folder you have in your computer. This way, your local folder is identified by Git as the local content for that specific remote project.
To add a remote repository to your local copy:
- In GitLab, create a new 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 firstname.lastname@example.org:username/projectpath.git
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.
To view your remote repositories, type:
git remote -v
-v flag stands for verbose.
If you want to add code to a project but you’re not sure if it works properly, or you’re collaborating on the project with others, and don’t want your work to get mixed up, it’s a good idea to work on a different branch.
When you create a branch in a Git repository, you make a copy of its files at the time of branching. You’re free
to do whatever you want with the code in your branch without impacting the main branch or other branches. And when
you’re ready to bring your changes to the main codebase, you can merge your branch into the default branch
used in your project (such as
A new branch is often called feature branch to differentiate from the default branch.
To create a new feature branch and work from without affecting the
git checkout -b <name-of-branch>
Note that Git does not accept empty spaces and special characters in branch
names, so use only lowercase letters, numbers, hyphens (
-), and underscores
_). Do not use capital letters, as it may cause duplications.
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
master to the branch name.
git checkout master
To switch to an existing branch, so you can work on it:
git checkout <name-of-branch>
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:
To view the differences between your local, unstaged changes and the repository versions that you cloned or pulled, type:
Local changes are shown 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
git add <file-name OR folder-name> git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
To add and commit (save) all local changes quickly:
git add . git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
.character means all file changes in the current directory and all subdirectories.
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
git push origin master
On certain occasions, Git disallows pushes to your repository, and then you must force an update.
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.
To undo the most recently added, but not committed, changes to files/folders:
git reset .
To undo the most recent commit, type:
git reset HEAD~1
This leaves the changed files and folders unstaged in your local repository.
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
For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.
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