debian-mirror-gitlab/doc/gitlab-basics/start-using-git.md

493 lines
17 KiB
Markdown
Raw Normal View History

2019-10-12 21:52:04 +05:30
---
2020-10-24 23:57:45 +05:30
stage: Create
group: Source Code
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-10-12 21:52:04 +05:30
type: howto, tutorial
2020-05-24 23:13:21 +05:30
description: "Introduction to using Git through the command line."
2019-10-12 21:52:04 +05:30
---
2021-03-11 19:13:27 +05:30
# Start using Git on the command line **(FREE)**
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
[Git](https://git-scm.com/) is an open-source distributed version control system. GitLab is built
2020-05-24 23:13:21 +05:30
on top of Git.
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
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.
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
For a quick reference of Git commands, download a [Git Cheat Sheet](https://about.gitlab.com/images/press/git-cheat-sheet.pdf).
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
For more information about the advantages of working with Git and GitLab:
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>&nbsp;Watch the [GitLab Source Code Management Walkthrough](https://www.youtube.com/watch?v=wTQ3aXJswtM) video.
- Learn how [GitLab became the backbone of the Worldline](https://about.gitlab.com/customers/worldline/) development environment.
2020-06-23 00:09:42 +05:30
2021-09-04 01:27:46 +05:30
To help you visualize what you're doing locally, you can install a
[Git GUI app](https://git-scm.com/download/gui/).
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
## Git terminology
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
If you're familiar with Git terminology, you might want to skip this section and
go directly to [prerequisites](#prerequisites).
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
### Repository
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
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.
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
- A **remote repository** refers to the files in GitLab.
- A **local copy** refers to the files on your computer.
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
<!-- vale gitlab.Spelling = NO -->
<!-- vale gitlab.SubstitutionWarning = NO -->
Often, the word "repository" is shortened to "repo".
<!-- vale gitlab.Spelling = YES -->
<!-- vale gitlab.SubstitutionWarning = YES -->
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
In GitLab, a repository is contained in a **project**.
2020-05-24 23:13:21 +05:30
2021-09-04 01:27:46 +05:30
### Fork
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
When you want to contribute to someone else's repository, you make a copy of it.
This copy is called a [**fork**](../user/project/repository/forking_workflow.md#creating-a-fork).
The process is called "creating a fork."
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
When you fork a repo, you create a copy of the project in your own
[namespace](../user/group/#namespaces). You then have write permissions to modify the project files
and settings.
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
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
`https://gitlab.com/your-namespace/sample-project/`.
Then you can clone the repository to your local machine, work on the files, and submit changes back to the
original repository.
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
### Difference between download and clone
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
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.
2020-05-24 23:13:21 +05:30
2021-09-04 01:27:46 +05:30
[Cloning](#clone-a-repository) 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.
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
### Pull and push
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
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
[`git push`](#send-changes-to-gitlabcom).
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
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
[`git pull`](#download-the-latest-changes-in-the-project).
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
## Prerequisites
2015-09-11 14:41:01 +05:30
2021-09-04 01:27:46 +05:30
To start using GitLab with Git, complete the following tasks:
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
- Create and sign in to a GitLab account.
- [Open a terminal](#open-a-terminal).
- [Install Git](#install-git) on your computer.
- [Configure Git](#configure-git).
- [Choose a repository](#choose-a-repository).
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
### Open a terminal
2020-05-24 23:13:21 +05:30
2021-09-04 01:27:46 +05:30
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:
2020-05-24 23:13:21 +05:30
2021-09-04 01:27:46 +05:30
- For macOS users:
- Built-in [Terminal](https://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line). Press <kbd>⌘ command</kbd> + <kbd>space</kbd> and type `terminal`.
- [iTerm2](https://iterm2.com/). You can integrate it with [zsh](https://git-scm.com/book/id/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Zsh) and [oh my zsh](https://ohmyz.sh/) for color highlighting and other advanced features.
- For Windows users:
- Built-in command line. On the Windows taskbar, select the search icon and type `cmd`.
- [PowerShell](https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/install/installing-windows-powershell?view=powershell-7).
- Git Bash. It is built into [Git for Windows](https://gitforwindows.org/).
- For Linux users:
- Built-in [Linux Terminal](https://ubuntu.com/tutorials/command-line-for-beginners#3-opening-a-terminal).
2016-06-02 11:05:42 +05:30
2021-09-04 01:27:46 +05:30
### Install Git
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
Determine if Git is already installed on your computer by opening a terminal
and running this command:
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
```shell
git --version
```
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
If Git is installed, the output is:
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
```shell
git version X.Y.Z
```
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
If your computer doesn't recognize `git` as a command, you must [install Git](../topics/git/how_to_install_git/index.md).
After you install Git, run `git --version` to confirm that it installed correctly.
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
### Configure Git
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
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.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
1. In your shell, add your user name:
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
```shell
git config --global user.name "your_username"
```
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
1. Add your email address:
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
```shell
git config --global user.email "your_email_address@example.com"
```
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
1. To check the configuration, run:
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
```shell
git config --global --list
```
2021-04-17 20:07:23 +05:30
2021-09-04 01:27:46 +05:30
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 applies only to the current
repository.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
You can read more on how Git manages configurations in the
[Git configuration documentation](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration).
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
### Choose a repository
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
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.
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
To use the repository in the examples on this page:
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
1. Go to [https://gitlab.com/gitlab-tests/sample-project/](https://gitlab.com/gitlab-tests/sample-project/).
1. In the top right, select **Fork**.
1. Choose a namespace for your fork.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
The project becomes available at `https://gitlab.com/<your-namespace>/sample-project/`.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
You can [fork](../user/project/repository/forking_workflow.md#creating-a-fork) any project you have access to.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
## Clone a repository
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
When you clone a repository, the files from the remote repository are downloaded to your computer,
and a connection is created.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
### Clone with SSH
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
Clone with SSH when you want to authenticate only one time.
2020-07-28 23:09:34 +05:30
2021-09-30 23:02:18 +05:30
1. Authenticate with GitLab by following the instructions in the [SSH documentation](../ssh/index.md).
2021-09-04 01:27:46 +05:30
1. Go to your project's landing page and select **Clone**. Copy the URL for **Clone with SSH**.
1. 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.
1. Run this command:
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
```shell
git clone git@gitlab.com:gitlab-tests/sample-project.git
```
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
1. To view the files, go to the new directory:
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
```shell
cd sample-project
```
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
You can also
[clone a repository and open it directly in Visual Studio Code](../user/project/repository/index.md#clone-and-open-in-visual-studio-code).
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
### Clone with HTTPS
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
Clone with HTTPS when you want to authenticate each time you perform an operation
between your computer and GitLab.
2020-05-24 23:13:21 +05:30
2021-09-04 01:27:46 +05:30
1. Go to your project's landing page and select **Clone**. Copy the URL for **Clone with HTTPS**.
1. Open a terminal and go to the directory where you want to clone the files.
1. Run the following command. Git automatically creates a folder with the repository name and downloads the files there.
```shell
git clone https://gitlab.com/gitlab-tests/sample-project.git
```
2020-05-24 23:13:21 +05:30
2021-09-04 01:27:46 +05:30
1. GitLab requests your username and password:
- If you have 2FA enabled for your account, you must use a [Personal Access Token](../user/profile/personal_access_tokens.md)
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.
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
1. To view the files, go to the new directory:
2019-03-02 22:35:43 +05:30
2021-09-04 01:27:46 +05:30
```shell
cd sample-project
```
2019-03-02 22:35:43 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2021-09-04 01:27:46 +05:30
On Windows, if you enter your password incorrectly multiple times and an `Access denied` message appears,
add your namespace (username or group) to the path:
2020-05-24 23:13:21 +05:30
`git clone https://namespace@gitlab.com/gitlab-org/gitlab.git`.
2020-07-28 23:09:34 +05:30
### Convert a local directory into a repository
2019-10-12 21:52:04 +05:30
2021-09-04 01:27:46 +05:30
You can initialize a local folder so Git tracks it as a repository.
2016-06-02 11:05:42 +05:30
2021-09-04 01:27:46 +05:30
1. Open the terminal in the directory you'd like to convert.
1. Run this command:
2016-06-02 11:05:42 +05:30
2021-09-04 01:27:46 +05:30
```shell
git init
```
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
A `.git` folder is created in your directory. This folder contains Git
records and configuration files. You should not edit these files
directly.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
1. Add the [path to your remote repository](#add-a-remote)
so Git can upload your files into the correct project.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
#### Add a remote
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
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.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
To add a remote to your local copy:
1. In GitLab, [create a project](../user/project/working_with_projects.md#create-a-project) to hold your files.
2020-07-28 23:09:34 +05:30
1. Visit this project's homepage, scroll down to **Push an existing folder**, and copy the command that starts with `git remote add`.
1. On your computer, open the terminal in the directory you've initialized, paste the command you copied, and press <kbd>enter</kbd>:
```shell
2021-02-22 17:27:13 +05:30
git remote add origin git@gitlab.com:username/projectpath.git
2020-07-28 23:09:34 +05:30
```
After you've done that, you can [stage your files](#add-and-commit-local-changes) and [upload them to GitLab](#send-changes-to-gitlabcom).
2021-09-04 01:27:46 +05:30
#### View your remote repositories
To view your remote repositories, type:
```shell
git remote -v
```
The `-v` flag stands for verbose.
2016-06-02 11:05:42 +05:30
### Download the latest changes in the project
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
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 `<name-of-branch>`
with the name of your [default branch](../user/project/repository/branches/default.md)
to get the main branch code, or replace it with the branch name of the branch
2020-01-01 13:55:28 +05:30
you are currently working in.
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-12-04 20:38:33 +05:30
git pull <REMOTE> <name-of-branch>
2016-06-02 11:05:42 +05:30
```
2018-11-08 19:23:39 +05:30
2019-12-04 20:38:33 +05:30
When you clone a repository, `REMOTE` is typically `origin`. This is where the
2019-10-12 21:52:04 +05:30
repository was cloned from, and it indicates the SSH or HTTPS URL of the repository
2021-09-04 01:27:46 +05:30
on the remote server. `<name-of-branch>` is usually the name of your
[default branch](../user/project/repository/branches/default.md), but it may be any
2020-01-01 13:55:28 +05:30
existing branch. You can create additional named remotes and branches as necessary.
2019-12-04 20:38:33 +05:30
2020-01-01 13:55:28 +05:30
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-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
## Branches
2019-12-04 20:38:33 +05:30
2021-09-04 01:27:46 +05:30
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, `main`.
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
Use branches when you:
2019-09-04 21:01:54 +05:30
2021-09-04 01:27:46 +05:30
- 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.
2019-09-04 21:01:54 +05:30
2021-01-03 14:25:43 +05:30
A new branch is often called **feature branch** to differentiate from the
2021-09-04 01:27:46 +05:30
[default branch](../user/project/repository/branches/default.md).
2021-01-03 14:25:43 +05:30
2016-06-02 11:05:42 +05:30
### Create a branch
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
To create a feature branch:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-12-04 20:38:33 +05:30
git checkout -b <name-of-branch>
2016-06-02 11:05:42 +05:30
```
2021-09-04 01:27:46 +05:30
Branch names cannot contain empty spaces and special characters. Use only lowercase letters, numbers,
hyphens (`-`), and underscores (`_`).
2021-01-03 14:25:43 +05:30
2021-09-04 01:27:46 +05:30
### Switch to a branch
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
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.
2020-07-28 23:09:34 +05:30
2021-09-04 01:27:46 +05:30
To switch to an existing branch:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-10-12 21:52:04 +05:30
git checkout <name-of-branch>
2016-06-02 11:05:42 +05:30
```
2021-09-04 01:27:46 +05:30
For example, to change to the `main` branch:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-09-04 01:27:46 +05:30
git checkout main
2016-06-02 11:05:42 +05:30
```
2018-11-08 19:23:39 +05:30
### View differences
2021-09-04 01:27:46 +05:30
To view the differences between your local unstaged changes and the latest version
that you cloned or pulled:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2018-11-08 19:23:39 +05:30
git diff
```
2021-09-04 01:27:46 +05:30
### View the files that have changes
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
When you add, change, or delete files or folders, Git knows about the changes.
To check which files have been changed:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-09-04 01:27:46 +05:30
git status
2016-06-02 11:05:42 +05:30
```
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
### Add and commit local changes
When you type `git status`, locally changed files are shown in red. These changes may
be new, modified, or deleted files or folders.
1. To stage a file for commit:
```shell
git add <file-name OR folder-name>
```
1. 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 .`.
1. Confirm that the files have been added to staging:
```shell
git status
```
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
The files should be displayed in green text.
1. To commit the staged files:
```shell
git commit -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
```
#### Stage and commit all changes
As a shortcut, you can add all local changes to staging and commit them with one command:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-09-04 01:27:46 +05:30
git commit -a -m "COMMENT TO DESCRIBE THE INTENTION OF THE COMMIT"
2016-06-02 11:05:42 +05:30
```
2019-09-04 21:01:54 +05:30
### Send changes to GitLab.com
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
To push all local changes to the remote repository:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-10-12 21:52:04 +05:30
git push <remote> <name-of-branch>
2016-06-02 11:05:42 +05:30
```
2021-09-04 01:27:46 +05:30
For example, to push your local commits to the `main` branch of the `origin` remote:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-09-04 01:27:46 +05:30
git push origin main
2016-06-02 11:05:42 +05:30
```
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
Sometimes Git does not allow you to push to a repository. Instead,
2021-04-17 20:07:23 +05:30
you must [force an update](../topics/git/git_rebase.md#force-push).
2021-01-03 14:25:43 +05:30
2019-10-12 21:52:04 +05:30
### Delete all changes in the branch
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
To discard all changes to tracked files:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2016-06-02 11:05:42 +05:30
git checkout .
```
2021-09-04 01:27:46 +05:30
This action removes *changes* to files, not the files themselves.
Untracked (new) files do not change.
2016-06-02 11:05:42 +05:30
2018-11-08 19:23:39 +05:30
### Unstage all changes that have been added to the staging area
2021-09-04 01:27:46 +05:30
To unstage (remove) all files that have not been committed:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-09-04 01:27:46 +05:30
git reset
2018-11-08 19:23:39 +05:30
```
### Undo most recent commit
2021-09-04 01:27:46 +05:30
To undo the most recent commit:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2018-11-08 19:23:39 +05:30
git reset HEAD~1
```
2021-09-04 01:27:46 +05:30
This action leaves the changed files and folders unstaged in your local repository.
2018-11-08 19:23:39 +05:30
2021-02-22 17:27:13 +05:30
WARNING:
2021-09-04 01:27:46 +05:30
A Git commit should not be reversed if you already pushed it
2019-10-12 21:52:04 +05:30
to the remote repository. Although you can undo a commit, the best option is to avoid
the situation altogether by working carefully.
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
You can learn more about the different ways Git can undo changes in the
[Git Undoing Things documentation](https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things).
2018-11-08 19:23:39 +05:30
2021-09-04 01:27:46 +05:30
### Merge a branch with default branch
When you are ready to add your changes to
2021-10-27 15:23:28 +05:30
the default branch, you merge the feature branch into it:
2018-11-08 19:23:39 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-10-27 15:23:28 +05:30
git checkout <default-branch>
git merge <feature-branch>
2016-06-02 11:05:42 +05:30
```
2016-09-13 17:45:13 +05:30
2021-09-04 01:27:46 +05:30
In GitLab, you typically use a [merge request](../user/project/merge_requests/) 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](../user/project/repository/forking_workflow.md).
2021-01-03 14:25:43 +05:30
## Advanced use of Git through the command line
For an introduction of more advanced Git techniques, see [Git rebase, force-push, and merge conflicts](../topics/git/git_rebase.md).
2020-07-28 23:09:34 +05:30
## Synchronize changes in a forked repository with the upstream
2020-01-01 13:55:28 +05:30
2021-09-04 01:27:46 +05:30
To create a copy of a repository in your namespace, you [fork it](../user/project/repository/forking_workflow.md).
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.
2020-01-01 13:55:28 +05:30
2021-09-04 01:27:46 +05:30
You must [create a link to the remote repository](#add-a-remote) to pull
changes from the original repository. It is common to call this remote repository the `upstream`.
2020-01-01 13:55:28 +05:30
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-10-12 21:52:04 +05:30
<!-- ## Troubleshooting
2018-11-08 19:23:39 +05:30
2019-10-12 21:52:04 +05:30
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-11-08 19:23:39 +05:30
2019-10-12 21:52:04 +05:30
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. -->