2019-07-30 05:02:59 +00:00
|
|
|
|
---
|
|
|
|
|
type: howto, tutorial
|
|
|
|
|
---
|
|
|
|
|
|
2015-07-09 22:33:42 +00:00
|
|
|
|
# Start using Git on the command line
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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.
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
|
|
|
|
## Open a shell
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Depending on your operating system, you will need to use a shell of your preference.
|
|
|
|
|
Here are some suggestions:
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
2019-10-11 12:06:29 +00:00
|
|
|
|
- [Terminal](https://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line) on macOS
|
2015-06-17 16:44:48 +00:00
|
|
|
|
- [GitBash](https://msysgit.github.io) on Windows
|
2019-10-11 12:06:29 +00:00
|
|
|
|
- [Linux Terminal](https://www.howtogeek.com/140679/beginner-geek-how-to-start-using-the-linux-terminal/) on Linux
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
|
|
|
|
## Check if Git has already been installed
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Git is usually preinstalled on Mac and Linux, so run the following command:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2015-06-17 16:44:48 +00:00
|
|
|
|
git --version
|
|
|
|
|
```
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
After you are finished installing Git, open a new shell and type `git --version` again
|
|
|
|
|
to verify that it was correctly installed.
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
|
|
|
|
## Add your Git username and set your email
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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.
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
In your shell, type the following command to add your username:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2016-09-19 21:18:03 +00:00
|
|
|
|
git config --global user.name "YOUR_USERNAME"
|
2015-06-17 16:44:48 +00:00
|
|
|
|
```
|
|
|
|
|
|
2015-07-09 22:33:42 +00:00
|
|
|
|
Then verify that you have the correct username:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2015-06-17 16:44:48 +00:00
|
|
|
|
git config --global user.name
|
|
|
|
|
```
|
|
|
|
|
|
2015-07-09 22:33:42 +00:00
|
|
|
|
To set your email address, type the following command:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2016-09-19 21:18:03 +00:00
|
|
|
|
git config --global user.email "your_email_address@example.com"
|
2015-06-17 16:44:48 +00:00
|
|
|
|
```
|
|
|
|
|
|
2015-07-09 22:33:42 +00:00
|
|
|
|
To verify that you entered your email correctly, type:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2015-06-17 16:44:48 +00:00
|
|
|
|
git config --global user.email
|
|
|
|
|
```
|
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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 `--global` option
|
|
|
|
|
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](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) documentation.
|
2015-06-17 16:44:48 +00:00
|
|
|
|
|
|
|
|
|
## Check your information
|
|
|
|
|
|
2018-06-13 13:54:23 +00:00
|
|
|
|
To view the information that you entered, along with other global options, type:
|
|
|
|
|
|
|
|
|
|
```bash
|
2015-06-17 16:44:48 +00:00
|
|
|
|
git config --global --list
|
|
|
|
|
```
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2016-03-22 10:01:13 +00:00
|
|
|
|
## Basic Git commands
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Start using Git via the command line with the most basic commands as described below.
|
2019-01-23 17:09:19 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
### Initialize a local directory for Git version control
|
2019-05-19 20:47:32 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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:
|
2019-05-19 20:47:32 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git init
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This creates a `.git` directory that contains the Git configuration files.
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Once the directory has been initialized, you can [add a remote repository](#add-a-remote-repository)
|
|
|
|
|
and [send changes to GitLab.com](#send-changes-to-gitlabcom). You will also need to
|
|
|
|
|
[create a new project in GitLab](../gitlab-basics/create-project.html#push-to-create-a-new-project)
|
|
|
|
|
for your Git repository.
|
2019-05-19 20:47:32 +00:00
|
|
|
|
|
2019-01-23 16:16:48 +00:00
|
|
|
|
### Clone a repository
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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.
|
2019-01-23 16:16:48 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
You can either clone it via HTTPS or [SSH](../ssh/README.md). If you chose to clone
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
|
|
|
|
|
With SSH, you enter your credentials only once.
|
2019-01-23 16:16:48 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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
|
2019-01-23 16:16:48 +00:00
|
|
|
|
and paste in your command line.
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
As an example, consider this repository path:
|
2019-01-23 16:16:48 +00:00
|
|
|
|
|
2019-09-18 18:06:14 +00:00
|
|
|
|
- HTTPS: `https://gitlab.com/gitlab-org/gitlab.git`
|
|
|
|
|
- SSH: `git@gitlab.com:gitlab-org/gitlab.git`
|
2019-01-23 16:16:48 +00:00
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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.
|
2019-01-23 16:16:48 +00:00
|
|
|
|
|
|
|
|
|
Clone via HTTPS:
|
2019-01-17 22:07:07 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2019-09-18 18:06:14 +00:00
|
|
|
|
git clone https://gitlab.com/gitlab-org/gitlab.git
|
2019-01-17 22:07:07 +00:00
|
|
|
|
```
|
|
|
|
|
|
2019-01-23 16:16:48 +00:00
|
|
|
|
Clone via SSH:
|
2019-01-17 22:07:07 +00:00
|
|
|
|
|
2019-01-23 16:16:48 +00:00
|
|
|
|
```bash
|
2019-09-18 18:06:14 +00:00
|
|
|
|
git clone git@gitlab.com:gitlab-org/gitlab.git
|
2019-01-17 22:07:07 +00:00
|
|
|
|
```
|
2019-01-23 16:16:48 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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
|
2019-01-23 16:16:48 +00:00
|
|
|
|
on it locally.
|
2019-01-17 22:07:07 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
### Switch to the master branch
|
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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.
|
2016-03-22 10:01:13 +00:00
|
|
|
|
|
2018-06-13 13:54:23 +00:00
|
|
|
|
```bash
|
2016-03-22 10:01:13 +00:00
|
|
|
|
git checkout master
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
### Download the latest changes in the project
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
To work on an up-to-date copy of the project (it is important to do this every time
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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.
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2019-08-21 09:17:47 +00:00
|
|
|
|
git pull <REMOTE> <name-of-branch>
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-08-21 09:17:47 +00:00
|
|
|
|
When you clone a repository, `REMOTE` is typically `origin`. This is where the
|
2019-07-30 05:02:59 +00:00
|
|
|
|
repository was cloned from, and it indicates the SSH or HTTPS URL of the repository
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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.
|
2019-08-21 09:17:47 +00:00
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
You can learn more on how Git manages remote repositories in the
|
|
|
|
|
[Git Remote documentation](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes).
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
### View your remote repositories
|
|
|
|
|
|
|
|
|
|
To view your remote repositories, type:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git remote -v
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
|
|
|
|
|
2019-08-26 20:31:04 +00:00
|
|
|
|
The `-v` flag stands for verbose.
|
2019-08-21 09:17:47 +00:00
|
|
|
|
|
2019-05-19 20:47:32 +00:00
|
|
|
|
### Add a remote repository
|
|
|
|
|
|
|
|
|
|
To add a link to a remote repository:
|
|
|
|
|
|
|
|
|
|
```bash
|
2019-07-30 05:02:59 +00:00
|
|
|
|
git remote add <source-name> <repository-path>
|
2019-05-19 20:47:32 +00:00
|
|
|
|
```
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
You'll use this source name every time you [push changes to GitLab.com](#send-changes-to-gitlabcom),
|
|
|
|
|
so use something easy to remember and type.
|
2019-05-19 20:47:32 +00:00
|
|
|
|
|
2016-03-22 10:01:13 +00:00
|
|
|
|
### Create a branch
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
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):
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2019-08-21 09:17:47 +00:00
|
|
|
|
git checkout -b <name-of-branch>
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
|
|
|
|
|
2018-06-13 13:54:23 +00:00
|
|
|
|
### Work on an existing branch
|
|
|
|
|
|
|
|
|
|
To switch to an existing branch, so you can work on it:
|
|
|
|
|
|
|
|
|
|
```bash
|
2019-07-30 05:02:59 +00:00
|
|
|
|
git checkout <name-of-branch>
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
### View the changes you've made
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2016-03-22 10:01:13 +00:00
|
|
|
|
git status
|
|
|
|
|
```
|
|
|
|
|
|
2018-06-13 13:54:23 +00:00
|
|
|
|
### View differences
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
To view the differences between your local, unstaged changes and the repository versions
|
|
|
|
|
that you cloned or pulled, type:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git diff
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
### Add and commit local changes
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
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:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2019-07-30 05:02:59 +00:00
|
|
|
|
git add <file-name OR folder-name>
|
2018-06-13 13:54:23 +00:00
|
|
|
|
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
### Add all changes to commit
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
To add and commit (save) all local changes quickly:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git add .
|
|
|
|
|
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
|
|
|
|
|
2018-06-13 13:54:23 +00:00
|
|
|
|
NOTE: **Note:**
|
2019-08-21 09:17:47 +00:00
|
|
|
|
The `.` character means _all file changes in the current directory and all subdirectories_.
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-05-19 20:47:32 +00:00
|
|
|
|
### Send changes to GitLab.com
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
NOTE: **Note:**
|
|
|
|
|
To create a merge request from a fork to an upstream repository, see the
|
|
|
|
|
[forking workflow](../user/project/repository/forking_workflow.md)
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
To push all local commits (saved changes) to the remote repository:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2019-07-30 05:02:59 +00:00
|
|
|
|
git push <remote> <name-of-branch>
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
For example, to push your local commits to the _`master`_ branch of the _`origin`_ remote:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git push origin master
|
2016-03-22 10:01:13 +00:00
|
|
|
|
```
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
### Delete all changes in the branch
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
To delete all local changes in the branch that have not been added to the staging
|
|
|
|
|
area, and leave unstaged files/folders, type:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2016-03-22 10:01:13 +00:00
|
|
|
|
git checkout .
|
|
|
|
|
```
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Note that this removes *changes* to files, not the files themselves.
|
2016-03-22 10:01:13 +00:00
|
|
|
|
|
2018-06-13 13:54:23 +00:00
|
|
|
|
### Unstage all changes that have been added to the staging area
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
To undo the most recently added, but not committed, changes to files/folders:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git reset .
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
### Undo most recent commit
|
|
|
|
|
|
|
|
|
|
To undo the most recent commit, type:
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git reset HEAD~1
|
|
|
|
|
```
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
This leaves the changed files and folders unstaged in your local repository.
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
CAUTION: **Warning:**
|
2019-11-14 18:06:15 +00:00
|
|
|
|
A Git commit should not usually be reversed, particularly if you already pushed it
|
2019-07-30 05:02:59 +00:00
|
|
|
|
to the remote repository. Although you can undo a commit, the best option is to avoid
|
|
|
|
|
the situation altogether by working carefully.
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
### Merge a branch with master branch
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
When you are ready to make all the changes in a branch a permanent addition to
|
|
|
|
|
the master branch, you `merge` the two together:
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
|
|
|
|
```bash
|
2019-07-30 05:02:59 +00:00
|
|
|
|
git checkout <name-of-branch>
|
2016-03-22 10:01:13 +00:00
|
|
|
|
git merge master
|
|
|
|
|
```
|
2016-07-21 16:49:40 +00:00
|
|
|
|
|
2019-11-27 09:06:29 +00:00
|
|
|
|
### Synchronize changes in a forked repository with the upstream
|
|
|
|
|
|
|
|
|
|
[Forking a repository](../user/project/repository/forking_workflow.md 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](#add-a-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](#download-the-latest-changes-in-the-project)
|
|
|
|
|
from the original repository, and use the `origin`
|
|
|
|
|
to [push local changes](#send-changes-to-gitlabcom) and create merge requests.
|
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
<!-- ## Troubleshooting
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
|
|
|
|
one might have when setting this up, or when something is changed, or on upgrading, it's
|
|
|
|
|
important to describe those, too. Think of things that may go wrong and include them here.
|
|
|
|
|
This is important to minimize requests for support, and to avoid doc comments with
|
|
|
|
|
questions that you know someone might ask.
|
2018-06-13 13:54:23 +00:00
|
|
|
|
|
2019-07-30 05:02:59 +00:00
|
|
|
|
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
|
|
|
|
If you have none to add when creating a doc, leave this section in place
|
|
|
|
|
but commented out to help encourage others to add to it in the future. -->
|