diff options
Diffstat (limited to 'doc/topics')
| -rw-r--r-- | doc/topics/authentication/index.md | 8 | ||||
| -rw-r--r-- | doc/topics/autodevops/img/autodevops_domain_variables.png | bin | 8456 -> 0 bytes | |||
| -rw-r--r-- | doc/topics/autodevops/img/guide_connect_cluster.png | bin | 15225 -> 0 bytes | |||
| -rw-r--r-- | doc/topics/autodevops/img/guide_create_cluster.png | bin | 18915 -> 0 bytes | |||
| -rw-r--r-- | doc/topics/autodevops/img/guide_gke_apis_after.png | bin | 26811 -> 0 bytes | |||
| -rw-r--r-- | doc/topics/autodevops/img/guide_gke_apis_before.png | bin | 14882 -> 0 bytes | |||
| -rw-r--r-- | doc/topics/autodevops/img/guide_merge_request_ide.png | bin | 35052 -> 0 bytes | |||
| -rw-r--r-- | doc/topics/autodevops/index.md | 211 | ||||
| -rw-r--r-- | doc/topics/autodevops/quick_start_guide.md | 4 | ||||
| -rw-r--r-- | doc/topics/git/how_to_install_git/index.md | 29 | ||||
| -rw-r--r-- | doc/topics/git/index.md | 61 | ||||
| -rw-r--r-- | doc/topics/git/numerous_undo_possibilities_in_git/index.md | 121 | ||||
| -rw-r--r-- | doc/topics/git/troubleshooting_git.md | 48 |
13 files changed, 285 insertions, 197 deletions
diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md index 0fc7f57feab..228da2d1f57 100644 --- a/doc/topics/authentication/index.md +++ b/doc/topics/authentication/index.md @@ -17,11 +17,11 @@ This page gathers all the resources for the topic **Authentication** within GitL ## GitLab administrators - [LDAP (Community Edition)](../../administration/auth/ldap.md) -- [LDAP (Enterprise Edition)](https://docs.gitlab.com/ee/administration/auth/ldap-ee.html) +- [LDAP (Enterprise Edition)](../../administration/auth/ldap-ee.md) **[STARTER]** - [Enforce Two-factor Authentication (2FA)](../../security/two_factor_authentication.md#enforce-two-factor-authentication-2fa) - **Articles:** - [How to Configure LDAP with GitLab CE](../../administration/auth/how_to_configure_ldap_gitlab_ce/index.md) - - [How to Configure LDAP with GitLab EE](https://docs.gitlab.com/ee/administration/auth/how_to_configure_ldap_gitlab_ee/index.html) + - [How to Configure LDAP with GitLab EE](../../administration/auth/how_to_configure_ldap_gitlab_ee/index.md) **[STARTER]** - [Feature Highlight: LDAP Integration](https://about.gitlab.com/2014/07/10/feature-highlight-ldap-sync/) - [Debugging LDAP](https://about.gitlab.com/handbook/support/workflows/support-engineering/ldap/debugging_ldap.html) - **Integrations:** @@ -30,8 +30,10 @@ This page gathers all the resources for the topic **Authentication** within GitL - [Atlassian Crowd OmniAuth Provider](../../administration/auth/crowd.md) - [CAS OmniAuth Provider](../../integration/cas.md) - [SAML OmniAuth Provider](../../integration/saml.md) + - [SAML for GitLab.com Groups](../../user/group/saml_sso/index.md) **[SILVER ONLY]** + - [SCIM user provisioning for GitLab.com Groups](../../user/group/saml_sso/scim_setup.md) **[SILVER ONLY]** - [Okta SSO provider](../../administration/auth/okta.md) - - [Kerberos integration (GitLab EE)](https://docs.gitlab.com/ee/integration/kerberos.html) + - [Kerberos integration (GitLab EE)](../../integration/kerberos.md) **[STARTER]** ## API diff --git a/doc/topics/autodevops/img/autodevops_domain_variables.png b/doc/topics/autodevops/img/autodevops_domain_variables.png Binary files differdeleted file mode 100644 index b6f8864796f..00000000000 --- a/doc/topics/autodevops/img/autodevops_domain_variables.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_connect_cluster.png b/doc/topics/autodevops/img/guide_connect_cluster.png Binary files differdeleted file mode 100644 index 703d536f37a..00000000000 --- a/doc/topics/autodevops/img/guide_connect_cluster.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_create_cluster.png b/doc/topics/autodevops/img/guide_create_cluster.png Binary files differdeleted file mode 100644 index cd1d0fdd8da..00000000000 --- a/doc/topics/autodevops/img/guide_create_cluster.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_gke_apis_after.png b/doc/topics/autodevops/img/guide_gke_apis_after.png Binary files differdeleted file mode 100644 index 380de958867..00000000000 --- a/doc/topics/autodevops/img/guide_gke_apis_after.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_gke_apis_before.png b/doc/topics/autodevops/img/guide_gke_apis_before.png Binary files differdeleted file mode 100644 index d06fc707887..00000000000 --- a/doc/topics/autodevops/img/guide_gke_apis_before.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_merge_request_ide.png b/doc/topics/autodevops/img/guide_merge_request_ide.png Binary files differdeleted file mode 100644 index c825b0849e1..00000000000 --- a/doc/topics/autodevops/img/guide_merge_request_ide.png +++ /dev/null diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 1df492ba82c..34140a3260e 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -8,20 +8,23 @@ to simplify the setup and execution of a mature & modern software development li ## Overview -NOTE: **Enabled by default:** -Starting with GitLab 11.3, the Auto DevOps pipeline is enabled by default for all -projects. If it has not been explicitly enabled for the project, Auto DevOps will be automatically -disabled on the first pipeline failure. Your project will continue to use an alternative -[CI/CD configuration file](../../ci/yaml/README.md) if one is found. A GitLab -administrator can [change this setting](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only) -in the admin area. - With Auto DevOps, the software development process becomes easier to set up as every project can have a complete workflow from verification to monitoring with minimal configuration. Just push your code and GitLab takes care of everything else. This makes it easier to start new projects and brings consistency to how applications are set up throughout a company. +For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4). + +## Enabled by default + +Starting with GitLab 11.3, the Auto DevOps pipeline is enabled by default for all +projects. If it has not been explicitly enabled for the project, Auto DevOps will be automatically +disabled on the first pipeline failure. Your project will continue to use an alternative +[CI/CD configuration file](../../ci/yaml/README.md) if one is found. A GitLab +administrator can [change this setting](../../user/admin_area/settings/continuous_integration.md#auto-devops-core-only) +in the admin area. + ## Quick start If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) @@ -62,7 +65,7 @@ project in a simple and automatic way: 1. [Auto SAST (Static Application Security Testing)](#auto-sast-ultimate) **[ULTIMATE]** 1. [Auto Dependency Scanning](#auto-dependency-scanning-ultimate) **[ULTIMATE]** 1. [Auto License Management](#auto-license-management-ultimate) **[ULTIMATE]** -1. [Auto Container Scanning](#auto-container-scanning) +1. [Auto Container Scanning](#auto-container-scanning-ultimate) **[ULTIMATE]** 1. [Auto Review Apps](#auto-review-apps) 1. [Auto DAST (Dynamic Application Security Testing)](#auto-dast-ultimate) **[ULTIMATE]** 1. [Auto Deploy](#auto-deploy) @@ -120,16 +123,11 @@ To make full use of Auto DevOps, you will need: [default service template](../../user/project/integrations/services_templates.md) for the entire GitLab installation. -NOTE: **Note:** If you do not have Kubernetes or Prometheus installed, then Auto Review Apps, Auto Deploy, and Auto Monitoring will be silently skipped. ## Auto DevOps base domain -NOTE: **Note** -`AUTO_DEVOPS_DOMAIN` environment variable is deprecated and -[is scheduled to be removed](https://gitlab.com/gitlab-org/gitlab-ce/issues/56959). - The Auto DevOps base domain is required if you want to make use of [Auto Review Apps](#auto-review-apps) and [Auto Deploy](#auto-deploy). It can be defined in any of the following places: @@ -139,10 +137,13 @@ in any of the following places: - or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN` - or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`. -NOTE: **Note** -The Auto DevOps base domain variable (`KUBE_INGRESS_BASE_DOMAIN`) follows the same order of precedence +The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables). +NOTE: **Note** +`AUTO_DEVOPS_DOMAIN` environment variable is deprecated and +[is scheduled to be removed](https://gitlab.com/gitlab-org/gitlab-ce/issues/56959). + A wildcard DNS A record matching the base domain(s) is required, for example, given a base domain of `example.com`, you'd need a DNS entry like: @@ -162,6 +163,12 @@ Auto DevOps base domain to `1.2.3.4.nip.io`. Once set up, all requests will hit the load balancer, which in turn will route them to the Kubernetes pods that run your application(s). +NOTE: **Note:** +From GitLab 11.8, `KUBE_INGRESS_BASE_DOMAIN` replaces `AUTO_DEVOPS_DOMAIN`. +Support for `AUTO_DEVOPS_DOMAIN` was [removed in GitLab +12.0](https://gitlab.com/gitlab-org/gitlab-ce/issues/56959). + + ## Using multiple Kubernetes clusters **[PREMIUM]** When using Auto DevOps, you may want to deploy different environments to @@ -179,7 +186,7 @@ Those environments are tied to jobs that use [Auto Deploy](#auto-deploy), so except for the environment scope, they would also need to have a different domain they would be deployed to. This is why you need to define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for all the above -[based on the environment](https://docs.gitlab.com/ee/ci/variables/index.html#limiting-environment-scopes-of-variables-premium). +[based on the environment](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables-premium). The following table is an example of how the three different clusters would be configured. @@ -209,10 +216,6 @@ and verifying that your app is deployed as a review app in the Kubernetes cluster with the `review/*` environment scope. Similarly, you can check the other environments. -NOTE: **Note:** -From GitLab 11.8, `KUBE_INGRESS_BASE_DOMAIN` replaces `AUTO_DEVOPS_DOMAIN`. -`AUTO_DEVOPS_DOMAIN` [is scheduled to be removed](https://gitlab.com/gitlab-org/gitlab-ce/issues/56959). - ## Enabling/Disabling Auto DevOps When first using Auto Devops, review the [requirements](#requirements) to ensure all necessary components to make @@ -224,19 +227,20 @@ can enable/disable Auto DevOps at either the project-level or instance-level. ### Enabling/disabling Auto DevOps at the instance-level (Administrators only) +Even when disabled at the instance level, group owners and project maintainers can still enable +Auto DevOps at the group and project level, respectively. + 1. Go to **Admin area > Settings > Continuous Integration and Deployment**. 1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**. 1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps. 1. Click **Save changes** for the changes to take effect. -NOTE: **Note:** -Even when disabled at the instance level, group owners and project maintainers are still able to enable -Auto DevOps at group-level and project-level, respectively. - ### Enabling/disabling Auto DevOps at the group-level > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/52447) in GitLab 11.10. +Only administrators and group owners can enable or disable Auto DevOps at the group level. + To enable or disable Auto DevOps at the group-level: 1. Go to group's **Settings > CI/CD > Auto DevOps** page. @@ -247,9 +251,6 @@ When enabling or disabling Auto DevOps at group-level, group configuration will the subgroups and projects inside that group, unless Auto DevOps is specifically enabled or disabled on the subgroup or project. -NOTE: **Note** -Only administrators and group owners are allowed to enable or disable Auto DevOps at group-level. - ### Enabling/disabling Auto DevOps at the project-level If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it. @@ -263,16 +264,13 @@ If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch. -NOTE: **Note:** -For GitLab versions 10.0 - 10.2, when enabling Auto DevOps, a pipeline needs to be -manually triggered either by pushing a new commit to the repository or by visiting -`https://example.gitlab.com/<username>/<project>/pipelines/new` and creating -a new pipeline for your default branch, generally `master`. +### Feature flag to enable for a percentage of projects -NOTE: **Note:** -There is also a feature flag to enable Auto DevOps to a percentage of projects -which can be enabled from the console with -`Feature.get(:force_autodevops_on_by_default).enable_percentage_of_actors(10)`. +There is also a feature flag to enable Auto DevOps by default to your chosen percentage of projects. + +This can be enabled from the console with the following, which uses the example of 10%: + +`Feature.get(:force_autodevops_on_by_default).enable_percentage_of_actors(10)` ### Deployment strategy @@ -352,7 +350,6 @@ frameworks are detected automatically, but if your language is not detected, you may succeed with a [custom buildpack](#custom-buildpacks). Check the [currently supported languages](#currently-supported-languages). -NOTE: **Note:** Auto Test uses tests you already have in your application. If there are no tests, it's up to you to add them. @@ -365,7 +362,7 @@ created, and is uploaded as an artifact which you can later download and check out. Any differences between the source and target branches are also -[shown in the merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html). +[shown in the merge request widget](../../user/project/merge_requests/code_quality.md). ### Auto SAST **[ULTIMATE]** @@ -373,18 +370,14 @@ Any differences between the source and target branches are also Static Application Security Testing (SAST) uses the [SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static -analysis on the current code and checks for potential security issues. Once the -report is created, it's uploaded as an artifact which you can later download and -check out. - -Any security warnings are also -[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/sast.html). +analysis on the current code and checks for potential security issues. The +the Auto SAST stage will be skipped on licenses other than Ultimate and requires GitLab Runner 11.5 or above. -NOTE: **Note:** -The Auto SAST stage will be skipped on licenses other than Ultimate. +Once the report is created, it's uploaded as an artifact which you can later download and +check out. -NOTE: **Note:** -The Auto SAST job requires GitLab Runner 11.5 or above. +Any security warnings are also shown in the merge request widget. Read more how +[SAST works](../../user/application_security/sast/index.md). ### Auto Dependency Scanning **[ULTIMATE]** @@ -392,18 +385,16 @@ The Auto SAST job requires GitLab Runner 11.5 or above. Dependency Scanning uses the [Dependency Scanning Docker image](https://gitlab.com/gitlab-org/security-products/dependency-scanning) -to run analysis on the project dependencies and checks for potential security issues. Once the +to run analysis on the project dependencies and checks for potential security issues. +The Auto Dependency Scanning stage will be skipped on licenses other than Ultimate +and requires GitLab Runner 11.5 or above. + +Once the report is created, it's uploaded as an artifact which you can later download and check out. -Any security warnings are also -[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/dependency_scanning.html). - -NOTE: **Note:** -The Auto Dependency Scanning stage will be skipped on licenses other than Ultimate. - -NOTE: **Note:** -The Auto Dependency Scanning job requires GitLab Runner 11.5 or above. +Any security warnings are also shown in the merge request widget. Read more about +[Dependency Scanning](../../user/application_security/dependency_scanning/index.md). ### Auto License Management **[ULTIMATE]** @@ -411,35 +402,34 @@ The Auto Dependency Scanning job requires GitLab Runner 11.5 or above. License Management uses the [License Management Docker image](https://gitlab.com/gitlab-org/security-products/license-management) -to search the project dependencies for their license. Once the +to search the project dependencies for their license. The Auto License Management stage +will be skipped on licenses other than Ultimate. + +Once the report is created, it's uploaded as an artifact which you can later download and check out. -Any licenses are also -[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/license_management.html). - -NOTE: **Note:** -The Auto License Management stage will be skipped on licenses other than Ultimate. +Any licenses are also shown in the merge request widget. Read more how +[License Management works](../../user/application_security/license_management/index.md). -### Auto Container Scanning +### Auto Container Scanning **[ULTIMATE]** > Introduced in GitLab 10.4. Vulnerability Static Analysis for containers uses [Clair](https://github.com/coreos/clair) to run static analysis on a -Docker image and checks for potential security issues. Once the report is +Docker image and checks for potential security issues. The Auto Container Scanning stage +will be skipped on licenses other than Ultimate. + +Once the report is created, it's uploaded as an artifact which you can later download and check out. -Any security warnings are also -[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/container_scanning.html). - -NOTE: **Note:** -The Auto Container Scanning stage will be skipped on licenses other than Ultimate. +Any security warnings are also shown in the merge request widget. Read more how +[Container Scanning works](../../user/application_security/container_scanning/index.md). ### Auto Review Apps -NOTE: **Note:** This is an optional step, since many projects do not have a Kubernetes cluster available. If the [requirements](#requirements) are not met, the job will silently be skipped. @@ -460,7 +450,7 @@ for example after the merge request is merged, the Review App will automatically be deleted. Review apps are deployed using the -[auto-deploy-app](https://gitlab.com/charts/auto-deploy-app) chart with +[auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with Helm. The app will be deployed into the [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables) for the environment. @@ -484,14 +474,13 @@ in the first place, and thus not realize that it needs to re-apply the old confi Dynamic Application Security Testing (DAST) uses the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy) to perform an analysis on the current code and checks for potential security -issues. Once the report is created, it's uploaded as an artifact which you can -later download and check out. +issues. The Auto DAST stage will be skipped on licenses other than Ultimate. -Any security warnings are also -[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/dast.html). +Once the report is created, it's uploaded as an artifact which you can +later download and check out. -NOTE: **Note:** -The Auto DAST stage will be skipped on licenses other than Ultimate. +Any security warnings are also shown in the merge request widget. Read how +[DAST works](../../user/application_security/dast/index.md). ### Auto Browser Performance Testing **[PREMIUM]** @@ -506,11 +495,10 @@ Auto Browser Performance Testing utilizes the [Sitespeed.io container](https://h ``` Any performance differences between the source and target branches are also -[shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/browser_performance_testing.html). +[shown in the merge request widget](../../user/project/merge_requests/browser_performance_testing.md). ### Auto Deploy -NOTE: **Note:** This is an optional step, since many projects do not have a Kubernetes cluster available. If the [requirements](#requirements) are not met, the job will silently be skipped. @@ -528,7 +516,7 @@ You can make use of [environment variables](#environment-variables) to automatic scale your pod replicas. Apps are deployed using the -[auto-deploy-app](https://gitlab.com/charts/auto-deploy-app) chart with +[auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with Helm. The app will be deployed into the [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables) for the environment. @@ -549,7 +537,7 @@ in the first place, and thus not realize that it needs to re-apply the old confi For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token) will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token -can be used for permanent access to the registry. +can be used for permanent access to the registry. When the GitLab Deploy Token has been manually revoked, it won't be automatically created. If the GitLab Deploy Token cannot be found, `CI_REGISTRY_PASSWORD` is used. Note that `CI_REGISTRY_PASSWORD` is only valid during deployment. @@ -559,9 +547,6 @@ be pulled again, e.g. after pod eviction, Kubernetes will fail to do so as it will be attempting to fetch the image using `CI_REGISTRY_PASSWORD`. -NOTE: **Note:** -When the GitLab Deploy Token has been manually revoked, it won't be automatically created. - #### Migrations > [Introduced][ce-21955] in GitLab 11.4 @@ -584,22 +569,19 @@ Note that a post-install hook means that if any deploy succeeds, If present, `DB_MIGRATE` will be run as a shell command within an application pod as a helm pre-upgrade hook. -For example, in a Rails application: +For example, in a Rails application in an image built with +[Herokuish](https://github.com/gliderlabs/herokuish): -- `DB_INITIALIZE` can be set to `cd /app && RAILS_ENV=production - bin/setup` -- `DB_MIGRATE` can be set to `cd /app && RAILS_ENV=production bin/update` +- `DB_INITIALIZE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:setup` +- `DB_MIGRATE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:migrate` -NOTE: **Note:** -The `/app` path is the directory of your project inside the docker image -as [configured by -Herokuish](https://github.com/gliderlabs/herokuish#paths) +Unless you have a `Dockerfile` in your repo, your image is built with +Herokuish, and you must prefix commands run in these images with `/bin/herokuish +procfile exec` to replicate the environment where your application will run. ### Auto Monitoring -NOTE: **Note:** -Check the [requirements](#requirements) for Auto Monitoring to make this stage -work. +See the [requirements](#requirements) for Auto Monitoring to enable this stage. Once your application is deployed, Auto Monitoring makes it possible to monitor your application's server and response metrics right out of the box. Auto @@ -667,7 +649,7 @@ repo or by specifying a project variable: - **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml` file in it, Auto DevOps will detect the chart and use it instead of the [default - one](https://gitlab.com/charts/auto-deploy-app). + one](https://gitlab.com/gitlab-org/charts/auto-deploy-app). This can be a great way to control exactly how your application is deployed. - **Project variable** - Create a [project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables) `AUTO_DEVOPS_CHART` with the URL of a custom chart to use or create two project variables `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository and `AUTO_DEVOPS_CHART` with the path to the chart. @@ -675,7 +657,7 @@ repo or by specifying a project variable: ### Custom Helm chart per environment **[PREMIUM]** You can specify the use of a custom Helm chart per environment by scoping the environment variable -to the desired environment. See [Limiting environment scopes of variables](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-variables-premium). +to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables-premium). ### Customizing `.gitlab-ci.yml` @@ -734,13 +716,15 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac | **Variable** | **Description** | | ------------ | --------------- | -| `AUTO_DEVOPS_DOMAIN` | The [Auto DevOps domain](#auto-devops-base-domain). By default, set automatically by the [Auto DevOps setting](#enablingdisabling-auto-devops). This variable is deprecated and [is scheduled to be removed](https://gitlab.com/gitlab-org/gitlab-ce/issues/56959). Use `KUBE_INGRESS_BASE_DOMAIN` instead. | -| `AUTO_DEVOPS_CHART` | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/charts/auto-deploy-app). | +| `AUTO_DEVOPS_CHART` | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/charts/auto-deploy-app). | | `AUTO_DEVOPS_CHART_REPOSITORY` | The Helm Chart repository used to search for charts; defaults to `https://charts.gitlab.io`. | +| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | From Gitlab 11.11, this variable can be used to set the name of the helm repository; defaults to "gitlab" | +| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From Gitlab 11.11, this variable can be used to set a username to connect to the helm repository. Defaults to no credentials. (Also set AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD) | +| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From Gitlab 11.11, this variable can be used to set a password to connect to the helm repository. Defaults to no credentials. (Also set AUTO_DEVOPS_CHART_REPOSITORY_USERNAME) | | `REPLICAS` | The number of replicas to deploy; defaults to 1. | | `PRODUCTION_REPLICAS` | The number of replicas to deploy in the production environment. This takes precedence over `REPLICAS`; defaults to 1. | -| `CANARY_REPLICAS` | The number of canary replicas to deploy for [Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html); defaults to 1 | -| `CANARY_PRODUCTION_REPLICAS` | The number of canary replicas to deploy for [Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html) in the production environment. This takes precedence over `CANARY_REPLICAS`; defaults to 1 | +| `CANARY_REPLICAS` | The number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md); defaults to 1 | +| `CANARY_PRODUCTION_REPLICAS` | The number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. This takes precedence over `CANARY_REPLICAS`; defaults to 1 | | `ADDITIONAL_HOSTS` | Fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. | | `<ENVIRONMENT>_ADDITIONAL_HOSTS` | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. | | `POSTGRES_ENABLED` | Whether PostgreSQL is enabled; defaults to `"true"`. Set to `false` to disable the automatic deployment of PostgreSQL. | @@ -767,6 +751,9 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac | `PERFORMANCE_DISABLED` | From GitLab 11.0, this variable can be used to disable the `performance` job. If the variable is present, the job will not be created. | | `K8S_SECRET_*` | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) will be made available by Auto DevOps as environment variables to the deployed application. | | `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/index.md#base-domain) for more information. | +| `ROLLOUT_RESOURCE_TYPE` | From GitLab 11.9, this variable allows specification of the resource type being deployed when using a custom helm chart. Default value is `deployment`. | +| `ROLLOUT_STATUS_DISABLED` | From GitLab 12.0, this variable allows to disable rollout status check because it doesn't support all resource types, for example, `cronjob`. | +| `HELM_UPGRADE_EXTRA_ARGS` | From GitLab 11.11, this variable allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. | TIP: **Tip:** Set up the replica variables using a @@ -822,11 +809,6 @@ metadata: type: Opaque ``` -CAUTION: **Caution:** -Variables with multiline values are not currently supported due to -limitations with the current Auto DevOps scripting environment. - -NOTE: **Note:** Environment variables are generally considered immutable in a Kubernetes pod. Therefore, if you update an application secret without changing any code then manually create a new pipeline, you will find that any running @@ -835,6 +817,10 @@ can either push a code update to GitLab to force the Kubernetes Deployment to recreate pods or manually delete running pods to cause Kubernetes to create new pods with updated secrets. +NOTE: **Note:** +Variables with multiline values are not currently supported due to +limitations with the current Auto DevOps scripting environment. + #### Advanced replica variables setup Apart from the two replica-related variables for production mentioned above, @@ -914,7 +900,7 @@ you when you're ready to manually deploy to production. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/171) in GitLab 11.0. -A [canary environment](https://docs.gitlab.com/ee/user/project/canary_deployments.html) can be used +A [canary environment](../../user/project/canary_deployments.md) can be used before any changes are deployed to production. If `CANARY_ENABLED` is defined in your project (e.g., set `CANARY_ENABLED` to @@ -1003,8 +989,7 @@ Everything behaves the same way, except: ## Currently supported languages -NOTE: **Note:** -Not all buildpacks support Auto Test yet, as it's a relatively new +Note that not all buildpacks support Auto Test yet, as it's a relatively new enhancement. All of Heroku's [officially supported languages](https://devcenter.heroku.com/articles/heroku-ci#currently-supported-languages) support it, and some third-party buildpacks as well e.g., Go, Node, Java, PHP, @@ -1094,3 +1079,7 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/ [ee]: https://about.gitlab.com/pricing/ [ce-21955]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21955 [ce-19507]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19507 + +## Development guides + +Configuring [GDK for Auto DevOps](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/auto_devops.md). diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 367e192b85a..6717e95266e 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -161,7 +161,7 @@ In the **test** stage, GitLab runs various checks on the application: - The `code_quality` job checks the code quality and is allowed to fail ([Auto Code Quality](index.md#auto-code-quality-starter)) **[STARTER]** - The `container_scanning` job checks the Docker container if it has any - vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning)) + vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning-ultimate)) - The `dependency_scanning` job checks if the application has any dependencies susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](index.md#auto-dependency-scanning-ultimate)) **[ULTIMATE]** - The `sast` job runs static analysis on the current code to check for potential @@ -208,7 +208,7 @@ applications. In the rightmost column for the production environment, you can ma application is running. Right below, there is the -[Deploy Board](https://docs.gitlab.com/ee/user/project/deploy_boards.html). +[Deploy Board](../../user/project/deploy_boards.md). The squares represent pods in your Kubernetes cluster that are associated with the given environment. Hovering above each square you can see the state of a deployment and clicking a square will take you to the pod's logs page. diff --git a/doc/topics/git/how_to_install_git/index.md b/doc/topics/git/how_to_install_git/index.md index d7e1979217e..c7bede2d269 100644 --- a/doc/topics/git/how_to_install_git/index.md +++ b/doc/topics/git/how_to_install_git/index.md @@ -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. --> diff --git a/doc/topics/git/index.md b/doc/topics/git/index.md index 7707d56764e..cdcd8215b23 100644 --- a/doc/topics/git/index.md +++ b/doc/topics/git/index.md @@ -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,73 @@ 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-ing started with Git](https://www.youtube.com/watch?v=Ce5nz5n41z4), + a video introduction to 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](https://docs.gitlab.com/ee/workflow/lfs/migrate_from_git_annex_to_git_lfs.html) -- 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/) +- [Git-Annex to Git-LFS migration guide](../../workflow/lfs/migrate_from_git_annex_to_git_lfs.md) +- [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/) diff --git a/doc/topics/git/numerous_undo_possibilities_in_git/index.md b/doc/topics/git/numerous_undo_possibilities_in_git/index.md index 8a8021dc36d..84201e11831 100644 --- a/doc/topics/git/numerous_undo_possibilities_in_git/index.md +++ b/doc/topics/git/numerous_undo_possibilities_in_git/index.md @@ -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/ diff --git a/doc/topics/git/troubleshooting_git.md b/doc/topics/git/troubleshooting_git.md index d1729d70158..417d91bf834 100644 --- a/doc/topics/git/troubleshooting_git.md +++ b/doc/topics/git/troubleshooting_git.md @@ -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 ``` @@ -78,13 +83,40 @@ git push In case you're running an older version of Git (< 2.9), consider upgrading to >= 2.9 (see [Broken pipe when pushing to Git repository][Broken-Pipe]). +## `ssh_exchange_identification` error + +Users may experience the following error when attempting to push or pull +using Git over SSH: + +```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. +``` + +This error usually indicates that SSH daemon's `MaxStartups` value is throttling +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`. + +Increase `MaxStartups` by adding or modifying the value in `/etc/ssh/sshd_config`: + +```text +MaxStartups 100 +``` + +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) |
