Merge branch 'docs/ssot-git-topics' into 'master'
SSoT audit fixes for some topics in git section Closes #61512 See merge request gitlab-org/gitlab-ce!28966
This commit is contained in:
commit
ccdd66d035
|
@ -5,14 +5,20 @@ level: beginner
|
|||
article_type: user guide
|
||||
date: 2017-05-15
|
||||
description: 'This article describes how to install Git on macOS, Ubuntu Linux and Windows.'
|
||||
type: howto
|
||||
last_updated: 2019-05-31
|
||||
---
|
||||
|
||||
# Installing Git
|
||||
|
||||
To begin contributing to GitLab projects
|
||||
To begin contributing to GitLab projects,
|
||||
you will need to install the Git client on your computer.
|
||||
|
||||
This article will show you how to install Git on macOS, Ubuntu Linux and Windows.
|
||||
|
||||
Information on [installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
|
||||
is also available at the official Git website.
|
||||
|
||||
## Install Git on macOS using the Homebrew package manager
|
||||
|
||||
Although it is easy to use the version of Git shipped with macOS
|
||||
|
@ -21,7 +27,7 @@ we recommend installing it via Homebrew to get access to
|
|||
an extensive selection of dependency managed libraries and applications.
|
||||
|
||||
If you are sure you don't need access to any additional development libraries
|
||||
or don't have approximately 15gb of available disk space for Xcode and Homebrew
|
||||
or don't have approximately 15gb of available disk space for Xcode and Homebrew,
|
||||
use one of the aforementioned methods.
|
||||
|
||||
### Installing Xcode
|
||||
|
@ -40,11 +46,12 @@ for the official Homebrew installation instructions.
|
|||
With Homebrew installed you are now ready to install Git.
|
||||
Open a Terminal and enter in the following command:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
brew install git
|
||||
```
|
||||
|
||||
Congratulations you should now have Git installed via Homebrew.
|
||||
|
||||
Next read our article on [adding an SSH key to GitLab](../../../ssh/README.md).
|
||||
|
||||
## Install Git on Ubuntu Linux
|
||||
|
@ -55,16 +62,30 @@ it is recommended to use the built in package manager to install Git.
|
|||
Open a Terminal and enter in the following commands
|
||||
to install the latest Git from the official Git maintained package archives:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
sudo apt-add-repository ppa:git-core/ppa
|
||||
sudo apt-get update
|
||||
sudo apt-get install git
|
||||
```
|
||||
|
||||
Congratulations you should now have Git installed via the Ubuntu package manager.
|
||||
|
||||
Next read our article on [adding an SSH key to GitLab](../../../ssh/README.md).
|
||||
|
||||
## Installing Git on Windows from the Git website
|
||||
|
||||
Browse to the [Git website](https://git-scm.com/) and download and install Git for Windows.
|
||||
|
||||
Next read our article on [adding an SSH key to GitLab](../../../ssh/README.md).
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
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.
|
||||
|
||||
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. -->
|
||||
|
|
|
@ -1,8 +1,12 @@
|
|||
# Git documentation
|
||||
---
|
||||
type: index
|
||||
---
|
||||
|
||||
# Git
|
||||
|
||||
Git is a [free and open source](https://git-scm.com/about/free-and-open-source)
|
||||
distributed version control system designed to handle everything from small to
|
||||
very large projects with speed and efficiency.
|
||||
large projects with speed and efficiency.
|
||||
|
||||
[GitLab](https://about.gitlab.com) is a Git-based fully integrated platform for
|
||||
software development. Besides Git's functionalities, GitLab has a lot of
|
||||
|
@ -11,64 +15,71 @@ powerful [features](https://about.gitlab.com/features/) to enhance your
|
|||
|
||||
We've gathered some resources to help you to get the best from Git with GitLab.
|
||||
|
||||
More information is also available on the [Git website](https://git-scm.com).
|
||||
|
||||
## Getting started
|
||||
|
||||
- [Git concepts](../../university/training/user_training.md#git-concepts)
|
||||
The following resources will help you get started with Git:
|
||||
|
||||
- [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics)
|
||||
- [Git on the Server - GitLab](https://git-scm.com/book/en/v2/Git-on-the-Server-GitLab)
|
||||
- [How to install Git](how_to_install_git/index.md)
|
||||
- [Start using Git on the command line](../../gitlab-basics/start-using-git.md)
|
||||
- [Command Line basic commands](../../gitlab-basics/command-line-commands.md)
|
||||
- [GitLab Git Cheat Sheet (download)](https://about.gitlab.com/images/press/git-cheat-sheet.pdf)
|
||||
- Commits
|
||||
- [Revert a commit](../../user/project/merge_requests/revert_changes.md#reverting-a-commit)
|
||||
- Commits:
|
||||
- [Revert a commit](../../user/project/merge_requests/revert_changes.md#reverting-a-commit)
|
||||
- [Cherry-picking a commit](../../user/project/merge_requests/cherry_pick_changes.md#cherry-picking-a-commit)
|
||||
- [Squashing commits](../../workflow/gitlab_flow.md#squashing-commits-with-rebase)
|
||||
|
||||
**Third-party references:**
|
||||
|
||||
- [Getting Started - Git website](https://git-scm.com)
|
||||
- [Getting Started - Version control](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)
|
||||
- [Getting Started - Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics)
|
||||
- [Getting Started - Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
|
||||
- [Git on the Server - GitLab](https://git-scm.com/book/en/v2/Git-on-the-Server-GitLab)
|
||||
|
||||
### Concepts
|
||||
|
||||
- Article (2017-05-17): [Why Git is Worth the Learning Curve](https://about.gitlab.com/2017/05/17/learning-curve-is-the-biggest-challenge-developers-face-with-git/)
|
||||
- Article (2016-05-11): [The future of SaaS hosted Git repository pricing](https://about.gitlab.com/2016/05/11/git-repository-pricing/)
|
||||
- GLU Course (Presentation): [About Version Control](https://docs.google.com/presentation/d/16sX7hUrCZyOFbpvnrAFrg6tVO5_yT98IgdAqOmXwBho/edit?usp=sharing)
|
||||
The following are resources about version control concepts:
|
||||
|
||||
## Exploring Git
|
||||
- [Git concepts](../../university/training/user_training.md#git-concepts)
|
||||
- [Why Git is Worth the Learning Curve](https://about.gitlab.com/2017/05/17/learning-curve-is-the-biggest-challenge-developers-face-with-git/)
|
||||
- [The future of SaaS hosted Git repository pricing](https://about.gitlab.com/2016/05/11/git-repository-pricing/)
|
||||
- [Git website topic about version control](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)
|
||||
- [GitLab University presentation about Version Control](https://docs.google.com/presentation/d/16sX7hUrCZyOFbpvnrAFrg6tVO5_yT98IgdAqOmXwBho/edit?usp=sharing)
|
||||
|
||||
## Git tips
|
||||
|
||||
The following resources may help you become more efficient at using Git:
|
||||
|
||||
- [Git Tips & Tricks](https://about.gitlab.com/2016/12/08/git-tips-and-tricks/)
|
||||
- [Eight Tips to help you work better with Git](https://about.gitlab.com/2015/02/19/8-tips-to-help-you-work-better-with-git/)
|
||||
|
||||
## Troubleshooting Git
|
||||
|
||||
If you have problems with Git, the following may help:
|
||||
|
||||
- [Numerous _undo_ possibilities in Git](numerous_undo_possibilities_in_git/index.md)
|
||||
- Learn a few [Git troubleshooting](troubleshooting_git.md) techniques to help you out.
|
||||
- Learn a few [Git troubleshooting](troubleshooting_git.md) techniques
|
||||
|
||||
## Branching strategies
|
||||
|
||||
- [GitLab Flow](https://about.gitlab.com/2014/09/29/gitlab-flow/)
|
||||
|
||||
**Third-party references:**
|
||||
|
||||
- [Git Branching - Branches in a Nutshell](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)
|
||||
- [Git Branching - Branching Workflows](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows)
|
||||
- [GitLab Flow](https://about.gitlab.com/2014/09/29/gitlab-flow/)
|
||||
|
||||
## Advanced use
|
||||
|
||||
The following are advanced topics for those who want to get the most out of Git:
|
||||
|
||||
- [Custom Git Hooks](../../administration/custom_hooks.md)
|
||||
- [Git Attributes](../../user/project/git_attributes.md)
|
||||
- Git Submodules: [Using Git submodules with GitLab CI](../../ci/git_submodules.md#using-git-submodules-with-gitlab-ci)
|
||||
|
||||
## API
|
||||
|
||||
- [Gitignore templates](../../api/templates/gitignores.md)
|
||||
[Gitignore templates](../../api/templates/gitignores.md) API allow for
|
||||
Git-related queries from GitLab.
|
||||
|
||||
## Git LFS
|
||||
|
||||
The following relate to Git Large File Storage:
|
||||
|
||||
- [Getting Started with Git LFS](https://about.gitlab.com/2017/01/30/getting-started-with-git-lfs-tutorial/)
|
||||
- [GitLab Git LFS documentation](../../workflow/lfs/manage_large_binaries_with_git_lfs.md)
|
||||
- [Git-Annex to Git-LFS migration guide](../../workflow/lfs/migrate_from_git_annex_to_git_lfs.md)
|
||||
- Article (2015-08-13): [Towards a production quality open source Git LFS server](https://about.gitlab.com/2015/08/13/towards-a-production-quality-open-source-git-lfs-server/)
|
||||
- [Towards a production quality open source Git LFS server](https://about.gitlab.com/2015/08/13/towards-a-production-quality-open-source-git-lfs-server/)
|
||||
|
|
|
@ -4,25 +4,30 @@ author_gitlab: Letme
|
|||
level: intermediary
|
||||
article_type: tutorial
|
||||
date: 2017-05-15
|
||||
type: howto
|
||||
last_updated: 2019-05-31
|
||||
---
|
||||
|
||||
# Numerous undo possibilities in Git
|
||||
|
||||
## Introduction
|
||||
|
||||
In this tutorial, we will show you different ways of undoing your work in Git, for which
|
||||
we will assume you have a basic working knowledge of. Check GitLab's
|
||||
[Git documentation](../index.md#git-documentation) for reference.
|
||||
[Git documentation](../index.md) for reference.
|
||||
|
||||
Also, we will only provide some general info of the commands, which is enough
|
||||
to get you started for the easy cases/examples, but for anything more advanced please refer to the [Git book](https://git-scm.com/book/en/v2).
|
||||
to get you started for the easy cases/examples, but for anything more advanced
|
||||
please refer to the [Git book](https://git-scm.com/book/en/v2).
|
||||
|
||||
We will explain a few different techniques to undo your changes based on the stage
|
||||
of the change in your current development. Also, keep in mind that [nothing in
|
||||
Git is really deleted.][git-autoclean-ref]
|
||||
Git is really deleted][git-autoclean-ref].
|
||||
|
||||
This means that until Git automatically cleans detached commits (which cannot be
|
||||
accessed by branch or tag) it will be possible to view them with `git reflog` command
|
||||
and access them with direct commit-id. Read more about _[redoing the undo](#redoing-the-undo)_ on the section below.
|
||||
|
||||
## Introduction
|
||||
|
||||
This guide is organized depending on the [stage of development][git-basics]
|
||||
where you want to undo your changes from and if they were shared with other developers
|
||||
or not. Because Git is tracking changes a created or edited file is in the unstaged state
|
||||
|
@ -31,35 +36,41 @@ a file into the **staged** state, which is then committed (`git commit`) to your
|
|||
local repository. After that, file can be shared with other developers (`git push`).
|
||||
Here's what we'll cover in this tutorial:
|
||||
|
||||
- [Undo local changes](#undo-local-changes) which were not pushed to remote repository
|
||||
- [Undo local changes](#undo-local-changes) which were not pushed to remote repository:
|
||||
|
||||
- Before you commit, in both unstaged and staged state
|
||||
- After you committed
|
||||
- Before you commit, in both unstaged and staged state.
|
||||
- After you committed.
|
||||
|
||||
- Undo changes after they are pushed to remote repository
|
||||
- Undo changes after they are pushed to remote repository:
|
||||
|
||||
- [Without history modification](#undo-remote-changes-without-changing-history) (preferred way)
|
||||
- [With history modification](#undo-remote-changes-with-modifying-history) (requires
|
||||
coordination with team and force pushes).
|
||||
- [Usecases when modifying history is generally acceptable](#where-modifying-history-is-generally-acceptable)
|
||||
- [How to modify history](#how-modifying-history-is-done)
|
||||
- [How to remove sensitive information from repository](#deleting-sensitive-information-from-commits)
|
||||
- [Without history modification](#undo-remote-changes-without-changing-history) (preferred way).
|
||||
- [With history modification](#undo-remote-changes-with-modifying-history) (requires
|
||||
coordination with team and force pushes).
|
||||
- [Use cases when modifying history is generally acceptable](#where-modifying-history-is-generally-acceptable).
|
||||
- [How to modify history](#how-modifying-history-is-done).
|
||||
- [How to remove sensitive information from repository](#deleting-sensitive-information-from-commits).
|
||||
|
||||
### Branching strategy
|
||||
|
||||
[Git][git-official] is a de-centralized version control system, which means that beside regular
|
||||
versioning of the whole repository, it has possibilities to exchange changes
|
||||
with other repositories. To avoid chaos with
|
||||
with other repositories.
|
||||
|
||||
To avoid chaos with
|
||||
[multiple sources of truth][git-distributed], various
|
||||
development workflows have to be followed, and it depends on your internal
|
||||
workflow how certain changes or commits can be undone or changed.
|
||||
|
||||
[GitLab Flow][gitlab-flow] provides a good
|
||||
balance between developers clashing with each other while
|
||||
developing the same feature and cooperating seamlessly, but it does not enable
|
||||
joined development of the same feature by multiple developers by default.
|
||||
|
||||
When multiple developers develop the same feature on the same branch, clashing
|
||||
with every synchronization is unavoidable, but a proper or chosen Git Workflow will
|
||||
prevent that anything is lost or out of sync when feature is complete. You can also
|
||||
prevent that anything is lost or out of sync when feature is complete.
|
||||
|
||||
You can also
|
||||
read through this blog post on [Git Tips & Tricks][gitlab-git-tips-n-tricks]
|
||||
to learn how to easily **do** things in Git.
|
||||
|
||||
|
@ -97,19 +108,19 @@ no changes added to commit (use "git add" and/or "git commit -a")
|
|||
|
||||
At this point there are 3 options to undo the local changes you have:
|
||||
|
||||
- Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes)
|
||||
- Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes):
|
||||
|
||||
```shell
|
||||
git stash
|
||||
```
|
||||
|
||||
- Discarding local changes (permanently) to a file
|
||||
- Discarding local changes (permanently) to a file:
|
||||
|
||||
```shell
|
||||
git checkout -- <file>
|
||||
```
|
||||
|
||||
- Discard all local changes to all files permanently
|
||||
- Discard all local changes to all files permanently:
|
||||
|
||||
```shell
|
||||
git reset --hard
|
||||
|
@ -150,7 +161,7 @@ of the staging tree. You also have an option to discard all changes with
|
|||
Lets start the example by editing a file, with your favorite editor, to change the
|
||||
content and add it to staging
|
||||
|
||||
```
|
||||
```sh
|
||||
vim <file>
|
||||
git add <file>
|
||||
```
|
||||
|
@ -164,30 +175,30 @@ Your branch is up-to-date with 'origin/master'.
|
|||
Changes to be committed:
|
||||
(use "git reset HEAD <file>..." to unstage)
|
||||
|
||||
new file: <file>
|
||||
new file: <file>
|
||||
```
|
||||
|
||||
Now you have 4 options to undo your changes:
|
||||
|
||||
- Unstage the file to current commit (HEAD)
|
||||
- Unstage the file to current commit (HEAD):
|
||||
|
||||
```shell
|
||||
git reset HEAD <file>
|
||||
```
|
||||
|
||||
- Unstage everything - retain changes
|
||||
- Unstage everything - retain changes:
|
||||
|
||||
```shell
|
||||
git reset
|
||||
```
|
||||
|
||||
- Discard all local changes, but save them for [later](#quickly-save-local-changes)
|
||||
- Discard all local changes, but save them for [later](#quickly-save-local-changes):
|
||||
|
||||
```shell
|
||||
git stash
|
||||
```
|
||||
|
||||
- Discard everything permanently
|
||||
- Discard everything permanently:
|
||||
|
||||
```shell
|
||||
git reset --hard
|
||||
|
@ -206,7 +217,9 @@ your code, you'll have less options to troubleshoot your work.
|
|||
Through the development process some of the previously committed changes do not
|
||||
fit anymore in the end solution, or are source of the bugs. Once you find the
|
||||
commit which triggered bug, or once you have a faulty commit, you can simply
|
||||
revert it with `git revert commit-id`. This command inverts (swaps) the additions and
|
||||
revert it with `git revert commit-id`.
|
||||
|
||||
This command inverts (swaps) the additions and
|
||||
deletions in that commit, so that it does not modify history. Retaining history
|
||||
can be helpful in future to notice that some changes have been tried
|
||||
unsuccessfully in the past.
|
||||
|
@ -225,19 +238,19 @@ through simple bisection process. You can read more about it [in official Git To
|
|||
In our example we will end up with commit `B`, that introduced bug/error. We have
|
||||
4 options on how to remove it (or part of it) from our repository.
|
||||
|
||||
- Undo (swap additions and deletions) changes introduced by commit `B`.
|
||||
- Undo (swap additions and deletions) changes introduced by commit `B`:
|
||||
|
||||
```shell
|
||||
git revert commit-B-id
|
||||
```
|
||||
|
||||
- Undo changes on a single file or directory from commit `B`, but retain them in the staged state
|
||||
- Undo changes on a single file or directory from commit `B`, but retain them in the staged state:
|
||||
|
||||
```shell
|
||||
git checkout commit-B-id <file>
|
||||
```
|
||||
|
||||
- Undo changes on a single file or directory from commit `B`, but retain them in the unstaged state
|
||||
- Undo changes on a single file or directory from commit `B`, but retain them in the unstaged state:
|
||||
|
||||
```shell
|
||||
git reset commit-B-id <file>
|
||||
|
@ -246,7 +259,9 @@ In our example we will end up with commit `B`, that introduced bug/error. We hav
|
|||
- There is one command we also must not forget: **creating a new branch**
|
||||
from the point where changes are not applicable or where the development has hit a
|
||||
dead end. For example you have done commits `A-B-C-D` on your feature-branch
|
||||
and then you figure `C` and `D` are wrong. At this point you either reset to `B`
|
||||
and then you figure `C` and `D` are wrong.
|
||||
|
||||
At this point you either reset to `B`
|
||||
and do commit `F` (which will cause problems with pushing and if forced pushed also with other developers)
|
||||
since branch now looks `A-B-F`, which clashes with what other developers have locally (you will
|
||||
[change history](#with-history-modification)), or you simply checkout commit `B` create
|
||||
|
@ -269,13 +284,13 @@ In our example we will end up with commit `B`, that introduced bug/error. We hav
|
|||
There is one command for history modification and that is `git rebase`. Command
|
||||
provides interactive mode (`-i` flag) which enables you to:
|
||||
|
||||
- **reword** commit messages (there is also `git commit --amend` for editing
|
||||
last commit message)
|
||||
- **edit** the commit content (changes introduced by commit) and message
|
||||
- **squash** multiple commits into a single one, and have a custom or aggregated
|
||||
commit message
|
||||
- **drop** commits - simply delete them
|
||||
- and few more options
|
||||
- **reword** commit messages (there is also `git commit --amend` for editing
|
||||
last commit message).
|
||||
- **edit** the commit content (changes introduced by commit) and message.
|
||||
- **squash** multiple commits into a single one, and have a custom or aggregated
|
||||
commit message.
|
||||
- **drop** commits - simply delete them.
|
||||
- and few more options.
|
||||
|
||||
Let us check few examples. Again there are commits `A-B-C-D` where you want to
|
||||
delete commit `B`.
|
||||
|
@ -301,7 +316,7 @@ In case you want to modify something introduced in commit `B`.
|
|||
|
||||
- Command opens your favorite text editor where you write `edit` in front of commit
|
||||
`B`, but leave default `pick` with all other commits. Save and exit the editor to
|
||||
perform a rebase
|
||||
perform a rebase.
|
||||
|
||||
- Now do your edits and commit changes:
|
||||
|
||||
|
@ -348,7 +363,9 @@ and then on end description of that action.
|
|||
This topic is roughly same as modifying committed local changes without modifying
|
||||
history. **It should be the preferred way of undoing changes on any remote repository
|
||||
or public branch.** Keep in mind that branching is the best solution when you want
|
||||
to retain the history of faulty development, yet start anew from certain point. Branching
|
||||
to retain the history of faulty development, yet start anew from certain point.
|
||||
|
||||
Branching
|
||||
enables you to include the existing changes in new development (by merging) and
|
||||
it also provides a clear timeline and development structure.
|
||||
|
||||
|
@ -386,12 +403,14 @@ the cleanup of detached commits (happens automatically).
|
|||
Modified history breaks the development chain of other developers, as changed
|
||||
history does not have matching commits'ids. For that reason it should not
|
||||
be used on any public branch or on branch that *might* be used by other
|
||||
developers. When contributing to big open source repositories (e.g. [GitLab CE][gitlab-ce]),
|
||||
developers. When contributing to big open source repositories (for example, [GitLab CE][gitlab-ce]),
|
||||
it is acceptable to *squash* commits into a single one, to present
|
||||
a nicer history of your contribution.
|
||||
|
||||
Keep in mind that this also removes the comments attached to certain commits
|
||||
in merge requests, so if you need to retain traceability in GitLab, then
|
||||
modifying history is not acceptable.
|
||||
|
||||
A feature-branch of a merge request is a public branch and might be used by
|
||||
other developers, but project process and rules might allow or require
|
||||
you to use `git rebase` (command that changes history) to reduce number of
|
||||
|
@ -400,8 +419,8 @@ GitLab). There is a `git merge --squash` command which does exactly that
|
|||
(squashes commits on feature-branch to a single commit on target branch
|
||||
at merge).
|
||||
|
||||
>**Note:**
|
||||
Never modify the commit history of `master` or shared branch
|
||||
NOTE: **Note:**
|
||||
Never modify the commit history of `master` or shared branch.
|
||||
|
||||
### How modifying history is done
|
||||
|
||||
|
@ -436,7 +455,7 @@ pick <commit3-id> <commit3-commit-message>
|
|||
# Note that empty commits are commented out
|
||||
```
|
||||
|
||||
>**Note:**
|
||||
NOTE: **Note:**
|
||||
It is important to notice that comment from the output clearly states that, if
|
||||
you decide to abort, then do not just close your editor (as that will in-fact
|
||||
modify history), but remove all uncommented lines and save.
|
||||
|
@ -470,7 +489,7 @@ tools that can use some of Git specifics to enable faster execution of common
|
|||
tasks (which is exactly what removing sensitive information file is about).
|
||||
An alternative is [BFG Repo-cleaner][bfg-repo-cleaner]. Keep in mind that these
|
||||
tools are faster because they do not provide a same fully feature set as `git filter-branch`
|
||||
does, but focus on specific usecases.
|
||||
does, but focus on specific use cases.
|
||||
|
||||
## Conclusion
|
||||
|
||||
|
@ -480,6 +499,18 @@ depending on the stage of your process. Git also enables rewriting history, but
|
|||
should be avoided as it might cause problems when multiple developers are
|
||||
contributing to the same codebase.
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
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.
|
||||
|
||||
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. -->
|
||||
|
||||
<!-- Identifiers, in alphabetical order -->
|
||||
|
||||
[bfg-repo-cleaner]: https://rtyley.github.io/bfg-repo-cleaner/
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
type: howto
|
||||
---
|
||||
|
||||
# Troubleshooting Git
|
||||
|
||||
Sometimes things don't work the way they should or as you might expect when
|
||||
|
@ -9,7 +13,7 @@ with Git.
|
|||
'Broken pipe' errors can occur when attempting to push to a remote repository.
|
||||
When pushing you will usually see:
|
||||
|
||||
```
|
||||
```text
|
||||
Write failed: Broken pipe
|
||||
fatal: The remote end hung up unexpectedly
|
||||
```
|
||||
|
@ -39,14 +43,15 @@ There's another option where you can prevent session timeouts by configuring
|
|||
SSH 'keep alive' either on the client or on the server (if you are a GitLab
|
||||
admin and have access to the server).
|
||||
|
||||
NOTE: **Note:** configuring *both* the client and the server is unnecessary.
|
||||
NOTE: **Note:**
|
||||
Configuring *both* the client and the server is unnecessary.
|
||||
|
||||
**To configure SSH on the client side**:
|
||||
|
||||
- On UNIX, edit `~/.ssh/config` (create the file if it doesn’t exist) and
|
||||
add or edit:
|
||||
- On UNIX, edit `~/.ssh/config` (create the file if it doesn’t exist) and
|
||||
add or edit:
|
||||
|
||||
```
|
||||
```text
|
||||
Host your-gitlab-instance-url.com
|
||||
ServerAliveInterval 60
|
||||
ServerAliveCountMax 5
|
||||
|
@ -58,7 +63,7 @@ NOTE: **Note:** configuring *both* the client and the server is unnecessary.
|
|||
|
||||
**To configure SSH on the server side**, edit `/etc/ssh/sshd_config` and add:
|
||||
|
||||
```
|
||||
```text
|
||||
ClientAliveInterval 60
|
||||
ClientAliveCountMax 5
|
||||
```
|
||||
|
@ -83,35 +88,35 @@ to >= 2.9 (see [Broken pipe when pushing to Git repository][Broken-Pipe]).
|
|||
Users may experience the following error when attempting to push or pull
|
||||
using Git over SSH:
|
||||
|
||||
```
|
||||
Please make sure you have the correct access rights
|
||||
and the repository exists.
|
||||
```text
|
||||
Please make sure you have the correct access rights
|
||||
and the repository exists.
|
||||
...
|
||||
ssh_exchange_identification: read: Connection reset by peer
|
||||
fatal: Could not read from remote repository.
|
||||
ssh_exchange_identification: read: Connection reset by peer
|
||||
fatal: Could not read from remote repository.
|
||||
```
|
||||
|
||||
This error usually indicates that SSH daemon's `MaxStartups` value is throttling
|
||||
SSH connections. This setting specifies the maximum number of unauthenticated
|
||||
SSH connections. This setting specifies the maximum number of unauthenticated
|
||||
connections to the SSH daemon. This affects users with proper authentication
|
||||
credentials (SSH keys) because every connection is 'unauthenticated' in the
|
||||
beginning. The default value is `10`.
|
||||
beginning. The default value is `10`.
|
||||
|
||||
Increase `MaxStartups` by adding or modifying the value in `/etc/ssh/sshd_config`:
|
||||
|
||||
```
|
||||
```text
|
||||
MaxStartups 100
|
||||
```
|
||||
|
||||
Restart SSHD for the change to take effect.
|
||||
Restart SSHD for the change to take effect.
|
||||
|
||||
## Timeout during git push/pull
|
||||
|
||||
If pulling/pushing from/to your repository ends up taking more than 50 seconds,
|
||||
a timeout will be issued with a log of the number of operations performed
|
||||
a timeout will be issued with a log of the number of operations performed
|
||||
and their respective timings, like the example below:
|
||||
|
||||
```
|
||||
```text
|
||||
remote: Running checks for branch: master
|
||||
remote: Scanning for LFS objects... (153ms)
|
||||
remote: Calculating new repository size... (cancelled after 729ms)
|
||||
|
|
Loading…
Reference in New Issue