Skip to content
Snippets Groups Projects
Commit 9b2c39c6 authored by Evan Read's avatar Evan Read Committed by Achilleas Pipinellis
Browse files

SSoT audit fixes 

Implements part of the single source of truth audit
fixes for the topics/git section.
parent 95d1e2da
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
doc/topics/git/how_to_install_git/index.md
+ 25
− 4
View file @ 9b2c39c6
@@ -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. -->
doc/topics/git/index.md
+ 34
− 23
View file @ 9b2c39c6
# 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:**
### Concepts
 
- [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)
The following are resources about version control concepts:
 
### Concepts
- [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)
 
- 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)
## Git tips
 
## Exploring Git
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/)
doc/topics/git/numerous_undo_possibilities_in_git/index.md
+ 76
− 45
View file @ 9b2c39c6
@@ -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/
doc/topics/git/troubleshooting_git.md
+ 22
− 17
View file @ 9b2c39c6
---
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)
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment