- Open a shell
- Check if Git has already been installed
- Add your Git username and set your email
- Check your information
Basic Git commands
- Initialize a local directory for Git version control
- Clone a repository
- Switch to the master branch
- Download the latest changes in the project
- View your remote repositories
- Add a remote repository
- Create a branch
- Work on an existing branch
- View the changes you’ve made
- View differences
- Add and commit local changes
- Add all changes to commit
- 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
- Synchronize changes in a forked repository with the upstream
While GitLab has a powerful user interface, if you want to use Git itself, you will have to do so from the command line. If you want to start using Git and GitLab together, make sure that you have created and/or signed into an account on GitLab.
Depending on your operating system, you will need to use a shell of your preference. Here are some suggestions:
Git is usually preinstalled on Mac and Linux, so run the following command:
You should receive a message that tells you which Git version you have on your computer. If you don’t receive a “Git version” message, it means that you need to download Git.
After you are finished installing Git, open a new shell and type
git --version again
to verify that it was correctly installed.
It is important to configure your Git username and email address, since every Git commit will use this information to identify you as the author.
In your shell, type the following command to add your username:
git config --global user.name "YOUR_USERNAME"
Then verify that you have the correct username:
git config --global user.name
To set your email address, type the following command:
git config --global user.email "email@example.com"
To verify that you entered your email correctly, type:
git config --global user.email
You’ll need to do this only once, since you are using the
--global option. It
tells Git to always use this information for anything you do on that system. If
you want to override this with a different username or email address for specific
projects or repositories, you can run the command without the
when you’re in that project, and that will default to
--local. You can read more
on how Git manages configurations in the Git Config documentation.
To view the information that you entered, along with other global options, type:
git config --global --list
Start using Git via the command line with the most basic commands as described below.
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:
This creates a
.git directory that contains the Git configuration files.
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
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:
To get started, open a terminal window in the directory you wish to clone the repository files into, and run one of the following commands.
Clone via HTTPS:
git clone https://gitlab.com/gitlab-org/gitlab.git
Clone via SSH:
git clone firstname.lastname@example.org:gitlab-org/gitlab.git
Both commands will download a copy of the files in a folder named after the project’s name. You can then navigate to the directory and start working on it locally.
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 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.
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.
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>
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:
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
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
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
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