[Localization] Translation batch 1637091418 (#22869)
* New Crowdin translations by Github Action * Reset broken translated files to English * Ran script/i18n/homogenize-frontmatter.js * Ran script/i18n/fix-translation-errors.js * Reverted translated files with parsing and rendering errors * Enable all languages in CI * Revert "Enable all languages in CI" This reverts commit b70a5a10b16e29731162389097aa025d3d0f60b8. Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
Chris
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: Using OpenID Connect with reusable workflows
|
||||
shortTitle: Using OpenID Connect with reusable workflows
|
||||
intro: 'You can use reusable workflows with OIDC to standardize and security harden your deployment steps.'
|
||||
miniTocMaxHeadingLevel: 3
|
||||
redirect_from:
|
||||
- /actions/deployment/security-hardening-your-deployments/using-oidc-with-your-reusable-workflows
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghae: 'issue-4757-and-5856'
|
||||
ghec: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Workflows
|
||||
- Security
|
||||
---
|
||||
|
||||
{% data reusables.actions.enterprise-beta %}
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Reusable workflows are currently in beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
## About reusable workflows
|
||||
|
||||
Rather than copying and pasting deployment jobs from one workflow to another, you can create a reusable workflow that performs the deployment steps. A reusable workflow can be used by another workflow if it meets one of the access requirements described in "[Reusing workflows](/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows)."
|
||||
|
||||
When combined with OpenID Connect (OIDC), reusable workflows let you enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows.
|
||||
|
||||
In order to create trust conditions based on reusable workflows, your cloud provider must support custom claims for `job_workflow_ref`. This allows your cloud provider to identify which repository the job originally came from. If your cloud provider only supports the standard claims (_audience_ and _subject_), it will not be able to determine that the job originated from the reusable workflow repository. Cloud providers that support `job_workflow_ref` include Google Cloud Platform and HashiCorp Vault.
|
||||
|
||||
Before proceeding, you should be familiar with the concepts of [reusable workflows](/actions/learn-github-actions/reusing-workflows) and [OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).
|
||||
|
||||
## How the token works with reusable workflows
|
||||
|
||||
During a workflow run, {% data variables.product.prodname_dotcom %}'s OIDC provider presents a OIDC token to the cloud provider which contains information about the job. If that job is part of a reusable workflow, the token will include the standard claims that contain information about the calling workflow, and will also include a custom claim called `job_workflow_ref` that contains information about the called workflow.
|
||||
|
||||
For example, the following OIDC token is for a job that was part of a called workflow. The `workflow`, `ref`, and other attributes describe the caller workflow, while `job_workflow_ref` refers to the called workflow:
|
||||
|
||||
```yaml{:copy}
|
||||
{
|
||||
"typ": "JWT",
|
||||
"alg": "RS256",
|
||||
"x5t": "example-thumbprint",
|
||||
"kid": "example-key-id"
|
||||
}
|
||||
{
|
||||
"jti": "example-id",
|
||||
"sub": "repo:octo-org/octo-repo:environment:prod",
|
||||
"aud": "https://github.com/octo-org",
|
||||
"ref": "refs/heads/main",
|
||||
"sha": "example-sha",
|
||||
"repository": "octo-org/octo-repo",
|
||||
"repository_owner": "octo-org",
|
||||
"run_id": "example-run-id",
|
||||
"run_number": "10",
|
||||
"run_attempt": "2",
|
||||
"actor": "octocat",
|
||||
"workflow": "example-workflow",
|
||||
"head_ref": "",
|
||||
"base_ref": "",
|
||||
"event_name": "workflow_dispatch",
|
||||
"ref_type": "branch",
|
||||
"job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
|
||||
"iss": "https://token.actions.githubusercontent.com",
|
||||
"nbf": 1632492967,
|
||||
"exp": 1632493867,
|
||||
"iat": 1632493567
|
||||
}
|
||||
```
|
||||
|
||||
If your reusable workflow performs deployment steps, then it will typically need access to a specific cloud role, and you might want to allow any repository in your organization to call that reusable workflow. To permit this, you'll create the trust condition that allows any repository and any caller workflow, and then filter on the organization and the called workflow. See the next section for some examples.
|
||||
|
||||
## Examples
|
||||
|
||||
**Filtering for reusable workflows within a specific repository**
|
||||
|
||||
You can configure a custom claim that filters for any reusable workflow in a specific repository. In this example, the workflow run must have originated from a job defined in a reusable workflow in the `octo-org/octo-automation` repository, and in any repository that is owned by the `octo-org` organization.
|
||||
|
||||
- **Subject**:
|
||||
- Syntax: `repo:ORG_NAME/*`
|
||||
- Example: `repo:octo-org/*`
|
||||
|
||||
- **Custom claim**:
|
||||
- Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME`
|
||||
- Example: `job_workflow_ref:octo-org/octo-automation@*`
|
||||
|
||||
**Filtering for a specific reusable workflow at a specific ref**
|
||||
|
||||
You can configure a custom claim that filters for a specific reusable workflow. In this example, the workflow run must have originated from a job defined in the reusable workflow `octo-org/octo-automation/.github/workflows/deployment.yml`, and in any repository that is owned by the `octo-org` organization.
|
||||
|
||||
- **Subject**:
|
||||
- Syntax: `repo:ORG_NAME/*`
|
||||
- Example: `repo:octo-org/*`
|
||||
|
||||
- **Custom claim**:
|
||||
- Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME/.github/workflows/WORKFLOW_FILE@ref`
|
||||
- Example: `job_workflow_ref:octo-org/octo-automation/.github/workflows/deployment.yml@ 10040c56a8c0253d69db7c1f26a0d227275512e2`
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: About repository caching
|
||||
intro: "You can increase the performance of Git read operations for distributed teams and CI farms with repository caching."
|
||||
versions:
|
||||
ghes: '>=3.3'
|
||||
type: overview
|
||||
topics:
|
||||
- Enterprise
|
||||
---
|
||||
|
||||
{% data reusables.enterprise.repository-caching-release-phase %}
|
||||
|
||||
If you have teams and CI farms located around the world, you may experience reduced performance on your primary {% data variables.product.prodname_ghe_server %} instance. While active geo-replicas can improve the performance of read requests, this comes at the cost of limiting write throughput. To reduce load on your primary instance and improve write throughput performance, you can configure a repository cache, an asynchronous read-only mirror of repositories located near these geographically-distributed clients.
|
||||
|
||||
A repository cache eliminates the need for {% data variables.product.product_name %} to transmit the same Git data over a long-haul network link multiple times to serve multiple clients, by serving your repository data close to CI farms and distributed teams. For instance, if your primary instance is in North America and you also have a large presence in Asia, you will benefit from setting up the repository cache in Asia for use by CI runners there.
|
||||
|
||||
The repository cache listens to the primary instance, whether that's a single instance or a geo-replicated set of instances, for changes to Git data. CI farms and other read-heavy consumers clone and fetch from the repository cache instead of the primary instance. Changes are propagated across the network, at periodic intervals, once per cache instance rather than once per client. Git data will typically be visible on the repository cache within several minutes after the data is pushed to the primary instance.
|
||||
|
||||
You have fine-grained control over which repositories are allowed to sync to the repository cache.
|
||||
|
||||
{% data reusables.enterprise.repository-caching-config-summary %} For more information, see "[Configuring a repository cache](/admin/enterprise-management/caching-repositories/configuring-a-repository-cache)."
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: Configuring a repository cache
|
||||
intro: "You can configure a repository cache by creating a new appliance, connecting the repository cache to your primary appliance, and configuring replication of repository networks to the repository cache."
|
||||
versions:
|
||||
ghes: '>=3.3'
|
||||
type: how_to
|
||||
topics:
|
||||
- Enterprise
|
||||
---
|
||||
|
||||
{% data reusables.enterprise.repository-caching-release-phase %}
|
||||
|
||||
## About configuration for repository caching
|
||||
|
||||
{% data reusables.enterprise.repository-caching-config-summary %} Then, you can set data location policies that govern which repository networks are replicated to the repository cache.
|
||||
|
||||
Repository caching is not supported with clustering.
|
||||
|
||||
## DNS for repository caches
|
||||
|
||||
The primary instance and repository cache should have different DNS names. For example, if your primary instance is at `github.example.com`, you might decide to name a cache `europe-ci.github.example.com` or `github.asia.example.com`.
|
||||
|
||||
To have your CI machines fetch from the repository cache instead of the primary instance, you can use Git's `url.<base>.insteadOf` configuration setting. For more information, see [`git-config`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtinsteadOf) in the Git documentation.
|
||||
|
||||
For example, the global `.gitconfig` for the CI machine would include these lines.
|
||||
|
||||
```
|
||||
[url "https://europe-ci.github.example.com/"]
|
||||
insteadOf = https://github.example.com/
|
||||
```
|
||||
|
||||
Then, when told to fetch `https://github.example.com/myorg/myrepo`, Git will instead fetch from `https://europe-ci.github.example.com/myorg/myrepo`.
|
||||
|
||||
## Configuring a repository cache
|
||||
|
||||
1. During the beta, you must enable the feature flag for repository caching on your primary {% data variables.product.prodname_ghe_server %} appliance.
|
||||
|
||||
```
|
||||
$ ghe-config cluster.cache-enabled true
|
||||
```
|
||||
|
||||
1. Set up a new {% data variables.product.prodname_ghe_server %} appliance on your desired platform. This appliance will be your repository cache. For more information, see "[Setting up a {% data variables.product.prodname_ghe_server %} instance](/admin/guides/installation/setting-up-a-github-enterprise-server-instance)."
|
||||
{% data reusables.enterprise_installation.replica-steps %}
|
||||
1. Connect to the repository cache's IP address using SSH.
|
||||
|
||||
```shell
|
||||
$ ssh -p 122 admin@<em>REPLICA IP</em>
|
||||
```
|
||||
|
||||
{% data reusables.enterprise_installation.generate-replication-key-pair %}
|
||||
{% data reusables.enterprise_installation.add-ssh-key-to-primary %}
|
||||
1. To verify the connection to the primary and enable replica mode for the repository cache, run `ghe-repl-setup` again.
|
||||
|
||||
```shell
|
||||
$ ghe-repl-setup <em>PRIMARY IP</em>
|
||||
```
|
||||
|
||||
1. Set a `cache_location` for the repository cache, replacing *CACHE-LOCATION* with an alphanumeric identifier, such as the region where the cache is deployed.
|
||||
|
||||
```shell
|
||||
$ ghe-repl-node --cache <em>CACHE-LOCATION</em>
|
||||
```
|
||||
|
||||
{% data reusables.enterprise_installation.replication-command %}
|
||||
{% data reusables.enterprise_installation.verify-replication-channel %}
|
||||
1. To enable replication of repository networks to the repository cache, set a data location policy. For more information, see "[Data location policies](#data-location-policies)."
|
||||
|
||||
## Data location policies
|
||||
|
||||
You can control data locality by configuring data location policies for your repositories with the `spokesctl cache-policy` command. Data location policies determine which repository networks are replicated on which repository caches. By default, no repository networks will be replicated on any repository caches until a data location policy is configured.
|
||||
|
||||
You can configure a policy to replicate all networks with the `--default` flag. For example, this command will create a policy to replicate a single copy of every repository network to the set of repository caches whose `cache_location` is "kansas".
|
||||
|
||||
```
|
||||
$ ghe-spokesctl cache-policy set --default 1 kansas
|
||||
```
|
||||
|
||||
To configure replication for a repository network, specify the repository that is the root of the network. A repository network includes a repository and all of the repository's forks. You cannot replicate part of a network without replicating the whole network.
|
||||
|
||||
```
|
||||
$ ghe-spokesctl cache-policy set <owner/repository> 1 kansas
|
||||
```
|
||||
|
||||
You can override a policy that replicates all networks and exclude specific networks by specifying a replica count of zero for the network. For example, this command specifies that any repository cache in location "kansas" cannot contain any copies of that network.
|
||||
|
||||
```
|
||||
$ ghe-spokesctl cache-policy set <owner/repository> 0 kansas
|
||||
```
|
||||
|
||||
Replica counts greater than one in a given cache location are not supported.
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Caching repositories
|
||||
intro: "You can improve performance for your geographically-distributed team with repository caching, which provides read-only mirrors close to your users and CI clients."
|
||||
versions:
|
||||
ghes: '>=3.3'
|
||||
topics:
|
||||
- Enterprise
|
||||
children:
|
||||
- /about-repository-caching
|
||||
- /configuring-a-repository-cache
|
||||
---
|
||||
|
||||
{% data reusables.enterprise.repository-caching-release-phase %}
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Setting up Dependabot security and version updates on your enterprise
|
||||
intro: 'You can create dedicated runners for {% data variables.product.product_location %} that {% data variables.product.prodname_dependabot %} uses to create pull requests to help secure and maintain the dependencies used in repositories on your enterprise.'
|
||||
allowTitleToDifferFromFilename: true
|
||||
miniTocMaxHeadingLevel: 3
|
||||
versions:
|
||||
ghes: '> 3.2'
|
||||
topics:
|
||||
- Enterprise
|
||||
- Security
|
||||
- Dependabot
|
||||
- Dependencies
|
||||
shortTitle: Set up Dependabot updates
|
||||
---
|
||||
|
||||
{% data reusables.dependabot.beta-security-and-version-updates %}
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: If {% data variables.product.product_location %} uses clustering, you cannot set up {% data variables.product.prodname_dependabot %} security and version updates as {% data variables.product.prodname_actions %} are not supported in cluster mode.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## About {% data variables.product.prodname_dependabot %} updates
|
||||
|
||||
When you set up {% data variables.product.prodname_dependabot %} security and version updates for {% data variables.product.product_location %}, users can configure repositories so that their dependencies are updated and kept secure automatically. This is an important step in helping developers create and maintain secure code.
|
||||
|
||||
Users can set up {% data variables.product.prodname_dependabot %} to create pull requests to update their dependencies using two features.
|
||||
|
||||
- **{% data variables.product.prodname_dependabot_version_updates %}**: Users add a {% data variables.product.prodname_dependabot %} configuration file to the repository to enable {% data variables.product.prodname_dependabot %} to create pull requests when a new version of a tracked dependency is released. For more information, see "[About {% data variables.product.prodname_dependabot_version_updates %}](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates)."
|
||||
- **{% data variables.product.prodname_dependabot_security_updates %}**: Users toggle a repository setting to enable {% data variables.product.prodname_dependabot %} to create pull requests when {% data variables.product.prodname_dotcom %} detects a vulnerability in one of the dependencies of the dependency graph for the repository. For more information, see "[About alerts for vulnerable dependencies](/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-alerts-for-vulnerable-dependencies)" and "[About {% data variables.product.prodname_dependabot_security_updates %}](/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-dependabot-security-updates)."
|
||||
|
||||
## Prerequisites for {% data variables.product.prodname_dependabot %} updates
|
||||
|
||||
Both types of {% data variables.product.prodname_dependabot %} update have the following requirements.
|
||||
|
||||
- Configure {% data variables.product.product_location %} to use {% data variables.product.prodname_actions %}. For more information, see "[Getting started with {% data variables.product.prodname_actions %} for GitHub Enterprise Server](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/getting-started-with-github-actions-for-github-enterprise-server)."
|
||||
- Set up one or more {% data variables.product.prodname_actions %} self-hosted runners for {% data variables.product.prodname_dependabot %}. For more information, see "[Setting up self-hosted runners for {% data variables.product.prodname_dependabot %} updates](#setting-up-self-hosted-runners-for-dependabot-updates)" below.
|
||||
|
||||
Additionally, {% data variables.product.prodname_dependabot_security_updates %} rely on the dependency graph, vulnerability data from {% data variables.product.prodname_github_connect %}, and {% data variables.product.prodname_dependabot_alerts %}. These features must be enabled on {% data variables.product.product_location %}. For more information, see "[Enabling the dependency graph and {% data variables.product.prodname_dependabot %} alerts on your enterprise account](/admin/configuration/managing-connections-between-your-enterprise-accounts/enabling-the-dependency-graph-and-dependabot-alerts-on-your-enterprise-account)."
|
||||
|
||||
## Setting up self-hosted runners for {% data variables.product.prodname_dependabot %} updates
|
||||
|
||||
When you have configured {% data variables.product.product_location %} to use {% data variables.product.prodname_actions %}, you need to add self-hosted runners for {% data variables.product.prodname_dependabot %} updates. For more information, see "[Getting started with {% data variables.product.prodname_actions %} for GitHub Enterprise Server](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/getting-started-with-github-actions-for-github-enterprise-server)."
|
||||
|
||||
### System requirements for {% data variables.product.prodname_dependabot %} runners
|
||||
|
||||
Any VM that you use for {% data variables.product.prodname_dependabot %} runners must meet the requirements for self-hosted runners. In addition, they must meet the following requirements.
|
||||
|
||||
- Linux operating system
|
||||
- The following dependencies installed:
|
||||
- Docker running as the same user as the self-hosted runner application
|
||||
- Git
|
||||
|
||||
The CPU and memory requirements will depend on the number of concurrent runners you deploy on a given VM. As guidance, we have successfully set up 20 runners on a single 2 CPU 8GB machine, but ultimately, your CPU and memory requirements will heavily depend on the repositories being updated. Some ecosystems will require more resources than others.
|
||||
|
||||
If you specify more than 14 concurrent runners on a VM, you must also update the Docker `/etc/docker/daemon.json` configuration to increase the default number of networks Docker can create.
|
||||
|
||||
```
|
||||
{
|
||||
"default-address-pools": [
|
||||
{"base":"10.10.0.0/16","size":24}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Network requirements for {% data variables.product.prodname_dependabot %} runners
|
||||
|
||||
{% data variables.product.prodname_dependabot %} runners require access to the public internet, {% data variables.product.prodname_dotcom_the_website %}, and any internal registries that will be used in {% data variables.product.prodname_dependabot %} updates. To minimize the risk to your internal network, you should limit access from the Virtual Machine (VM) to your internal network. This reduces the potential for damage to internal systems if a runner were to download a hijacked dependency.
|
||||
|
||||
### Adding self-hosted runners for {% data variables.product.prodname_dependabot %} updates
|
||||
|
||||
1. Provision self-hosted runners, at the repository, organization, or enterprise account level. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)" and "[Adding self-hosted runners](/actions/hosting-your-own-runners/adding-self-hosted-runners)."
|
||||
|
||||
2. Verify that the self-hosted runners meet the requirements for {% data variables.product.prodname_dependabot %} before assigning a `dependabot` label to each runner you want {% data variables.product.prodname_dependabot %} to use. For more information, see "[Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners#assigning-a-label-to-a-self-hosted-runner)."
|
||||
|
||||
3. Optionally, enable workflows triggered by {% data variables.product.prodname_dependabot %} to use more than read-only permissions and to have access to any secrets that are normally available. For more information, see "[Troubleshooting {% data variables.product.prodname_actions %} for your enterprise](/admin/github-actions/advanced-configuration-and-troubleshooting/troubleshooting-github-actions-for-your-enterprise#enabling-workflows-triggered-by-dependabot-access-to-dependabot-secrets-and-increased-permissions)."
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Creating an enterprise account
|
||||
intro: "If you're currently using {% data variables.product.prodname_ghe_cloud %} with a single organization, you can create an enterprise account to centrally manage multiple organizations."
|
||||
versions:
|
||||
ghec: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Accounts
|
||||
- Enterprise
|
||||
- Fundamentals
|
||||
permissions: Organization owners can create an enterprise account.
|
||||
shortTitle: Create enterprise account
|
||||
---
|
||||
|
||||
## About enterprise account creation
|
||||
|
||||
{% data variables.product.prodname_ghe_cloud %} includes the option to create an enterprise account, which enables collaboration between multiple organizations and gives administrators a single point of visibility and management. For more information, see "[About enterprise accounts](/admin/overview/about-enterprise-accounts)."
|
||||
|
||||
{% data reusables.enterprise.create-an-enterprise-account %} If you pay by invoice, you can create an enterprise account yourself on {% data variables.product.prodname_dotcom %}. If not, you can [contact our sales team](https://github.com/enterprise/contact?ref_page=/pricing&ref_cta=Contact%20Sales&ref_loc=cards) to move to invoicing.
|
||||
|
||||
An enterprise account is included in {% data variables.product.prodname_ghe_cloud %}, so creating one will not affect your bill.
|
||||
|
||||
When you create an enterprise account, your existing organization will automatically be owned by the enterprise account. All current owners of your organization will become owners of the enterprise account. All current billing managers of the organization will become billing managers of the new enterprise account. The current billing details of the organization, including the organization's billing email address, will become billing details of the new enterprise account.
|
||||
|
||||
## Creating an enterprise account on {% data variables.product.prodname_dotcom %}
|
||||
|
||||
To create an enterprise account on {% data variables.product.prodname_dotcom %}, your organization must be using {% data variables.product.prodname_ghe_cloud %} and paying by invoice.
|
||||
|
||||
{% data reusables.organizations.billing-settings %}
|
||||
1. Click **Upgrade to enterprise account**.
|
||||
|
||||
|
||||
1. Under "Enterprise name", type a name for your enterprise account.
|
||||
|
||||
|
||||
1. Under "Enterprise URL slug", type a slug for your enterprise account. This slug will be used in the URL for your enterprise. For example, if you choose `octo-enterprise`, the URL for your enterprise will be `https://github.com/enterprises/octo-enterprise`.
|
||||
|
||||
|
||||
1. Click **Confirm and upgrade**.
|
||||
|
||||
|
||||
1. Read the warnings, then click **Create enterprise account**.
|
||||
|
||||
|
||||
|
||||
## Next steps
|
||||
|
||||
After your enterprise account is created, we recommend learning more about how enterprise accounts work and configuring settings and policies. For more information, follow the "[Get started with your enterprise account](/admin/guides#get-started-with-your-enterprise-account)" learning path.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Impersonating a user
|
||||
intro: 'You can impersonate users and perform actions on their behalf, for troubleshooting, unblocking, and other legitimate reasons.'
|
||||
permissions: 'Enterprise owners can impersonate users within their enterprise.'
|
||||
versions:
|
||||
ghes: '>3.2'
|
||||
type: how_to
|
||||
topics:
|
||||
- Administrator
|
||||
- Enterprise
|
||||
- User account
|
||||
shortTitle: Impersonate a user
|
||||
---
|
||||
|
||||
## About user impersonation
|
||||
|
||||
If you need to temporarily take over a user account, for example when troubleshooting a user problem, or when the user is unavailable and urgent action is required, you can start an impersonation session to act on their behalf.
|
||||
|
||||
For each impersonation session, you need to provide a reason for the impersonation. A session is limited to one hour, and you will have the same access as the user being impersonated.
|
||||
|
||||
Actions you perform during an impersonation session are recorded as events in the enterprise audit log, as well as the impersonated user's security log. The person being impersonated is sent an email notification when the impersonation session starts. For more information, see "[Audited actions](/admin/user-management/monitoring-activity-in-your-enterprise/audited-actions)" and "[Reviewing your security log](/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log)."
|
||||
|
||||
## Impersonating a user
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
{% data reusables.enterprise_site_admin_settings.search-user %}
|
||||
{% data reusables.enterprise_site_admin_settings.click-user %}
|
||||
4. In the top left of the page, click **User info**.
|
||||
|
||||
|
||||
5. Under "Danger Zone", click **Sign in to GitHub as @username**
|
||||
|
||||
|
||||
6. Select a reason from the dropdown list. If you select **Other** you will need to provide additional context in the **Notes** section. Click **Begin impersonation** to begin the session.
|
||||
|
||||
|
||||
7. When you are ready to end the impersonation session, click the **Return to your mundane life as username** banner at the top of the page.
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: About Visual Studio subscriptions with GitHub Enterprise
|
||||
intro: 'You can give {% data variables.product.prodname_vs %} subscribers on your team access to {% data variables.product.prodname_enterprise %} with a combined offering from Microsoft.'
|
||||
redirect_from:
|
||||
- /github/setting-up-and-managing-your-enterprise/managing-your-enterprise-account/managing-licenses-for-visual-studio-subscription-with-github-enterprise
|
||||
- /github/setting-up-and-managing-your-enterprise/managing-licenses-for-the-github-enterprise-and-visual-studio-bundle
|
||||
- /github/setting-up-and-managing-your-enterprise-account/managing-licenses-for-the-github-enterprise-and-visual-studio-bundle
|
||||
- /github/articles/about-the-github-and-visual-studio-bundle
|
||||
- /articles/about-the-github-and-visual-studio-bundle
|
||||
- /github/setting-up-and-managing-your-enterprise-account/managing-licenses-for-visual-studio-subscription-with-github-enterprise
|
||||
- /github/setting-up-and-managing-your-enterprise/managing-licenses-for-visual-studio-subscription-with-github-enterprise
|
||||
- /billing/managing-your-license-for-github-enterprise/managing-licenses-for-visual-studio-subscription-with-github-enterprise
|
||||
versions:
|
||||
ghec: '*'
|
||||
type: overview
|
||||
topics:
|
||||
- Enterprise
|
||||
- Licensing
|
||||
shortTitle: About
|
||||
---
|
||||
|
||||
## About {% data variables.product.prodname_vss_ghe %}
|
||||
|
||||
{% data reusables.enterprise-accounts.vss-ghe-description %} {% data variables.product.prodname_vss_ghe %} is available from Microsoft under the terms of the Microsoft Enterprise Agreement. For more information, see [{% data variables.product.prodname_vss_ghe %}](https://visualstudio.microsoft.com/subscriptions/visual-studio-github/) on the {% data variables.product.prodname_vs %} website.
|
||||
|
||||
To use the {% data variables.product.prodname_enterprise %} portion of the license, each subscriber's user account on {% data variables.product.prodname_dotcom_the_website %} must be or become a member of an organization owned by your enterprise on {% data variables.product.prodname_dotcom_the_website %}. To accomplish this, organization owners can invite new members to an organization by email address. The subscriber can accept the invitation with an existing user account on {% data variables.product.prodname_dotcom_the_website %} or create a new account.
|
||||
|
||||
For more information about the setup of {% data variables.product.prodname_vss_ghe %}, see "[Setting up {% data variables.product.prodname_vss_ghe %}](/billing/managing-licenses-for-visual-studio-subscriptions-with-github-enterprise/setting-up-visual-studio-subscriptions-with-github-enterprise)."
|
||||
|
||||
## About licenses for {% data variables.product.prodname_vss_ghe %}
|
||||
|
||||
After you assign a license for {% data variables.product.prodname_vss_ghe %} to a subscriber, the subscriber will use the {% data variables.product.prodname_enterprise %} portion of the license by joining an organization in your enterprise with a user account on {% data variables.product.prodname_dotcom_the_website %}. If the email address for the user account of an enterprise member on {% data variables.product.prodname_dotcom_the_website %} matches the User Primary Name (UPN) for a subscriber to your {% data variables.product.prodname_vs %} account, the {% data variables.product.prodname_vs %} subscriber will automatically consume one license for {% data variables.product.prodname_vss_ghe %}.
|
||||
|
||||
The total quantity of your licenses for your enterprise on {% data variables.product.prodname_dotcom %} is the sum of any standard {% data variables.product.prodname_enterprise %} licenses and the number of {% data variables.product.prodname_vs %} subscription licenses that include access to {% data variables.product.prodname_dotcom %}. If the user account for an enterprise member does not correspond with the email address for a {% data variables.product.prodname_vs %} subscriber, the license that the user account consumes is unavailable for a {% data variables.product.prodname_vs %} subscriber.
|
||||
|
||||
For more information about {% data variables.product.prodname_enterprise %}, see "[{% data variables.product.company_short %}'s products](/github/getting-started-with-github/githubs-products#github-enterprise)." For more information about accounts on {% data variables.product.prodname_dotcom_the_website %}, see "[Types of {% data variables.product.prodname_dotcom %} accounts](/github/getting-started-with-github/types-of-github-accounts)."
|
||||
|
||||
You can view the number of {% data variables.product.prodname_enterprise %} licenses available to your enterprise on {% data variables.product.product_location %}. The list of pending invitations includes subscribers who are not yet members of at least one organization in your enterprise. For more information, see "[Viewing the subscription and usage for your enterprise account](/billing/managing-billing-for-your-github-account/viewing-the-subscription-and-usage-for-your-enterprise-account)" and "[Viewing people in your enterprise](/admin/user-management/managing-users-in-your-enterprise/viewing-people-in-your-enterprise#viewing-members-and-outside-collaborators)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: If you download a CSV file with your enterprise's license usage in step 6 of "[Viewing the subscription and usage for your enterprise account](https://docs-internal-19656--vss-ghe-s.herokuapp.com/en/enterprise-cloud@latest/billing/managing-billing-for-your-github-account/viewing-the-subscription-and-usage-for-your-enterprise-account#viewing-the-subscription-and-usage-for-your-enterprise-account)," any members with a missing value for the "Name" or "Profile" columns have not yet accepted an invitation to join an organization within the enterprise.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
You can also see pending {% data variables.product.prodname_enterprise %} invitations to subscribers in {% data variables.product.prodname_vss_admin_portal_with_url %}.
|
||||
|
||||
## Further reading
|
||||
|
||||
- [{% data variables.product.prodname_vs %} subscriptions with {% data variables.product.prodname_enterprise %}](https://docs.microsoft.com/visualstudio/subscriptions/access-github) in Microsoft Docs
|
||||
- [Use {% data variables.product.prodname_vs %} or {% data variables.product.prodname_vscode %} to deploy apps from {% data variables.product.prodname_dotcom %}](https://docs.microsoft.com/en-us/azure/developer/github/deploy-with-visual-studio) in Microsoft Docs
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Managing licenses for Visual Studio subscriptions with GitHub Enterprise
|
||||
shortTitle: Visual Studio & GitHub Enterprise
|
||||
intro: '{% data reusables.enterprise-accounts.vss-ghe-description %}'
|
||||
versions:
|
||||
ghec: '*'
|
||||
children:
|
||||
- /about-visual-studio-subscriptions-with-github-enterprise
|
||||
- /setting-up-visual-studio-subscriptions-with-github-enterprise
|
||||
---
|
||||
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Setting up Visual Studio subscriptions with GitHub Enterprise
|
||||
intro: "Your team's subscription to {% data variables.product.prodname_vs %} can also provide access to {% data variables.product.prodname_enterprise %}."
|
||||
versions:
|
||||
ghec: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Enterprise
|
||||
- Licensing
|
||||
shortTitle: Set up
|
||||
---
|
||||
|
||||
## About setup of {% data variables.product.prodname_vss_ghe %}
|
||||
|
||||
{% data reusables.enterprise-accounts.vss-ghe-description %} For more information, see "[About {% data variables.product.prodname_vss_ghe %}](/billing/managing-licenses-for-visual-studio-subscriptions-with-github-enterprise/about-visual-studio-subscriptions-with-github-enterprise)."
|
||||
|
||||
This guide shows you how your team can get {% data variables.product.prodname_vs %} subscribers licensed and started with {% data variables.product.prodname_enterprise %}.
|
||||
|
||||
## Roles for {% data variables.product.prodname_vss_ghe %}
|
||||
|
||||
Before setting up {% data variables.product.prodname_vss_ghe %}, it's important to understand the roles for this combined offering.
|
||||
|
||||
| Role | Service | Description | More information |
|
||||
| :- | :- | :- | :- |
|
||||
| **Subscriptions admin** | {% data variables.product.prodname_vs %} subscription | Person who assigns licenses for {% data variables.product.prodname_vs %} subscription | [Overview of admin responsibilities](https://docs.microsoft.com/en-us/visualstudio/subscriptions/admin-responsibilities) in Microsoft Docs |
|
||||
| **Subscriber** | {% data variables.product.prodname_vs %} subscription | Person who uses a license for {% data variables.product.prodname_vs %} subscription | [Visual Studio Subscriptions documentation](https://docs.microsoft.com/en-us/visualstudio/subscriptions/) in Microsoft Docs |
|
||||
| **Enterprise owner** | {% data variables.product.prodname_dotcom %} | Person who has a user account that's an administrator of an enterprise on {% data variables.product.product_location %} | "[Roles in an enterprise](/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise#enterprise-owner)" |
|
||||
| **Organization owner** | {% data variables.product.prodname_dotcom %} | Person who has a user account that's an owner of an organization in your team's enterprise on {% data variables.product.product_location %} | "[Roles in an organization](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#organization-owners)" |
|
||||
| **Enterprise member** | {% data variables.product.prodname_dotcom %} | Person who has a user account that's a member of an enterprise on {% data variables.product.product_location %} | "[Roles in an enterprise](/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise#enterprise-members)" |
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Your team's {% data variables.product.prodname_vs %} subscription must include {% data variables.product.prodname_enterprise %}. For more information, see [{% data variables.product.prodname_vs %} Subscriptions and Benefits](https://visualstudio.microsoft.com/subscriptions/) on the {% data variables.product.prodname_vs %} website and
|
||||
[Overview of admin responsibilities](https://docs.microsoft.com/en-us/visualstudio/subscriptions/admin-responsibilities) in Microsoft Docs.
|
||||
|
||||
- Your team must have an enterprise on {% data variables.product.product_location %}. If you're not sure whether your team has an enterprise, contact your {% data variables.product.prodname_dotcom %} administrator. If you're not sure who on your team is responsible for {% data variables.product.prodname_dotcom %}, contact {% data variables.contact.contact_enterprise_sales %}. For more information, see "[About enterprise accounts](/admin/overview/about-enterprise-accounts)."
|
||||
|
||||
## Setting up {% data variables.product.prodname_vss_ghe %}
|
||||
|
||||
To set up {% data variables.product.prodname_vss_ghe %}, members of your team must complete the following tasks.
|
||||
|
||||
One person may be able to complete the tasks because the person has all of the roles, but you may need to coordinate the tasks with multiple people. For more information, see "[Roles for {% data variables.product.prodname_vss_ghe %}](#roles-for-visual-studio-subscriptions-with-github-enterprise)."
|
||||
|
||||
1. An [enterprise owner](#roles-for-visual-studio-subscriptions-with-github-enterprise) must create at least one organization in your enterprise on {% data variables.product.product_location %}. For more information, see "[Adding organizations to your enterprise](/admin/user-management/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise)."
|
||||
|
||||
1. The [subscription admin](#roles-for-visual-studio-subscriptions-with-github-enterprise) must assign a license for {% data variables.product.prodname_vs %} to a [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) in {% data variables.product.prodname_vss_admin_portal_with_url %}. For more information, see [Overview of the {% data variables.product.prodname_vs %} Subscriptions Administrator Portal](https://docs.microsoft.com/en-us/visualstudio/subscriptions/using-admin-portal) and [Assign {% data variables.product.prodname_vs %} Licenses in the {% data variables.product.prodname_vs %} Subscriptions Administration Portal](https://docs.microsoft.com/en-us/visualstudio/subscriptions/assign-license) in Microsoft Docs.
|
||||
|
||||
1. Optionally, if the [subscription admin](#roles-for-visual-studio-subscriptions-with-github-enterprise) assigned licenses to [subscribers](#roles-for-visual-studio-subscriptions-with-github-enterprise) in {% data variables.product.prodname_vs %} before adding {% data variables.product.prodname_enterprise %} to the subscription, the [subscription admin](#roles-for-visual-studio-subscriptions-with-github-enterprise) can move the [subscribers](#roles-for-visual-studio-subscriptions-with-github-enterprise) to the combined offering in the {% data variables.product.prodname_vs %} administration portal. For more information, see [Manage {% data variables.product.prodname_vs %} subscriptions with {% data variables.product.prodname_enterprise %}](https://docs.microsoft.com/en-us/visualstudio/subscriptions/assign-github#moving-to-visual-studio-with-github-enterprise) in Microsoft Docs.
|
||||
|
||||
1. If the [subscription admin](#roles-for-visual-studio-subscriptions-with-github-enterprise) has not disabled email notifications, the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) will receive two confirmation emails. For more information, see [{% data variables.product.prodname_vs %} subscriptions with {% data variables.product.prodname_enterprise %}](https://docs.microsoft.com/en-us/visualstudio/subscriptions/access-github#what-is-the-visual-studio-subscription-with-github-enterprise-setup-process) in Microsoft Docs.
|
||||
|
||||
1. An [organization owner](#roles-for-visual-studio-subscriptions-with-github-enterprise) must invite the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) to the organization on {% data variables.product.product_location %} from step 1. The [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) can accept the invitation with an existing user account on {% data variables.product.prodname_dotcom_the_website %} or create a new account. After the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) joins the organization, the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) becomes an [enterprise member](#roles-for-visual-studio-subscriptions-with-github-enterprise). For more information, see "[Inviting users to join your organization](/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tips**:
|
||||
|
||||
- While not required, we recommend that the [organization owner](#roles-for-visual-studio-subscriptions-with-github-enterprise) sends an invitation to the same email address used for the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise)'s User Primary Name (UPN). When the email address on {% data variables.product.product_location %} matches the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise)'s UPN, you can ensure that another [enterprise member](#roles-for-visual-studio-subscriptions-with-github-enterprise) does not claim the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise)'s license.
|
||||
- If the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) accepts the invitation to the organization with an existing user account on {% data variables.product.product_location %}, we recommend that the [subscriber](#roles-for-visual-studio-subscriptions-with-github-enterprise) add the email address they use for {% data variables.product.prodname_vs %} to their user account on {% data variables.product.product_location %}. For more information, see "[Adding an email address to your {% data variables.product.prodname_dotcom %} account](/account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/adding-an-email-address-to-your-github-account)."
|
||||
- If the [organization owner](#roles-for-visual-studio-subscriptions-with-github-enterprise) must invite a large number of [subscribers](#roles-for-visual-studio-subscriptions-with-github-enterprise), a script may make the process faster. For more information, see [the sample PowerShell script](https://github.com/github/platform-samples/blob/master/api/powershell/invite_members_to_org.ps1) in the `github/platform-samples` repository.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
After {% data variables.product.prodname_vss_ghe %} is set up for [subscribers](#roles-for-visual-studio-subscriptions-with-github-enterprise) on your team, [enterprise owners](#roles-for-visual-studio-subscriptions-with-github-enterprise) can review licensing information on {% data variables.product.product_location %}. For more information, see "[Viewing the subscription and usage for your enterprise account](/billing/managing-billing-for-your-github-account/viewing-the-subscription-and-usage-for-your-enterprise-account)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Getting started with {% data variables.product.prodname_ghe_cloud %}](/get-started/onboarding/getting-started-with-github-enterprise-cloud)"
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: Tracking code scanning alerts in issues using task lists
|
||||
shortTitle: Track alerts in issues
|
||||
intro: 'You can add code scanning alerts to issues using task lists. This makes it easy to create a plan for development work that includes fixing alerts.'
|
||||
product: '{% data reusables.gated-features.code-scanning %}'
|
||||
permissions: 'If you have write permission to a repository you can track {% data variables.product.prodname_code_scanning %} alerts in issues using task lists.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '> 3.3'
|
||||
ghae: "issue-5036"
|
||||
type: how_to
|
||||
topics:
|
||||
- Advanced Security
|
||||
- Code scanning
|
||||
- Alerts
|
||||
- Repositories
|
||||
- Issues
|
||||
---
|
||||
|
||||
{% data reusables.code-scanning.beta-alert-tracking-in-issues %}
|
||||
|
||||
## About tracking {% data variables.product.prodname_code_scanning %} alerts in issues
|
||||
|
||||
{% data reusables.code-scanning.github-issues-integration %}
|
||||
|
||||
You can also create a new issue to track an alert:
|
||||
- From a {% data variables.product.prodname_code_scanning %} alert, which automatically adds the code scanning alert to a task list in the new issue. For more information, see "[Creating a tracking issue from a {% data variables.product.prodname_code_scanning %} alert](#creating-a-tracking-issue-from-a-code-scanning-alert)" below.
|
||||
|
||||
- Via the API as you normally would, and then provide the code scanning link within the body of the issue. You must use the task list syntax to create the tracked relationship:
|
||||
- `- [ ] <full-URL- to-the-code-scanning-alert>`
|
||||
- For example, if you add `- [ ] https://github.com/octocat-org/octocat-repo/security/code-scanning/17` to an issue, the issue will track the code scanning alert that has an ID number of 17 in the "Security" tab of the `octocat-repo` repository in the `octocat-org` organization.
|
||||
|
||||
You can use more than one issue to track the same {% data variables.product.prodname_code_scanning %} alert, and issues can belong to different repositories from the repository where the {% data variables.product.prodname_code_scanning %} alert was found.
|
||||
|
||||
|
||||
{% data variables.product.product_name %} provides visual cues in different locations of the user interface to indicate when you are tracking {% data variables.product.prodname_code_scanning %} alerts in issues.
|
||||
|
||||
- The code scanning alerts list page will show which alerts are tracked in issues so that you can view at a glance which alerts still require processing.
|
||||
|
||||
|
||||
|
||||
- A "tracked in" section will also show in the corresponding alert page.
|
||||
|
||||
|
||||
|
||||
- On the tracking issue, {% data variables.product.prodname_dotcom %} displays a security badge icon in the task list and on the hovercard.
|
||||
|
||||
{% note %}
|
||||
|
||||
Only users with write permissions to the repository will see the unfurled URL to the alert in the issue, as well as the hovercard. For users with read permissions to the repository, or no permissions at all, the alert will appear as a plain URL.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
The color of the icon is grey because an alert has a status of "open" or "closed" on every branch. The issue tracks an alert, so the alert cannot have a single open/closed state in the issue. If the alert is closed on one branch, the icon color will not change.
|
||||
|
||||
|
||||
|
||||
The status of the tracked alert won't change if you change the checkbox state of the corresponding task list item (checked/unchecked) in the issue.
|
||||
|
||||
## Creating a tracking issue from a code scanning alert
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-security %}
|
||||
{% data reusables.repositories.sidebar-code-scanning-alerts %}
|
||||
{% ifversion fpt or ghes or ghae-next %}
|
||||
{% data reusables.code-scanning.explore-alert %}
|
||||
1. Optionally, to find the alert to track, you can use the free-text search or the drop-down menus to filter and locate the alert. For more information, see "[Managing code scanning alerts for your repository](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/managing-code-scanning-alerts-for-your-repository#filtering-code-scanning-alerts)."
|
||||
{% endif %}
|
||||
1. Towards the top of the page, on the right side, click **Create issue**.
|
||||
|
||||
{% data variables.product.prodname_dotcom %} automatically creates an issue to track the alert and adds the alert as a task list item.
|
||||
{% data variables.product.prodname_dotcom %} prepopulates the issue:
|
||||
- The title contains the name of the {% data variables.product.prodname_code_scanning %} alert.
|
||||
- The body contains the task list item with the full URL to the {% data variables.product.prodname_code_scanning %} alert.
|
||||
2. Optionally, edit the title and the body of the issue.
|
||||
{% warning %}
|
||||
|
||||
**Warning:** You may want to edit the title of the issue as it may expose security information. You can also edit the body of the issue, but do not edit the task list item or the issue will no longer track the alert.
|
||||
{% endwarning %}
|
||||
|
||||
|
||||
3. Click **Submit new issue**.
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
title: Enabling and disabling Dependabot version updates
|
||||
intro: 'You can configure your repository so that {% data variables.product.prodname_dependabot %} automatically updates the packages you use.'
|
||||
permissions: 'People with write permissions to a repository can enable or disable {% data variables.product.prodname_dependabot_version_updates %} for the repository.'
|
||||
redirect_from:
|
||||
- /github/administering-a-repository/enabling-and-disabling-version-updates
|
||||
- /code-security/supply-chain-security/enabling-and-disabling-version-updates
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-version-updates
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '> 3.2'
|
||||
type: how_to
|
||||
topics:
|
||||
- Dependabot
|
||||
- Version updates
|
||||
- Repositories
|
||||
- Dependencies
|
||||
- Pull requests
|
||||
shortTitle: Enable and disable updates
|
||||
---
|
||||
<!--Marketing-LINK: From /features/security/software-supply-chain page "About version updates for dependencies".-->
|
||||
{% data reusables.dependabot.beta-security-and-version-updates %}
|
||||
{% data reusables.dependabot.enterprise-enable-dependabot %}
|
||||
|
||||
## About version updates for dependencies
|
||||
|
||||
You enable {% data variables.product.prodname_dependabot_version_updates %} by checking a *dependabot.yml* configuration file in to your repository's `.github` directory. {% data variables.product.prodname_dependabot %} then raises pull requests to keep the dependencies you configure up-to-date. For each package manager's dependencies that you want to update, you must specify the location of the package manifest files and how often to check for updates to the dependencies listed in those files. For information about enabling security updates, see "[Configuring {% data variables.product.prodname_dependabot_security_updates %}](/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)."
|
||||
|
||||
{% data reusables.dependabot.initial-updates %} For more information, see "[Customizing dependency updates](/github/administering-a-repository/customizing-dependency-updates)."
|
||||
|
||||
{% data reusables.dependabot.private-dependencies-note %} Additionally, {% data variables.product.prodname_dependabot %} doesn't support private {% data variables.product.prodname_dotcom %} dependencies for all package managers. For more information, see "[About Dependabot version updates](/github/administering-a-repository/about-dependabot-version-updates#supported-repositories-and-ecosystems)" and "[{% data variables.product.prodname_dotcom %} language support](/github/getting-started-with-github/github-language-support)."
|
||||
|
||||
## Enabling {% data variables.product.prodname_dependabot_version_updates %}
|
||||
|
||||
{% data reusables.dependabot.create-dependabot-yml %} For information, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates)."
|
||||
1. Add a `version`.
|
||||
1. Optionally, if you have dependencies in a private registry, add a `registries` section containing authentication details.
|
||||
1. Add an `updates` section, with an entry for each package manager you want {% data variables.product.prodname_dependabot %} to monitor.
|
||||
1. For each package manager, use:
|
||||
- `package-ecosystem` to specify the package manager.
|
||||
- `directory` to specify the location of the manifest or other definition files.
|
||||
- `schedule.interval` to specify how often to check for new versions.
|
||||
{% data reusables.dependabot.check-in-dependabot-yml %}
|
||||
|
||||
### Example *dependabot.yml* file
|
||||
|
||||
The example *dependabot.yml* file below configures version updates for two package managers: npm and Docker. When this file is checked in, {% data variables.product.prodname_dependabot %} checks the manifest files on the default branch for outdated dependencies. If it finds outdated dependencies, it will raise pull requests against the default branch to update the dependencies.
|
||||
|
||||
```yaml
|
||||
# Basic dependabot.yml file with
|
||||
# minimum configuration for two package managers
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Enable version updates for npm
|
||||
- package-ecosystem: "npm"
|
||||
# Look for `package.json` and `lock` files in the `root` directory
|
||||
directory: "/"
|
||||
# Check the npm registry for updates every day (weekdays)
|
||||
schedule:
|
||||
interval: "daily"
|
||||
|
||||
# Enable version updates for Docker
|
||||
- package-ecosystem: "docker"
|
||||
# Look for a `Dockerfile` in the `root` directory
|
||||
directory: "/"
|
||||
# Check for updates once a week
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
```
|
||||
|
||||
In the example above, if the Docker dependencies were very outdated, you might want to start with a `daily` schedule until the dependencies are up-to-date, and then drop back to a weekly schedule.
|
||||
|
||||
### Enabling version updates on forks
|
||||
|
||||
If you want to enable version updates on forks, there's an extra step. Version updates are not automatically enabled on forks when a *dependabot.yml* configuration file is present. This ensures that fork owners don't unintentionally enable version updates when they pull changes including a *dependabot.yml* configuration file from the original repository.
|
||||
|
||||
On a fork, you also need to explicitly enable {% data variables.product.prodname_dependabot %}.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.accessing-repository-graphs %}
|
||||
{% data reusables.repositories.click-dependency-graph %}
|
||||
{% data reusables.dependabot.click-dependabot-tab %}
|
||||
5. Under "Enable Dependabot", click **Enable Dependabot**.
|
||||
|
||||
## Checking the status of version updates
|
||||
|
||||
After you enable version updates, the **Dependabot** tab in the dependency graph for the repository is populated. This tab shows which package managers {% data variables.product.prodname_dependabot %} is configured to monitor and when {% data variables.product.prodname_dependabot %} last checked for new versions.
|
||||
|
||||
|
||||
|
||||
For information, see "[Listing dependencies configured for version updates](/github/administering-a-repository/listing-dependencies-configured-for-version-updates)."
|
||||
|
||||
## Disabling {% data variables.product.prodname_dependabot_version_updates %}
|
||||
|
||||
You can disable version updates entirely by deleting the *dependabot.yml* file from your repository. More usually, you want to disable updates temporarily for one or more dependencies, or package managers.
|
||||
|
||||
- Package managers: disable by setting `open-pull-requests-limit: 0` or by commenting out the relevant `package-ecosystem` in the configuration file.
|
||||
- Specific dependencies: disable by adding `ignore` attributes for packages or applications that you want to exclude from updates.
|
||||
|
||||
When you disable dependencies, you can use wild cards to match a set of related libraries. You can also specify which versions to exclude. This is particularly useful if you need to block updates to a library, pending work to support a breaking change to its API, but want to get any security fixes to the version you use.
|
||||
|
||||
### Example disabling version updates for some dependencies
|
||||
|
||||
The example *dependabot.yml* file below includes examples of the different ways to disable updates to some dependencies, while allowing other updates to continue.
|
||||
|
||||
```yaml
|
||||
# dependabot.yml file with updates
|
||||
# disabled for Docker and limited for npm
|
||||
|
||||
version: 2
|
||||
updates:
|
||||
# Configuration for Dockerfile
|
||||
- package-ecosystem: "docker"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
# Disable all pull requests for Docker dependencies
|
||||
open-pull-requests-limit: 0
|
||||
|
||||
# Configuration for npm
|
||||
- package-ecosystem: "npm"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "daily"
|
||||
ignore:
|
||||
# Ignore updates to packages that start with 'aws'
|
||||
# Wildcards match zero or more arbitrary characters
|
||||
- dependency-name: "aws*"
|
||||
# Ignore some updates to the 'express' package
|
||||
- dependency-name: "express"
|
||||
# Ignore only new versions for 4.x and 5.x
|
||||
versions: ["4.x", "5.x"]
|
||||
# For all packages, ignore all patch updates
|
||||
- dependency-name: "*"
|
||||
update-types: ["version-update:semver-patch"]
|
||||
```
|
||||
|
||||
For more information about checking for existing ignore preferences, see "[Configuration options for dependency updates](/github/administering-a-repository/configuration-options-for-dependency-updates#ignore)."
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: Codespaces lifecycle
|
||||
intro: 'You can develop in a {% data variables.product.prodname_codespaces %} environment and maintain your data throughout the entire codespace lifecycle.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
type: overview
|
||||
topics:
|
||||
- Codespaces
|
||||
- Developer
|
||||
product: '{% data reusables.gated-features.codespaces %}'
|
||||
---
|
||||
|
||||
## About the lifecycle of a codespace
|
||||
|
||||
The lifecycle of a codespace begins when you create a codespace and ends when you delete it. You can disconnect and reconnect to an active codespace without affecting its running processes. You may stop and restart a codespace without losing changes that you have made to your project.
|
||||
|
||||
## Creating a codespace
|
||||
|
||||
When you want to work on a project, you can choose to create a new codespace or open an existing codespace. You might want to create a new codespace from a branch of your project each time you develop in {% data variables.product.prodname_codespaces %} or keep a long-running codespace for a feature.
|
||||
|
||||
If you choose to create a new codespace each time you work on a project, you should regularly push your changes so that any new commits are on {% data variables.product.prodname_dotcom %}. You can have up to 10 codespaces at a time. Once you have 10 codespaces, you must delete a codespace before you can create a new one. For more information, see "[Creating a codespace](/codespaces/developing-in-codespaces/creating-a-codespace)."
|
||||
|
||||
If you choose to use a long-running codespace for your project, you should pull from your repository's default branch each time you start working in your codespace so that your environment has the latest commits. This workflow is very similar to if you were working with a project on your local machine.
|
||||
|
||||
## Saving changes in a codespace
|
||||
|
||||
When you connect to a codespace through the web, auto-save is enabled automatically for the web editor and configured to save changes after a delay. When you connect to a codespace through {% data variables.product.prodname_vscode %} running on your desktop, you must enable auto-save. For more information, see [Save/Auto Save](https://code.visualstudio.com/docs/editor/codebasics#_save-auto-save) in the {% data variables.product.prodname_vscode %} documentation.
|
||||
|
||||
If you want to save your changes in the git repository on the codespace's file system, commit them and push them to a remote branch.
|
||||
|
||||
If you have unsaved changes, your editor will prompt you to save them before exiting.
|
||||
|
||||
## Codespaces timeouts
|
||||
|
||||
If you leave your codespace running without interaction or if you exit your codespace without explicitly stopping it, the codespace will timeout after 30 minutes of inactivity and stop running. For more information, see "[Stopping a codespace](#stopping-a-codespace)."
|
||||
|
||||
When a codespace times out, your data is preserved from the last time your changes were saved. For more information, see "[Saving changes in a codespace](#saving-changes-in-a-codespace)."
|
||||
|
||||
## Rebuilding a codespace
|
||||
|
||||
You can rebuild your codespace to restore a clean state as if you had created a new codespace. For most uses, you can create a new codespace as an alternative to rebuilding a codespace. You are most likely to rebuild a codespace to implement changes to your dev container. When you rebuild a codespace, any Docker containers, images, volumes, and caches are cleaned, then the codespace is rebuilt.
|
||||
|
||||
If you need any of this data to persist over a rebuild, you can create, at the desired location in the container, a symbolic link (symlink) to the persistent directory. For example, in your `.devcontainer` directory, you can create a `config` directory that will be preserved across a rebuild. You can then symlink the `config` directory and its contents as a `postCreateCommand` in your `devcontainer.json` file.
|
||||
|
||||
```json
|
||||
{
|
||||
"image": "mcr.microsoft.com/vscode/devcontainers/base:alpine",
|
||||
"postCreateCommand": ".devcontainer/postCreate.sh"
|
||||
}
|
||||
```
|
||||
|
||||
In the example `postCreate.sh` file below, the contents of the `config` directory are symbolically linked to the home directory.
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
ln -sf $PWD/.devcontainer/config $HOME/config && set +x
|
||||
```
|
||||
|
||||
## Stopping a codespace
|
||||
|
||||
You can stop a codespace at any time. When you stop a codespace, any running processes are stopped and the terminal history is cleared. Any saved changes in your codespace will still be available when you next start it. If you do not explicitly stop a codespace, it will continue to run until it times out from inactivity. For more information, see "[Codespaces timeouts](#codespaces-timeouts)."
|
||||
|
||||
Only running codespaces incur CPU charges; a stopped codespace incurs only storage costs.
|
||||
|
||||
You may want to stop and restart a codespace to apply changes to it. For example, if you change the machine type used for your codespace, you will need to stop and restart it for the change to take effect. You can also stop your codespace and choose to restart or delete it if you encounter an error or something unexpected. For more information, see "[Suspending or stopping a codespace](/codespaces/codespaces-reference/using-the-command-palette-in-codespaces#suspending-or-stopping-a-codespace)."
|
||||
|
||||
## Deleting a codespace
|
||||
|
||||
You can create a codespace for a particular task and then safely delete the codespace after you push your changes to a remote branch.
|
||||
|
||||
If you try to delete a codespace with unpushed git commits, your editor will notify you that you have changes that have not been pushed to a remote branch. You can push any desired changes and then delete your codespace, or continue to delete your codespace and any uncommitted changes. You can also export your code to a new branch without creating a new codespace. For more information, see "[Exporting changes to a branch](/codespaces/troubleshooting/exporting-changes-to-a-branch)."
|
||||
|
||||
You will be charged for the storage of all your codespaces. When you delete a codespace, you will no longer be charged.
|
||||
|
||||
For more information on deleting a codespace, see "[Deleting a codespace](/codespaces/developing-in-codespaces/deleting-a-codespace)."
|
||||
|
||||
## Losing the connection while using Codespaces
|
||||
|
||||
{% data variables.product.prodname_codespaces %} is a cloud-based development environment and requires an internet connection. If you lose connection to the internet while working in a codespace, you will not be able to access your codespace. However, any uncommitted changes will be saved. When you have access to an internet connection again, you can connect to your codespace in the exact same state that it was left in. If you have an unstable internet connection, you should commit and push your changes often.
|
||||
|
||||
If you know that you will often be working offline, you can use your `devcontainer.json` file with the ["{% data variables.product.prodname_vscode %} Remote - Containers" extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) to build and attach to a local development container for your repository. For more information, see [Developing inside a container](https://code.visualstudio.com/docs/remote/containers) in the {% data variables.product.prodname_vscode %} documentation.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Coordinated Disclosure of Security Vulnerabilities
|
||||
redirect_from:
|
||||
- /responsible-disclosure/
|
||||
- /coordinated-disclosure/
|
||||
- /articles/responsible-disclosure-of-security-vulnerabilities
|
||||
- /site-policy/responsible-disclosure-of-security-vulnerabilities
|
||||
versions:
|
||||
fpt: '*'
|
||||
topics:
|
||||
- Policy
|
||||
- Legal
|
||||
---
|
||||
We want to keep GitHub safe for everyone. If you've discovered a security vulnerability in GitHub, we appreciate your help in disclosing it to us in a coordinated manner.
|
||||
|
||||
## Bounty Program
|
||||
|
||||
Like several other large software companies, GitHub provides a bug bounty to better engage with security researchers. The idea is simple: hackers and security researchers (like you) find and report vulnerabilities through our coordinated disclosure process. Then, to recognize the significant effort that these researchers often put forth when hunting down bugs, we reward them with some cold hard cash.
|
||||
|
||||
Check out the [GitHub Bug Bounty](https://bounty.github.com) site for bounty details, review our comprehensive [Legal Safe Harbor Policy](/articles/github-bug-bounty-program-legal-safe-harbor) terms as well, and happy hunting!
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Exporting member information for your organization
|
||||
intro: You can export information about members in your organization, directly from the user interface.
|
||||
permissions: Organization owners can export member information for their organization.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.3'
|
||||
ghae: issue-5146
|
||||
topics:
|
||||
- Organizations
|
||||
- Teams
|
||||
shortTitle: Export member information
|
||||
---
|
||||
|
||||
You can export information about members in your organization. This is useful if you want to perform an audit of users within the organization. The exported information includes username and display name details, and whether the membership is public or private.
|
||||
|
||||
You can get member information directly from the {% data variables.product.product_name %} user interface, or using APIs. This article explains how to obtain member information from within {% data variables.product.product_name %}.
|
||||
|
||||
For more information about the APIs, see our [GraphQL API](/graphql/reference/objects#user) and [REST API](/rest/reference/users) documentation about users.
|
||||
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.user_settings.access_org %}
|
||||
{% data reusables.organizations.people %}
|
||||
{% data reusables.organizations.people-export %}
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: Managing code review settings for your team
|
||||
intro: You can decrease noise for your team by limiting notifications when your team is requested to review a pull request.
|
||||
redirect_from:
|
||||
- /github/setting-up-and-managing-organizations-and-teams/managing-code-review-assignment-for-your-team
|
||||
- /organizations/organizing-members-into-teams/managing-code-review-assignment-for-your-team
|
||||
product: '{% data reusables.gated-features.code-review-assignment %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Organizations
|
||||
- Teams
|
||||
shortTitle: Code review settings
|
||||
permissions: Team maintainers and organization owners can configure code review settings.
|
||||
---
|
||||
|
||||
## About code review settings
|
||||
|
||||
{% if only-notify-requested-members %}
|
||||
To reduce noise for your team and clarify individual responsibility for pull request reviews, you can configure code review settings.
|
||||
|
||||
- Team notifications
|
||||
- Auto assignment
|
||||
|
||||
## About team notifications
|
||||
|
||||
When you choose to only notify requested team members, you disable sending notifications to the entire team when the team is requested to review a pull request if a specific member of that team is also requested for review. This is especially useful when a repository is configured with teams as code owners, but contributors to the repository often know a specific individual that would be the correct reviewer for their pull request. For more information, see "[About code owners](/github/creating-cloning-and-archiving-repositories/about-code-owners)."
|
||||
|
||||
## About auto assignment
|
||||
{% endif %}
|
||||
|
||||
When you enable auto assignment, any time your team has been requested to review a pull request, the team is removed as a reviewer and a specified subset of team members are assigned in the team's place. Code review assignments allow you to decide whether the whole team or just a subset of team members are notified when a team is requested for review.
|
||||
|
||||
When code owners are automatically requested for review, the team is still removed and replaced with individuals unless a branch protection rule is configured to require review from code owners. If such a branch protection rule is in place, the team request cannot be removed and so the individual request will appear in addition.
|
||||
|
||||
{% ifversion fpt %}
|
||||
To further enhance your team's collaboration abilities, you can upgrade to {% data variables.product.prodname_ghe_cloud %}, which includes features like protected branches and code owners on private repositories. {% data reusables.enterprise.link-to-ghec-trial %}
|
||||
{% endif %}
|
||||
|
||||
### Routing algorithms
|
||||
|
||||
Code review assignments automatically choose and assign reviewers based on one of two possible algorithms.
|
||||
|
||||
The round robin algorithm chooses reviewers based on who's received the least recent review request, focusing on alternating between all members of the team regardless of the number of outstanding reviews they currently have.
|
||||
|
||||
The load balance algorithm chooses reviewers based on each member's total number of recent review requests and considers the number of outstanding reviews for each member. The load balance algorithm tries to ensure that each team member reviews an equal number of pull requests in any 30 day period.
|
||||
|
||||
Any team members that have set their status to "Busy" will not be selected for review. If all team members are busy, the pull request will remain assigned to the team itself. For more information about user statuses, see "[Setting a status](/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status)."
|
||||
|
||||
{% if only-notify-requested-members %}
|
||||
## Configuring team notifications
|
||||
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.user_settings.access_org %}
|
||||
{% data reusables.organizations.specific_team %}
|
||||
{% data reusables.organizations.team_settings %}
|
||||
5. In the left sidebar, click **Code review**
|
||||
|
||||
2. Select **Only notify requested team members.**
|
||||
|
||||
3. Click **Save changes**.
|
||||
{% endif %}
|
||||
|
||||
## Configuring auto assignment
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.user_settings.access_org %}
|
||||
{% data reusables.organizations.specific_team %}
|
||||
{% data reusables.organizations.team_settings %}
|
||||
5. In the left sidebar, click **Code review**
|
||||
|
||||
6. Select **Enable auto assignment**.
|
||||
|
||||
7. Under "How many team members should be assigned to review?", use the drop-down menu and choose a number of reviewers to be assigned to each pull request.
|
||||
|
||||
8. Under "Routing algorithm", use the drop-down menu and choose which algorithm you'd like to use. For more information, see "[Routing algorithms](#routing-algorithms)."
|
||||
|
||||
9. Optionally, to always skip certain members of the team, select **Never assign certain team members**. Then, select one or more team members you'd like to always skip.
|
||||
|
||||
{% ifversion fpt or ghec or ghae-next or ghes > 3.2 %}
|
||||
11. Optionally, to include members of child teams as potential reviewers when assigning requests, select **Child team members**.
|
||||
12. Optionally, to count any members whose review has already been requested against the total number of members to assign, select **Count existing requests**.
|
||||
13. Optionally, to remove the review request from the team when assigning team members, select **Team review request**.
|
||||
{%- else %}
|
||||
10. Optionally, to only notify the team members chosen by code review assignment for each pull review request, under "Notifications" select **If assigning team members, don't notify the entire team.**
|
||||
{%- endif %}
|
||||
14. Click **Save changes**.
|
||||
|
||||
## Disabling auto assignment
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.user_settings.access_org %}
|
||||
{% data reusables.organizations.specific_team %}
|
||||
{% data reusables.organizations.team_settings %}
|
||||
5. Select **Enable auto assignment** to remove the checkmark.
|
||||
|
||||
6. Click **Save changes**.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Verifying your custom domain for GitHub Pages
|
||||
intro: 'You can increase the security of your custom domain and avoid takeover attacks by verifying your domain.'
|
||||
product: '{% data reusables.gated-features.pages %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pages
|
||||
shortTitle: Verify a custom domain
|
||||
---
|
||||
|
||||
## About domain verification for GitHub Pages
|
||||
|
||||
When you verify your custom domain for your user account or organization, only repositories owned by your user account or organization may be used to publish a {% data variables.product.prodname_pages %} site to the verified custom domain or the domain's immediate subdomains.
|
||||
|
||||
Verifying your domain stops other GitHub users from taking over your custom domain and using it to publish their own {% data variables.product.prodname_pages %} site. Domain takeovers can happen when you delete your repository, when your billing plan is downgraded, or after any other change which unlinks the custom domain or disables {% data variables.product.prodname_pages %} while the domain remains configured for {% data variables.product.prodname_pages %} and is not verified.
|
||||
|
||||
When you verify a domain, any immediate subdomains are also included in the verification. For example, if the `github.com` custom domain is verified, `docs.github.com`, `support.github.com`, and any other immediate subdomains will also be protected from takeovers.
|
||||
|
||||
It's also possible to verify a domain for your organization{% ifversion ghec %} or enterprise{% endif %}, which displays a "Verified" badge on the organization {% ifversion ghec %}or enterprise{% endif %} profile{% ifversion ghec %} and, on {% data variables.product.prodname_ghe_cloud %}, allows you to restrict notifications to email addresses using the verified domain{% endif %}. For more information, see "[Verifying or approving a domain for your organization](/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization){% ifversion ghec %}" and "[Verifying or approving a domain for your enterprise](/enterprise-cloud@latest/admin/configuration/configuring-your-enterprise/verifying-or-approving-a-domain-for-your-enterprise){% endif %}."
|
||||
|
||||
## Verifying a domain for your user site
|
||||
|
||||
{% data reusables.user_settings.access_settings %}
|
||||
1. In the left sidebar, click **Pages**.
|
||||
|
||||
{% data reusables.pages.settings-verify-domain-setup %}
|
||||
1. Wait for your DNS configuration to change, this may be immediate or take up to 24 hours. You can confirm the change to your DNS configuration by running the `dig` command on the command line. In the command below, replace `USERNAME` with your username and `example.com` with the domain you're verifying. If your DNS configuration has updated, you should see your new TXT record in the output.
|
||||
```
|
||||
dig _github-pages-challenge-USERNAME.example.com +nostats +nocomments +nocmd TXT
|
||||
```
|
||||
{% data reusables.pages.settings-verify-domain-confirm %}
|
||||
|
||||
## Verifying a domain for your organization site
|
||||
|
||||
Organization owners can verify custom domains for their organization.
|
||||
|
||||
{% data reusables.profile.access_org %}
|
||||
{% data reusables.profile.org_settings %}
|
||||
1. In the left sidebar, click **Pages**.
|
||||
|
||||
{% data reusables.pages.settings-verify-domain-setup %}
|
||||
1. Wait for your DNS configuration to change, this may be immediate or take up to 24 hours. You can confirm the change to your DNS configuration by running the `dig` command on the command line. In the command below, replace `ORGANIZATION` with the name of your organization and `example.com` with the domain you're verifying. If your DNS configuration has updated, you should see your new TXT record in the output.
|
||||
```
|
||||
dig _github-pages-challenge-ORGANIZATION.example.com +nostats +nocomments +nocmd TXT
|
||||
```
|
||||
{% data reusables.pages.settings-verify-domain-confirm %}
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: About merge conflicts
|
||||
intro: 'Merge conflicts happen when you merge branches that have competing commits, and Git needs your help to decide which changes to incorporate in the final merge.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/addressing-merge-conflicts/about-merge-conflicts
|
||||
- /articles/about-merge-conflicts
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-merge-conflicts
|
||||
- /github/about-merge-conflicts
|
||||
- /github/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
Git can often resolve differences between branches and merge them automatically. Usually, the changes are on different lines, or even in different files, which makes the merge simple for computers to understand. However, sometimes there are competing changes that Git can't resolve without your help. Often, merge conflicts happen when people make different changes to the same line of the same file, or when one person edits a file and another person deletes the same file.
|
||||
|
||||
You must resolve all merge conflicts before you can merge a pull request on {% data variables.product.product_name %}. If you have a merge conflict between the compare branch and base branch in your pull request, you can view a list of the files with conflicting changes above the **Merge pull request** button. The **Merge pull request** button is deactivated until you've resolved all conflicts between the compare branch and base branch.
|
||||
|
||||
|
||||
|
||||
## Resolving merge conflicts
|
||||
|
||||
To resolve a merge conflict, you must manually edit the conflicted file to select the changes that you want to keep in the final merge. There are a couple of different ways to resolve a merge conflict:
|
||||
|
||||
- If your merge conflict is caused by competing line changes, such as when people make different changes to the same line of the same file on different branches in your Git repository, you can resolve it on {% data variables.product.product_name %} using the conflict editor. For more information, see "[Resolving a merge conflict on {% data variables.product.prodname_dotcom %}](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)."
|
||||
- For all other types of merge conflicts, you must resolve the merge conflict in a local clone of the repository and push the change to your branch on {% data variables.product.product_name %}. You can use the command line or a tool like [{% data variables.product.prodname_desktop %}](https://desktop.github.com/) to push the change. For more information, see "[Resolving a merge conflict on the command line](/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line)."
|
||||
|
||||
If you have a merge conflict on the command line, you cannot push your local changes to {% data variables.product.product_name %} until you resolve the merge conflict locally on your computer. If you try merging branches on the command line that have a merge conflict, you'll get an error message. For more information, see "[Resolving a merge conflict using the command line](/articles/resolving-a-merge-conflict-using-the-command-line/)."
|
||||
```shell
|
||||
$ git merge <em>BRANCH-NAME</em>
|
||||
> Auto-merging styleguide.md
|
||||
> CONFLICT (content): Merge conflict in styleguide.md
|
||||
> Automatic merge failed; fix conflicts and then commit the result
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull request merges](/articles/about-pull-request-merges/)"
|
||||
- "[About pull requests](/articles/about-pull-requests/)"
|
||||
- "[Resolving a merge conflict using the command line](/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line)"
|
||||
- "[Resolving a merge conflict on GitHub](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)"
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Addressing merge conflicts
|
||||
intro: 'If your changes have merge conflicts with the base branch, you must address the merge conflicts before you can merge your pull request''s changes.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/addressing-merge-conflicts/
|
||||
- /articles/addressing-merge-conflicts
|
||||
- /github/collaborating-with-pull-requests/addressing-merge-conflicts
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-merge-conflicts
|
||||
- /resolving-a-merge-conflict-on-github
|
||||
- /resolving-a-merge-conflict-using-the-command-line
|
||||
shortTitle: Address merge conflicts
|
||||
---
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Resolving a merge conflict on GitHub
|
||||
intro: 'You can resolve simple merge conflicts that involve competing line changes on GitHub, using the conflict editor.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github
|
||||
- /articles/resolving-a-merge-conflict-on-github
|
||||
- /github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github
|
||||
- /github/resolving-a-merge-conflict-on-github
|
||||
- /github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Resolve merge conflicts
|
||||
---
|
||||
You can only resolve merge conflicts on {% data variables.product.product_name %} that are caused by competing line changes, such as when people make different changes to the same line of the same file on different branches in your Git repository. For all other types of merge conflicts, you must resolve the conflict locally on the command line. For more information, see "[Resolving a merge conflict using the command line](/articles/resolving-a-merge-conflict-using-the-command-line/)."
|
||||
|
||||
{% ifversion ghes or ghae %}
|
||||
If a site administrator disables the merge conflict editor for pull requests between repositories, you cannot use the conflict editor on {% data variables.product.product_name %} and must resolve merge conflicts on the command line. For example, if the merge conflict editor is disabled, you cannot use it on a pull request between a fork and upstream repository.
|
||||
{% endif %}
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning:** When you resolve a merge conflict on {% data variables.product.product_name %}, the entire [base branch](/github/getting-started-with-github/github-glossary#base-branch) of your pull request is merged into the [head branch](/github/getting-started-with-github/github-glossary#head-branch). Make sure you really want to commit to this branch. If the head branch is the default branch of your repository, you'll be given the option of creating a new branch to serve as the head branch for your pull request. If the head branch is protected you won't be able to merge your conflict resolution into it, so you'll be prompted to create a new head branch. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the "Pull Requests" list, click the pull request with a merge conflict that you'd like to resolve.
|
||||
1. Near the bottom of your pull request, click **Resolve conflicts**.
|
||||
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** If the **Resolve conflicts** button is deactivated, your pull request's merge conflict is too complex to resolve on {% data variables.product.product_name %}{% ifversion ghes or ghae %} or the site administrator has disabled the conflict editor for pull requests between repositories{% endif %}. You must resolve the merge conflict using an alternative Git client, or by using Git on the command line. For more information see "[Resolving a merge conflict using the command line](/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line."
|
||||
|
||||
{% endtip %}
|
||||
{% data reusables.pull_requests.decide-how-to-resolve-competing-line-change-merge-conflict %}
|
||||
|
||||
1. If you have more than one merge conflict in your file, scroll down to the next set of conflict markers and repeat steps four and five to resolve your merge conflict.
|
||||
1. Once you've resolved all the conflicts in the file, click **Mark as resolved**.
|
||||
|
||||
1. If you have more than one file with a conflict, select the next file you want to edit on the left side of the page under "conflicting files" and repeat steps four through seven until you've resolved all of your pull request's merge conflicts.
|
||||
|
||||
1. Once you've resolved all your merge conflicts, click **Commit merge**. This merges the entire base branch into your head branch.
|
||||
|
||||
1. If prompted, review the branch that you are committing to.
|
||||
|
||||
If the head branch is the default branch of the repository, you can choose either to update this branch with the changes you made to resolve the conflict, or to create a new branch and use this as the head branch of the pull request.
|
||||
|
||||
|
||||
If you choose to create a new branch, enter a name for the branch.
|
||||
|
||||
If the head branch of your pull request is protected you must create a new branch. You won't get the option to update the protected branch.
|
||||
|
||||
Click **Create branch and update my pull request** or **I understand, continue updating _BRANCH_**. The button text corresponds to the action you are performing.
|
||||
1. To merge your pull request, click **Merge pull request**. For more information about other pull request merge options, see "[Merging a pull request](/articles/merging-a-pull-request/)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull request merges](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)"
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
title: Resolving a merge conflict using the command line
|
||||
intro: You can resolve merge conflicts using the command line and a text editor.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line
|
||||
- /articles/resolving-a-merge-conflict-from-the-command-line/
|
||||
- /articles/resolving-a-merge-conflict-using-the-command-line
|
||||
- /github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line
|
||||
- /github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Resolve merge conflicts in Git
|
||||
---
|
||||
Merge conflicts occur when competing changes are made to the same line of a file, or when one person edits a file and another person deletes the same file. For more information, see "[About merge conflicts](/articles/about-merge-conflicts/)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** You can use the conflict editor on {% data variables.product.product_name %} to resolve competing line change merge conflicts between branches that are part of a pull request. For more information, see "[Resolving a merge conflict on GitHub](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Competing line change merge conflicts
|
||||
|
||||
To resolve a merge conflict caused by competing line changes, you must choose which changes to incorporate from the different branches in a new commit.
|
||||
|
||||
For example, if you and another person both edited the file _styleguide.md_ on the same lines in different branches of the same Git repository, you'll get a merge conflict error when you try to merge these branches. You must resolve this merge conflict with a new commit before you can merge these branches.
|
||||
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Navigate into the local Git repository that has the merge conflict.
|
||||
```shell
|
||||
cd <em>REPOSITORY-NAME</em>
|
||||
```
|
||||
3. Generate a list of the files affected by the merge conflict. In this example, the file *styleguide.md* has a merge conflict.
|
||||
```shell
|
||||
$ git status
|
||||
> # On branch branch-b
|
||||
> # You have unmerged paths.
|
||||
> # (fix conflicts and run "git commit")
|
||||
> #
|
||||
> # Unmerged paths:
|
||||
> # (use "git add <file>..." to mark resolution)
|
||||
> #
|
||||
> # both modified: styleguide.md
|
||||
> #
|
||||
> no changes added to commit (use "git add" and/or "git commit -a")
|
||||
```
|
||||
4. Open your favorite text editor, such as [Atom](https://atom.io/), and navigate to the file that has merge conflicts.
|
||||
5. To see the beginning of the merge conflict in your file, search the file for the conflict marker `<<<<<<<`. When you open the file in your text editor, you'll see the changes from the HEAD or base branch after the line `<<<<<<< HEAD`. Next, you'll see `=======`, which divides your changes from the changes in the other branch, followed by `>>>>>>> BRANCH-NAME`. In this example, one person wrote "open an issue" in the base or HEAD branch and another person wrote "ask your question in IRC" in the compare branch or `branch-a`.
|
||||
|
||||
```
|
||||
If you have questions, please
|
||||
<<<<<<< HEAD
|
||||
open an issue
|
||||
=======
|
||||
ask your question in IRC.
|
||||
>>>>>>> branch-a
|
||||
```
|
||||
{% data reusables.pull_requests.decide-how-to-resolve-competing-line-change-merge-conflict %} In this example, both changes are incorporated into the final merge:
|
||||
|
||||
```shell
|
||||
If you have questions, please open an issue or ask in our IRC channel if it's more urgent.
|
||||
```
|
||||
7. Add or stage your changes.
|
||||
```shell
|
||||
$ git add .
|
||||
```
|
||||
8. Commit your changes with a comment.
|
||||
```shell
|
||||
$ git commit -m "Resolved merge conflict by incorporating both suggestions."
|
||||
```
|
||||
|
||||
You can now merge the branches on the command line or [push your changes to your remote repository](/github/getting-started-with-github/pushing-commits-to-a-remote-repository/) on {% data variables.product.product_name %} and [merge your changes](/articles/merging-a-pull-request/) in a pull request.
|
||||
|
||||
## Removed file merge conflicts
|
||||
|
||||
To resolve a merge conflict caused by competing changes to a file, where a person deletes a file in one branch and another person edits the same file, you must choose whether to delete or keep the removed file in a new commit.
|
||||
|
||||
For example, if you edited a file, such as *README.md*, and another person removed the same file in another branch in the same Git repository, you'll get a merge conflict error when you try to merge these branches. You must resolve this merge conflict with a new commit before you can merge these branches.
|
||||
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Navigate into the local Git repository that has the merge conflict.
|
||||
```shell
|
||||
cd <em>REPOSITORY-NAME</em>
|
||||
```
|
||||
2. Generate a list of the files affected by the merge conflict. In this example, the file *README.md* has a merge conflict.
|
||||
```shell
|
||||
$ git status
|
||||
> # On branch main
|
||||
> # Your branch and 'origin/main' have diverged,
|
||||
> # and have 1 and 2 different commits each, respectively.
|
||||
> # (use "git pull" to merge the remote branch into yours)
|
||||
> # You have unmerged paths.
|
||||
> # (fix conflicts and run "git commit")
|
||||
> #
|
||||
> # Unmerged paths:
|
||||
> # (use "git add/rm <file>..." as appropriate to mark resolution)
|
||||
> #
|
||||
> # deleted by us: README.md
|
||||
> #
|
||||
> # no changes added to commit (use "git add" and/or "git commit -a")
|
||||
```
|
||||
3. Open your favorite text editor, such as [Atom](https://atom.io/), and navigate to the file that has merge conflicts.
|
||||
6. Decide if you want keep the removed file. You may want to view the latest changes made to the removed file in your text editor.
|
||||
|
||||
To add the removed file back to your repository:
|
||||
```shell
|
||||
$ git add README.md
|
||||
```
|
||||
To remove this file from your repository:
|
||||
```shell
|
||||
$ git rm README.md
|
||||
> README.md: needs merge
|
||||
> rm 'README.md'
|
||||
```
|
||||
7. Commit your changes with a comment.
|
||||
```shell
|
||||
$ git commit -m "Resolved merge conflict by keeping README.md file."
|
||||
> [branch-d 6f89e49] Merge branch 'branch-c' into branch-d
|
||||
```
|
||||
|
||||
You can now merge the branches on the command line or [push your changes to your remote repository](/github/getting-started-with-github/pushing-commits-to-a-remote-repository/) on {% data variables.product.product_name %} and [merge your changes](/articles/merging-a-pull-request/) in a pull request.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About merge conflicts](/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts)"
|
||||
- "[Checking out pull requests locally](/articles/checking-out-pull-requests-locally/)"
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: About status checks
|
||||
intro: Status checks let you know if your commits meet the conditions set for the repository you're contributing to.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks
|
||||
- /articles/about-statuses/
|
||||
- /articles/about-status-checks
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-status-checks
|
||||
- /github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
Status checks are based on external processes, such as continuous integration builds, which run for each push you make to a repository. You can see the *pending*, *passing*, or *failing* state of status checks next to individual commits in your pull request.
|
||||
|
||||
|
||||
|
||||
Anyone with write permissions to a repository can set the state for any status check in the repository.
|
||||
|
||||
You can see the overall state of the last commit to a branch on your repository's branches page or in your repository's list of pull requests.
|
||||
|
||||
{% data reusables.pull_requests.required-checks-must-pass-to-merge %}
|
||||
|
||||
## Types of status checks on {% data variables.product.product_name %}
|
||||
|
||||
There are two types of status checks on {% data variables.product.product_name %}:
|
||||
|
||||
- Checks
|
||||
- Statuses
|
||||
|
||||
_Checks_ are different from _statuses_ in that they provide line annotations, more detailed messaging, and are only available for use with {% data variables.product.prodname_github_apps %}.
|
||||
|
||||
Organization owners and users with push access to a repository can create checks and statuses with {% data variables.product.product_name %}'s API. For more information, see "[Checks](/rest/reference/checks)" and "[Statuses](/rest/reference/repos#statuses)."
|
||||
|
||||
## Checks
|
||||
|
||||
When _checks_ are set up in a repository, pull requests have a **Checks** tab where you can view detailed build output from status checks and rerun failed checks.
|
||||
|
||||
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The **Checks** tab only gets populated for pull requests if you set up _checks_, not _statuses_, for the repository.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
When a specific line in a commit causes a check to fail, you will see details about the failure, warning, or notice next to the relevant code in the **Files** tab of the pull request.
|
||||
|
||||
|
||||
|
||||
You can navigate between the checks summaries for various commits in a pull request, using the commit drop-down menu under the **Conversation** tab.
|
||||
|
||||
|
||||
|
||||
### Skipping and requesting checks for individual commits
|
||||
|
||||
When a repository is set to automatically request checks for pushes, you can choose to skip checks for an individual commit you push. When a repository is _not_ set to automatically request checks for pushes, you can request checks for an individual commit you push. For more information on these settings, see "[Check Suites](/rest/reference/checks#update-repository-preferences-for-check-suites)."
|
||||
|
||||
To skip or request checks for your commit, add one of the following trailer lines to the end of your commit message:
|
||||
|
||||
- To _skip checks_ for a commit, type your commit message and a short, meaningful description of your changes. After your commit description, before the closing quotation, add two empty lines followed by `skip-checks: true`:
|
||||
```shell
|
||||
$ git commit -m "Update README
|
||||
>
|
||||
>
|
||||
skip-checks: true"
|
||||
```
|
||||
- To _request_ checks for a commit, type your commit message and a short, meaningful description of your changes. After your commit description, before the closing quotation, add two empty lines followed by `request-checks: true`:
|
||||
```shell
|
||||
$ git commit -m "Refactor usability tests
|
||||
>
|
||||
>
|
||||
request-checks: true"
|
||||
```
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Collaborating on repositories with code quality features
|
||||
intro: 'Workflow quality features like statuses, {% ifversion ghes %}pre-receive hooks, {% endif %}protected branches, and required status checks help collaborators make contributions that meet conditions set by organization and repository administrators.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/collaborating-on-repositories-with-code-quality-features/
|
||||
- /articles/collaborating-on-repositories-with-code-quality-features-enabled/
|
||||
- /articles/collaborating-on-repositories-with-code-quality-features
|
||||
- /github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-status-checks
|
||||
- /working-with-pre-receive-hooks
|
||||
shortTitle: Code quality features
|
||||
---
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Working with pre-receive hooks
|
||||
intro: '*Pre-receive hooks* enforce rules for contributions before commits may be pushed to a repository.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/collaborating-on-repositories-with-code-quality-features/working-with-pre-receive-hooks
|
||||
- /articles/working-with-pre-receive-hooks
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-pre-receive-hooks
|
||||
- /github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/working-with-pre-receive-hooks
|
||||
versions:
|
||||
ghes: '*'
|
||||
shortTitle: Pre-receive hooks
|
||||
---
|
||||
Pre-receive hooks run tests on code pushed to a repository to ensure contributions meet repository or organization policy. If the commit contents pass the tests, the push will be accepted into the repository. If the commit contents do not pass the tests, the push will not be accepted.
|
||||
|
||||
If your push isn't accepted, you'll see an error message corresponding to the failed pre-receive hook.
|
||||
|
||||
```shell
|
||||
$ git push
|
||||
Counting objects: 3, done.
|
||||
Delta compression using up to 4 threads.
|
||||
Compressing objects: 100% (2/2), done.
|
||||
Writing objects: 100% (3/3), 916 bytes | 0 bytes/s, done.
|
||||
Total 3 (delta 0), reused 0 (delta 0)
|
||||
remote: always_reject.sh: failed with exit status 1
|
||||
remote: error: rejecting all pushes
|
||||
To https://54.204.174.51/hodor/nope.git
|
||||
! [remote rejected] main -> main (pre-receive hook declined)
|
||||
error: failed to push some refs to 'https://54.204.174.51/hodor/nope.git'
|
||||
```
|
||||
|
||||
|
||||
|
||||
Your {% data variables.product.product_name %} site administrator can create and remove pre-receive hooks for your organization or repository, and may allow organization or repository administrators to enable or disable pre-receive hooks. For more information, see "[Using pre-receive hooks to enforce policy](/enterprise/{{ currentVersion }}/admin/guides/developer-workflow/using-pre-receive-hooks-to-enforce-policy)."
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: About collaborative development models
|
||||
intro: The way you use pull requests depends on the type of development model you use in your project. You can use the fork and pull model or the shared repository model.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/getting-started/about-collaborative-development-models
|
||||
- /articles/types-of-collaborative-development-models/
|
||||
- /articles/about-collaborative-development-models
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-collaborative-development-models
|
||||
- /github/collaborating-with-pull-requests/getting-started/about-collaborative-development-models
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Collaborative development
|
||||
---
|
||||
## Fork and pull model
|
||||
|
||||
In the fork and pull model, anyone can fork an existing repository and push changes to their personal fork. You do not need permission to the source repository to push to a user-owned fork. The changes can be pulled into the source repository by the project maintainer. When you open a pull request proposing changes from your user-owned fork to a branch in the source (upstream) repository, you can allow anyone with push access to the upstream repository to make changes to your pull request. This model is popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** {% data reusables.open-source.open-source-guide-general %} {% data reusables.open-source.open-source-learning-lab %}
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Shared repository model
|
||||
|
||||
In the shared repository model, collaborators are granted push access to a single shared repository and topic branches are created when changes need to be made. Pull requests are useful in this model as they initiate code review and general discussion about a set of changes before the changes are merged into the main development branch. This model is more prevalent with small teams and organizations collaborating on private projects.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)"
|
||||
- "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)"
|
||||
- "[Allowing changes to a pull request branch created from a fork](/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)"
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Getting started
|
||||
shortTitle: Getting started
|
||||
intro: 'Learn about the {% data variables.product.prodname_dotcom %} flow and different ways to collaborate on and discuss your projects.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/getting-started/
|
||||
- /github/collaborating-with-issues-and-pull-requests/overview
|
||||
- /github/collaborating-with-pull-requests/getting-started
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
- Issues
|
||||
- Discussions
|
||||
- Fundamentals
|
||||
children:
|
||||
- /about-collaborative-development-models
|
||||
---
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: About pull request merges
|
||||
intro: 'You can [merge pull requests](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request) by retaining all the commits in a feature branch, squashing all commits into a single commit, or by rebasing individual commits from the `head` branch onto the `base` branch.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges
|
||||
- /articles/about-pull-request-merge-squashing/
|
||||
- /articles/about-pull-request-merges
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-pull-request-merges
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
{% data reusables.pull_requests.default_merge_option %}
|
||||
|
||||
## Squash and merge your pull request commits
|
||||
|
||||
{% data reusables.pull_requests.squash_and_merge_summary %}
|
||||
|
||||
### Merge message for a squash merge
|
||||
|
||||
When you squash and merge, {% data variables.product.prodname_dotcom %} generates a commit message which you can change if you want to. The message default depends on whether the pull request contains multiple commits or just one. We do not include merge commits when we count the total number of commits.
|
||||
|
||||
Number of commits | Summary | Description |
|
||||
----------------- | ------- | ----------- |
|
||||
One commit | The title of the commit message for the single commit, followed by the pull request number | The body text of the commit message for the single commit
|
||||
More than one commit | The pull request title, followed by the pull request number | A list of the commit messages for all of the squashed commits, in date order
|
||||
|
||||
### Squashing and merging a long-running branch
|
||||
|
||||
If you plan to continue work on the [head branch](/github/getting-started-with-github/github-glossary#head-branch) of a pull request after the pull request is merged, we recommend you don't squash and merge the pull request.
|
||||
|
||||
When you create a pull request, {% data variables.product.prodname_dotcom %} identifies the most recent commit that is on both the head branch and the [base branch](/github/getting-started-with-github/github-glossary#base-branch): the common ancestor commit. When you squash and merge the pull request, {% data variables.product.prodname_dotcom %} creates a commit on the base branch that contains all of the changes you made on the head branch since the common ancestor commit.
|
||||
|
||||
Because this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request. If there are no conflicts, you can safely merge these commits. However, this workflow makes merge conflicts more likely. If you continue to squash and merge pull requests for a long-running head branch, you will have to resolve the same conflicts repeatedly.
|
||||
|
||||
## Rebase and merge your pull request commits
|
||||
|
||||
{% data reusables.pull_requests.rebase_and_merge_summary %}
|
||||
|
||||
You aren't able to automatically rebase and merge on {% data variables.product.product_location %} when:
|
||||
- The pull request has merge conflicts.
|
||||
- Rebasing the commits from the base branch into the head branch runs into conflicts.
|
||||
- Rebasing the commits is considered "unsafe," such as when a rebase is possible without merge conflicts but would produce a different result than a merge would.
|
||||
|
||||
If you still want to rebase the commits but can't rebase and merge automatically on {% data variables.product.product_location %} you must:
|
||||
- Rebase the topic branch (or head branch) onto the base branch locally on the command line
|
||||
- [Resolve any merge conflicts on the command line](/articles/resolving-a-merge-conflict-using-the-command-line/).
|
||||
- Force-push the rebased commits to the pull request's topic branch (or remote head branch).
|
||||
|
||||
Anyone with write permissions in the repository, can then [merge the changes](/articles/merging-a-pull-request/) using the rebase and merge button on {% data variables.product.product_location %}.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull requests](/articles/about-pull-requests/)"
|
||||
- "[Addressing merge conflicts](/github/collaborating-with-pull-requests/addressing-merge-conflicts)"
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: Adding a pull request to the merge queue
|
||||
intro: If merge queues are enabled for the repository, you can add your pull requests to the merge queue once all the required checks have passed. {% data variables.product.product_name %} will merge the pull requests for you.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Add PR to merge queue
|
||||
redirect_from:
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/adding-a-pull-request-to-the-merge-queue
|
||||
---
|
||||
|
||||
{% data reusables.pull_requests.merge-queue-beta %}
|
||||
|
||||
## About pull request merge queue
|
||||
|
||||
{% data reusables.pull_requests.merge-queue-overview-short %}
|
||||
{% data reusables.pull_requests.merge-queue-references %}
|
||||
|
||||
## Adding a pull request to the merge queue
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the "Pull Requests" list, click the pull request you'd like to add to the merge queue.
|
||||
1. Click **Add to merge queue** to add your pull request to the merge queue. This enables the default **Queue and merge in a group** option. Alternatively, you can:
|
||||
- Add your pull request to the front of the queue by selecting the **Add to merge queue** drop down menu, and clicking **Jump the queue** (only available to repository maintainers and administrators).
|
||||
- Directly merge your pull request by selecting the **Add to merge queue** drop down menu, and clicking **Directly merge** (only available to repository administrators).
|
||||
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** The **Add to merge queue** button is only enabled once the pull request meets all the review/approval and status check requirements.
|
||||
|
||||
{% endtip %}
|
||||
2. Confirm you want to add the pull request to the merge queue by clicking **Confirm add to merge queue**.
|
||||
{% data variables.product.product_name %} adds the pull request to the merge queue and will merge it for you.
|
||||
|
||||
## Viewing the merge queue
|
||||
|
||||
You can view the merge queue in various places on {% data variables.product.product_name %}.
|
||||
|
||||
- On the **Branches** page for the repository. We recommend you use this route if you don't have or don't know about a pull request already in the queue, and if you want to see what's in the queue. For more information, see "[Viewing branches in your repository](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/viewing-branches-in-your-repository)."
|
||||
|
||||
|
||||
|
||||
- On the **Pull requests** page of your repository, click {% octicon "clock" aria-label="The clock symbol" %}.
|
||||
|
||||
|
||||
|
||||
- On your pull request, scroll down to the section with the checks, and click **View merge queue**.
|
||||
|
||||
|
||||
|
||||
The merge queue view shows the pull requests that are currently in the queue, with your pull requests clearly marked.
|
||||
|
||||
|
||||
|
||||
## Handling pull requests removed from the merge queue
|
||||
|
||||
{% data reusables.pull_requests.merge-queue-reject %}
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Automatically merging a pull request
|
||||
intro: You can increase development velocity by enabling auto-merge for a pull request so that the pull request will merge automatically when all merge requirements are met.
|
||||
product: '{% data reusables.gated-features.auto-merge %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '>=3.1'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request
|
||||
|
||||
shortTitle: Merge PR automatically
|
||||
---
|
||||
## About auto-merge
|
||||
|
||||
If you enable auto-merge for a pull request, the pull request will merge automatically when all required reviews are met and status checks have passed. Auto-merge prevents you from waiting around for requirements to be met, so you can move on to other tasks.
|
||||
|
||||
Before you can use auto-merge with a pull request, auto-merge must be enabled for the repository. For more information, see "[Managing auto-merge for pull requests in your repository](/github/administering-a-repository/managing-auto-merge-for-pull-requests-in-your-repository)."{% ifversion fpt or ghae-next or ghes > 3.1 or ghec %}
|
||||
|
||||
After you enable auto-merge for a pull request, if someone who does not have write permissions to the repository pushes new changes to the head branch or switches the base branch of the pull request, auto-merge will be disabled. For example, if a maintainer enables auto-merge for a pull request from a fork, auto-merge will be disabled after a contributor pushes new changes to the pull request.{% endif %}
|
||||
|
||||
You can provide feedback about auto-merge by [contacting us](https://support.github.com/contact/feedback?category=prs-and-code-review&subject=Pull%20request%20auto-merge%20feedback).
|
||||
|
||||
## Enabling auto-merge
|
||||
|
||||
{% data reusables.pull_requests.auto-merge-requires-branch-protection %}
|
||||
|
||||
People with write permissions to a repository can enable auto-merge for a pull request.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the "Pull Requests" list, click the pull request you'd like to auto-merge.
|
||||
1. Optionally, to choose a merge method, select the **Enable auto-merge** drop-down menu, then click a merge method. For more information, see "[About pull request merges](/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges)."
|
||||
|
||||
1. Click **Enable auto-merge**.
|
||||
|
||||
1. If you chose the merge or squash and merge methods, type a commit message and description and choose the email address you want to author the merge commit.
|
||||
|
||||
1. Click **Confirm auto-merge**.
|
||||
|
||||
|
||||
## Disabling auto-merge
|
||||
|
||||
People with write permissions to a repository and pull request authors can disable auto-merge for a pull request.
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
1. In the "Pull Requests" list, click the pull request you'd like to disable auto-merge for.
|
||||
1. In the merge box, click **Disable auto-merge**.
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Closing a pull request
|
||||
intro: 'You may choose to *close* a pull request without [merging it into the upstream branch](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request). This can be handy if the changes proposed in the branch are no longer needed, or if another solution has been proposed in another branch.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-changes-from-a-pull-request/closing-a-pull-request
|
||||
- /articles/closing-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/closing-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/closing-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
{% tip %}
|
||||
|
||||
**Tip**: If you opened a pull request with the wrong base branch, rather than closing it out and opening a new one, you can instead change the base branch. For more information, see "[Changing the base branch of a pull request](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the "Pull Requests" list, click the pull request you'd like to close.
|
||||
3. At the bottom of the pull request, below the comment box, click **Close pull request**.
|
||||
|
||||
4. Optionally, [delete the branch](/articles/deleting-unused-branches). This keeps the list of branches in your repository tidy.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Incorporating changes from a pull request
|
||||
intro: 'You can propose changes to your work on {% data variables.product.product_name %} through pull requests. Learn how to create, manage, and merge pull requests.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-changes-from-a-pull-request/
|
||||
- /articles/incorporating-changes-from-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-pull-request-merges
|
||||
- /merging-a-pull-request
|
||||
- /automatically-merging-a-pull-request
|
||||
- /adding-a-pull-request-to-the-merge-queue
|
||||
- /closing-a-pull-request
|
||||
- /reverting-a-pull-request
|
||||
shortTitle: Incorporate changes
|
||||
---
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
title: Merging a pull request
|
||||
intro: Merge a pull request into the upstream branch when work is completed. Anyone with push access to the repository can complete the merge.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request
|
||||
- /articles/merging-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/merging-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
## About pull request merges
|
||||
|
||||
In a pull request, you propose that changes you've made on a head branch should be merged into a base branch. By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches)."
|
||||
|
||||
{% data reusables.pull_requests.you-can-auto-merge %}
|
||||
|
||||
If the pull request has merge conflicts, or if you'd like to test the changes before merging, you can [check out the pull request locally](/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally) and merge it using the command line.
|
||||
|
||||
You can't merge a draft pull request. For more information about draft pull requests, see "[About pull requests](/articles/about-pull-requests#draft-pull-requests)."
|
||||
|
||||
The repository may be configured so that the head branch for a pull request is automatically deleted when you merge a pull request. For more information, see "[Managing the automatic deletion of branches](/github/administering-a-repository/managing-the-automatic-deletion-of-branches)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data reusables.pull_requests.retargeted-on-branch-deletion %}
|
||||
For more information, see "[About branches](/github/collaborating-with-issues-and-pull-requests/about-branches#working-with-branches)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
Pull requests are merged using [the `--no-ff` option](https://git-scm.com/docs/git-merge#_fast_forward_merge), except for [pull requests with squashed or rebased commits](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges), which are merged using the fast-forward option.
|
||||
|
||||
{% data reusables.pull_requests.close-issues-using-keywords %}
|
||||
|
||||
If you decide you don't want the changes in a topic branch to be merged to the upstream branch, you can [close the pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/closing-a-pull-request) without merging.
|
||||
|
||||
## Merging a pull request
|
||||
|
||||
{% include tool-switcher %}
|
||||
|
||||
{% webui %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the "Pull Requests" list, click the pull request you'd like to merge.
|
||||
3. Depending on the merge options enabled for your repository, you can:
|
||||
- [Merge all of the commits into the base branch](/articles/about-pull-request-merges/) by clicking **Merge pull request**. If the **Merge pull request** option is not shown, then click the merge drop down menu and select **Create a merge commit**.
|
||||
|
||||
- [Squash the commits into one commit](/articles/about-pull-request-merges/#squash-and-merge-your-pull-request-commits) by clicking the merge drop down menu, selecting **Squash and merge** and then clicking the **Squash and merge** button.
|
||||
|
||||
- [Rebase the commits individually onto the base branch](/articles/about-pull-request-merges/#rebase-and-merge-your-pull-request-commits) by clicking the merge drop down menu, selecting **Rebase and merge** and then clicking the **Rebase and merge** button.
|
||||
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Rebase and merge will always update the committer information and create new commit SHAs. For more information, see "[About pull request merges](/articles/about-pull-request-merges#rebase-and-merge-your-pull-request-commits)."
|
||||
|
||||
{% endnote %}
|
||||
4. If prompted, type a commit message, or accept the default message.
|
||||
|
||||
{% data reusables.pull_requests.default-commit-message-squash-merge %}
|
||||
|
||||
|
||||
{% data reusables.files.choose-commit-email %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The email selector is not available for rebase merges, which do not create a merge commit, or for squash merges, which credit the user who created the pull request as the author of the squashed commit.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
6. Click **Confirm merge**, **Confirm squash and merge**, or **Confirm rebase and merge**.
|
||||
6. Optionally, [delete the branch](/articles/deleting-unused-branches). This keeps the list of branches in your repository tidy.
|
||||
|
||||
{% endwebui %}
|
||||
|
||||
{% cli %}
|
||||
|
||||
{% data reusables.cli.cli-learn-more %}
|
||||
|
||||
To merge a pull request, use the `gh pr merge` subcommand. Replace `pull-request` with the number, URL, or head branch of the pull request.
|
||||
|
||||
```shell
|
||||
gh pr merge <em>pull-request</em>
|
||||
```
|
||||
|
||||
Follow the interactive prompts to complete the merge. For more information about the merge methods that you can choose, see "[About pull request merges](/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)."
|
||||
|
||||
Alternatively, you can use flags to skip the interactive prompts. For example, this command will squash the commits into a single commit with the commit message "my squash commit", merge the squashed commit into the base branch, and then delete the local and remote branch.
|
||||
|
||||
```shell
|
||||
gh pr merge 523 --squash --body "my squash commit" --delete-branch
|
||||
```
|
||||
|
||||
{% endcli %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Reverting a pull request](/articles/reverting-a-pull-request)"
|
||||
- "[Syncing your branch](/desktop/guides/contributing-to-projects/syncing-your-branch/)" using {% data variables.product.prodname_desktop %}
|
||||
- "[About pull request merges](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)"
|
||||
- "[Addressing merge conflicts](/github/collaborating-with-pull-requests/addressing-merge-conflicts)"
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Reverting a pull request
|
||||
intro: You can revert a pull request after it's been merged to the upstream branch.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request
|
||||
- /articles/reverting-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/reverting-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
## About reverting a pull request
|
||||
|
||||
Reverting a pull request on {% data variables.product.product_name %} creates a new pull request that contains one revert of the merge commit from the original merged pull request.
|
||||
|
||||
## Reverting a pull request
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** You may need to revert the individual commits in your pull request if either of the following is true.
|
||||
|
||||
- Reverting the pull request causes merge conflicts
|
||||
- The original pull request was not originally merged on {% data variables.product.product_name %}. For example, someone could have merged the pull request using a fast-forward merge on the command line.
|
||||
|
||||
For more information about using Git to manually revert individual commits, see [Git revert](https://git-scm.com/docs/git-revert.html) in the Git documentation.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the "Pull Requests" list, click the pull request you'd like to revert.
|
||||
3. Near the bottom of the pull request, click **Revert**.
|
||||
|
||||
4. Merge the resulting pull request. For more information, see "[Merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request)."
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Collaborating with pull requests
|
||||
intro: 'Track and discuss changes in issues, then propose and review changes in pull requests.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/
|
||||
- /categories/63/articles/
|
||||
- /categories/collaborating/
|
||||
- /categories/collaborating-on-projects-using-pull-requests/
|
||||
- /categories/collaborating-on-projects-using-issues-and-pull-requests/
|
||||
- /categories/collaborating-with-issues-and-pull-requests/
|
||||
- /github/collaborating-with-pull-requests
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /getting-started
|
||||
- /working-with-forks
|
||||
- /collaborating-on-repositories-with-code-quality-features
|
||||
- /proposing-changes-to-your-work-with-pull-requests
|
||||
- /addressing-merge-conflicts
|
||||
- /reviewing-changes-in-pull-requests
|
||||
- /incorporating-changes-from-a-pull-request
|
||||
shortTitle: Collaborate with pull requests
|
||||
---
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: About branches
|
||||
intro: 'Use a branch to isolate development work without affecting other branches in the repository. Each repository has one default branch, and can have multiple other branches. You can merge a branch into another branch using a pull request.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
|
||||
- /articles/working-with-protected-branches/
|
||||
- /articles/about-branches
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-branches
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
## About branches
|
||||
|
||||
Branches allow you to develop features, fix bugs, or safely experiment with new ideas in a contained area of your repository.
|
||||
|
||||
You always create a branch from an existing branch. Typically, you might create a new branch from the default branch of your repository. You can then work on this new branch in isolation from changes that other people are making to the repository. A branch you create to build a feature is commonly referred to as a feature branch or topic branch. For more information, see "[Creating and deleting branches within your repository](/articles/creating-and-deleting-branches-within-your-repository/)."
|
||||
|
||||
You can also use a branch to publish a {% data variables.product.prodname_pages %} site. For more information, see "[About {% data variables.product.prodname_pages %}](/articles/what-is-github-pages)."
|
||||
|
||||
You must have write access to a repository to create a branch, open a pull request, or delete and restore branches in a pull request. For more information, see "[Access permissions on {% data variables.product.prodname_dotcom %}](/github/getting-started-with-github/access-permissions-on-github)."
|
||||
|
||||
## About the default branch
|
||||
|
||||
{% data reusables.branches.new-repo-default-branch %} The default branch is the branch that {% data variables.product.prodname_dotcom %} displays when anyone visits your repository. The default branch is also the initial branch that Git checks out locally when someone clones the repository. {% data reusables.branches.default-branch-automatically-base-branch %}
|
||||
|
||||
By default, {% data variables.product.product_name %} names the default branch `main` in any new repository.
|
||||
|
||||
{% data reusables.branches.change-default-branch %}
|
||||
|
||||
{% data reusables.branches.set-default-branch %}
|
||||
|
||||
## Working with branches
|
||||
|
||||
Once you're satisfied with your work, you can open a pull request to merge the changes in the current branch (the *head* branch) into another branch (the *base* branch). For more information, see "[About pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)."
|
||||
|
||||
After a pull request has been merged, or closed, you can delete the head branch as this is no longer needed. You must have write access in the repository to delete branches. You can't delete branches that are directly associated with open pull requests. For more information, see "[Deleting and restoring branches in a pull request](/github/administering-a-repository/deleting-and-restoring-branches-in-a-pull-request)"
|
||||
|
||||
{% data reusables.pull_requests.retargeted-on-branch-deletion %}
|
||||
The following diagrams illustrate this.
|
||||
|
||||
Here someone has created a branch called `feature1` from the `main` branch, and you've then created a branch called `feature2` from `feature1`. There are open pull requests for both branches. The arrows indicate the current base branch for each pull request. At this point, `feature1` is the base branch for `feature2`. If the pull request for `feature2` is merged now, the `feature2` branch will be merged into `feature1`.
|
||||
|
||||
|
||||
|
||||
In the next diagram, someone has merged the pull request for `feature1` into the `main` branch, and they have deleted the `feature1` branch. As a result, {% data variables.product.prodname_dotcom %} has automatically retargeted the pull request for `feature2` so that its base branch is now `main`.
|
||||
|
||||
|
||||
|
||||
Now when you merge the `feature2` pull request, it'll be merged into the `main` branch.
|
||||
|
||||
## Working with protected branches
|
||||
|
||||
Repository administrators can enable protections on a branch. If you're working on a branch that's protected, you won't be able to delete or force push to the branch. Repository administrators can additionally enable several other protected branch settings to enforce various workflows before a branch can be merged.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If you're a repository administrator, you can merge pull requests on branches with branch protections enabled even if the pull request does not meet the requirements, unless branch protections have been set to "Include administrators."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
To see if your pull request can be merged, look in the merge box at the bottom of the pull request's **Conversation** tab. For more information, see "[About protected branches](/articles/about-protected-branches)."
|
||||
|
||||
When a branch is protected:
|
||||
|
||||
- You won't be able to delete or force push to the branch.
|
||||
- If required status checks are enabled on the branch, you won't be able to merge changes into the branch until all of the required CI tests pass. For more information, see "[About status checks](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)."
|
||||
- If required pull request reviews are enabled on the branch, you won't be able to merge changes into the branch until all requirements in the pull request review policy have been met. For more information, see "[Merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request)."
|
||||
- If required review from a code owner is enabled on a branch, and a pull request modifies code that has an owner, a code owner must approve the pull request before it can be merged. For more information, see "[About code owners](/articles/about-code-owners)."
|
||||
- If required commit signing is enabled on a branch, you won't be able to push any commits to the branch that are not signed and verified. For more information, see "[About commit signature verification](/articles/about-commit-signature-verification)" and "[About protected branches](/github/administering-a-repository/about-protected-branches#require-signed-commits)."
|
||||
- If you use {% data variables.product.prodname_dotcom %}'s conflict editor to fix conflicts for a pull request that you created from a protected branch, {% data variables.product.prodname_dotcom %} helps you to create an alternative branch for the pull request, so that your resolution of the conflicts can be merged. For more information, see "[Resolving a merge conflict on {% data variables.product.prodname_dotcom %}](/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)"
|
||||
- "[Branch](/articles/github-glossary/#branch)" in the {% data variables.product.prodname_dotcom %} glossary
|
||||
- "[Branches in a Nutshell](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)" in the Git documentation
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: About comparing branches in pull requests
|
||||
intro: Pull requests display diffs to compare the changes you made in your topic branch against the base branch that you want to merge your changes into.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests
|
||||
- /articles/about-comparing-branches-in-pull-requests
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-comparing-branches-in-pull-requests
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Compare branches
|
||||
---
|
||||
{% note %}
|
||||
|
||||
**Note:** When creating your pull request, you can change the base branch that you're comparing your changes against. For more information, see "[Creating a pull request](/articles/creating-a-pull-request#changing-the-branch-range-and-destination-repository)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can view proposed changes in a pull request in the Files changed tab.
|
||||
|
||||
|
||||
Rather than viewing the commits themselves, you can view the proposed changes as they'll appear in the files once the pull request is merged. The files appear in alphabetical order within the Files changed tab. Additions to the files appear in green and are prefaced by a `+` sign while content that has been removed appears in red and is prefaced by a `-` sign.
|
||||
|
||||
## Diff view options
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** If you're having a hard time understanding the context of a change, you can click **View** in the Files changed tab to view the whole file with the proposed changes.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
You have several options for viewing a diff:
|
||||
- The unified view shows updated and existing content together in a linear view.
|
||||
- The split view shows old content on one side and new content on the other side.
|
||||
- The rich diff view shows a preview of how the changes will look once the pull request is merged.
|
||||
- The source view shows the changes in source without the formatting of the rich diff view.
|
||||
|
||||
You can also choose to ignore whitespace changes to get a more accurate view of the substantial changes in a pull request.
|
||||
|
||||
|
||||
|
||||
To simplify reviewing changes in a large pull request, you can filter the diff to only show selected file types, show files you are a CODEOWNER of, hide files you have already viewed, or hide deleted files. For more information, see "[Filtering files in a pull request by file type](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/filtering-files-in-a-pull-request)."
|
||||
|
||||
|
||||
|
||||
## Three-dot and two-dot Git diff comparisons
|
||||
|
||||
By default, pull requests on {% data variables.product.prodname_dotcom %} show a three-dot diff, or a comparison between the most recent version of the topic branch and the commit where the topic branch was last synced with the base branch.
|
||||
|
||||
To see two committish references in a two-dot diff comparison on {% data variables.product.prodname_dotcom %}, you can edit the URL of your repository's "Comparing changes" page. For more information, see the [Git Glossary for "committish"](https://git-scm.com/docs/gitglossary#gitglossary-aiddefcommit-ishacommit-ishalsocommittish) from the _Pro Git_ book site.
|
||||
|
||||
{% data reusables.repositories.two-dot-diff-comparison-example-urls %}
|
||||
|
||||
A two-dot diff compares two Git committish references, such as SHAs or OIDs (Object IDs), directly with each other. On {% data variables.product.prodname_dotcom %}, the Git committish references in a two-dot diff comparison must be pushed to the same repository or its forks.
|
||||
|
||||
If you want to simulate a two-dot diff in a pull request and see a comparison between the most recent versions of each branch, you can merge the base branch into your topic branch, which updates the last common ancestor between your branches.
|
||||
|
||||
For more information about Git commands to compare changes, see "[Git diff options](https://git-scm.com/docs/git-diff#git-diff-emgitdiffemltoptionsgtltcommitgtltcommitgt--ltpathgt82308203)" from the _Pro Git_ book site.
|
||||
|
||||
## Reasons diffs will not display
|
||||
- You've exceeded the total limit of files or certain file types. For more information, see "[About repositories](/repositories/creating-and-managing-repositories/about-repositories#limits-for-viewing-content-and-diffs-in-a-repository)."
|
||||
- Your file matches a rule in the repository's *.gitattributes* file to block that file from displaying by default. For more information, see "[Customizing how changed files appear on GitHub](/articles/customizing-how-changed-files-appear-on-github)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)"
|
||||
- "[About forks](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)"
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: About pull requests
|
||||
intro: 'Pull requests let you tell others about changes you''ve pushed to a branch in a repository on {% data variables.product.product_name %}. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
|
||||
- /articles/using-pull-requests/
|
||||
- /articles/about-pull-requests
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-pull-requests
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
## About pull requests
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** When working with pull requests, keep the following in mind:
|
||||
* If you're working in the [shared repository model](/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models), we recommend that you use a topic branch for your pull request. While you can send pull requests from any branch or commit, with a topic branch you can push follow-up commits if you need to update your proposed changes.
|
||||
* When pushing commits to a pull request, don't force push. Force pushing can corrupt your pull request.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can create pull requests on {% data variables.product.prodname_dotcom_the_website %}, with {% data variables.product.prodname_desktop %}, in {% data variables.product.prodname_codespaces %}, on {% data variables.product.prodname_mobile %}, and when using GitHub CLI.
|
||||
|
||||
After initializing a pull request, you'll see a review page that shows a high-level overview of the changes between your branch (the compare branch) and the repository's base branch. You can add a summary of the proposed changes, review the changes made by commits, add labels, milestones, and assignees, and @mention individual contributors or teams. For more information, see "[Creating a pull request](/articles/creating-a-pull-request)."
|
||||
|
||||
Once you've created a pull request, you can push commits from your topic branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.
|
||||
|
||||
Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
You can see information about the branch's current deployment status and past deployment activity on the "Conversation" tab. For more information, see "[Viewing deployment activity for a repository](/repositories/viewing-activity-and-data-for-your-repository/viewing-deployment-activity-for-your-repository)."
|
||||
{% endif %}
|
||||
|
||||
After you're happy with the proposed changes, you can merge the pull request. If you're working in a shared repository model, you create a pull request and you, or someone else, will merge your changes from your feature branch into the base branch you specify in your pull request. For more information, see "[Merging a pull request](/articles/merging-a-pull-request)."
|
||||
|
||||
{% data reusables.pull_requests.required-checks-must-pass-to-merge %}
|
||||
|
||||
{% data reusables.pull_requests.close-issues-using-keywords %}
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tips:**
|
||||
- To toggle between collapsing and expanding all outdated review comments in a pull request, hold down <span class="platform-mac"><kbd>option</kbd></span><span class="platform-linux"><kbd>Alt</kbd></span><span class="platform-windows"><kbd>Alt</kbd></span> and click **Show outdated** or **Hide outdated**. For more shortcuts, see "[Keyboard shortcuts](/articles/keyboard-shortcuts)."
|
||||
- You can squash commits when merging a pull request to gain a more streamlined view of changes. For more information, see "[About pull request merges](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
You can visit your dashboard to quickly find links to recently updated pull requests you're working on or subscribed to. For more information, see "[About your personal dashboard](/articles/about-your-personal-dashboard)."
|
||||
|
||||
## Draft pull requests
|
||||
|
||||
{% data reusables.gated-features.draft-prs %}
|
||||
|
||||
When you create a pull request, you can choose to create a pull request that is ready for review or a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review draft pull requests. For more information about creating a draft pull request, see "[Creating a pull request](/articles/creating-a-pull-request)" and "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)."
|
||||
|
||||
{% data reusables.pull_requests.mark-ready-review %} You can convert a pull request to a draft at any time. For more information, see "[Changing the stage of a pull request](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request)."
|
||||
|
||||
## Differences between commits on compare and pull request pages
|
||||
|
||||
The compare and pull request pages use different methods to calculate the diff for changed files:
|
||||
|
||||
- Compare pages show the diff between the tip of the head ref and the current common ancestor (that is, the merge base) of the head and base ref.
|
||||
- Pull request pages show the diff between the tip of the head ref and the common ancestor of the head and base ref at the time when the pull request was created. Consequently, the merge base used for the comparison might be different.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Pull request](/articles/github-glossary/#pull-request)" in the {% data variables.product.prodname_dotcom %} glossary
|
||||
- "[About branches](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches)"
|
||||
- "[Commenting on a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)"
|
||||
- "[Closing a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/closing-a-pull-request)"
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Changing the base branch of a pull request
|
||||
intro: 'After a pull request is opened, you can change the base branch to compare the changes in the pull request against a different branch.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request
|
||||
- /articles/changing-the-base-branch-of-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Change the base branch
|
||||
---
|
||||
{% warning %}
|
||||
|
||||
**Warning**: When you change the base branch of your pull request, some commits may be removed from the timeline. Review comments may also become outdated, as the line of code that the comment referenced may no longer be part of the changes in the pull request.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the "Pull Requests" list, click the pull request you'd like to modify.
|
||||
3. Next to the pull request's title, click **Edit**. 
|
||||
4. In the base branch drop-down menu, select the base branch you'd like to [compare changes against](/github/committing-changes-to-your-project/comparing-commits#comparing-branches). 
|
||||
5. Read the information about changing the base branch and click **Change base**. 
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** When you open a pull request, {% data variables.product.product_name %} will set the base to the commit that branch references. If the branch is updated in the future, {% data variables.product.product_name %} will not update the base branch's commit.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Creating a pull request](/articles/creating-a-pull-request)"
|
||||
- "[About pull requests](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)"
|
||||
- "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Changing the stage of a pull request
|
||||
intro: 'You can mark a draft pull request as ready for review{% ifversion fpt or ghae or ghes or ghec %} or convert a pull request to a draft{% endif %}.'
|
||||
permissions: People with write permissions to a repository and pull request authors can change the stage of a pull request.
|
||||
product: '{% data reusables.gated-features.draft-prs %}'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request
|
||||
- /articles/changing-the-stage-of-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Change the state
|
||||
---
|
||||
## Marking a pull request as ready for review
|
||||
|
||||
{% data reusables.pull_requests.mark-ready-review %}
|
||||
|
||||
{% ifversion fpt or ghae or ghes or ghec %}
|
||||
{% tip %}
|
||||
|
||||
**Tip**: You can also mark a pull request as ready for review using the {% data variables.product.prodname_cli %}. For more information, see "[`gh pr ready`](https://cli.github.com/manual/gh_pr_ready)" in the {% data variables.product.prodname_cli %} documentation.
|
||||
|
||||
{% endtip %}
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the "Pull requests" list, click the pull request you'd like to mark as ready for review.
|
||||
3. In the merge box, click **Ready for review**.
|
||||
|
||||
|
||||
{% ifversion fpt or ghae or ghes or ghec %}
|
||||
|
||||
## Converting a pull request to a draft
|
||||
|
||||
You can convert a pull request to a draft at any time. For example, if you accidentally opened a pull request instead of a draft, or if you've received feedback on your pull request that needs to be addressed, you can convert the pull request to a draft to indicate further changes are needed. No one can merge the pull request until you mark the pull request as ready for review again. People who are already subscribed to notifications for the pull request will not be unsubscribed when you convert the pull request to a draft.
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the "Pull requests" list, click the pull request you'd like to convert to a draft.
|
||||
3. In the right sidebar, under "Reviewers," click **Convert to draft**.
|
||||
|
||||
4. Click **Convert to draft**.
|
||||
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull requests](/github/collaborating-with-issues-and-pull-requests/about-pull-requests)"
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Committing changes to a pull request branch created from a fork
|
||||
intro: You can commit changes on a pull request branch that was created from a fork of your repository with permission from the pull request creator.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /articles/committing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Commit to PR branch from fork
|
||||
---
|
||||
You can only make commits on pull request branches that:
|
||||
- are opened in a repository that you have push access to and that were created from a fork of that repository
|
||||
- are on a user-owned fork
|
||||
- have permission granted from the pull request creator
|
||||
- don't have [branch restrictions](/github/administering-a-repository/about-protected-branches#restrict-who-can-push-to-matching-branches) that will prevent you from committing
|
||||
|
||||
Only the user who created the pull request can give you permission to push commits to the user-owned fork. For more information, see "[Allowing changes to a pull request branch created from a fork](/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** You can also make commits to a pull request branch from a fork of your repository through {% data variables.product.product_location %} by creating your own copy (or fork) of the fork of your repository and committing changes to the same head branch that the original pull request changes were created on. For some general guidelines, see "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. On {% data variables.product.product_name %}, navigate to the main page of the fork (or copy of your repository) where the pull request branch was created.
|
||||
{% data reusables.repositories.copy-clone-url %}
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
{% tip %}
|
||||
|
||||
**Tip:** If you prefer to clone the fork using {% data variables.product.prodname_desktop %}, then see "[Cloning a repository to {% data variables.product.prodname_desktop %}](/articles/cloning-a-repository/#cloning-a-repository-to-github-desktop)."
|
||||
|
||||
{% endtip %}
|
||||
4. Change the current working directory to the location where you want to download the cloned directory.
|
||||
```shell
|
||||
$ cd open-source-projects
|
||||
```
|
||||
5. Type `git clone`, and then paste the URL you copied in Step 3.
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>FORK-OF-THE-REPOSITORY</em>
|
||||
```
|
||||
6. Press **Enter**. Your local clone will be created.
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>FORK-OF-THE-REPOSITORY</em>
|
||||
> Cloning into `FORK-OF-THE-REPOSITORY`...
|
||||
> remote: Counting objects: 10, done.
|
||||
> remote: Compressing objects: 100% (8/8), done.
|
||||
> remove: Total 10 (delta 1), reused 10 (delta 1)
|
||||
> Unpacking objects: 100% (10/10), done.
|
||||
```
|
||||
{% tip %}
|
||||
|
||||
**Tip:** The error message "fatal: destination path 'REPOSITORY-NAME' already exists and is not an empty directory" means that your current working directory already contains a repository with the same name. To resolve the error, you must clone the fork in a different directory.
|
||||
|
||||
{% endtip %}
|
||||
7. Navigate into your new cloned repository.
|
||||
```shell
|
||||
$ cd <em>FORK-OF-THE-REPOSITORY</em>
|
||||
```
|
||||
7. Switch branches to the compare branch of the pull request where the original changes were made. If you navigate to the original pull request, you'll see the compare branch at the top of the pull request.
|
||||
|
||||
In this example, the compare branch is `test-branch`:
|
||||
```shell
|
||||
$ git checkout <em>test-branch</em>
|
||||
```
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** For more information about pull request branches, including examples, see "[Creating a Pull Request](/articles/creating-a-pull-request/#changing-the-branch-range-and-destination-repository)."
|
||||
|
||||
{% endtip %}
|
||||
8. At this point, you can do anything you want with this branch. You can push new commits to it, run some local tests, or merge other branches into the branch. Make modifications as you like.
|
||||
9. After you commit your changes to the head branch of the pull request you can push your changes up to the original pull request directly. In this example, the head branch is `test-branch`:
|
||||
```shell
|
||||
$ git push origin <em>test-branch</em>
|
||||
> Counting objects: 32, done.
|
||||
> Delta compression using up to 8 threads.
|
||||
> Compressing objects: 100% (26/26), done.
|
||||
> Writing objects: 100% (29/29), 74.94 KiB | 0 bytes/s, done.
|
||||
> Total 29 (delta 8), reused 0 (delta 0)
|
||||
> To https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>FORK-OF-THE-REPOSITORY</em>.git
|
||||
> 12da2e9..250e946 <em>test-branch</em> -> <em>test-branch</em>
|
||||
```
|
||||
|
||||
Your new commits will be reflected on the original pull request on {% data variables.product.product_location %}.
|
||||
|
||||
## Further Reading
|
||||
|
||||
- "[About forks](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)"
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Creating a pull request from a fork
|
||||
intro: You can create a pull request to propose changes you've made to a fork of an upstream repository.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork
|
||||
- /articles/creating-a-pull-request-from-a-fork
|
||||
- /github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork
|
||||
permissions: 'Anyone with write access to a repository can create a pull request from a user-owned fork. {% data reusables.enterprise-accounts.emu-permission-propose %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Create a PR from a fork
|
||||
---
|
||||
You can also give the upstream repository's maintainers permission to push commits to a user-owned fork. If your pull request compares your topic branch with a branch in the upstream repository as the base branch, then your topic branch is also called the compare branch of the pull request. For more information about pull request branches, including examples, see "[Creating a pull request](/articles/creating-a-pull-request/#changing-the-branch-range-and-destination-repository)."
|
||||
|
||||
{% data reusables.pull_requests.perms-to-open-pull-request %}
|
||||
|
||||
1. Navigate to the original repository where you created your fork.
|
||||
{% data reusables.repositories.new-pull-request %}
|
||||
3. On the Compare page, click **compare across forks**.
|
||||
|
||||
4. In the "base branch" drop-down menu, select the branch of the upstream repository you'd like to merge changes into.
|
||||
|
||||
5. In the "head fork" drop-down menu, select your fork, then use the "compare branch" drop-down menu to select the branch you made your changes in.
|
||||
|
||||
{% data reusables.repositories.pr-title-description %}
|
||||
{% data reusables.repositories.allow-maintainers-user-forks %}
|
||||
|
||||
|
||||
{% data reusables.repositories.create-pull-request %}
|
||||
|
||||
{% data reusables.repositories.asking-for-review %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Working with forks](/articles/working-with-forks)"
|
||||
- "[Allowing changes to a pull request branch created from a fork](/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)"
|
||||
@@ -0,0 +1,179 @@
|
||||
---
|
||||
title: Creating a pull request
|
||||
intro: 'Create a pull request to propose and collaborate on changes to a repository. These changes are proposed in a *branch*, which ensures that the default branch only contains finished and approved work.'
|
||||
permissions: 'Anyone with read access to a repository can create a pull request. {% data reusables.enterprise-accounts.emu-permission-propose %}'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
|
||||
- /articles/creating-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/creating-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
|
||||
If you want to create a new branch for your pull request and do not have write permissions to the repository, you can fork the repository first. For more information, see "[Creating a pull request from a fork](/articles/creating-a-pull-request-from-a-fork)" and "[About forks](/articles/about-forks)."
|
||||
|
||||
You can specify which branch you'd like to merge your changes into when you create your pull request. Pull requests can only be opened between two branches that are different.
|
||||
|
||||
{% data reusables.pull_requests.perms-to-open-pull-request %}
|
||||
|
||||
{% data reusables.pull_requests.close-issues-using-keywords %}
|
||||
|
||||
## Changing the branch range and destination repository
|
||||
|
||||
By default, pull requests are based on the parent repository's default branch. For more information, see "[About branches](/github/collaborating-with-issues-and-pull-requests/about-branches#about-the-default-branch)."
|
||||
|
||||
If the default parent repository isn't correct, you can change both the parent repository and the branch with the drop-down lists. You can also swap your head and base branches with the drop-down lists to establish diffs between reference points. References here must be branch names in your GitHub repository.
|
||||
|
||||
|
||||
|
||||
When thinking about branches, remember that the *base branch* is **where** changes should be applied, the *head branch* contains **what** you would like to be applied.
|
||||
|
||||
When you change the base repository, you also change notifications for the pull request. Everyone that can push to the base repository will receive an email notification and see the new pull request in their dashboard the next time they sign in.
|
||||
|
||||
When you change any of the information in the branch range, the Commit and Files changed preview areas will update to show your new range.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tips**:
|
||||
- Using the compare view, you can set up comparisons across any timeframe. For more information, see "[Comparing commits](/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits)."
|
||||
- Project maintainers can add a pull request template for a repository. Templates include prompts for information in the body of a pull request. For more information, see "[About issue and pull request templates](/articles/about-issue-and-pull-request-templates)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Creating the pull request
|
||||
|
||||
{% include tool-switcher %}
|
||||
|
||||
{% webui %}
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
2. In the "Branch" menu, choose the branch that contains your commits.
|
||||
|
||||
{% data reusables.repositories.new-pull-request %}
|
||||
4. Use the _base_ branch dropdown menu to select the branch you'd like to merge your changes into, then use the _compare_ branch drop-down menu to choose the topic branch you made your changes in.
|
||||
|
||||
{% data reusables.repositories.pr-title-description %}
|
||||
{% data reusables.repositories.create-pull-request %}
|
||||
|
||||
{% data reusables.repositories.asking-for-review %}
|
||||
|
||||
After your pull request has been reviewed, it can be [merged into the repository](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request).
|
||||
|
||||
{% endwebui %}
|
||||
|
||||
{% cli %}
|
||||
|
||||
{% data reusables.cli.cli-learn-more %}
|
||||
|
||||
To create a pull request, use the `gh pr create` subcommand.
|
||||
|
||||
```shell
|
||||
gh pr create
|
||||
```
|
||||
|
||||
To assign a pull request to an individual, use the `--assignee` or `-a` flags. You can use `@me` to self-assign the pull request.
|
||||
|
||||
```shell
|
||||
gh pr create --assignee "@octocat"
|
||||
```
|
||||
|
||||
To specify the branch into which you want the pull request merged, use the `--base` or `-B` flags. To specify the branch that contains commits for your pull request, use the `--head` or `-H` flags.
|
||||
|
||||
```shell
|
||||
gh pr create --base my-base-branch --head my-changed-branch
|
||||
```
|
||||
|
||||
To include a title and body for the new pull request, use the `--title` and `--body` flags.
|
||||
|
||||
```shell
|
||||
gh pr create --title "The bug is fixed" --body "Everything works again"
|
||||
```
|
||||
|
||||
To mark a pull request as a draft, use the `--draft` flag.
|
||||
|
||||
```shell
|
||||
gh pr create --draft
|
||||
```
|
||||
|
||||
To add a labels or milestones to the new pull request, use the `--label` and `--milestone` flags.
|
||||
|
||||
```shell
|
||||
gh pr create --label "bug,help wanted" --milestone octocat-milestone
|
||||
```
|
||||
|
||||
To add the new pull request to a specific project, use the `--project` flag.
|
||||
|
||||
```shell
|
||||
gh pr create --project octocat-project
|
||||
```
|
||||
|
||||
To assign an individual or team as reviewers, use the `--reviewer` flag.
|
||||
|
||||
```shell
|
||||
gh pr create --reviewer monalisa,hubot --reviewer myorg/team-name
|
||||
```
|
||||
|
||||
To create the pull request in your default web browser, use the `--web` flag.
|
||||
|
||||
```shell
|
||||
gh pr create --web
|
||||
```
|
||||
|
||||
{% endcli %}
|
||||
|
||||
{% desktop %}
|
||||
|
||||
{% mac %}
|
||||
|
||||
1. Switch to the branch that you want to create a pull request for. For more information, see "[Switching between branches](/desktop/contributing-and-collaborating-using-github-desktop/managing-branches#switching-between-branches)."
|
||||
2. Click **Create Pull Request**. {% data variables.product.prodname_desktop %} will open your default browser to take you to {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
4. On {% data variables.product.prodname_dotcom %}, confirm that the branch in the **base:** drop-down menu is the branch where you want to merge your changes. Confirm that the branch in the **compare:** drop-down menu is the topic branch where you made your changes.
|
||||
|
||||
{% data reusables.repositories.pr-title-description %}
|
||||
{% data reusables.repositories.create-pull-request %}
|
||||
|
||||
{% endmac %}
|
||||
|
||||
{% windows %}
|
||||
|
||||
1. Switch to the branch that you want to create a pull request for. For more information, see "[Switching between branches](/desktop/contributing-and-collaborating-using-github-desktop/managing-branches#switching-between-branches)."
|
||||
2. Click **Create Pull Request**. {% data variables.product.prodname_desktop %} will open your default browser to take you to {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
3. On {% data variables.product.prodname_dotcom %}, confirm that the branch in the **base:** drop-down menu is the branch where you want to merge your changes. Confirm that the branch in the **compare:** drop-down menu is the topic branch where you made your changes.
|
||||
|
||||
{% data reusables.repositories.pr-title-description %}
|
||||
{% data reusables.repositories.create-pull-request %}
|
||||
|
||||
{% endwindows %}
|
||||
|
||||
{% enddesktop %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
{% codespaces %}
|
||||
|
||||
1. Once you've committed changes to your local copy of the repository, click the **Create Pull Request** icon.
|
||||
|
||||
1. Check that the local branch and repository you're merging from, and the remote branch and repository you're merging into, are correct. Then give the pull request a title and a description.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
For more information on creating pull requests in {% data variables.product.prodname_codespaces %}, see "[Using Codespaces for pull requests](/codespaces/developing-in-codespaces/using-codespaces-for-pull-requests)."
|
||||
|
||||
{% endcodespaces %}
|
||||
|
||||
{% endif %}
|
||||
## Further reading
|
||||
|
||||
- "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)"
|
||||
- "[Changing the base branch of a pull request](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request)"
|
||||
- "[Adding issues and pull requests to a project board from the sidebar](/articles/adding-issues-and-pull-requests-to-a-project-board/#adding-issues-and-pull-requests-to-a-project-board-from-the-sidebar)"
|
||||
- "[About automation for issues and pull requests with query parameters](/issues/tracking-your-work-with-issues/creating-issues/about-automation-for-issues-and-pull-requests-with-query-parameters)"
|
||||
- "[Assigning issues and pull requests to other GitHub users](/issues/tracking-your-work-with-issues/managing-issues/assigning-issues-and-pull-requests-to-other-github-users)"
|
||||
- "[Writing on GitHub](/github/writing-on-github)"
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Creating and deleting branches within your repository
|
||||
intro: 'You can create or delete branches directly on {% data variables.product.product_name %}.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
|
||||
- /articles/deleting-branches-in-a-pull-request/
|
||||
- /articles/creating-and-deleting-branches-within-your-repository
|
||||
- /github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Create & delete branches
|
||||
---
|
||||
## Creating a branch
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
|
||||
1. Optionally, if you want to create your new branch from a branch other than the default branch for the repository, click {% octicon "git-branch" aria-label="The branch icon" %} **<em>NUMBER</em> branches** then choose another branch:
|
||||
|
||||
1. Click the branch selector menu.
|
||||
|
||||
1. Type a unique name for your new branch, then select **Create branch**.
|
||||
|
||||
|
||||
## Deleting a branch
|
||||
|
||||
{% data reusables.pull_requests.automatically-delete-branches %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If the branch you want to delete is the repository's default branch, you must choose a new default branch before deleting the branch. For more information, see "[Changing the default branch](/github/administering-a-repository/changing-the-default-branch)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
If the branch you want to delete is associated with an open pull request, you must merge or close the pull request before deleting the branch. For more information, see "[Merging a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request)" or "[Closing a pull request](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/closing-a-pull-request)."
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.navigate-to-branches %}
|
||||
1. Scroll to the branch that you want to delete, then click {% octicon "trash" aria-label="The trash icon to delete the branch" %}.
|
||||
|
||||
|
||||
{% data reusables.pull_requests.retargeted-on-branch-deletion %}
|
||||
For more information, see "[About branches](/github/collaborating-with-issues-and-pull-requests/about-branches#working-with-branches)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About branches](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches)"
|
||||
- "[Viewing branches in your repository](/github/administering-a-repository/viewing-branches-in-your-repository)"
|
||||
- "[Deleting and restoring branches in a pull request](/github/administering-a-repository/deleting-and-restoring-branches-in-a-pull-request)"
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: Proposing changes to your work with pull requests
|
||||
intro: 'After you add changes to a topic branch or fork, you can open a pull request to ask your collaborators or the repository administrator to review your changes before merging them into the project.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/
|
||||
- /articles/proposing-changes-to-your-work-with-pull-requests
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-branches
|
||||
- /creating-and-deleting-branches-within-your-repository
|
||||
- /about-pull-requests
|
||||
- /about-comparing-branches-in-pull-requests
|
||||
- /creating-a-pull-request
|
||||
- /creating-a-pull-request-from-a-fork
|
||||
- /using-query-parameters-to-create-a-pull-request
|
||||
- /changing-the-stage-of-a-pull-request
|
||||
- /requesting-a-pull-request-review
|
||||
- /changing-the-base-branch-of-a-pull-request
|
||||
- /committing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
shortTitle: Propose changes
|
||||
---
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Requesting a pull request review
|
||||
intro: 'After you create a pull request, you can ask a specific person to review the changes you''ve proposed. If you''re an organization member, you can also request a specific team to review your changes.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review
|
||||
- /articles/requesting-a-pull-request-review
|
||||
- /github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Request a PR review
|
||||
---
|
||||
Owners and collaborators on a repository owned by a user account can assign pull request reviews. Organization members with triage permissions to a repository can assign a pull request review.
|
||||
|
||||
Owners or collaborators can assign a pull request review to any person that has been explicitly granted [read access](/articles/access-permissions-on-github) to a user-owned repository. Organization members can assign a pull request review to any person or team with read access to a repository. The requested reviewer or team will receive a notification that you asked them to review the pull request. {% ifversion fpt or ghae or ghes or ghec %}If you request a review from a team and code review assignment is enabled, specific members will be requested and the team will be removed as a reviewer. For more information, see "[Managing code review settings for your team](/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team)."{% endif %}
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Pull request authors can't request reviews unless they are either a repository owner or collaborator with write access to the repository.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
You can request a review from either a suggested or specific person. Suggested reviewers are based on [git blame data](/articles/tracking-changes-in-a-file/). If you request a review, other people with read access to the repository can still review your pull request. Once someone has reviewed your pull request and you've made the necessary changes, you can re-request review from the same reviewer. If the requested reviewer does not submit a review, and the pull request meets the repository's [mergeability requirements](/articles/defining-the-mergeability-of-pull-requests), you can still merge the pull request.
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the list of pull requests, click the pull request that you'd like to ask a specific person or a team to review.
|
||||
3. Navigate to **Reviewers** in the right sidebar.
|
||||
4. To request a review from a suggested person under **Reviewers**, next to their username, click **Request**.
|
||||
|
||||
5. Optionally, to request a review from someone other than a suggested person, click **Reviewers**, then click on a name in the dropdown menu.
|
||||
|
||||
6. Optionally, if you know the name of the person or team you'd like a review from, click **Reviewers**, then type the username of the person or the name of the team you're asking to review your changes. Click their team name or username to request a review.
|
||||
|
||||
7. After your pull request is reviewed and you've made the necessary changes, you can ask a reviewer to re-review your pull request. Navigate to **Reviewers** in the right sidebar and click {% octicon "sync" aria-label="The sync icon" %} next to the reviewer's name whose review you'd like.
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)"
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Using query parameters to create a pull request
|
||||
intro: Use query parameters to create custom URLs to open pull requests with pre-populated fields.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/using-query-parameters-to-create-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
|
||||
You can use query parameters to open pull requests. Query parameters are optional parts of a URL you can customize to share a specific web page view, such as search filter results or a pull request template on {% data variables.product.prodname_dotcom %}. To create your own query parameters, you must match the key and value pair.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** You can also create pull request templates that open with default labels, assignees, and an pull request title. For more information, see "[Using templates to encourage useful issues and pull requests](/communities/using-templates-to-encourage-useful-issues-and-pull-requests)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
You must have the proper permissions for any action to use the equivalent query parameter. For example, you must have permission to add a label to a pull request to use the `labels` query parameter. For more information, see "[Repository roles for an organization](/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)."
|
||||
|
||||
If you create an invalid URL using query parameters, or if you don’t have the proper permissions, the URL will return a `404 Not Found` error page. If you create a URL that exceeds the server limit, the URL will return a `414 URI Too Long` error page.
|
||||
|
||||
Query parameter | Example
|
||||
--- | ---
|
||||
`quick_pull` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1` creates a pull request that compares the base branch `main` and head branch `my-branch`. The `quick_pull=1` query brings you directly to the "Open a pull request" page.
|
||||
`title` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&labels=bug&title=Bug+fix+report` creates a pull request with the label "bug" and title "Bug fix."
|
||||
`body` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&title=Bug+fix&body=Describe+the+fix.` creates a pull request with the title "Bug fix" and the comment "Describe the fix" in the pull request body.
|
||||
`labels` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&labels=help+wanted,bug` creates a pull request with the labels "help wanted" and "bug".
|
||||
`milestone` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&milestone=testing+milestones` creates a pull request with the milestone "testing milestones."
|
||||
`assignees` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&assignees=octocat` creates a pull request and assigns it to @octocat.
|
||||
`projects` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&title=Bug+fix&projects=octo-org/1` creates a pull request with the title "Bug fix" and adds it to the organization's project board 1.
|
||||
`template` | `https://github.com/octo-org/octo-repo/compare/main...my-branch?quick_pull=1&template=issue_template.md` creates a pull request with a template in the pull request body. The `template` query parameter works with templates stored in a `PULL_REQUEST_TEMPLATE` subdirectory within the root, `docs/` or `.github/` directory in a repository. For more information, see "[Using templates to encourage useful issues and pull requests](/communities/using-templates-to-encourage-useful-issues-and-pull-requests)."
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: About pull request reviews
|
||||
intro: 'Reviews allow collaborators to comment on the changes proposed in pull requests, approve the changes, or request further changes before the pull request is merged. Repository administrators can require that all pull requests are approved before being merged.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
|
||||
- /articles/about-pull-request-reviews
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: About PR reviews
|
||||
---
|
||||
## About pull request reviews
|
||||
|
||||
After a pull request is opened, anyone with *read* access can review and comment on the changes it proposes. You can also suggest specific changes to lines of code, which the author can apply directly from the pull request. For more information, see "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)."
|
||||
|
||||
Repository owners and collaborators can request a pull request review from a specific person. Organization members can also request a pull request review from a team with read access to the repository. For more information, see "[Requesting a pull request review](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review)." {% ifversion fpt or ghae or ghes or ghec %}You can specify a subset of team members to be automatically assigned in the place of the whole team. For more information, see "[Managing code review settings for your team](/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team)."{% endif %}
|
||||
|
||||
Reviews allow for discussion of proposed changes and help ensure that the changes meet the repository's contributing guidelines and other quality standards. You can define which individuals or teams own certain types or areas of code in a CODEOWNERS file. When a pull request modifies code that has a defined owner, that individual or team will automatically be requested as a reviewer. For more information, see "[About code owners](/articles/about-code-owners/)."
|
||||
|
||||
{% ifversion fpt or ghec %}You can schedule reminders for pull requests that need to be reviewed. For more information, see "[Managing scheduled reminders for pull requests](/github/setting-up-and-managing-organizations-and-teams/managing-scheduled-reminders-for-pull-requests)."{% endif %}
|
||||
|
||||
|
||||
|
||||
A review has three possible statuses:
|
||||
- **Comment**: Submit general feedback without explicitly approving the changes or requesting additional changes.
|
||||
- **Approve**: Submit feedback and approve merging the changes proposed in the pull request.
|
||||
- **Request changes**: Submit feedback that must be addressed before the pull request can be merged.
|
||||
|
||||
|
||||
|
||||
{% data reusables.repositories.request-changes-tips %}
|
||||
|
||||
You can view all of the reviews a pull request has received in the Conversation timeline, and you can see reviews by repository owners and collaborators in the pull request's merge box.
|
||||
|
||||
|
||||
|
||||
{% data reusables.search.requested_reviews_search_tip %}
|
||||
|
||||
{% data reusables.pull_requests.resolving-conversations %}
|
||||
|
||||
## Re-requesting a review
|
||||
|
||||
{% data reusables.pull_requests.re-request-review %}
|
||||
|
||||
## Required reviews
|
||||
|
||||
{% data reusables.pull_requests.required-reviews-for-prs-summary %} For more information, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: If necessary, people with *admin* or *write* access to a repository can dismiss a pull request review. For more information, see "[Dismissing a pull request review](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[Viewing a pull request review](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/viewing-a-pull-request-review)"
|
||||
- "[Setting guidelines for repository contributors](/articles/setting-guidelines-for-repository-contributors)"
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Approving a pull request with required reviews
|
||||
intro: 'If your repository requires reviews, pull requests must have a specific number of approving reviews from people with _write_ or _admin_ permissions in the repository before they can be merged.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews
|
||||
- /articles/approving-a-pull-request-with-required-reviews
|
||||
- /github/collaborating-with-issues-and-pull-requests/approving-a-pull-request-with-required-reviews
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Required reviews
|
||||
---
|
||||
For more information about required reviews, see "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)."
|
||||
|
||||
You can comment on a pull request, approve the changes, or request improvements before approving. For more information, see "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)."
|
||||
|
||||
{% data reusables.search.requested_reviews_search %}
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: If a pull request you approved has changed significantly, you can dismiss your review. The pull request will need a new review before it can be merged. For more information, see "[Dismissing a pull request review](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
{% data reusables.repositories.choose-pr-review %}
|
||||
{% data reusables.repositories.changed-files %}
|
||||
4. Review the changes in the pull request, and optionally, [comment on specific lines](/articles/reviewing-proposed-changes-in-a-pull-request/#starting-a-review).
|
||||
{% data reusables.repositories.review-changes %}
|
||||
{% data reusables.repositories.review-summary-comment %}
|
||||
7. Select **Approve** to approve merging the changes proposed in the pull request.
|
||||
{% data reusables.repositories.submit-review %}
|
||||
|
||||
{% data reusables.repositories.request-changes-tips %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[Commenting on a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)"
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: Checking out pull requests locally
|
||||
intro: 'When someone sends you a pull request from a fork or branch of your repository, you can merge it locally to resolve a merge conflict or to test and verify the changes before merging on {% data variables.product.product_name %}.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
|
||||
- /articles/checking-out-pull-requests-locally
|
||||
- /github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
|
||||
permissions: Anyone with write access to a repository can pull a remote pull request down locally.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Check out a PR locally
|
||||
---
|
||||
{% note %}
|
||||
|
||||
**Note:** Pull request authors can give upstream repository maintainers, or those with push access to the upstream repository, permission to make commits to their pull request's compare branch in a user-owned fork. For more information, see "[Allowing changes to a pull request branch created from a fork](/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
## Modifying an active pull request locally
|
||||
|
||||
{% include tool-switcher %}
|
||||
|
||||
{% webui %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the list of pull requests, click the pull request you'd like to modify.{% ifversion fpt or ghec %}
|
||||
3. To choose where you'd like to open the pull request, select the **Open with {% octicon "triangle-down" aria-label="The down triangle icon" %}** drop-down and click one of the tabs.
|
||||
{% else %}
|
||||
3. In the merge box, click **command line instructions**. Follow the sequence of steps to bring down the proposed pull request.
|
||||
|
||||
4. Optionally, to view proposed changes in {% data variables.product.prodname_desktop %}, click **open this in {% data variables.product.prodname_desktop %}**.
|
||||
{% endif %}
|
||||
|
||||
{% endwebui %}
|
||||
|
||||
{% cli %}
|
||||
|
||||
{% data reusables.cli.cli-learn-more %}
|
||||
|
||||
To check out a pull request locally, use the `gh pr checkout` subcommand. Replace `pull-request` with the number, URL, or head branch of the pull request.
|
||||
|
||||
```shell
|
||||
gh pr checkout <em>pull-request</em>
|
||||
```
|
||||
|
||||
{% endcli %}
|
||||
|
||||
## Modifying an inactive pull request locally
|
||||
|
||||
If a pull request's author is unresponsive to requests or has deleted their fork, the pull request can still be merged. However, if you want to make changes to a pull request and the author is not responding, you'll need to perform some additional steps to update the pull request.
|
||||
|
||||
Once a pull request is opened, {% data variables.product.product_name %} stores all of the changes remotely. In other words, commits in a pull request are available in a repository even before the pull request is merged. You can fetch an open pull request and recreate it as your own.
|
||||
|
||||
Anyone can work with a previously opened pull request to continue working on it, test it out, or even open a new pull request with additional changes. However, only collaborators with push access can merge pull requests.
|
||||
|
||||
{% data reusables.repositories.sidebar-issue-pr %}
|
||||
2. In the "Pull Requests" list, click the pull request you'd like to merge.
|
||||
3. Find the ID number of the inactive pull request. This is the sequence of digits right after the pull request's title.
|
||||
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
5. Fetch the reference to the pull request based on its ID number, creating a new branch in the process.
|
||||
```shell
|
||||
$ git fetch origin pull/<em>ID</em>/head:<em>BRANCHNAME</em>
|
||||
```
|
||||
6. Switch to the new branch that's based on this pull request:
|
||||
```shell
|
||||
[main] $ git checkout <em>BRANCHNAME</em>
|
||||
> Switched to a new branch '<em>BRANCHNAME</em>'
|
||||
```
|
||||
7. At this point, you can do anything you want with this branch. You can run some local tests, or merge other branches into the branch.
|
||||
8. When you're ready, you can push the new branch up:
|
||||
```shell
|
||||
[pull-inactive-pull-request] $ git push origin <em>BRANCHNAME</em>
|
||||
> Counting objects: 32, done.
|
||||
> Delta compression using up to 8 threads.
|
||||
> Compressing objects: 100% (26/26), done.
|
||||
> Writing objects: 100% (29/29), 74.94 KiB | 0 bytes/s, done.
|
||||
> Total 29 (delta 8), reused 0 (delta 0)
|
||||
> To https://{% data variables.command_line.codeblock %}/<em>username</em>/<em>repository</em>.git
|
||||
> * [new branch] <em>BRANCHNAME</em> -> <em>BRANCHNAME</em>
|
||||
```
|
||||
9. [Create a new pull request](/articles/creating-a-pull-request) with your new branch.
|
||||
|
||||
## Error: Failed to push some refs
|
||||
|
||||
The remote `refs/pull/` namespace is *read-only*. If you try to push any commits there, you'll see this error:
|
||||
```shell
|
||||
! [remote rejected] HEAD -> refs/pull/1/head (deny updating a hidden ref)
|
||||
error: failed to push some refs to 'git@github.local:<em>USERNAME</em>/<em>REPOSITORY</em>.git'
|
||||
```
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** When you remove or rename a remote reference, your local `refs/pull/origin/` namespace will not be affected by calls to `git-remote`.
|
||||
|
||||
{% endtip %}
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Commenting on a pull request
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request
|
||||
- /articles/adding-commit-comments/
|
||||
- /articles/commenting-on-the-diff-of-a-pull-request/
|
||||
- /articles/commenting-on-differences-between-files/
|
||||
- /articles/commenting-on-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request
|
||||
intro: 'After you open a pull request in a repository, collaborators or team members can comment on the comparison of files between the two specified branches, or leave general comments on the project as a whole.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Comment on a PR
|
||||
---
|
||||
## About pull request comments
|
||||
|
||||
You can comment on a pull request's **Conversation** tab to leave general comments, questions, or props. You can also suggest changes that the author of the pull request can apply directly from your comment.
|
||||
|
||||
|
||||
|
||||
You can also comment on specific sections of a file on a pull request's **Files changed** tab in the form of individual line comments or as part of a [pull request review](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews). Adding line comments is a great way to discuss questions about implementation or provide feedback to the author.
|
||||
|
||||
For more information on adding line comments to a pull request review, see ["Reviewing proposed changes in a pull request."](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If you reply to a pull request via email, your comment will be added on the **Conversation** tab and will not be part of a pull request review.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
To reply to an existing line comment, you'll need to navigate to the comment on either the **Conversation** tab or **Files changed** tab and add an additional line comment below it.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tips:**
|
||||
- Pull request comments support the same [formatting](/categories/writing-on-github) as regular comments on {% data variables.product.product_name %}, such as @mentions, emoji, and references.
|
||||
- You can add reactions to comments in pull requests in the **Files changed** tab.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Adding line comments to a pull request
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the list of pull requests, click the pull request where you'd like to leave line comments.
|
||||
{% data reusables.repositories.changed-files %}
|
||||
{% data reusables.repositories.start-line-comment %}
|
||||
{% data reusables.repositories.type-line-comment %}
|
||||
{% data reusables.repositories.suggest-changes %}
|
||||
5. When you're done, click **Add single comment**.
|
||||
|
||||
|
||||
Anyone watching the pull request or repository will receive a notification of your comment.
|
||||
|
||||
{% data reusables.pull_requests.resolving-conversations %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Writing on GitHub](/github/writing-on-github)"
|
||||
{% ifversion fpt or ghec %}- "[Reporting abuse or spam](/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam)"
|
||||
{% endif %}
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: Dismissing a pull request review
|
||||
intro: 'If your repository requires reviews, you can dismiss pull request reviews that are no longer valid or are unable to be approved by the reviewer.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review
|
||||
- /articles/dismissing-a-pull-request-review
|
||||
- /github/collaborating-with-issues-and-pull-requests/dismissing-a-pull-request-review
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Dismiss a PR review
|
||||
---
|
||||
{% data reusables.pull_requests.dismiss_review %}
|
||||
This changes the status of the review to a review comment. When you dismiss a review, you must add a comment explaining why you dismissed it. Your comment will be added to the pull request conversation.
|
||||
|
||||
{% data reusables.search.requested_reviews_search %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
{% data reusables.repositories.choose-pr-review %}
|
||||
3. On the "Conversation" tab, scroll to the review you'd like to dismiss, then click {% octicon "chevron-down" aria-label="The down button" %}. 
|
||||
4. Click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click **Dismiss review**.
|
||||
|
||||
5. Type your reason for dismissing the review, then click **Dismiss review**.
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)"
|
||||
- "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Filtering files in a pull request
|
||||
intro: 'To help you quickly review changes in a large pull request, you can filter changed files.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/filtering-files-in-a-pull-request
|
||||
- /articles/filtering-files-in-a-pull-request-by-file-type/
|
||||
- /articles/filtering-files-in-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/filtering-files-in-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/filtering-files-in-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Filter files
|
||||
---
|
||||
You can filter files in a pull request by file extension type, such as `.html` or `.js`, lack of an extension, code ownership, or dotfiles.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** To simplify your pull request diff view, you can also temporarily hide deleted files or files you have already viewed in the pull request diff from the file filter drop-down menu.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the list of pull requests, click the pull request you'd like to filter.
|
||||
{% data reusables.repositories.changed-files %}
|
||||
4. Use the File filter drop-down menu, and select, unselect, or click the desired filters.
|
||||
|
||||
5. Optionally, to clear the filter selection, under the **Files changed** tab, click **Clear**.
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About comparing branches in a pull request](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)"
|
||||
- "[Finding changed methods and functions in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/finding-changed-methods-and-functions-in-a-pull-request)"
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Finding changed methods and functions in a pull request
|
||||
intro: 'You can quickly find proposed changes to a method or function in a pull request in *.go*, *.js*, *.ts*, *.py*, *.php*, and *.rb* files.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/finding-changed-methods-and-functions-in-a-pull-request
|
||||
- /articles/finding-changed-methods-and-functions-in-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/finding-changed-methods-and-functions-in-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/finding-changed-methods-and-functions-in-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Methods & functions
|
||||
---
|
||||
Anyone with read access to a repository can see a summary list of the functions and methods changes in certain files of a pull request.
|
||||
|
||||
The summary list of methods and functions is created from these supported file types:
|
||||
- Go
|
||||
- JavaScript (includes Typescript, Flow, and other types of JavaScript)
|
||||
- PHP
|
||||
- Python
|
||||
- Ruby
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the list of pull requests, click the pull request where you'd like to find the changed functions and methods.
|
||||
{% data reusables.repositories.changed-files %}
|
||||
4. To see a summary list of the changed functions and methods, click **Jump to...**.
|
||||
|
||||
5. Select the changed function or method from the drop-down menu. You can also enter the name of the function or method to filter results.
|
||||
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** If you don't see the functions or methods you expected, confirm that your code compiles and doesn't contain errors. Only functions and methods changed in this pull request and found in *.go*, *.js*, *.ts*, *.py*, *.php*, and *.rb* files appear in the drop-down menu.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
6. You'll be redirected to the first line of the function or method you selected.
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About comparing branches in a pull request](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)"
|
||||
- "[Filtering files in a pull request by file type](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/filtering-files-in-a-pull-request)"
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Incorporating feedback in your pull request
|
||||
intro: 'When reviewers suggest changes in a pull request, you can automatically incorporate the changes into the pull request or open an issue to track out-of-scope suggestions.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
|
||||
- /articles/incorporating-feedback-in-your-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Incorporate feedback
|
||||
---
|
||||
## Applying suggested changes
|
||||
|
||||
Other people can suggest specific changes to your pull request. You can apply these suggested changes directly in a pull request if you have write access to the repository. If the pull request was created from a fork and the author allowed edits from maintainers, you can also apply suggested changes if you have write access to the upstream repository. For more information, see "[Commenting on a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)" and "[Allowing changes to a pull request branch created from a fork](/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)."
|
||||
|
||||
To quickly incorporate more than one suggested change into a single commit, you can also apply suggested changes as a batch. Applying one suggested change or a batch of suggested changes creates a single commit on the compare branch of the pull request.
|
||||
|
||||
Each person who suggested a change included in the commit will be a co-author of the commit. The person who applies the suggested changes will be a co-author and the committer of the commit. For more information about the term committer in Git, see "[Git Basics - Viewing the Commit History](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History)" from the _Pro Git_ book site.
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
2. In the list of pull requests, click the pull request you'd like to apply a suggested change to.
|
||||
3. Navigate to the first suggested change you'd like to apply.
|
||||
- To apply the change in its own commit, click **Commit suggestion**.
|
||||
|
||||
- To add the suggestion to a batch of changes, click **Add suggestion to batch**. Continue to add the suggested changes you want to include in a single commit. When you've finished adding suggested changes, click **Commit suggestions**.
|
||||
|
||||
4. In the commit message field, type a short, meaningful commit message that describes the change you made to the file or files.
|
||||
|
||||
5. Click **Commit changes.**
|
||||
|
||||
|
||||
## Re-requesting a review
|
||||
|
||||
{% data reusables.pull_requests.re-request-review %}
|
||||
|
||||
## Opening an issue for an out-of-scope suggestion
|
||||
|
||||
If someone suggests changes to your pull request and the changes are out of the pull request's scope, you can open a new issue to track the feedback. For more information, see "[Opening an issue from a comment](/github/managing-your-work-on-github/opening-an-issue-from-a-comment)."
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull request reviews](/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews)"
|
||||
- "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
|
||||
- "[Commenting on a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request)"
|
||||
- "[Requesting a pull request review](/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review)"
|
||||
- "[Opening an issue from a comment](/github/managing-your-work-on-github/opening-an-issue-from-a-comment)"
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: Reviewing changes in pull requests
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/
|
||||
- /articles/reviewing-and-discussing-changes-in-pull-requests/
|
||||
- /articles/reviewing-changes-in-pull-requests
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests
|
||||
intro: 'After a pull request has been opened, you can review and discuss the set of proposed changes.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-pull-request-reviews
|
||||
- /reviewing-proposed-changes-in-a-pull-request
|
||||
- /filtering-files-in-a-pull-request
|
||||
- /finding-changed-methods-and-functions-in-a-pull-request
|
||||
- /commenting-on-a-pull-request
|
||||
- /viewing-a-pull-request-review
|
||||
- /reviewing-dependency-changes-in-a-pull-request
|
||||
- /incorporating-feedback-in-your-pull-request
|
||||
- /approving-a-pull-request-with-required-reviews
|
||||
- /dismissing-a-pull-request-review
|
||||
- /checking-out-pull-requests-locally
|
||||
shortTitle: Review changes
|
||||
---
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: Reviewing dependency changes in a pull request
|
||||
intro: 'If a pull request contains changes to dependencies, you can view a summary of what has changed and whether there are known vulnerabilities in any of the dependencies.'
|
||||
product: '{% data reusables.gated-features.dependency-review %}'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '>= 3.2'
|
||||
ghae: issue-4864
|
||||
ghec: '*'
|
||||
type: how_to
|
||||
topics:
|
||||
- Pull requests
|
||||
- Dependency review
|
||||
- Advanced Security
|
||||
- Vulnerabilities
|
||||
- Dependencies
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/reviewing-dependency-changes-in-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-dependency-changes-in-a-pull-request
|
||||
shortTitle: Review dependency changes
|
||||
---
|
||||
<!--Marketing-LINK: From /features/security/software-supply-chain page "Sign up for the dependency review beta" and "Reviewing dependency changes in a pull request".-->
|
||||
|
||||
{% data reusables.dependency-review.beta %}
|
||||
|
||||
## About dependency review
|
||||
|
||||
{% data reusables.dependency-review.feature-overview %}
|
||||
|
||||
{% ifversion ghes > 3.1 %} Before you can use dependency review, you must enable the dependency graph and connect {% data variables.product.product_location %} to {% data variables.product.prodname_dotcom_the_website %}. For more information, see "[Enabling alerts for vulnerable dependencies on {% data variables.product.prodname_ghe_server %}](/admin/configuration/managing-connections-between-github-enterprise-server-and-github-enterprise-cloud/enabling-alerts-for-vulnerable-dependencies-on-github-enterprise-server)."{% endif %}
|
||||
|
||||
Dependency review allows you to "shift left". You can use the provided predictive information to catch vulnerable dependencies before they hit production. For more information, see "[About dependency review](/code-security/supply-chain-security/about-dependency-review)."
|
||||
|
||||
## Reviewing dependencies in a pull request
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
{% data reusables.repositories.choose-pr-review %}
|
||||
{% data reusables.repositories.changed-files %}
|
||||
|
||||
1. If the pull request contains many files, use the **File filter** drop-down menu to collapse all files that don't record dependencies. This will make it easier to focus your review on the dependency changes.
|
||||
|
||||
|
||||
The dependency review provides a clearer view of what has changed in large lock files, where the source diff is not rendered by default.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Dependency review rich diffs are not available for committed static JavaScript files like `jquery.js`.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. On the right of the header for a manifest or lock file, display the dependency review by clicking the **{% octicon "file" aria-label="The rich diff icon" %}** rich diff button.
|
||||
|
||||
|
||||
|
||||
2. Check the dependencies listed in the dependency review.
|
||||
|
||||
|
||||
|
||||
Any added or changed dependencies that have vulnerabilities are listed first, ordered by severity and then by dependency name. This means that the highest severity dependencies are always at the top of a dependency review. Other dependencies are listed alphabetically by dependency name.
|
||||
|
||||
The icon beside each dependency indicates whether the dependency has been added (<span style="color:#22863a">{% octicon "diff-added" aria-label="Dependency added icon" %}</span>), updated (<span style="color:#b08800">{% octicon "diff-modified" aria-label="Dependency modified icon" %}</span>), or removed (<span style="color:#cb2431">{% octicon "diff-removed" aria-label="Dependency removed icon" %}</span>) in this pull request.
|
||||
|
||||
Other information includes:
|
||||
|
||||
* The version, or version range, of the new, updated, or deleted dependency.
|
||||
* For a specific version of a dependency:
|
||||
* The age of that release of the dependency.
|
||||
* The number of projects that are dependent on this software. This information is taken from the dependency graph. Checking the number of dependents can help you avoid accidentally adding the wrong dependency.
|
||||
* The license used by this dependency, if this information is available. This is useful if you want to avoid code with certain licenses being used in your project.
|
||||
|
||||
Where a dependency has a known vulnerability, the warning message includes:
|
||||
|
||||
* A brief description of the vulnerability.
|
||||
* A Common Vulnerabilities and Exposures (CVE) or {% data variables.product.prodname_security_advisories %} (GHSA) identification number. You can click this ID to find out more about the vulnerability.
|
||||
* The severity of the vulnerability.
|
||||
* The version of the dependency in which the vulnerability was fixed. If you are reviewing a pull request for someone, you might ask the contributor to update the dependency to the patched version, or a later release.
|
||||
|
||||
{% data reusables.repositories.return-to-source-diff %}
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: Reviewing proposed changes in a pull request
|
||||
intro: 'In a pull request, you can review and discuss commits, changed files, and the differences (or "diff") between the files in the base and compare branches.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
|
||||
- /articles/reviewing-proposed-changes-in-a-pull-request
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Review proposed changes
|
||||
---
|
||||
## About reviewing pull requests
|
||||
|
||||
You can review changes in a pull request one file at a time. While reviewing the files in a pull request, you can leave individual comments on specific changes. After you finish reviewing each file, you can mark the file as viewed. This collapses the file, helping you identify the files you still need to review. A progress bar in the pull request header shows the number of files you've viewed. After reviewing as many files as you want, you can approve the pull request or request additional changes by submitting your review with a summary comment.
|
||||
|
||||
{% data reusables.search.requested_reviews_search_tip %}
|
||||
|
||||
## Starting a review
|
||||
|
||||
{% include tool-switcher %}
|
||||
|
||||
{% webui %}
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
{% data reusables.repositories.choose-pr-review %}
|
||||
{% data reusables.repositories.changed-files %}
|
||||
{% ifversion fpt or ghec or ghes > 3.2 or ghae-next %}
|
||||
|
||||
You can change the format of the diff view in this tab by clicking {% octicon "gear" aria-label="The Settings gear" %} and choosing the unified or split view. The choice you make will apply when you view the diff for other pull requests.
|
||||
|
||||
|
||||
|
||||
You can also choose to hide whitespace differences. The choice you make only applies to this pull request and will be remembered the next time you visit this page.
|
||||
{% endif %}
|
||||
{% data reusables.repositories.start-line-comment %}
|
||||
{% data reusables.repositories.type-line-comment %}
|
||||
{% data reusables.repositories.suggest-changes %}
|
||||
1. When you're done, click **Start a review**. If you have already started a review, you can click **Add review comment**.
|
||||
|
||||
|
||||
|
||||
Before you submit your review, your line comments are _pending_ and only visible to you. You can edit pending comments anytime before you submit your review. To cancel a pending review, including all of its pending comments, scroll down to the end of the timeline on the Conversation tab, then click **Cancel review**.
|
||||
|
||||
|
||||
{% endwebui %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
{% codespaces %}
|
||||
|
||||
You can use [{% data variables.product.prodname_codespaces %}](/codespaces/overview) to test, run, and review pull requests.
|
||||
|
||||
{% data reusables.codespaces.review-pr %}
|
||||
|
||||
For more information on reviewing pull requests in {% data variables.product.prodname_codespaces %}, see "[Using Codespaces for pull requests](/codespaces/developing-in-codespaces/using-codespaces-for-pull-requests)."
|
||||
|
||||
{% endcodespaces %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghes > 3.1 or ghec %}
|
||||
## Reviewing dependency changes
|
||||
|
||||
{% data reusables.dependency-review.beta %}
|
||||
|
||||
If the pull request contains changes to dependencies you can use the dependency review for a manifest or lock file to see what has changed and check whether the changes introduce security vulnerabilities. For more information, see "[Reviewing dependency changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request)."
|
||||
|
||||
{% data reusables.repositories.changed-files %}
|
||||
|
||||
1. On the right of the header for a manifest or lock file, display the dependency review by clicking the **{% octicon "file" aria-label="The rich diff icon" %}** rich diff button.
|
||||
|
||||
|
||||
|
||||
{% data reusables.repositories.return-to-source-diff %}
|
||||
{% endif %}
|
||||
|
||||
## Marking a file as viewed
|
||||
|
||||
After you finish reviewing a file, you can mark the file as viewed, and the file will collapse. If the file changes after you view the file, it will be unmarked as viewed.
|
||||
|
||||
{% data reusables.repositories.changed-files %}
|
||||
2. On the right of the header of the file you've finished reviewing, select **Viewed**.
|
||||
|
||||
|
||||
|
||||
## Submitting your review
|
||||
|
||||
After you've finished reviewing all the files you want in the pull request, submit your review.
|
||||
|
||||
{% data reusables.repositories.changed-files %}
|
||||
{% data reusables.repositories.review-changes %}
|
||||
{% data reusables.repositories.review-summary-comment %}
|
||||
4. Select the type of review you'd like to leave:
|
||||
|
||||
|
||||
|
||||
- Select **Comment** to leave general feedback without explicitly approving the changes or requesting additional changes.
|
||||
- Select **Approve** to submit your feedback and approve merging the changes proposed in the pull request.
|
||||
- Select **Request changes** to submit feedback that must be addressed before the pull request can be merged.
|
||||
{% data reusables.repositories.submit-review %}
|
||||
|
||||
{% data reusables.repositories.request-changes-tips %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"
|
||||
- "[Filtering pull requests by review status](/github/managing-your-work-on-github/filtering-pull-requests-by-review-status)"
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Viewing a pull request review
|
||||
intro: You can view all of the comments made in a single pull request review.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests/viewing-a-pull-request-review
|
||||
- /articles/viewing-a-pull-request-review
|
||||
- /github/collaborating-with-issues-and-pull-requests/viewing-a-pull-request-review
|
||||
- /github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/viewing-a-pull-request-review
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: View a PR review
|
||||
---
|
||||
{% data reusables.search.requested_reviews_search %}
|
||||
|
||||
When you view a full review, you'll see the same version of the pull request as the reviewer did at the time of the review.
|
||||
|
||||
{% data reusables.repositories.sidebar-pr %}
|
||||
{% data reusables.repositories.choose-pr-review %}
|
||||
3. On the "Conversation" tab, scroll to the review you'd like to see, then click **View changes**.
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About pull request reviews](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)"
|
||||
- "[Reviewing proposed changes in a pull request](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: About forks
|
||||
intro: A fork is a copy of a repository that you manage. Forks let you make changes to a project without affecting the original repository. You can fetch updates from or submit changes to the original repository with pull requests.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/about-forks
|
||||
- /articles/about-forks
|
||||
- /github/collaborating-with-issues-and-pull-requests/about-forks
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/about-forks
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
Forking a repository is similar to copying a repository, with two major differences:
|
||||
|
||||
* You can use a pull request to suggest changes from your user-owned fork to the original repository, also known as the *upstream* repository.
|
||||
* You can bring changes from the upstream repository to your local fork by synchronizing your fork with the upstream repository.
|
||||
|
||||
{% data reusables.repositories.you-can-fork %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
If you're a member of a {% data variables.product.prodname_emu_enterprise %}, there are further restrictions on the repositories you can fork. {% data reusables.enterprise-accounts.emu-forks %} For more information, see "[About {% data variables.product.prodname_emus %}](/enterprise-cloud@latest/admin/authentication/managing-your-enterprise-users-with-your-identity-provider/about-enterprise-managed-users){% ifversion fpt %}" in the {% data variables.product.prodname_ghe_cloud %} documentation.{% else %}."{% endif %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.repositories.desktop-fork %}
|
||||
|
||||
Deleting a fork will not delete the original upstream repository. You can make any changes you want to your fork—add collaborators, rename files, generate {% data variables.product.prodname_pages %}—with no effect on the original.{% ifversion fpt or ghec %} You cannot restore a deleted forked repository. For more information, see "[Restoring a deleted repository](/articles/restoring-a-deleted-repository)."{% endif %}
|
||||
|
||||
In open source projects, forks are often used to iterate on ideas or changes before they are offered back to the upstream repository. When you make changes in your user-owned fork and open a pull request that compares your work to the upstream repository, you can give anyone with push access to the upstream repository permission to push changes to your pull request branch. This speeds up collaboration by allowing repository maintainers the ability to make commits or run tests locally to your pull request branch from a user-owned fork before merging. You cannot give push permissions to a fork owned by an organization.
|
||||
|
||||
{% data reusables.repositories.private_forks_inherit_permissions %}
|
||||
|
||||
If you want to create a new repository from the contents of an existing repository but don't want to merge your changes upstream in the future, you can duplicate the repository or, if the repository is a template, use the repository as a template. For more information, see "[Duplicating a repository](/articles/duplicating-a-repository)" and "[Creating a repository from a template](/articles/creating-a-repository-from-a-template)".
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[About collaborative development models](/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models)"
|
||||
- "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)"
|
||||
- [Open Source Guides](https://opensource.guide/){% ifversion fpt or ghec %}
|
||||
- [{% data variables.product.prodname_learning %}]({% data variables.product.prodname_learning_link %}){% endif %}
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: Allowing changes to a pull request branch created from a fork
|
||||
intro: 'For greater collaboration, you can allow commits on branches you''ve created from forks owned by your user account.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
permissions: People with push access to the upstream repository of a fork owned by a user account can commit to the forked branches.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Allow changes to a branch
|
||||
---
|
||||
Only pull request authors can give upstream repository maintainers, or those with push access to the upstream repository, permission to make commits to their pull request's compare branch in a user-owned fork. To learn more about upstream repositories, see "[About forks](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)."
|
||||
|
||||
Pull request authors can give these permissions when they initially create a pull request from a user-owned fork or after they create the pull request. For more information, see "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)."
|
||||
|
||||
You can set commit permissions when you first create a pull request from a fork. For more information, see "[Creating a pull request from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)." Additionally, you can modify an existing pull request to let repository maintainers make commits to your branch.
|
||||
|
||||
## Enabling repository maintainer permissions on existing pull requests
|
||||
|
||||
1. On {% data variables.product.product_name %}, navigate to the main page of the upstream repository of your pull request.
|
||||
2. Under the upstream repository name, click {% octicon "git-pull-request" aria-label="The pull request icon" %} **Pull requests**.
|
||||
|
||||
3. In the list of pull requests, navigate to the pull request that you'd like to allow commits on.
|
||||
{% data reusables.repositories.allow-maintainers-user-forks %}
|
||||
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Committing changes to a pull request branch created from a fork](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork)"
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Configuring a remote for a fork
|
||||
intro: 'You must configure a remote that points to the upstream repository in Git to [sync changes you make in a fork](/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) with the original repository. This also allows you to sync changes made in the original repository with the fork.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/configuring-a-remote-for-a-fork
|
||||
- /articles/configuring-a-remote-for-a-fork
|
||||
- /github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Configure a remote
|
||||
---
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. List the current configured remote repository for your fork.
|
||||
```shell
|
||||
$ git remote -v
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>YOUR_USERNAME</em>/<em>YOUR_FORK</em>.git (fetch)
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>YOUR_USERNAME</em>/<em>YOUR_FORK</em>.git (push)
|
||||
```
|
||||
3. Specify a new remote *upstream* repository that will be synced with the fork.
|
||||
```shell
|
||||
$ git remote add upstream https://{% data variables.command_line.codeblock %}/<em>ORIGINAL_OWNER</em>/<em>ORIGINAL_REPOSITORY</em>.git
|
||||
```
|
||||
4. Verify the new upstream repository you've specified for your fork.
|
||||
```shell
|
||||
$ git remote -v
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>YOUR_USERNAME</em>/<em>YOUR_FORK</em>.git (fetch)
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>YOUR_USERNAME</em>/<em>YOUR_FORK</em>.git (push)
|
||||
> upstream https://{% data variables.command_line.codeblock %}/<em>ORIGINAL_OWNER</em>/<em>ORIGINAL_REPOSITORY</em>.git (fetch)
|
||||
> upstream https://{% data variables.command_line.codeblock %}/<em>ORIGINAL_OWNER</em>/<em>ORIGINAL_REPOSITORY</em>.git (push)
|
||||
```
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Working with forks
|
||||
intro: 'Forks are often used in open source development on {% data variables.product.product_name %}.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/
|
||||
- /articles/working-with-forks
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-forks
|
||||
- /configuring-a-remote-for-a-fork
|
||||
- /syncing-a-fork
|
||||
- /merging-an-upstream-repository-into-your-fork
|
||||
- /allowing-changes-to-a-pull-request-branch-created-from-a-fork
|
||||
- /what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
|
||||
---
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: Merging an upstream repository into your fork
|
||||
intro: 'If you don''t have push (write) access to an upstream repository, then you can pull commits from that repository into your own fork.'
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork
|
||||
- /articles/merging-an-upstream-repository-into-your-fork
|
||||
- /github/collaborating-with-issues-and-pull-requests/merging-an-upstream-repository-into-your-fork
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Merge an upstream repo
|
||||
---
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Change the current working directory to your local project.
|
||||
3. Check out the branch you wish to merge to. Usually, you will merge into the default branch.
|
||||
```shell
|
||||
$ git checkout <em>DEFAULT_BRANCH_NAME</em>
|
||||
```
|
||||
4. Pull the desired branch from the upstream repository. This method will retain the commit history without modification.
|
||||
```shell
|
||||
$ git pull https://{% data variables.command_line.codeblock %}/<em>ORIGINAL_OWNER</em>/<em>ORIGINAL_REPOSITORY</em>.git <em>BRANCH_NAME</em>
|
||||
```
|
||||
5. If there are conflicts, resolve them. For more information, see "[Addressing merge conflicts](/github/collaborating-with-pull-requests/addressing-merge-conflicts)".
|
||||
6. Commit the merge.
|
||||
7. Review the changes and ensure they are satisfactory.
|
||||
8. Push the merge to your GitHub repository.
|
||||
```shell
|
||||
$ git push origin <em>DEFAULT_BRANCH_NAME</em>
|
||||
```
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: Syncing a fork
|
||||
intro: Sync a fork of a repository to keep it up-to-date with the upstream repository.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/syncing-a-fork
|
||||
- /articles/syncing-a-fork
|
||||
- /github/collaborating-with-issues-and-pull-requests/syncing-a-fork
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/syncing-a-fork
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
---
|
||||
|
||||
{% ifversion fpt or ghes > 3.1 or ghae-next or ghec %}
|
||||
|
||||
## Syncing a fork from the web UI
|
||||
|
||||
1. On {% data variables.product.product_name %}, navigate to the main page of the forked repository that you want to sync with the upstream repository.
|
||||
1. Select the **Fetch upstream** drop-down.
|
||||
|
||||
1. Review the details about the commits from the upstream repository, then click **Fetch and merge**.
|
||||
|
||||
|
||||
If the changes from the upstream repository cause conflicts, {% data variables.product.company_short %} will prompt you to create a pull request to resolve the conflicts.
|
||||
|
||||
## Syncing a fork from the command line
|
||||
|
||||
{% endif %}
|
||||
Before you can sync your fork with an upstream repository, you must [configure a remote that points to the upstream repository](/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork) in Git.
|
||||
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Change the current working directory to your local project.
|
||||
3. Fetch the branches and their respective commits from the upstream repository. Commits to `BRANCHNAME` will be stored in the local branch `upstream/BRANCHNAME`.
|
||||
```shell
|
||||
$ git fetch upstream
|
||||
> remote: Counting objects: 75, done.
|
||||
> remote: Compressing objects: 100% (53/53), done.
|
||||
> remote: Total 62 (delta 27), reused 44 (delta 9)
|
||||
> Unpacking objects: 100% (62/62), done.
|
||||
> From https://{% data variables.command_line.codeblock %}/<em>ORIGINAL_OWNER</em>/<em>ORIGINAL_REPOSITORY</em>
|
||||
> * [new branch] main -> upstream/main
|
||||
```
|
||||
4. Check out your fork's local default branch - in this case, we use `main`.
|
||||
```shell
|
||||
$ git checkout main
|
||||
> Switched to branch 'main'
|
||||
```
|
||||
5. Merge the changes from the upstream default branch - in this case, `upstream/main` - into your local default branch. This brings your fork's default branch into sync with the upstream repository, without losing your local changes.
|
||||
```shell
|
||||
$ git merge upstream/main
|
||||
> Updating a422352..5fdff0f
|
||||
> Fast-forward
|
||||
> README | 9 -------
|
||||
> README.md | 7 ++++++
|
||||
> 2 files changed, 7 insertions(+), 9 deletions(-)
|
||||
> delete mode 100644 README
|
||||
> create mode 100644 README.md
|
||||
``` If your local branch didn't have any unique commits, Git will instead perform a "fast-forward":
|
||||
```shell
|
||||
$ git merge upstream/main
|
||||
> Updating 34e91da..16c56ad
|
||||
> Fast-forward
|
||||
> README.md | 5 +++--
|
||||
> 1 file changed, 3 insertions(+), 2 deletions(-)
|
||||
```
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: Syncing your fork only updates your local copy of the repository. To update your fork on {% data variables.product.product_location %}, you must [push your changes](/github/getting-started-with-github/pushing-commits-to-a-remote-repository/).
|
||||
|
||||
{% endtip %}
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: What happens to forks when a repository is deleted or changes visibility?
|
||||
intro: Deleting your repository or changing its visibility affects that repository's forks.
|
||||
redirect_from:
|
||||
- /github/collaborating-with-issues-and-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
|
||||
- /articles/changing-the-visibility-of-a-network/
|
||||
- /articles/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
|
||||
- /github/collaborating-with-issues-and-pull-requests/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
|
||||
- /github/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
shortTitle: Deleted or changes visibility
|
||||
---
|
||||
{% data reusables.repositories.deleted_forks_from_private_repositories_warning %}
|
||||
|
||||
## Deleting a private repository
|
||||
|
||||
When you delete a private repository, all of its private forks are also deleted.
|
||||
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
|
||||
## Deleting a public repository
|
||||
|
||||
When you delete a public repository, one of the existing public forks is chosen to be the new parent repository. All other repositories are forked off of this new parent and subsequent pull requests go to this new parent.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Private forks and permissions
|
||||
|
||||
{% data reusables.repositories.private_forks_inherit_permissions %}
|
||||
|
||||
{% ifversion fpt or ghes or ghec %}
|
||||
|
||||
## Changing a public repository to a private repository
|
||||
|
||||
If a public repository is made private, its public forks are split off into a new network. As with deleting a public repository, one of the existing public forks is chosen to be the new parent repository and all other repositories are forked off of this new parent. Subsequent pull requests go to this new parent.
|
||||
|
||||
In other words, a public repository's forks will remain public in their own separate repository network even after the parent repository is made private. This allows the fork owners to continue to work and collaborate without interruption. If public forks were not moved into a separate network in this way, the owners of those forks would need to get the appropriate [access permissions](/articles/access-permissions-on-github) to pull changes from and submit pull requests to the (now private) parent repository—even though they didn't need those permissions before.
|
||||
|
||||
{% ifversion ghes or ghae %}
|
||||
If a public repository has anonymous Git read access enabled and the repository is made private, all of the repository's forks will lose anonymous Git read access and return to the default disabled setting. If a forked repository is made public, repository administrators can re-enable anonymous Git read access. For more information, see "[Enabling anonymous Git read access for a repository](/enterprise/{{ currentVersion }}/user/articles/enabling-anonymous-git-read-access-for-a-repository)."
|
||||
{% endif %}
|
||||
|
||||
### Deleting the private repository
|
||||
|
||||
If a public repository is made private and then deleted, its public forks will continue to exist in a separate network.
|
||||
|
||||
## Changing a private repository to a public repository
|
||||
|
||||
If a private repository is made public, each of its private forks is turned into a standalone private repository and becomes the parent of its own new repository network. Private forks are never automatically made public because they could contain sensitive commits that shouldn't be exposed publicly.
|
||||
|
||||
### Deleting the public repository
|
||||
|
||||
If a private repository is made public and then deleted, its private forks will continue to exist as standalone private repositories in separate networks.
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghae or ghes or ghec %}
|
||||
|
||||
## Changing the visibility of an internal repository
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data reusables.gated-features.internal-repos %}
|
||||
|
||||
{% endnote %}
|
||||
|
||||
If the policy for your enterprise permits forking, any fork of an internal repository will be private. If you change the visibility of an internal repository, any fork owned by an organization or user account will remain private.
|
||||
|
||||
### Deleting the internal repository
|
||||
|
||||
If you change the visibility of an internal repository and then delete the repository, the forks will continue to exist in a separate network.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Setting repository visibility](/articles/setting-repository-visibility)"
|
||||
- "[About forks](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)"
|
||||
- "[Managing the forking policy for your repository](/github/administering-a-repository/managing-the-forking-policy-for-your-repository)"
|
||||
- "[Managing the forking policy for your organization](/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization)"
|
||||
- "[Enforcing repository management policies in your enterprise](/admin/policies/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-on-forking-private-or-internal-repositories)"
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: About commits
|
||||
intro: You can save small groups of meaningful changes as commits.
|
||||
redirect_from:
|
||||
- /articles/why-are-my-commits-in-the-wrong-order
|
||||
- /github/committing-changes-to-your-project/why-are-my-commits-in-the-wrong-order
|
||||
- /github/committing-changes-to-your-project/about-commits
|
||||
- /github/committing-changes-to-your-project/creating-and-editing-commits/about-commits
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
---
|
||||
## About commits
|
||||
|
||||
{% data reusables.commits.about-commits %}
|
||||
|
||||
You can add a co-author on any commits you collaborate on. For more information, see "[Creating a commit with multiple authors](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)."
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
You can also create a commit on behalf of an organization. For more information, see "[Creating a commit on behalf of an organization](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-on-behalf-of-an-organization)."{% endif %}
|
||||
|
||||
Rebasing allows you to change a series of commits and can modify the order of the commits in your timeline. For more information, see "[About git rebase](/github/getting-started-with-github/about-git-rebase)."
|
||||
|
||||
## Further reading
|
||||
- "[Committing and reviewing changes to your project](/desktop/contributing-to-projects/committing-and-reviewing-changes-to-your-project#about-commits)" on {% data variables.product.prodname_desktop %}
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: Changing a commit message
|
||||
redirect_from:
|
||||
- /articles/can-i-delete-a-commit-message/
|
||||
- /articles/changing-a-commit-message
|
||||
- /github/committing-changes-to-your-project/changing-a-commit-message
|
||||
- /github/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message
|
||||
intro: 'If a commit message contains unclear, incorrect, or sensitive information, you can amend it locally and push a new commit with a new message to {% data variables.product.product_name %}. You can also change a commit message to add missing information.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
---
|
||||
## Rewriting the most recent commit message
|
||||
|
||||
You can change the most recent commit message using the `git commit --amend` command.
|
||||
|
||||
In Git, the text of the commit message is part of the commit. Changing the commit message will change the commit ID--i.e., the SHA1 checksum that names the commit. Effectively, you are creating a new commit that replaces the old one.
|
||||
|
||||
## Commit has not been pushed online
|
||||
|
||||
If the commit only exists in your local repository and has not been pushed to {% data variables.product.product_location %}, you can amend the commit message with the `git commit --amend` command.
|
||||
|
||||
1. On the command line, navigate to the repository that contains the commit you want to amend.
|
||||
2. Type `git commit --amend` and press **Enter**.
|
||||
3. In your text editor, edit the commit message, and save the commit.
|
||||
- You can add a co-author by adding a trailer to the commit. For more information, see "[Creating a commit with multiple authors](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)."
|
||||
{% ifversion fpt or ghec %}
|
||||
- You can create commits on behalf of your organization by adding a trailer to the commit. For more information, see "[Creating a commit on behalf of an organization](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-on-behalf-of-an-organization)"
|
||||
{% endif %}
|
||||
|
||||
The new commit and message will appear on {% data variables.product.product_location %} the next time you push.
|
||||
|
||||
{% tip %}
|
||||
|
||||
You can change the default text editor for Git by changing the `core.editor` setting. For more information, see "[Basic Client Configuration](https://git-scm.com/book/en/Customizing-Git-Git-Configuration#_basic_client_configuration)" in the Git manual.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Amending older or multiple commit messages
|
||||
|
||||
If you have already pushed the commit to {% data variables.product.product_location %}, you will have to force push a commit with an amended message.
|
||||
|
||||
{% warning %}
|
||||
|
||||
We strongly discourage force pushing, since this changes the history of your repository. If you force push, people who have already cloned your repository will have to manually fix their local history. For more information, see "[Recovering from upstream rebase](https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase)" in the Git manual.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
**Changing the message of the most recently pushed commit**
|
||||
|
||||
1. Follow the [steps above](/articles/changing-a-commit-message#commit-has-not-been-pushed-online) to amend the commit message.
|
||||
2. Use the `push --force-with-lease` command to force push over the old commit.
|
||||
```shell
|
||||
$ git push --force-with-lease <em>example-branch</em>
|
||||
```
|
||||
|
||||
**Changing the message of older or multiple commit messages**
|
||||
|
||||
If you need to amend the message for multiple commits or an older commit, you can use interactive rebase, then force push to change the commit history.
|
||||
|
||||
1. On the command line, navigate to the repository that contains the commit you want to amend.
|
||||
2. Use the `git rebase -i HEAD~n` command to display a list of the last `n` commits in your default text editor.
|
||||
|
||||
```shell
|
||||
# Displays a list of the last 3 commits on the current branch
|
||||
$ git rebase -i HEAD~3
|
||||
```
|
||||
The list will look similar to the following:
|
||||
|
||||
```shell
|
||||
pick e499d89 Delete CNAME
|
||||
pick 0c39034 Better README
|
||||
pick f7fde4a Change the commit message but push the same commit.
|
||||
|
||||
# Rebase 9fdb3bd..f7fde4a onto 9fdb3bd
|
||||
#
|
||||
# Commands:
|
||||
# p, pick = use commit
|
||||
# r, reword = use commit, but edit the commit message
|
||||
# e, edit = use commit, but stop for amending
|
||||
# s, squash = use commit, but meld into previous commit
|
||||
# f, fixup = like "squash", but discard this commit's log message
|
||||
# x, exec = run command (the rest of the line) using shell
|
||||
#
|
||||
# These lines can be re-ordered; they are executed from top to bottom.
|
||||
#
|
||||
# If you remove a line here THAT COMMIT WILL BE LOST.
|
||||
#
|
||||
# However, if you remove everything, the rebase will be aborted.
|
||||
#
|
||||
# Note that empty commits are commented out
|
||||
```
|
||||
3. Replace `pick` with `reword` before each commit message you want to change.
|
||||
```shell
|
||||
pick e499d89 Delete CNAME
|
||||
reword 0c39034 Better README
|
||||
reword f7fde4a Change the commit message but push the same commit.
|
||||
```
|
||||
4. Save and close the commit list file.
|
||||
5. In each resulting commit file, type the new commit message, save the file, and close it.
|
||||
6. When you're ready to push your changes to GitHub, use the push --force command to force push over the old commit.
|
||||
```shell
|
||||
$ git push --force <em>example-branch</em>
|
||||
```
|
||||
|
||||
For more information on interactive rebase, see "[Interactive mode](https://git-scm.com/docs/git-rebase#_interactive_mode)" in the Git manual.
|
||||
|
||||
{% tip %}
|
||||
|
||||
As before, amending the commit message will result in a new commit with a new ID. However, in this case, every commit that follows the amended commit will also get a new ID because each commit also contains the id of its parent.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
{% warning %}
|
||||
|
||||
If you have included sensitive information in a commit message, force pushing a commit with an amended commit may not remove the original commit from {% data variables.product.product_name %}. The old commit will not be a part of a subsequent clone; however, it may still be cached on {% data variables.product.product_name %} and accessible via the commit ID. You must contact {% data variables.contact.contact_support %} with the old commit ID to have it purged from the remote repository.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
## Further reading
|
||||
|
||||
* "[Signing commits](/articles/signing-commits)"
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Creating a commit on behalf of an organization
|
||||
intro: 'You can create commits on behalf of an organization by adding a trailer to the commit''s message. Commits attributed to an organization include an `on-behalf-of` badge on {% data variables.product.product_name %}.'
|
||||
redirect_from:
|
||||
- /articles/creating-a-commit-on-behalf-of-an-organization
|
||||
- /github/committing-changes-to-your-project/creating-a-commit-on-behalf-of-an-organization
|
||||
- /github/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-on-behalf-of-an-organization
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
shortTitle: On behalf of an organization
|
||||
---
|
||||
{% note %}
|
||||
|
||||
**Note:** The ability to create a commit on behalf of an organization is currently in public beta and is subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
To create commits on behalf of an organization:
|
||||
|
||||
- you must be a member of the organization indicated in the trailer
|
||||
- you must sign the commit
|
||||
- your commit email and the organization email must be in a domain verified by the organization
|
||||
- your commit message must end with the commit trailer `on-behalf-of: @org <name@organization.com>`
|
||||
- `org` is the organization's login
|
||||
- `name@organization.com` is in the organization's domain
|
||||
|
||||
Organization's can use the `name@organization.com` email as a public point of contact for open source efforts.
|
||||
|
||||
## Creating commits with an `on-behalf-of` badge on the command line
|
||||
|
||||
1. Type your commit message and a short, meaningful description of your changes. After your commit description, instead of a closing quotation, add two empty lines.
|
||||
```shell
|
||||
$ git commit -m "Refactor usability tests.
|
||||
>
|
||||
>
|
||||
```
|
||||
{% tip %}
|
||||
|
||||
**Tip:** If you're using a text editor on the command line to type your commit message, ensure there are two newlines between the end of your commit description and the `on-behalf-of:` commit trailer.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
2. On the next line of the commit message, type `on-behalf-of: @org <name@organization.com>`, then a closing quotation mark.
|
||||
|
||||
```shell
|
||||
$ git commit -m "Refactor usability tests.
|
||||
>
|
||||
>
|
||||
on-behalf-of: <em>@org</em> <<em>name@organization.com</em>>"
|
||||
```
|
||||
|
||||
The new commit, message, and badge will appear on {% data variables.product.product_location %} the next time you push. For more information, see "[Pushing changes to a remote repository](/github/getting-started-with-github/pushing-commits-to-a-remote-repository/)."
|
||||
|
||||
## Creating commits with an `on-behalf-of` badge on {% data variables.product.product_name %}
|
||||
|
||||
After you've made changes in a file using the web editor on {% data variables.product.product_name %}, you can create a commit on behalf of your organization by adding an `on-behalf-of:` trailer to the commit's message.
|
||||
|
||||
1. After making your changes, at the bottom of the page, type a short, meaningful commit message that describes the changes you made.
|
||||
|
||||
|
||||
2. In the text box below your commit message, add `on-behalf-of: @org <name@organization.com>`.
|
||||
|
||||
|
||||
4. Click **Commit changes** or **Propose changes**.
|
||||
|
||||
The new commit, message, and badge will appear on {% data variables.product.product_location %}.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Viewing contributions on your profile](/articles/viewing-contributions-on-your-profile)"
|
||||
- "[Why are my contributions not showing up on my profile?](/articles/why-are-my-contributions-not-showing-up-on-my-profile)"
|
||||
- "[Viewing a project’s contributors](/articles/viewing-a-projects-contributors)"
|
||||
- "[Changing a commit message](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message)"
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: Creating a commit with multiple authors
|
||||
intro: 'You can attribute a commit to more than one author by adding one or more `Co-authored-by` trailers to the commit''s message. Co-authored commits are visible on {% data variables.product.product_name %}{% ifversion ghes or ghae %} and can be included in the profile contributions graph and the repository''s statistics{% endif %}.'
|
||||
redirect_from:
|
||||
- /articles/creating-a-commit-with-multiple-authors
|
||||
- /github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors
|
||||
- /github/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
shortTitle: With multiple authors
|
||||
---
|
||||
## Required co-author information
|
||||
|
||||
Before you can add a co-author to a commit, you must know the appropriate email to use for each co-author. For the co-author's commit to count as a contribution, you must use the email associated with their account on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
|
||||
If a person chooses to keep their email address private, you should use their {% data variables.product.product_name %}-provided `no-reply` email to protect their privacy. Otherwise, the co-author's email will be available to the public in the commit message. If you want to keep your email private, you can choose to use a {% data variables.product.product_name %}-provided `no-reply` email for Git operations and ask other co-authors to list your `no-reply` email in commit trailers.
|
||||
|
||||
For more information, see "[Setting your commit email address](/articles/setting-your-commit-email-address)."
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** You can help a co-author find their preferred email address by sharing this information:
|
||||
- To find your {% data variables.product.product_name %}-provided `no-reply` email, navigate to your email settings page under "Keep my email address private."
|
||||
- To find the email you used to configure Git on your computer, run `git config user.email` on the command line.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Creating co-authored commits using {% data variables.product.prodname_desktop %}
|
||||
|
||||
You can use {% data variables.product.prodname_desktop %} to create a commit with a co-author. For more information, see "[Write a commit message and push your changes](/desktop/contributing-to-projects/committing-and-reviewing-changes-to-your-project#4-write-a-commit-message-and-push-your-changes)" and [{% data variables.product.prodname_desktop %}](https://desktop.github.com).
|
||||
|
||||
|
||||
|
||||
## Creating co-authored commits on the command line
|
||||
|
||||
{% data reusables.pull_requests.collect-co-author-commit-git-config-info %}
|
||||
|
||||
1. Type your commit message and a short, meaningful description of your changes. After your commit description, instead of a closing quotation, add two empty lines.
|
||||
```shell
|
||||
$ git commit -m "Refactor usability tests.
|
||||
>
|
||||
>
|
||||
```
|
||||
{% tip %}
|
||||
|
||||
**Tip:** If you're using a text editor on the command line to type your commit message, ensure there are two newlines between the end of your commit description and the `Co-authored-by:` commit trailer.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
3. On the next line of the commit message, type `Co-authored-by: name <name@example.com>` with specific information for each co-author. After the co-author information, add a closing quotation mark.
|
||||
|
||||
If you're adding multiple co-authors, give each co-author their own line and `Co-authored-by:` commit trailer.
|
||||
```shell
|
||||
$ git commit -m "Refactor usability tests.
|
||||
>
|
||||
>
|
||||
Co-authored-by: <em>name</em> <<em>name@example.com</em>>
|
||||
Co-authored-by: <em>another-name</em> <<em>another-name@example.com</em>>"
|
||||
```
|
||||
|
||||
The new commit and message will appear on {% data variables.product.product_location %} the next time you push. For more information, see "[Pushing changes to a remote repository](/github/getting-started-with-github/pushing-commits-to-a-remote-repository/)."
|
||||
|
||||
## Creating co-authored commits on {% data variables.product.product_name %}
|
||||
|
||||
After you've made changes in a file using the web editor on {% data variables.product.product_name %}, you can create a co-authored commit by adding a `Co-authored-by:` trailer to the commit's message.
|
||||
|
||||
{% data reusables.pull_requests.collect-co-author-commit-git-config-info %}
|
||||
2. After making your changes together, at the bottom of the page, type a short, meaningful commit message that describes the changes you made.
|
||||
|
||||
3. In the text box below your commit message, add `Co-authored-by: name <name@example.com>` with specific information for each co-author. If you're adding multiple co-authors, give each co-author their own line and `Co-authored-by:` commit trailer.
|
||||
|
||||
|
||||
4. Click **Commit changes** or **Propose changes**.
|
||||
|
||||
The new commit and message will appear on {% data variables.product.product_location %}.
|
||||
|
||||
## Further reading
|
||||
{% ifversion ghes or ghae %}
|
||||
- "[Viewing contributions on your profile](/articles/viewing-contributions-on-your-profile)"
|
||||
- "[Why are my contributions not showing up on my profile?](/articles/why-are-my-contributions-not-showing-up-on-my-profile)"{% endif %}
|
||||
- "[Viewing a project's contributors](/articles/viewing-a-projects-contributors)"
|
||||
- "[Changing a commit message](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message)"
|
||||
- "[Committing and reviewing changes to your project](/desktop/contributing-to-projects/committing-and-reviewing-changes-to-your-project#4-write-a-commit-message-and-push-your-changes)" in the {% data variables.product.prodname_desktop %} documentation
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Creating and editing commits
|
||||
intro: ''
|
||||
redirect_from:
|
||||
- /articles/creating-and-editing-commits
|
||||
- /github/committing-changes-to-your-project/creating-and-editing-commits
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
children:
|
||||
- /about-commits
|
||||
- /creating-a-commit-with-multiple-authors
|
||||
- /creating-a-commit-on-behalf-of-an-organization
|
||||
- /changing-a-commit-message
|
||||
shortTitle: Create & edit commits
|
||||
---
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Committing changes to your project
|
||||
intro: You can manage code changes in a repository by grouping work into commits.
|
||||
redirect_from:
|
||||
- /categories/21/articles/
|
||||
- /categories/commits/
|
||||
- /categories/committing-changes-to-your-project
|
||||
- /github/committing-changes-to-your-project
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
children:
|
||||
- /creating-and-editing-commits
|
||||
- /viewing-and-comparing-commits
|
||||
- /troubleshooting-commits
|
||||
shortTitle: Commit changes to your project
|
||||
---
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
title: Commit exists on GitHub but not in my local clone
|
||||
intro: 'Sometimes a commit will be viewable on {% data variables.product.product_name %}, but will not exist in your local clone of the repository.'
|
||||
redirect_from:
|
||||
- /articles/commit-exists-on-github-but-not-in-my-local-clone
|
||||
- /github/committing-changes-to-your-project/commit-exists-on-github-but-not-in-my-local-clone
|
||||
- /github/committing-changes-to-your-project/troubleshooting-commits/commit-exists-on-github-but-not-in-my-local-clone
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
shortTitle: Commit missing in local clone
|
||||
---
|
||||
When you use `git show` to view a specific commit on the command line, you may get a fatal error.
|
||||
|
||||
For example, you may receive a `bad object` error locally:
|
||||
|
||||
```shell
|
||||
$ git show 1095ff3d0153115e75b7bca2c09e5136845b5592
|
||||
> fatal: bad object 1095ff3d0153115e75b7bca2c09e5136845b5592
|
||||
```
|
||||
|
||||
However, when you view the commit on {% data variables.product.product_location %}, you'll be able to see it without any problems:
|
||||
|
||||
`github.com/$account/$repository/commit/1095ff3d0153115e75b7bca2c09e5136845b5592`
|
||||
|
||||
There are several possible explanations:
|
||||
|
||||
* The local repository is out of date.
|
||||
* The branch that contains the commit was deleted, so the commit is no longer referenced.
|
||||
* Someone force pushed over the commit.
|
||||
|
||||
## The local repository is out of date
|
||||
|
||||
Your local repository may not have the commit yet. To get information from your remote repository to your local clone, use `git fetch`:
|
||||
|
||||
```shell
|
||||
$ git fetch <em>remote</em>
|
||||
```
|
||||
|
||||
This safely copies information from the remote repository to your local clone without making any changes to the files you have checked out.
|
||||
You can use `git fetch upstream` to get information from a repository you've forked, or `git fetch origin` to get information from a repository you've only cloned.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: For more information, read about [managing remotes and fetching data](https://git-scm.com/book/en/Git-Basics-Working-with-Remotes) in the [Pro Git](https://git-scm.com/book) book.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## The branch that contained the commit was deleted
|
||||
|
||||
If a collaborator on the repository has deleted the branch containing the commit
|
||||
or has force pushed over the branch, the missing commit may have been orphaned
|
||||
(i.e. it cannot be reached from any reference) and therefore will not be fetched
|
||||
into your local clone.
|
||||
|
||||
Fortunately, if any collaborator has a local clone of the repository with the
|
||||
missing commit, they can push it back to {% data variables.product.product_name %}. They need to make sure the commit
|
||||
is referenced by a local branch and then push it as a new branch to {% data variables.product.product_name %}.
|
||||
|
||||
Let's say that the person still has a local branch (call it `B`) that contains
|
||||
the commit. This might be tracking the branch that was force pushed or deleted
|
||||
and they simply haven't updated yet. To preserve the commit, they can push that
|
||||
local branch to a new branch (call it `recover-B`) on {% data variables.product.product_name %}. For this example,
|
||||
let's assume they have a remote named `upstream` via which they have push access
|
||||
to `github.com/$account/$repository`.
|
||||
|
||||
The other person runs:
|
||||
|
||||
```shell
|
||||
$ git branch recover-B B
|
||||
# Create a new local branch referencing the commit
|
||||
$ git push upstream B:recover-B
|
||||
# Push local B to new upstream branch, creating new reference to commit
|
||||
```
|
||||
|
||||
Now, *you* can run:
|
||||
|
||||
```shell
|
||||
$ git fetch upstream recover-B
|
||||
# Fetch commit into your local repository.
|
||||
```
|
||||
|
||||
## Avoid force pushes
|
||||
|
||||
Avoid force pushing to a repository unless absolutely necessary. This is especially true if more than one person can push to the repository.
|
||||
|
||||
## Further reading
|
||||
|
||||
- ["Working with Remotes" from the _Pro Git_ book](https://git-scm.com/book/en/Git-Basics-Working-with-Remotes)
|
||||
- ["Data Recovery" from the _Pro Git_ book](https://git-scm.com/book/en/Git-Internals-Maintenance-and-Data-Recovery)
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Troubleshooting commits
|
||||
intro: ''
|
||||
redirect_from:
|
||||
- /articles/troubleshooting-commits
|
||||
- /github/committing-changes-to-your-project/troubleshooting-commits
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
children:
|
||||
- /commit-exists-on-github-but-not-in-my-local-clone
|
||||
- /why-are-my-commits-linked-to-the-wrong-user
|
||||
---
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Why are my commits linked to the wrong user?
|
||||
redirect_from:
|
||||
- /articles/how-do-i-get-my-commits-to-link-to-my-github-account/
|
||||
- /articles/why-are-my-commits-linked-to-the-wrong-user
|
||||
- /github/committing-changes-to-your-project/why-are-my-commits-linked-to-the-wrong-user
|
||||
- /github/committing-changes-to-your-project/troubleshooting-commits/why-are-my-commits-linked-to-the-wrong-user
|
||||
intro: '{% data variables.product.product_name %} uses the email address in the commit header to link the commit to a GitHub user. If your commits are being linked to another user, or not linked to a user at all, you may need to change your local Git configuration settings{% ifversion not ghae %}, add an email address to your account email settings, or do both{% endif %}.'
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
shortTitle: Linked to wrong user
|
||||
---
|
||||
{% tip %}
|
||||
|
||||
**Note**: If your commits are linked to another user, that does not mean the user can access your repository. A user can only access a repository you own if you add them as a collaborator or add them to a team that has access to the repository.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
## Commits are linked to another user
|
||||
|
||||
If your commits are linked to another user, that means the email address in your local Git configuration settings is connected to that user's account on {% data variables.product.product_name %}. In this case, you can change the email in your local Git configuration settings{% ifversion ghae %} to the address associated with your account on {% data variables.product.product_name %} to link your future commits. Old commits will not be linked. For more information, see "[Setting your commit email address](/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-in-git)."{% else %} and add the new email address to your account on {% ifversion ghae %}{% data variables.product.product_name %}{% else %}{% data variables.product.product_location %}{% endif %} account to link future commits to your account.
|
||||
|
||||
1. To change the email address in your local Git configuration, follow the steps in "[Setting your commit email address](/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-in-git)". If you work on multiple machines, you will need to change this setting on each one.
|
||||
2. Add the email address from step 2 to your account settings by following the steps in "[Adding an email address to your GitHub account](/articles/adding-an-email-address-to-your-github-account)".{% endif %}
|
||||
|
||||
Commits you make from this point forward will be linked to your account.
|
||||
|
||||
## Commits are not linked to any user
|
||||
|
||||
If your commits are not linked to any user, the commit author's name will not be rendered as a link to a user profile.
|
||||
|
||||
To check the email address used for those commits and connect commits to your account, take the following steps:
|
||||
|
||||
1. Navigate to the commit by clicking the commit message link.
|
||||
|
||||
2. To read a message about why the commit is not linked, hover over the blue {% octicon "question" aria-label="Question mark" %} to the right of the username.
|
||||
|
||||
|
||||
- **Unrecognized author (with email address)** If you see this message with an email address, the address you used to author the commit is not connected to your account on {% data variables.product.product_name %}. {% ifversion not ghae %}To link your commits, [add the email address to your GitHub email settings](/articles/adding-an-email-address-to-your-github-account).{% endif %} If the email address has a Gravatar associated with it, the Gravatar will be displayed next to the commit, rather than the default gray Octocat.
|
||||
- **Unrecognized author (no email address)** If you see this message without an email address, you used a generic email address that can't be connected to your account on {% data variables.product.product_name %}.{% ifversion not ghae %} You will need to [set your commit email address in Git](/articles/setting-your-commit-email-address), then [add the new address to your GitHub email settings](/articles/adding-an-email-address-to-your-github-account) to link your future commits. Old commits will not be linked.{% endif %}
|
||||
- **Invalid email** The email address in your local Git configuration settings is either blank or not formatted as an email address.{% ifversion not ghae %} You will need to [set your commit email address in Git](/articles/setting-your-commit-email-address), then [add the new address to your GitHub email settings](/articles/adding-an-email-address-to-your-github-account) to link your future commits. Old commits will not be linked.{% endif %}
|
||||
|
||||
{% ifversion ghae %}
|
||||
You can change the email in your local Git configuration settings to the address associated with your account to link your future commits. Old commits will not be linked. For more information, see "[Setting your commit email address](/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-in-git)."
|
||||
{% endif %}
|
||||
|
||||
{% warning %}
|
||||
|
||||
If your local Git configuration contained a generic email address, or an email address that was already attached to another user's account, then your previous commits will not be linked to your account. While Git does allow you to change the email address used for previous commits, we strongly discourage this, especially in a shared repository.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
## Further reading
|
||||
|
||||
* "[Searching commits](/search-github/searching-on-github/searching-commits)"
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Commit branch and tag labels
|
||||
intro: You can easily see what branch a commit is in by looking at the labels beneath the commit on the commit page.
|
||||
redirect_from:
|
||||
- /articles/commit-branch-and-tag-labels
|
||||
- /github/committing-changes-to-your-project/commit-branch-and-tag-labels
|
||||
- /github/committing-changes-to-your-project/viewing-and-comparing-commits/commit-branch-and-tag-labels
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
shortTitle: Branch & tag labels
|
||||
---
|
||||
If your commit is not on the default branch, an indicator will show the branches which contain the commit. If the commit is part of an unmerged pull request, it will show a link.
|
||||
|
||||
|
||||
|
||||
Once the commit is on the default branch, any tags that contain the commit will be shown and the default branch will be the only branch listed.
|
||||
|
||||
|
||||
|
||||
## Further reading
|
||||
|
||||
* "[Signing commits](/articles/signing-commits)"
|
||||
* "[Signing tags](/articles/signing-tags)"
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Comparing commits
|
||||
intro: 'You can compare the state of your repository across branches, tags, commits, forks, and dates.'
|
||||
redirect_from:
|
||||
- /articles/comparing-commits-across-time
|
||||
- /github/committing-changes-to-your-project/comparing-commits-across-time
|
||||
- /github/committing-changes-to-your-project/comparing-commits
|
||||
- /github/committing-changes-to-your-project/viewing-and-comparing-commits/comparing-commits
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
---
|
||||
To compare different versions of your repository, append `/compare` to your repository's path.
|
||||
|
||||
We'll demonstrate the power of Compare by looking at the compare page for [a fork of the Linguist repo](https://github.com/octocat/linguist), which is at [https://github.com/octocat/linguist/compare/master...octocat:master](https://github.com/octocat/linguist/compare/master...octocat:master).
|
||||
|
||||
Every repository's Compare view contains two drop down menus: `base` and `compare`.
|
||||
|
||||
`base` should be considered the starting point of your comparison, and `compare` is the endpoint. During a comparison, you can always change your `base` and `compare` points by clicking on **Edit**.
|
||||
|
||||
## Comparing branches
|
||||
|
||||
The most common use of Compare is to compare branches, such as when you're starting a new pull request. You'll always be taken to the branch comparison view when starting [a new pull request](/articles/creating-a-pull-request).
|
||||
|
||||
To compare branches, you can select a branch name from the `compare` drop down menu at the top of the page.
|
||||
|
||||
Here's an example of a [comparison between two branches](https://github.com/octocat/linguist/compare/master...octocat:an-example-comparison-for-docs).
|
||||
|
||||
## Comparing tags
|
||||
|
||||
Comparing release tags will show you changes to your repository since the last release. {% ifversion fpt or ghae or ghes or ghec %}
|
||||
For more information, see "[Comparing releases](/github/administering-a-repository/comparing-releases)."{% endif %}
|
||||
|
||||
{% ifversion fpt or ghae or ghes or ghec %}To compare tags, you can select a tag name from the `compare` drop-down menu at the top of the page.{% else %} Instead of typing a branch name, type the name of your tag in the `compare` drop down menu.{% endif %}
|
||||
|
||||
Here's an example of a [comparison between two tags](https://github.com/octocat/linguist/compare/v2.2.0...octocat:v2.3.3).
|
||||
|
||||
## Comparing commits
|
||||
|
||||
You can also compare two arbitrary commits in your repository or its forks on {% data variables.product.prodname_dotcom %} in a two-dot diff comparison.
|
||||
|
||||
To quickly compare two commits or Git Object IDs (OIDs) directly with each other in a two-dot diff comparison on {% data variables.product.prodname_dotcom %}, edit the URL of your repository's "Comparing changes" page.
|
||||
|
||||
{% data reusables.repositories.two-dot-diff-comparison-example-urls %}
|
||||
|
||||
To learn more about other comparison options, see "[Three-dot and two-dot diff comparisons](/articles/about-comparing-branches-in-pull-requests#three-dot-and-two-dot-git-diff-comparisons)."
|
||||
|
||||
## Comparing across forks
|
||||
|
||||
You can compare your base repository and any forked repository. This is the view that's presented when a user performs a Pull Request to a project.
|
||||
|
||||
To compare branches on different repositories, preface the branch names with user names. For example, by specifying `octocat:main` for `base` and `octo-org:main` for `compare`, you can compare the `main` branch of the repositories respectively owned by `octocat` and `octo-org`.
|
||||
|
||||
Here's an example of a [comparison between two repositories](https://github.com/octocat/linguist/compare/master...octo-org:master).
|
||||
|
||||
## Comparisons across commits
|
||||
|
||||
As a shortcut, Git uses the `^` notation to mean "one commit prior."
|
||||
|
||||
You can use this notation to compare a single commit or branch against its immediate predecessors. For example, `96d29b7^^^^^` indicates five commits prior to `96d29b7`, because there are five `^` marks. Typing `96d29b7^^^^^` in the `base` branch and `96d29b7` in the `compare` branch compares the five commits made before `96d29b7` with the `96d29b7` commit.
|
||||
|
||||
Here's an example of a [comparison using the `^` notation](https://github.com/octocat/linguist/compare/octocat:96d29b7%5E%5E%5E%5E%5E...octocat:96d29b7).
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Changing the base branch of a pull request](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request)"
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Differences between commit views
|
||||
intro: You might observe differences in commit history depending on the chosen viewing method.
|
||||
redirect_from:
|
||||
- /articles/differences-between-commit-views
|
||||
- /github/committing-changes-to-your-project/differences-between-commit-views
|
||||
- /github/committing-changes-to-your-project/viewing-and-comparing-commits/differences-between-commit-views
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
shortTitle: Commit views
|
||||
---
|
||||
On {% data variables.product.product_name %}, you can see the commit history of a repository by:
|
||||
|
||||
- Navigating directly to [the commits page](https://github.com/mozilla/rust/commits/master) of a repository
|
||||
- Clicking on a file, then clicking **History**, to get to [the commit history for a specific file](https://github.com/mozilla/rust/commits/master/README.md)
|
||||
|
||||
These two commit views may show _different_ information at times. The history for a single file may omit commits found on the repository's commit history.
|
||||
|
||||
Git has several different ways of showing the history of a repository. When Git shows the history of a single file, it simplifies history by omitting
|
||||
commits that did not change the file. Instead of looking at every commit to
|
||||
decide whether it touched the file, Git will omit a whole branch if that branch,
|
||||
when merged, did not impact the final contents of the file. Any commits on the
|
||||
branch that touched the file will not be shown.
|
||||
|
||||
For a file's commit history, {% data variables.product.product_name %} explicitly follows this simple strategy. It makes the history simpler by removing commits that didn't contribute to the final result. For example, if a side branch made a change and then reverted it, that commit would not show up in the branch history. This makes reviewing branches more efficient, since you only see the commits that affect the file.
|
||||
|
||||
This truncated view might not always contain the information you're
|
||||
after. If you want to see the entire history, {% data variables.product.product_name %} provides a view with more
|
||||
information on a repository's commits page.
|
||||
|
||||
For more information on how Git considers commit history, see [the "History Simplification"](https://git-scm.com/docs/git-log#_history_simplification) section of the `git log` help article.
|
||||
|
||||
## Further reading
|
||||
|
||||
- "[Signing commits](/articles/signing-commits)"
|
||||
- "[Searching commits](/search-github/searching-on-github/searching-commits)"
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Viewing and comparing commits
|
||||
intro: ''
|
||||
redirect_from:
|
||||
- /articles/viewing-and-comparing-commits
|
||||
- /github/committing-changes-to-your-project/viewing-and-comparing-commits
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
ghec: '*'
|
||||
children:
|
||||
- /commit-branch-and-tag-labels
|
||||
- /comparing-commits
|
||||
- /differences-between-commit-views
|
||||
shortTitle: View & compare commits
|
||||
---
|
||||
15
translations/es-ES/content/pull-requests/index.md
Normal file
15
translations/es-ES/content/pull-requests/index.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Pull requests
|
||||
intro: 'Learn how to commit changes to a project and use pull requests to collaborate with others.'
|
||||
shortTitle: Pull requests
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
ghae: '*'
|
||||
topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /committing-changes-to-your-project
|
||||
- /collaborating-with-pull-requests
|
||||
---
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
#Issue #5108
|
||||
#Documentation for the "Only notify requested team members" option in the code review settings
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>=3.4'
|
||||
ghae: '*'
|
||||
@@ -601,6 +601,10 @@
|
||||
term: repositorio
|
||||
description: >-
|
||||
Un repositorio es el elemento más básico de GitHub. Son más fáciles de imaginar como la carpeta de un proyecto. Un repositorio contiene todos los archivos del proyecto (incluida la documentación) y almacena el historial de revisión de cada archivo. Los repositorios pueden tener varios colaboradores y pueden ser públicos o privados.
|
||||
-
|
||||
term: repository cache
|
||||
description: >-
|
||||
A read-only mirror of repositories for your GitHub Enterprise server instance, located near distributed teams and CI clients.
|
||||
-
|
||||
term: gráfico del repositorio
|
||||
description: Una representación visual de los datos de tu repositorio.
|
||||
|
||||
@@ -1,284 +0,0 @@
|
||||
---
|
||||
-
|
||||
title: Registro del paquete de GitHub
|
||||
description: Esta vista previa agrega soporte para los objetos que se relacionen con GitHub Packages.
|
||||
toggled_by: ':packages-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Para GitHub
|
||||
- PackageFile
|
||||
- PackageFileOrder
|
||||
- PackageFileOrderField
|
||||
- PackageOrder
|
||||
- PackageOrderField
|
||||
- PackageOwner
|
||||
- PackageStatistics
|
||||
- PackageTag
|
||||
- PackageVersion
|
||||
- PackageVersionOrder
|
||||
- PackageVersionOrderField
|
||||
- PackageVersionStatistics
|
||||
- Organization.packages
|
||||
- PackageMetadatum.packageVersion
|
||||
- Repository.packages
|
||||
- User.packages
|
||||
- PackageConnection.nodes
|
||||
- PackageFileConnection.nodes
|
||||
- PackageTagConnection.nodes
|
||||
- PackageVersionConnection.nodes
|
||||
- PackageEdge.node
|
||||
- PackageFileEdge.node
|
||||
- PackageTagEdge.node
|
||||
- PackageVersionEdge.node
|
||||
- CreateRegistryPackageFilePayload.packageFile
|
||||
- CreateRegistryPackageVersionMetadataPayload.packageVersion
|
||||
- CreateRegistryPackageVersionPayload.packageVersion
|
||||
- DeleteRegistryPackagePayload.package
|
||||
- DeleteRegistryPackageTagPayload.package
|
||||
- SetRegistryPackageTagPayload.package
|
||||
- UpdateRegistryPackageFilePayload.packageFile
|
||||
- UpdateRegistryPackageVersionPayload.packageVersion
|
||||
- CreatePackageVersionPayload.packageVersion
|
||||
- UpdatePackageVersionPayload.packageVersion
|
||||
- CreatePackageFilePayload.packageFile
|
||||
- UpdatePackageFilePayload.packageFile
|
||||
- CreatePackageVersionMetadataPayload.packageVersion
|
||||
- AddPackageTagPayload.package
|
||||
- DeletePackageTagPayload.package
|
||||
owning_teams:
|
||||
- '@github/pe-package-registry'
|
||||
-
|
||||
title: Implementaciones
|
||||
description: >-
|
||||
Esta vista previa añade soporte para las mutaciones de despliegue y para nuevas características de despliegue.
|
||||
toggled_by: ':flash-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- DeploymentStatus.environment
|
||||
- Mutation.createDeploymentStatus
|
||||
- CreateDeploymentStatusInput
|
||||
- CreateDeploymentStatusPayload
|
||||
- Mutation.createDeployment
|
||||
- CreateDeploymentInput
|
||||
- CreateDeploymentPayload
|
||||
owning_teams:
|
||||
- '@github/ecosystem-api'
|
||||
-
|
||||
title: Vista Previa del Borrador de la Solicitud de Extracción
|
||||
description: Esta vista previa agrega soporte para borradores de solicitudes de extracción.
|
||||
toggled_by: ':shadow-cat-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.markPullRequestReadyForReview
|
||||
- CreatePullRequestInput.draft
|
||||
- PullRequest.isDraft
|
||||
- MarkPullRequestReadyForReviewInput
|
||||
- MarkPullRequestReadyForReviewPayload
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: Verificaciones
|
||||
description: Esta vista previa agrega soporte para leer las verificaciones que crea GitHub Apps.
|
||||
toggled_by: ':antiope-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- CheckAnnotationRange
|
||||
- CheckAnnotationPosition
|
||||
- CheckAnnotationSpan
|
||||
- CheckAnnotation
|
||||
- CheckAnnotationConnection.nodes
|
||||
- CheckAnnotationData
|
||||
- CheckAnnotationEdge.node
|
||||
- CheckAnnotationLevel
|
||||
- CheckConclusionState
|
||||
- CheckStatusState
|
||||
- CheckSuiteAutoTriggerPreference
|
||||
- CheckRun
|
||||
- CheckRunConnection.nodes
|
||||
- CheckRunEdge.node
|
||||
- CheckRunAction
|
||||
- CheckRunFilter
|
||||
- CheckRunOutput
|
||||
- CheckRunOutputImage
|
||||
- CheckRunType
|
||||
- CheckSuite
|
||||
- CheckSuiteConnection.nodes
|
||||
- CheckSuiteEdge.node
|
||||
- CheckSuiteFilter
|
||||
- CreateCheckRunInput
|
||||
- CreateCheckRunPayload
|
||||
- CreateCheckSuiteInput
|
||||
- CreateCheckSuitePayload
|
||||
- Commit.checkSuites
|
||||
- Mutation.createCheckRun
|
||||
- Mutation.createCheckSuite
|
||||
- Mutation.rerequestCheckSuite
|
||||
- Mutation.updateCheckRun
|
||||
- Mutation.updateCheckSuitePreferences
|
||||
- Subir
|
||||
- RequestableCheckStatusState
|
||||
- RerequestCheckSuiteInput
|
||||
- RerequestCheckSuitePayload
|
||||
- UpdateCheckRunInput
|
||||
- UpdateCheckRunPayload
|
||||
- UpdateCheckSuitePayload.checkSuite
|
||||
- UpdateCheckSuitePreferencesInput
|
||||
- UpdateCheckSuitePreferencesPayload
|
||||
owning_teams:
|
||||
- '@github/ecosystem-primitives'
|
||||
-
|
||||
title: >-
|
||||
MergeInfoPreview - Información más detallada sobre un estado de fusión de una solicitud de extracción.
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para acceder a campos que proporcionan información más detallada sobre el estado de la fusión de una solicitud de extracción.
|
||||
toggled_by: ':merge-info-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- PullRequest.canBeRebased
|
||||
- PullRequest.mergeStateStatus
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: UpdateRefsPreview - Actualiza varias refs en una sola operación.
|
||||
description: Esta vista previa agrega soporte para actualizar varias refs en una sola operación.
|
||||
toggled_by: ':update-refs-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.updateRefs
|
||||
- GitRefname
|
||||
- RefUpdate
|
||||
- UpdateRefsInput
|
||||
- UpdateRefsPayload
|
||||
owning_teams:
|
||||
- '@github/pe-repos'
|
||||
-
|
||||
title: Detalles de Eventos del Proyecto
|
||||
description: >-
|
||||
Esta vista previa añade detalles sobre el proyecto, tarjeta de proyecto y columna de proyecto a un evento de incidencia relacionado con un proyecto.
|
||||
toggled_by: ':starfox-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- AddedToProjectEvent.project
|
||||
- AddedToProjectEvent.projectCard
|
||||
- AddedToProjectEvent.projectColumnName
|
||||
- ConvertedNoteToIssueEvent.project
|
||||
- ConvertedNoteToIssueEvent.projectCard
|
||||
- ConvertedNoteToIssueEvent.projectColumnName
|
||||
- MovedColumnsInProjectEvent.project
|
||||
- MovedColumnsInProjectEvent.projectCard
|
||||
- MovedColumnsInProjectEvent.projectColumnName
|
||||
- MovedColumnsInProjectEvent.previousProjectColumnName
|
||||
- RemovedFromProjectEvent.project
|
||||
- RemovedFromProjectEvent.projectColumnName
|
||||
owning_teams:
|
||||
- '@github/github-projects'
|
||||
-
|
||||
title: Vista Previa de Comentarios Minimizados
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para comentarios minimizados en incidentes, solicitudes de extracción, confirmaciones y gists.
|
||||
toggled_by: ':queen-beryl-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.minimizeComment
|
||||
- Mutation.unminimizeComment
|
||||
- Minimizable
|
||||
owning_teams:
|
||||
- '@github/ce-community-and-safety'
|
||||
-
|
||||
title: Crear adjuntos de contenido
|
||||
description: Esta vista previa agrega soporte para crear adjuntos de contenido.
|
||||
toggled_by: ':corsair-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.createContentAttachment
|
||||
owning_teams:
|
||||
- '@github/ecosystem-primitives'
|
||||
-
|
||||
title: Vista Previa de Incidentes Fijados
|
||||
description: Esta vista previa agrega soporte para los incidentes fijados.
|
||||
toggled_by: ':elektra-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Repository.pinnedIssues
|
||||
- PinnedIssue
|
||||
- PinnedIssueEdge
|
||||
- PinnedIssueConnection
|
||||
- Mutation.pinIssue
|
||||
- Mutation.unpinIssue
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: Vista Previa de Etiquetas
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para crear, actualizar, agregar y borrar etiquetas.
|
||||
toggled_by: ':bane-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.createLabel
|
||||
- CreateLabelPayload
|
||||
- CreateLabelInput
|
||||
- Mutation.deleteLabel
|
||||
- DeleteLabelPayload
|
||||
- DeleteLabelInput
|
||||
- Mutation.updateLabel
|
||||
- UpdateLabelPayload
|
||||
- UpdateLabelInput
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: Importar Proyecto
|
||||
description: Esta vista previa agrega soporte para importar proyectos.
|
||||
toggled_by: ':slothette-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.importProject
|
||||
owning_teams:
|
||||
- '@github/pe-issues-projects'
|
||||
-
|
||||
title: Vista Previa de Comentarios de Línea Múltiple
|
||||
description: Esta vista previa agrega soporte para comentarios de línea múltiple y posicionados en un blob.
|
||||
toggled_by: ':comfort-fade-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.addPullRequestReviewThread
|
||||
- AddPullRequestReviewThreadInput
|
||||
- AddPullRequestReviewInput.threads
|
||||
- DiffSide
|
||||
- PullRequestReviewThread.startLine
|
||||
- PullRequestReviewThread.originalStartLine
|
||||
- PullRequestReviewThread.startDiffSide
|
||||
- PullRequestReviewThread.line
|
||||
- PullRequestReviewThread.originalLine
|
||||
- PullRequestReviewThread.diffSide
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: Vista Previa de las Tareas de Revisión del Equipo
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para actualizar la configuración para las tareas de revisión del equipo.
|
||||
toggled_by: ':stone-crop-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.updateTeamReviewAssignment
|
||||
- UpdateTeamReviewAssignmentInput
|
||||
- TeamReviewAssignmentAlgorithm
|
||||
- Team.reviewRequestDelegationEnabled
|
||||
- Team.reviewRequestDelegationAlgorithm
|
||||
- Team.reviewRequestDelegationMemberCount
|
||||
- Team.reviewRequestDelegationNotifyTeam
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
@@ -1,562 +0,0 @@
|
||||
---
|
||||
upcoming_changes:
|
||||
-
|
||||
location: Migration.uploadUrlTemplate
|
||||
description: 'Se eliminará a `uploadUrlTemplate`. Utiliza `uploadUrl` en sustitución.'
|
||||
reason: 'Se está eliminando a `uploadUrlTemplate` porque no es una URL estándar y agrega un paso extra al usuario.'
|
||||
date: '2019-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: ContributionOrder.field
|
||||
description: 'Se eliminará a `field`. Sólo hay compatibilidad par aun solo campo de orden.'
|
||||
reason: 'Se eliminará a `field`.'
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Issue.timeline
|
||||
description: 'Se eliminará a `timeline`. Utiliza Issue.timelineItems en sustitución.'
|
||||
reason: 'Se eliminará a `timeline`'
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: mikesea
|
||||
-
|
||||
location: Organization.pinnedRepositories
|
||||
description: 'Se eliminará a `pinnedRepositories`. Utiliza ProfileOwner.pinnedItems en sustitución.'
|
||||
reason: se eliminará a pinnedRepositories
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: cheshire137
|
||||
-
|
||||
location: PullRequest.timeline
|
||||
description: 'Se eliminará a `timeline`. Utiliza PullRequest.timelineItems en sustitución.'
|
||||
reason: 'Se eliminará a `timeline`'
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: mikesea
|
||||
-
|
||||
location: RepositoryOwner.pinnedRepositories
|
||||
description: 'Se eliminará a `pinnedRepositories`. Utiliza ProfileOwner.pinnedItems en sustitución.'
|
||||
reason: se eliminará a pinnedRepositories
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: cheshire137
|
||||
-
|
||||
location: User.pinnedRepositories
|
||||
description: 'Se eliminará a `pinnedRepositories`. Utiliza ProfileOwner.pinnedItems en sustitución.'
|
||||
reason: se eliminará a pinnedRepositories
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: cheshire137
|
||||
-
|
||||
location: AssignedEvent.user
|
||||
description: 'Se eliminará a `user`. Utiliza el campo `assignee` en sustitución.'
|
||||
reason: Los asignados ahora pueden ser maniquíes.
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: EnterpriseBillingInfo.availableSeats
|
||||
description: 'Se eliminará a `availableSeats`. Utiliza EnterpriseBillingInfo.totalAvailableLicenses en sustitución.'
|
||||
reason: 'Se reemplazará a `availableSeats` con `totalAvailableLicenses` para proporcionar más claridad en el valor que se devuelva'
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: BlakeWilliams
|
||||
-
|
||||
location: EnterpriseBillingInfo.seats
|
||||
description: 'Se eliminará a `seats`. Utiliza EnterpriseBillingInfo.totalLicenses en sustitución.'
|
||||
reason: 'Se reemplazará a `seats` con `totalLicenses` para proporcionar más claridad en el valor que se devuelva'
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: BlakeWilliams
|
||||
-
|
||||
location: UnassignedEvent.user
|
||||
description: 'Se eliminará a `user`. Utiliza el campo `assignee` en sustitución.'
|
||||
reason: Los asignados ahora pueden ser maniquíes.
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: Organization.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Organization.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.color
|
||||
description: 'Se eliminará a `color`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.latestVersion
|
||||
description: 'Se eliminará a `latestVersion`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.nameWithOwner
|
||||
description: 'Se eliminará a `nameWithOwner`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.packageFileByGuid
|
||||
description: 'Se eliminará a `packageFileByGuid`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.packageFileBySha256
|
||||
description: 'Se eliminará a `packageFileBySha256`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.packageType
|
||||
description: 'Se eliminará a `packageType`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.preReleaseVersions
|
||||
description: 'Se eliminará a `preReleaseVersions`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.registryPackageType
|
||||
description: 'Se eliminará a `registryPackageType`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.repository
|
||||
description: 'Se eliminará a `repository`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.statistics
|
||||
description: 'Se eliminará a `statistics`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.tags
|
||||
description: 'Se eliminará a `tags`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.topics
|
||||
description: 'Se eliminará a `topics`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versionByPlatform
|
||||
description: 'Se eliminará a `versionByPlatform`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versionBySha256
|
||||
description: 'Se eliminará a `versionBySha256`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versions
|
||||
description: 'Se eliminará a `versions`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versionsByMetadatum
|
||||
description: 'Se eliminará a `versionsByMetadatum`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageDependency.dependencyType
|
||||
description: 'Se eliminará a `dependencyType`. Utiliza el objeto `PackageDependency` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageDependency.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `PackageDependency` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageDependency.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `PackageDependency` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.guid
|
||||
description: 'Se eliminará a `guid`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.md5
|
||||
description: 'Se eliminará a `md5`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.metadataUrl
|
||||
description: 'Se eliminará a `metadataUrl`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.packageVersion
|
||||
description: 'Se eliminará a `packageVersion`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.sha1
|
||||
description: 'Se eliminará a `sha1`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.sha256
|
||||
description: 'Se eliminará a `sha256`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.size
|
||||
description: 'Se eliminará a `size`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.url
|
||||
description: 'Se eliminará a `url`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageOwner.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageSearch.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsThisMonth
|
||||
description: 'Se eliminará a `downloadsThisMonth`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsThisWeek
|
||||
description: 'Se eliminará a `downloadsThisWeek`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsThisYear
|
||||
description: 'Se eliminará a `downloadsThisYear`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsToday
|
||||
description: 'Se eliminará a `downloadsToday`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsTotalCount
|
||||
description: 'Se eliminará a `downloadsTotalCount`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageTag.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `PackageTag` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageTag.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `PackageTag` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.dependencies
|
||||
description: 'Se eliminará a `dependencies`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.fileByName
|
||||
description: 'Se eliminará a `fileByName`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.files
|
||||
description: 'Se eliminará a `files`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.installationCommand
|
||||
description: 'Se eliminará a `installationCommand`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.manifest
|
||||
description: 'Se eliminará a `manifest`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.platform
|
||||
description: 'Se eliminará a `platform`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.preRelease
|
||||
description: 'Se eliminará a `preRelease`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.readme
|
||||
description: 'Se eliminará a `readme`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.readmeHtml
|
||||
description: 'Se eliminará a `readmeHtml`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.registryPackage
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.release
|
||||
description: 'Se eliminará a `release`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.sha256
|
||||
description: 'Se eliminará a `sha256`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.size
|
||||
description: 'Se eliminará a `size`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.statistics
|
||||
description: 'Se eliminará a `statistics`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.summary
|
||||
description: 'Se eliminará a `summary`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.updatedAt
|
||||
description: 'Se eliminará a `updatedAt`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.viewerCanEdit
|
||||
description: 'Se eliminará a `viewerCanEdit`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsThisMonth
|
||||
description: 'Se eliminará a `downloadsThisMonth`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsThisWeek
|
||||
description: 'Se eliminará a `downloadsThisWeek`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsThisYear
|
||||
description: 'Se eliminará a `downloadsThisYear`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsToday
|
||||
description: 'Se eliminará a `downloadsToday`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsTotalCount
|
||||
description: 'Se eliminará a `downloadsTotalCount`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Repository.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Repository.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Sponsorship.maintainer
|
||||
description: 'Se eliminará a `maintainer`. Utiliza `Sponsorship.sponsorable` en sustitución.'
|
||||
reason: 'Se eliminará a `Sponsorship.maintainer`.'
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: antn
|
||||
-
|
||||
location: User.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: User.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
@@ -1,242 +0,0 @@
|
||||
---
|
||||
-
|
||||
title: Acceso al borrado de versiones de paquetes
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para la mutación DeletePackageVersion, la cual habilita el borrado de versiones de paquetes privados.
|
||||
toggled_by: ':package-deletes-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.deletePackageVersion
|
||||
- RegistryPackageVersion.deleted
|
||||
owning_teams:
|
||||
- '@github/pe-package-registry'
|
||||
-
|
||||
title: Registro del paquete de GitHub
|
||||
description: Esta vista previa agrega soporte para los objetos que se relacionen con GitHub Packages.
|
||||
toggled_by: ':packages-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Para GitHub
|
||||
- PackageFile
|
||||
- PackageFileOrder
|
||||
- PackageFileOrderField
|
||||
- PackageOrder
|
||||
- PackageOrderField
|
||||
- PackageOwner
|
||||
- PackageStatistics
|
||||
- PackageTag
|
||||
- PackageVersion
|
||||
- PackageVersionOrder
|
||||
- PackageVersionOrderField
|
||||
- PackageVersionStatistics
|
||||
- Organization.packages
|
||||
- PackageMetadatum.packageVersion
|
||||
- Repository.packages
|
||||
- User.packages
|
||||
- PackageConnection.nodes
|
||||
- PackageFileConnection.nodes
|
||||
- PackageTagConnection.nodes
|
||||
- PackageVersionConnection.nodes
|
||||
- PackageEdge.node
|
||||
- PackageFileEdge.node
|
||||
- PackageTagEdge.node
|
||||
- PackageVersionEdge.node
|
||||
- CreatePackageVersionPayload.packageVersion
|
||||
- UpdatePackageVersionPayload.packageVersion
|
||||
- CreatePackageFilePayload.packageFile
|
||||
- UpdatePackageFilePayload.packageFile
|
||||
- CreatePackageVersionMetadataPayload.packageVersion
|
||||
- AddPackageTagPayload.package
|
||||
- DeletePackageTagPayload.package
|
||||
owning_teams:
|
||||
- '@github/pe-package-registry'
|
||||
-
|
||||
title: Implementaciones
|
||||
description: >-
|
||||
Esta vista previa añade soporte para las mutaciones de despliegue y para nuevas características de despliegue.
|
||||
toggled_by: ':flash-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- DeploymentStatus.environment
|
||||
- Mutation.createDeploymentStatus
|
||||
- CreateDeploymentStatusInput
|
||||
- CreateDeploymentStatusPayload
|
||||
- Mutation.createDeployment
|
||||
- CreateDeploymentInput
|
||||
- CreateDeploymentPayload
|
||||
owning_teams:
|
||||
- '@github/ecosystem-api'
|
||||
-
|
||||
title: Verificaciones
|
||||
description: Esta vista previa agrega soporte para leer las verificaciones que crea GitHub Apps.
|
||||
toggled_by: ':antiope-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- CheckAnnotationRange
|
||||
- CheckAnnotationPosition
|
||||
- CheckAnnotationSpan
|
||||
- CheckAnnotation
|
||||
- CheckAnnotationConnection.nodes
|
||||
- CheckAnnotationData
|
||||
- CheckAnnotationEdge.node
|
||||
- CheckAnnotationLevel
|
||||
- CheckConclusionState
|
||||
- CheckStatusState
|
||||
- CheckSuiteAutoTriggerPreference
|
||||
- CheckRun
|
||||
- CheckRunConnection.nodes
|
||||
- CheckRunEdge.node
|
||||
- CheckRunAction
|
||||
- CheckRunFilter
|
||||
- CheckRunOutput
|
||||
- CheckRunOutputImage
|
||||
- CheckRunType
|
||||
- CheckSuite
|
||||
- CheckSuiteConnection.nodes
|
||||
- CheckSuiteEdge.node
|
||||
- CheckSuiteFilter
|
||||
- CreateCheckRunInput
|
||||
- CreateCheckRunPayload
|
||||
- CreateCheckSuiteInput
|
||||
- CreateCheckSuitePayload
|
||||
- Commit.checkSuites
|
||||
- Mutation.createCheckRun
|
||||
- Mutation.createCheckSuite
|
||||
- Mutation.rerequestCheckSuite
|
||||
- Mutation.updateCheckRun
|
||||
- Mutation.updateCheckSuitePreferences
|
||||
- Subir
|
||||
- RequestableCheckStatusState
|
||||
- RerequestCheckSuiteInput
|
||||
- RerequestCheckSuitePayload
|
||||
- UpdateCheckRunInput
|
||||
- UpdateCheckRunPayload
|
||||
- UpdateCheckSuitePayload.checkSuite
|
||||
- UpdateCheckSuitePreferencesInput
|
||||
- UpdateCheckSuitePreferencesPayload
|
||||
owning_teams:
|
||||
- '@github/ce-extensibility'
|
||||
-
|
||||
title: >-
|
||||
MergeInfoPreview - Información más detallada sobre un estado de fusión de una solicitud de extracción.
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para acceder a campos que proporcionan información más detallada sobre el estado de la fusión de una solicitud de extracción.
|
||||
toggled_by: ':merge-info-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- PullRequest.canBeRebased
|
||||
- PullRequest.mergeStateStatus
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: UpdateRefsPreview - Actualiza varias refs en una sola operación.
|
||||
description: Esta vista previa agrega soporte para actualizar varias refs en una sola operación.
|
||||
toggled_by: ':update-refs-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.updateRefs
|
||||
- GitRefname
|
||||
- RefUpdate
|
||||
- UpdateRefsInput
|
||||
- UpdateRefsPayload
|
||||
owning_teams:
|
||||
- '@github/pe-repos'
|
||||
-
|
||||
title: Detalles de Eventos del Proyecto
|
||||
description: >-
|
||||
Esta vista previa añade detalles sobre el proyecto, tarjeta de proyecto y columna de proyecto a un evento de incidencia relacionado con un proyecto.
|
||||
toggled_by: ':starfox-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- AddedToProjectEvent.project
|
||||
- AddedToProjectEvent.projectCard
|
||||
- AddedToProjectEvent.projectColumnName
|
||||
- ConvertedNoteToIssueEvent.project
|
||||
- ConvertedNoteToIssueEvent.projectCard
|
||||
- ConvertedNoteToIssueEvent.projectColumnName
|
||||
- MovedColumnsInProjectEvent.project
|
||||
- MovedColumnsInProjectEvent.projectCard
|
||||
- MovedColumnsInProjectEvent.projectColumnName
|
||||
- MovedColumnsInProjectEvent.previousProjectColumnName
|
||||
- RemovedFromProjectEvent.project
|
||||
- RemovedFromProjectEvent.projectColumnName
|
||||
owning_teams:
|
||||
- '@github/github-projects'
|
||||
-
|
||||
title: Crear adjuntos de contenido
|
||||
description: Esta vista previa agrega soporte para crear adjuntos de contenido.
|
||||
toggled_by: ':corsair-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.createContentAttachment
|
||||
owning_teams:
|
||||
- '@github/ce-extensibility'
|
||||
-
|
||||
title: Vista Previa de Incidentes Fijados
|
||||
description: Esta vista previa agrega soporte para los incidentes fijados.
|
||||
toggled_by: ':elektra-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Repository.pinnedIssues
|
||||
- PinnedIssue
|
||||
- PinnedIssueEdge
|
||||
- PinnedIssueConnection
|
||||
- Mutation.pinIssue
|
||||
- Mutation.unpinIssue
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: Vista Previa de Etiquetas
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para crear, actualizar, agregar y borrar etiquetas.
|
||||
toggled_by: ':bane-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.createLabel
|
||||
- CreateLabelPayload
|
||||
- CreateLabelInput
|
||||
- Mutation.deleteLabel
|
||||
- DeleteLabelPayload
|
||||
- DeleteLabelInput
|
||||
- Mutation.updateLabel
|
||||
- UpdateLabelPayload
|
||||
- UpdateLabelInput
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
-
|
||||
title: Importar Proyecto
|
||||
description: Esta vista previa agrega soporte para importar proyectos.
|
||||
toggled_by: ':slothette-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.importProject
|
||||
owning_teams:
|
||||
- '@github/pe-issues-projects'
|
||||
-
|
||||
title: Vista Previa de las Tareas de Revisión del Equipo
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para actualizar la configuración para las tareas de revisión del equipo.
|
||||
toggled_by: ':stone-crop-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Mutation.updateTeamReviewAssignment
|
||||
- UpdateTeamReviewAssignmentInput
|
||||
- TeamReviewAssignmentAlgorithm
|
||||
- Team.reviewRequestDelegationEnabled
|
||||
- Team.reviewRequestDelegationAlgorithm
|
||||
- Team.reviewRequestDelegationMemberCount
|
||||
- Team.reviewRequestDelegationNotifyTeam
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
@@ -1,569 +0,0 @@
|
||||
---
|
||||
upcoming_changes:
|
||||
-
|
||||
location: Migration.uploadUrlTemplate
|
||||
description: 'Se eliminará a `uploadUrlTemplate`. Utiliza `uploadUrl` en sustitución.'
|
||||
reason: 'Se está eliminando a `uploadUrlTemplate` porque no es una URL estándar y agrega un paso extra al usuario.'
|
||||
date: '2019-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: ContributionOrder.field
|
||||
description: 'Se eliminará a `field`. Sólo hay compatibilidad par aun solo campo de orden.'
|
||||
reason: 'Se eliminará a `field`.'
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Organization.pinnedRepositories
|
||||
description: 'Se eliminará a `pinnedRepositories`. Utiliza ProfileOwner.pinnedItems en sustitución.'
|
||||
reason: se eliminará a pinnedRepositories
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: cheshire137
|
||||
-
|
||||
location: RepositoryOwner.pinnedRepositories
|
||||
description: 'Se eliminará a `pinnedRepositories`. Utiliza ProfileOwner.pinnedItems en sustitución.'
|
||||
reason: se eliminará a pinnedRepositories
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: cheshire137
|
||||
-
|
||||
location: User.pinnedRepositories
|
||||
description: 'Se eliminará a `pinnedRepositories`. Utiliza ProfileOwner.pinnedItems en sustitución.'
|
||||
reason: se eliminará a pinnedRepositories
|
||||
date: '2019-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: cheshire137
|
||||
-
|
||||
location: AssignedEvent.user
|
||||
description: 'Se eliminará a `user`. Utiliza el campo `assignee` en sustitución.'
|
||||
reason: Los asignados ahora pueden ser maniquíes.
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: EnterpriseBillingInfo.availableSeats
|
||||
description: 'Se eliminará a `availableSeats`. Utiliza EnterpriseBillingInfo.totalAvailableLicenses en sustitución.'
|
||||
reason: 'Se reemplazará a `availableSeats` con `totalAvailableLicenses` para proporcionar más claridad en el valor que se devuelva'
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: BlakeWilliams
|
||||
-
|
||||
location: EnterpriseBillingInfo.seats
|
||||
description: 'Se eliminará a `seats`. Utiliza EnterpriseBillingInfo.totalLicenses en sustitución.'
|
||||
reason: 'Se reemplazará a `seats` con `totalLicenses` para proporcionar más claridad en el valor que se devuelva'
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: BlakeWilliams
|
||||
-
|
||||
location: UnassignedEvent.user
|
||||
description: 'Se eliminará a `user`. Utiliza el campo `assignee` en sustitución.'
|
||||
reason: Los asignados ahora pueden ser maniquíes.
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: Organization.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Organization.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.color
|
||||
description: 'Se eliminará a `color`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.latestVersion
|
||||
description: 'Se eliminará a `latestVersion`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.nameWithOwner
|
||||
description: 'Se eliminará a `nameWithOwner`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.packageFileByGuid
|
||||
description: 'Se eliminará a `packageFileByGuid`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.packageFileBySha256
|
||||
description: 'Se eliminará a `packageFileBySha256`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.packageType
|
||||
description: 'Se eliminará a `packageType`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.preReleaseVersions
|
||||
description: 'Se eliminará a `preReleaseVersions`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.registryPackageType
|
||||
description: 'Se eliminará a `registryPackageType`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.repository
|
||||
description: 'Se eliminará a `repository`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.statistics
|
||||
description: 'Se eliminará a `statistics`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.tags
|
||||
description: 'Se eliminará a `tags`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.topics
|
||||
description: 'Se eliminará a `topics`. Utiliza el objeto `Package`.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versionByPlatform
|
||||
description: 'Se eliminará a `versionByPlatform`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versionBySha256
|
||||
description: 'Se eliminará a `versionBySha256`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versions
|
||||
description: 'Se eliminará a `versions`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackage.versionsByMetadatum
|
||||
description: 'Se eliminará a `versionsByMetadatum`. Utiliza el objeto `Package` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageDependency.dependencyType
|
||||
description: 'Se eliminará a `dependencyType`. Utiliza el objeto `PackageDependency` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageDependency.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `PackageDependency` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageDependency.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `PackageDependency` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.guid
|
||||
description: 'Se eliminará a `guid`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.md5
|
||||
description: 'Se eliminará a `md5`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.metadataUrl
|
||||
description: 'Se eliminará a `metadataUrl`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.packageVersion
|
||||
description: 'Se eliminará a `packageVersion`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.sha1
|
||||
description: 'Se eliminará a `sha1`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.sha256
|
||||
description: 'Se eliminará a `sha256`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.size
|
||||
description: 'Se eliminará a `size`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageFile.url
|
||||
description: 'Se eliminará a `url`. Utiliza el objeto `PackageFile` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageOwner.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageSearch.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsThisMonth
|
||||
description: 'Se eliminará a `downloadsThisMonth`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsThisWeek
|
||||
description: 'Se eliminará a `downloadsThisWeek`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsThisYear
|
||||
description: 'Se eliminará a `downloadsThisYear`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsToday
|
||||
description: 'Se eliminará a `downloadsToday`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageStatistics.downloadsTotalCount
|
||||
description: 'Se eliminará a `downloadsTotalCount`. Utiliza el objeto `PackageStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageTag.name
|
||||
description: 'Se eliminará a `name`. Utiliza el objeto `PackageTag` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageTag.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `PackageTag` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.deleted
|
||||
description: 'Se eliminará a `deleted`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.dependencies
|
||||
description: 'Se eliminará a `dependencies`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.fileByName
|
||||
description: 'Se eliminará a `fileByName`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.files
|
||||
description: 'Se eliminará a `files`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.installationCommand
|
||||
description: 'Se eliminará a `installationCommand`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.manifest
|
||||
description: 'Se eliminará a `manifest`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.platform
|
||||
description: 'Se eliminará a `platform`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.preRelease
|
||||
description: 'Se eliminará a `preRelease`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.readme
|
||||
description: 'Se eliminará a `readme`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.readmeHtml
|
||||
description: 'Se eliminará a `readmeHtml`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.registryPackage
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.release
|
||||
description: 'Se eliminará a `release`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.sha256
|
||||
description: 'Se eliminará a `sha256`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.size
|
||||
description: 'Se eliminará a `size`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.statistics
|
||||
description: 'Se eliminará a `statistics`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.summary
|
||||
description: 'Se eliminará a `summary`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.updatedAt
|
||||
description: 'Se eliminará a `updatedAt`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.version
|
||||
description: 'Se eliminará a `version`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersion.viewerCanEdit
|
||||
description: 'Se eliminará a `viewerCanEdit`. Utiliza el objeto `PackageVersion` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsThisMonth
|
||||
description: 'Se eliminará a `downloadsThisMonth`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsThisWeek
|
||||
description: 'Se eliminará a `downloadsThisWeek`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsThisYear
|
||||
description: 'Se eliminará a `downloadsThisYear`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsToday
|
||||
description: 'Se eliminará a `downloadsToday`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: RegistryPackageVersionStatistics.downloadsTotalCount
|
||||
description: 'Se eliminará a `downloadsTotalCount`. Utiliza el objeto `PackageVersionStatistics` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Repository.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Repository.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Sponsorship.maintainer
|
||||
description: 'Se eliminará a `maintainer`. Utiliza `Sponsorship.sponsorable` en sustitución.'
|
||||
reason: 'Se eliminará a `Sponsorship.maintainer`.'
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: antn
|
||||
-
|
||||
location: User.registryPackages
|
||||
description: 'Se eliminará a `registryPackages`. Utiliza el objeto `PackageOwner` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: User.registryPackagesForQuery
|
||||
description: 'Se eliminará a `registryPackagesForQuery`. Utiliza el objeto `PackageSearch` en sustitución.'
|
||||
reason: Renombrar los campos y objetos de GitHub Packages.
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: dinahshi
|
||||
-
|
||||
location: Issue.timeline
|
||||
description: 'Se eliminará a `timeline`. Utiliza Issue.timelineItems en sustitución.'
|
||||
reason: 'Se eliminará a `timeline`'
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: mikesea
|
||||
-
|
||||
location: PullRequest.timeline
|
||||
description: 'Se eliminará a `timeline`. Utiliza PullRequest.timelineItems en sustitución.'
|
||||
reason: 'Se eliminará a `timeline`'
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: mikesea
|
||||
@@ -26,61 +26,10 @@
|
||||
- CreateDeploymentInput
|
||||
- CreateDeploymentPayload
|
||||
owning_teams:
|
||||
- '@github/ecosystem-api'
|
||||
-
|
||||
title: Verificaciones
|
||||
description: Esta vista previa agrega soporte para leer las verificaciones que crea GitHub Apps.
|
||||
toggled_by: ':antiope-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- CheckAnnotationRange
|
||||
- CheckAnnotationPosition
|
||||
- CheckAnnotationSpan
|
||||
- CheckAnnotation
|
||||
- CheckAnnotationConnection.nodes
|
||||
- CheckAnnotationData
|
||||
- CheckAnnotationEdge.node
|
||||
- CheckAnnotationLevel
|
||||
- CheckConclusionState
|
||||
- CheckStatusState
|
||||
- CheckSuiteAutoTriggerPreference
|
||||
- CheckRun
|
||||
- CheckRunConnection.nodes
|
||||
- CheckRunEdge.node
|
||||
- CheckRunAction
|
||||
- CheckRunFilter
|
||||
- CheckRunOutput
|
||||
- CheckRunOutputImage
|
||||
- CheckRunType
|
||||
- CheckSuite
|
||||
- CheckSuiteConnection.nodes
|
||||
- CheckSuiteEdge.node
|
||||
- CheckSuiteFilter
|
||||
- CreateCheckRunInput
|
||||
- CreateCheckRunPayload
|
||||
- CreateCheckSuiteInput
|
||||
- CreateCheckSuitePayload
|
||||
- Commit.checkSuites
|
||||
- Mutation.createCheckRun
|
||||
- Mutation.createCheckSuite
|
||||
- Mutation.rerequestCheckSuite
|
||||
- Mutation.updateCheckRun
|
||||
- Mutation.updateCheckSuitePreferences
|
||||
- Subir
|
||||
- RequestableCheckStatusState
|
||||
- RerequestCheckSuiteInput
|
||||
- RerequestCheckSuitePayload
|
||||
- UpdateCheckRunInput
|
||||
- UpdateCheckRunPayload
|
||||
- UpdateCheckSuitePayload.checkSuite
|
||||
- UpdateCheckSuitePreferencesInput
|
||||
- UpdateCheckSuitePreferencesPayload
|
||||
owning_teams:
|
||||
- '@github/ce-extensibility'
|
||||
- '@github/c2c-actions-service'
|
||||
-
|
||||
title: >-
|
||||
MergeInfoPreview - Información más detallada sobre un estado de fusión de una solicitud de extracción.
|
||||
>- MergeInfoPreview - Información más detallada sobre un estado de fusión de una solicitud de extracción.
|
||||
description: >-
|
||||
Esta vista previa agrega soporte para acceder a campos que proporcionan información más detallada sobre el estado de la fusión de una solicitud de extracción.
|
||||
toggled_by: ':merge-info-preview'
|
||||
@@ -104,7 +53,7 @@
|
||||
- UpdateRefsInput
|
||||
- UpdateRefsPayload
|
||||
owning_teams:
|
||||
- '@github/pe-repos'
|
||||
- '@github/reponauts'
|
||||
-
|
||||
title: Detalles de Eventos del Proyecto
|
||||
description: >-
|
||||
@@ -136,22 +85,7 @@
|
||||
toggled_on:
|
||||
- Mutation.createContentAttachment
|
||||
owning_teams:
|
||||
- '@github/ce-extensibility'
|
||||
-
|
||||
title: Vista Previa de Incidentes Fijados
|
||||
description: Esta vista previa agrega soporte para los incidentes fijados.
|
||||
toggled_by: ':elektra-preview'
|
||||
announcement: null
|
||||
updates: null
|
||||
toggled_on:
|
||||
- Repository.pinnedIssues
|
||||
- PinnedIssue
|
||||
- PinnedIssueEdge
|
||||
- PinnedIssueConnection
|
||||
- Mutation.pinIssue
|
||||
- Mutation.unpinIssue
|
||||
owning_teams:
|
||||
- '@github/pe-pull-requests'
|
||||
- '@github/feature-lifecycle'
|
||||
-
|
||||
title: Vista Previa de Etiquetas
|
||||
description: >-
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
upcoming_changes:
|
||||
-
|
||||
location: Migration.uploadUrlTemplate
|
||||
location: LegacyMigration.uploadUrlTemplate
|
||||
description: 'Se eliminará a `uploadUrlTemplate`. Utiliza `uploadUrl` en sustitución.'
|
||||
reason: 'Se está eliminando a `uploadUrlTemplate` porque no es una URL estándar y agrega un paso extra al usuario.'
|
||||
date: '2019-04-01T00:00:00+00:00'
|
||||
@@ -35,13 +35,6 @@ upcoming_changes:
|
||||
date: '2020-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: tambling
|
||||
-
|
||||
location: Sponsorship.maintainer
|
||||
description: 'Se eliminará a `maintainer`. Utiliza `Sponsorship.sponsorable` en sustitución.'
|
||||
reason: 'Se eliminará a `Sponsorship.maintainer`.'
|
||||
date: '2020-04-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: antn
|
||||
-
|
||||
location: EnterprisePendingMemberInvitationEdge.isUnlicensed
|
||||
description: 'Se eliminará a `isUnlicensed`.'
|
||||
@@ -70,20 +63,6 @@ upcoming_changes:
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: mikesea
|
||||
-
|
||||
location: RepositoryCollaboratorEdge.permission
|
||||
description: El tipo para `permission` cambiará de `RepositoryPermission!` a `String`.
|
||||
reason: Este campo podría devolver valores adicionales
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: oneill38
|
||||
-
|
||||
location: RepositoryInvitation.permission
|
||||
description: El tipo para `permission` cambiará de `RepositoryPermission!` a `String`.
|
||||
reason: Este campo podría devolver valores adicionales
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: oneill38
|
||||
-
|
||||
location: RepositoryInvitationOrderField.INVITEE_LOGIN
|
||||
description: 'Se eliminará a `INVITEE_LOGIN`.'
|
||||
@@ -91,20 +70,6 @@ upcoming_changes:
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: jdennes
|
||||
-
|
||||
location: Sponsorship.sponsor
|
||||
description: 'Se eliminará a `sponsor`. En vez de esto, utiliza `Sponsorship.sponsorEntity`.'
|
||||
reason: 'Se eliminará a `Sponsorship.sponsor`.'
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: nholden
|
||||
-
|
||||
location: TeamRepositoryEdge.permission
|
||||
description: El tipo para `permission` cambiará de `RepositoryPermission!` a `String`.
|
||||
reason: Este campo podría devolver valores adicionales
|
||||
date: '2020-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: oneill38
|
||||
-
|
||||
location: EnterpriseMemberEdge.isUnlicensed
|
||||
description: 'Se eliminará a `isUnlicensed`.'
|
||||
@@ -126,3 +91,24 @@ upcoming_changes:
|
||||
date: '2021-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: BrentWheeldon
|
||||
-
|
||||
location: MergeStateStatus.DRAFT
|
||||
description: 'El `DRAFT` se eliminará. Utiliza PullRequest.isDraft en su lugar.'
|
||||
reason: El estado del DRAFT se eliminará de esta enumeración y se deberá utilizar `isDraft` en su lugar
|
||||
date: '2021-01-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: nplasterer
|
||||
-
|
||||
location: PackageType.DOCKER
|
||||
description: 'Se eliminará a `DOCKER`.'
|
||||
reason: Se eliminará a DOCKER de esta enumeración, ya que este tipo se migrará para que solo lo utilice la API de REST de paquetes.
|
||||
date: '21-06-2021'
|
||||
criticality: breaking
|
||||
owner: reybard
|
||||
-
|
||||
location: ReactionGroup.users
|
||||
description: 'Se eliminará a `users`. Utiliza el campo de `reactors` en su lugar.'
|
||||
reason: Los reactores ahora pueden ser maniquíes, bots y organizaciones.
|
||||
date: '2021-10-01T00:00:00+00:00'
|
||||
criticality: breaking
|
||||
owner: synthead
|
||||
@@ -42,7 +42,7 @@ dependency_version_updates:
|
||||
description: 'Utilizar el Dependabot para verificar lanzamientos nuevos y crear solicitudes de cambios para actualizar tus dependencias.'
|
||||
guides:
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-version-updates
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/enabling-and-disabling-dependabot-version-updates
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/customizing-dependency-updates
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
|
||||
- /code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/keeping-your-actions-up-to-date-with-dependabot
|
||||
|
||||
@@ -221,7 +221,7 @@
|
||||
-
|
||||
title: Actualiza las GitHub Actions configuradas a sus últimas versiones
|
||||
description: Herramienta de CLI para verificar si todas tus acciones están actualizadas o no
|
||||
languages: 'C#, Inno Setup, PowerSHell, Shell'
|
||||
languages: 'C#, Inno Setup, PowerShell, Shell'
|
||||
href: fabasoad/ghacu
|
||||
tags:
|
||||
- versions
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
#this sequence sets the product order in the sidebar
|
||||
#the product IDs match keys in lib/all-products.js
|
||||
#note this file should not be translated
|
||||
productsInOrder:
|
||||
- github
|
||||
- admin
|
||||
- debates
|
||||
- code-security
|
||||
- acciones
|
||||
- paquetes
|
||||
- developers
|
||||
- rest
|
||||
- graphql
|
||||
- insights
|
||||
- comunidades
|
||||
- educación
|
||||
- desktop
|
||||
@@ -18,8 +18,8 @@ sections:
|
||||
- Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.
|
||||
- Las alertas de seguridad no se reportan cuando se sube a un repositorio en la línea de comandos.
|
||||
- |
|
||||
La rotación de bitácoras podría fallar en señalar los servicios para hacer la transición a archivos de bitácora nuevos, lo cual ocasiona que se utilicen los archivos de bitácora antiguos y, periódicamente, un agotamiento del espacio en el disco raíz.
|
||||
Para remediar o prevenir este problema, ejecuta los siguientes comandos en el [shell administrativo](https://docs.github.com/en/enterprise-server/admin/configuration/accessing-the-administrative-shell-ssh) (SSH), o contacta al [Soporte Empresarial de GitHub](https://enterprise.githubsupport.com/hc/en-us) para obtener ayuda:
|
||||
Log rotation may fail to signal services to transition to new log files, leading to older log files continuing to be used, and eventual root disk space exhaustion.
|
||||
To remedy and/or prevent this issue, run the following commands in the [administrative shell](https://docs.github.com/en/enterprise-server/admin/configuration/accessing-the-administrative-shell-ssh) (SSH), or contact [GitHub Enterprise Support](https://support.github.com/contact) for assistance:
|
||||
|
||||
```
|
||||
printf "PATH=/usr/local/sbin:/usr/local/bin:/usr/local/share/enterprise:/usr/sbin:/usr/bin:/sbin:/bin\n29,59 * * * * root /usr/sbin/logrotate /etc/logrotate.conf\n" | sudo sponge /etc/cron.d/logrotate
|
||||
|
||||
@@ -24,8 +24,8 @@ sections:
|
||||
- Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio era más grande a 255 caracteres.
|
||||
- Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.
|
||||
- |
|
||||
La rotación de bitácoras podría fallar en señalar los servicios para hacer la transición a archivos de bitácora nuevos, lo cual ocasiona que se utilicen los archivos de bitácora antiguos y, periódicamente, un agotamiento del espacio en el disco raíz.
|
||||
Para remediar o prevenir este problema, ejecuta los siguientes comandos en el [shell administrativo](https://docs.github.com/en/enterprise-server/admin/configuration/accessing-the-administrative-shell-ssh) (SSH), o contacta al [Soporte Empresarial de GitHub](https://enterprise.githubsupport.com/hc/en-us) para obtener ayuda:
|
||||
Log rotation may fail to signal services to transition to new log files, leading to older log files continuing to be used, and eventual root disk space exhaustion.
|
||||
To remedy and/or prevent this issue, run the following commands in the [administrative shell](https://docs.github.com/en/enterprise-server/admin/configuration/accessing-the-administrative-shell-ssh) (SSH), or contact [GitHub Enterprise Support](https://support.github.com/contact) for assistance:
|
||||
|
||||
```
|
||||
printf "PATH=/usr/local/sbin:/usr/local/bin:/usr/local/share/enterprise:/usr/sbin:/usr/bin:/sbin:/bin\n29,59 * * * * root /usr/sbin/logrotate /etc/logrotate.conf\n" | sudo sponge /etc/cron.d/logrotate
|
||||
|
||||
@@ -35,7 +35,7 @@ sections:
|
||||
- 'Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.'
|
||||
- 'Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio era más grande a 255 caracteres.'
|
||||
- 'Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.'
|
||||
- 'Cuando se habilita el modo de mantenimiento, algunos servicios siguen estando listados como "procesos activos". Se espera que los servicios identificados se ejecuten durante el modo de mantenimiento. Si experimentas este problema y no estás seguro de cómo solucionarlo, contacta al [Soporte Empresarial de GitHub](https://enterprise.githubsupport.com/hc/en-us).'
|
||||
- 'When maintenance mode is enabled, some services continue to be listed as "active processes". The services identified are expected to run during maintenance mode. If you experience this issue and are unsure, contact [GitHub Enterprise Support](https://support.github.com/contact).'
|
||||
- 'El registro duplicado hacia `/var/log/messages`, `/var/log/syslog`, y `/var/log/user.log` da como resultado una utilización incrementada del volúmen raíz.'
|
||||
- 'Los usuarios pueden descartar un mensaje obligatorio sin verificar todas las casillas.'
|
||||
- '[Los scripts de gancho de pre-recepción](/admin/policies/enforcing-policy-with-pre-receive-hooks) no pueden escribir archivos temporales, los cuales pueden causar que falle la ejecución del script. Los usuarios que utilizan ganchos de pre-recepción deberían hacer pruebas en un ambiente de pruebas para ver si dichos scripts requieren de acceso de escritura.'
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
date: '2021-10-28'
|
||||
sections:
|
||||
security_fixes:
|
||||
- 'Several known weak SSH public keys have been added to the deny list and can no longer be registered. In addition, versions of GitKraken known to generate weak SSH keys (7.6.x, 7.7.x and 8.0.0) have been blocked from registering new public keys.'
|
||||
- 'Los paquetes se actualizaron a las últimas versiones de seguridad.'
|
||||
bugs:
|
||||
- 'Several parts of the application were unusable for users who are owners of many organizations.'
|
||||
known_issues:
|
||||
- En una instalación nueva de {% data variables.product.prodname_ghe_server %} que no tenga ningún usuario, cualquier atacante podría crear el primer usuario administrativo.
|
||||
- Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.
|
||||
- Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.
|
||||
- Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio del blob era más grande a 255 caracteres.
|
||||
- Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.
|
||||
- Cuando un nodo de réplica está fuera de línea en una configuración de disponibilidad alta, {% data variables.product.product_name %} aún podría enrutar las solicitudes a {% data variables.product.prodname_pages %} para el nodo fuera de línea, reduciendo la disponibilidad de {% data variables.product.prodname_pages %} para los usuarios.
|
||||
- Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.
|
||||
@@ -0,0 +1,23 @@
|
||||
date: '2021-11-09'
|
||||
sections:
|
||||
security_fixes:
|
||||
- 'A path traversal vulnerability was identified in {% data variables.product.prodname_pages %} builds on {% data variables.product.prodname_ghe_server %} that could allow an attacker to read system files. To exploit this vulnerability, an attacker needed permission to create and build a {% data variables.product.prodname_pages %} site on the {% data variables.product.prodname_ghe_server %} instance. This vulnerability affected all versions of {% data variables.product.prodname_ghe_server %} prior to 3.3, and was fixed in versions 3.0.19, 3.1.11, and 3.2.3. This vulnerability was reported through the {% data variables.product.company_short %} Bug Bounty program and has been assigned CVE-2021-22870.'
|
||||
- 'Los paquetes se actualizaron a las últimas versiones de seguridad.'
|
||||
bugs:
|
||||
- 'Some Git operations failed after upgrading a {% data variables.product.prodname_ghe_server %} 3.x cluster because of the HAProxy configuration.'
|
||||
- 'Unicorn worker counts might have been set incorrectly in clustering mode.'
|
||||
- 'Resqued worker counts might have been set incorrectly in clustering mode.'
|
||||
- 'If Ubuntu''s Uncomplicated Firewall (UFW) status was inactive, a client could not clearly see it in the logs.'
|
||||
- 'Some pages and Git-related background jobs might not run in cluster mode with certain cluster configurations.'
|
||||
- 'The enterprise audit log page would not display audit events for {% data variables.product.prodname_secret_scanning %}.'
|
||||
- 'Users were not warned about potentially dangerous bidirectional unicode characters when viewing files. For more information, see "[Warning about bidirectional Unicode text](https://github.co/hiddenchars)" in {% data variables.product.prodname_blog %}.'
|
||||
- 'Hookshot Go sent distribution type metrics that Collectd could not handle, which caused a ballooning of parsing errors.'
|
||||
- 'Public repositories displayed unexpected results from {% data variables.product.prodname_secret_scanning %} with a type of `Unknown Token`.'
|
||||
known_issues:
|
||||
- 'En una instalación nueva de {% data variables.product.prodname_ghe_server %} que no tenga ningún usuario, cualquier atacante podría crear el primer usuario administrativo.'
|
||||
- 'Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.'
|
||||
- 'Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.'
|
||||
- 'Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio del blob era más grande a 255 caracteres.'
|
||||
- 'Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.'
|
||||
- 'Cuando un nodo de réplica está fuera de línea en una configuración de disponibilidad alta, {% data variables.product.product_name %} aún podría enrutar las solicitudes a {% data variables.product.prodname_pages %} para el nodo fuera de línea, reduciendo la disponibilidad de {% data variables.product.prodname_pages %} para los usuarios.'
|
||||
- 'Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.'
|
||||
@@ -27,7 +27,7 @@ sections:
|
||||
- Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.
|
||||
- Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio era más grande a 255 caracteres.
|
||||
- Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.
|
||||
- Cuando se habilita el modo de mantenimiento, algunos servicios siguen estando listados como "procesos activos". Se espera que los servicios identificados se ejecuten durante el modo de mantenimiento. Si experimentas este problema y no estás seguro de cómo solucionarlo, contacta al [Soporte Empresarial de GitHub](https://enterprise.githubsupport.com/hc/en-us).
|
||||
- When maintenance mode is enabled, some services continue to be listed as "active processes". The services identified are expected to run during maintenance mode. If you experience this issue and are unsure, contact [GitHub Enterprise Support](https://support.github.com/contact).
|
||||
- La interpretación de Jupyter Notebook en la IU web podría fallar si el bloc de notas incluye caracteres diferentes a los de ASCII UTF-8.
|
||||
- El reStructuredText (RST) que se representa en la IU web podría fallar y mostrar un texto de marcado RST sin procesar.
|
||||
- Las compilaciones antiguas de las páginas no se limpiaron, lo cual pudo haber llenado el disco del usuario (`/data/user/`).
|
||||
|
||||
@@ -26,14 +26,14 @@ sections:
|
||||
- Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.
|
||||
- Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio era más grande a 255 caracteres.
|
||||
- Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.
|
||||
- Cuando se habilita el modo de mantenimiento, algunos servicios siguen estando listados como "procesos activos". Se espera que los servicios identificados se ejecuten durante el modo de mantenimiento. Si experimentas este problema y no estás seguro de cómo solucionarlo, contacta al [Soporte Empresarial de GitHub](https://enterprise.githubsupport.com/hc/en-us).
|
||||
- When maintenance mode is enabled, some services continue to be listed as "active processes". The services identified are expected to run during maintenance mode. If you experience this issue and are unsure, contact [GitHub Enterprise Support](https://support.github.com/contact).
|
||||
- La interpretación de Jupyter Notebook en la IU web podría fallar si el bloc de notas incluye caracteres diferentes a los de ASCII UTF-8.
|
||||
- El reStructuredText (RST) que se representa en la IU web podría fallar y mostrar un texto de marcado RST sin procesar.
|
||||
- Las compilaciones antiguas de las páginas no se limpiaron, lo cual pudo haber llenado el disco del usuario (`/data/user/`).
|
||||
- Cuando borras una rama después de fusionar una solicitud de cambios, se mostrará un mensaje de error aunque el borrado de la rama sea exitoso.
|
||||
- |
|
||||
La rotación de bitácoras podría fallar en señalar los servicios para hacer la transición a archivos de bitácora nuevos, lo cual ocasiona que se utilicen los archivos de bitácora antiguos y, periódicamente, un agotamiento del espacio en el disco raíz.
|
||||
Para remediar o prevenir este problema, ejecuta los siguientes comandos en el [shell administrativo](https://docs.github.com/en/enterprise-server/admin/configuration/accessing-the-administrative-shell-ssh) (SSH), o contacta al [Soporte Empresarial de GitHub](https://enterprise.githubsupport.com/hc/en-us) para obtener ayuda:
|
||||
Log rotation may fail to signal services to transition to new log files, leading to older log files continuing to be used, and eventual root disk space exhaustion.
|
||||
To remedy and/or prevent this issue, run the following commands in the [administrative shell](https://docs.github.com/en/enterprise-server/admin/configuration/accessing-the-administrative-shell-ssh) (SSH), or contact [GitHub Enterprise Support](https://support.github.com/) for assistance:
|
||||
|
||||
```
|
||||
printf "PATH=/usr/local/sbin:/usr/local/bin:/usr/local/share/enterprise:/usr/sbin:/usr/bin:/sbin:/bin\n29,59 * * * * root /usr/sbin/logrotate /etc/logrotate.conf\n" | sudo sponge /etc/cron.d/logrotate
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
date: '2021-10-28'
|
||||
sections:
|
||||
security_fixes:
|
||||
- 'It was possible for cleartext passwords to end up in certain log files.'
|
||||
- 'Several known weak SSH public keys have been added to the deny list and can no longer be registered. In addition, versions of GitKraken known to generate weak SSH keys (7.6.x, 7.7.x and 8.0.0) have been blocked from registering new public keys.'
|
||||
- 'Los paquetes se actualizaron a las últimas versiones de seguridad.'
|
||||
bugs:
|
||||
- 'Restore might fail for enterprise server in clustering mode if orchestrator isnt healthily.'
|
||||
- 'Several parts of the application were unusable for users who are owners of many organizations.'
|
||||
- 'Fixed a link to https://docs.github.com.'
|
||||
changes:
|
||||
- 'Browsing and job performance optimizations for repositories with many refs.'
|
||||
known_issues:
|
||||
- El registor de npm del {% data variables.product.prodname_registry %} ya no regresa un valor de tiempo en las respuestas de metadatos. Esto se hizo para permitir mejoras de rendimiento sustanciales. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y terminaremos de devolver este valor ene l futuro una vez que hayamos resuelto los problemas de rendimiento existentes.
|
||||
- En una instalación nueva de {% data variables.product.prodname_ghe_server %} que no tenga ningún usuario, cualquier atacante podría crear el primer usuario administrativo.
|
||||
- Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.
|
||||
- Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.
|
||||
- Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio del blob era más grande a 255 caracteres.
|
||||
- Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.
|
||||
- Si se habilitan las {% data variables.product.prodname_actions %} para {% data variables.product.prodname_ghe_server %}, el desmontar un nodo de réplica con `ghe-repl-teardown` tendrá éxito, pero podría devolver un `ERROR:Running migrations`.
|
||||
- Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.
|
||||
@@ -0,0 +1,28 @@
|
||||
date: '2021-11-09'
|
||||
sections:
|
||||
security_fixes:
|
||||
- 'A path traversal vulnerability was identified in {% data variables.product.prodname_pages %} builds on {% data variables.product.prodname_ghe_server %} that could allow an attacker to read system files. To exploit this vulnerability, an attacker needed permission to create and build a {% data variables.product.prodname_pages %} site on the {% data variables.product.prodname_ghe_server %} instance. This vulnerability affected all versions of {% data variables.product.prodname_ghe_server %} prior to 3.3, and was fixed in versions 3.0.19, 3.1.11, and 3.2.3. This vulnerability was reported through the {% data variables.product.company_short %} Bug Bounty program and has been assigned CVE-2021-22870.'
|
||||
- 'Los paquetes se actualizaron a las últimas versiones de seguridad.'
|
||||
bugs:
|
||||
- 'Some Git operations failed after upgrading a {% data variables.product.prodname_ghe_server %} 3.x cluster because of the HAProxy configuration.'
|
||||
- 'Unicorn worker counts might have been set incorrectly in clustering mode.'
|
||||
- 'Resqued worker counts might have been set incorrectly in clustering mode.'
|
||||
- 'If Ubuntu''s Uncomplicated Firewall (UFW) status was inactive, a client could not clearly see it in the logs.'
|
||||
- 'Upgrading from {% data variables.product.prodname_ghe_server %} 2.x to 3.x failed when there were UTF8 characters in an LDAP configuration.'
|
||||
- 'Some pages and Git-related background jobs might not run in cluster mode with certain cluster configurations.'
|
||||
- 'When a new tag was created, the [push](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#push) webhook payload did not display a correct `head_commit` object. Now, when a new tag is created, the push webhook payload now always includes a `head_commit` object that contains the data of the commit that the new tag points to. As a result, the `head_commit` object will always contain the commit data of the payload''s `after` commit.'
|
||||
- 'The enterprise audit log page would not display audit events for {% data variables.product.prodname_secret_scanning %}.'
|
||||
- 'There was an insufficient job timeout for replica repairs.'
|
||||
- 'Users were not warned about potentially dangerous bidirectional unicode characters when viewing files. For more information, see "[Warning about bidirectional Unicode text](https://github.co/hiddenchars)" in {% data variables.product.prodname_blog %}.'
|
||||
- 'Hookshot Go sent distribution type metrics that Collectd could not handle, which caused a ballooning of parsing errors.'
|
||||
changes:
|
||||
- 'Kafka configuration improvements have been added. When deleting repositories, package files are now immediately deleted from storage account to free up space. `DestroyDeletedPackageVersionsJob` now deletes package files from storage account for stale packages along with metadata records.'
|
||||
known_issues:
|
||||
- 'El registor de npm del {% data variables.product.prodname_registry %} ya no regresa un valor de tiempo en las respuestas de metadatos. Esto se hizo para permitir mejoras de rendimiento sustanciales. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y terminaremos de devolver este valor ene l futuro una vez que hayamos resuelto los problemas de rendimiento existentes.'
|
||||
- 'En una instalación nueva de {% data variables.product.prodname_ghe_server %} que no tenga ningún usuario, cualquier atacante podría crear el primer usuario administrativo.'
|
||||
- 'Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.'
|
||||
- 'Los archivos rastreados del LFS de Git que se [cargaron mediante la interface web](https://github.com/blog/2105-upload-files-to-your-repositories) se agregaron incorrecta y directamente al repositorio.'
|
||||
- 'Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio del blob era más grande a 255 caracteres.'
|
||||
- 'Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.'
|
||||
- 'Si se habilitan las {% data variables.product.prodname_actions %} para {% data variables.product.prodname_ghe_server %}, el desmontar un nodo de réplica con `ghe-repl-teardown` tendrá éxito, pero podría devolver un `ERROR:Running migrations`.'
|
||||
- 'Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.'
|
||||
@@ -112,7 +112,7 @@ sections:
|
||||
- '**{% data variables.product.prodname_ghe_server %} 2.22 se descontinuará el 23 de septiembre de 2021**. Esto significa que no se harán lanzamientos de parches, incluso para los problemas de seguridad, después de dicha fecha. Para tener un rendimiento mejor, una seguridad mejorada y cualquier característica nueva, [actualiza a la versión más nueva de {% data variables.product.prodname_ghe_server %}](/enterprise-server@3.2/admin/enterprise-management/upgrading-github-enterprise-server) tan pronto te sea posible.'
|
||||
- heading: 'Obsoletización del soporte para XenServer Hypervisor'
|
||||
notes:
|
||||
- 'Desde la versión 3.1 de {% data variables.product.prodname_ghe_server %}, comenzaremos a descontinuar la compatibilidad con Xen Hypervisor. La obsoletización completa está programada para la versión 3.3 de {% data variables.product.prodname_ghe_server %}, siguiendo la ventana de obsoletización estándar de un año. Por favor, contacta al [Soporte de Github](https://enterprise.githubsupport.com/hc/en-us/signin) so tienes dudas o preguntas.'
|
||||
- 'Beginning in {% data variables.product.prodname_ghe_server %} 3.1, we will begin discontinuing support for Xen Hypervisor. The complete deprecation is scheduled for {% data variables.product.prodname_ghe_server %} 3.3, following the standard one year deprecation window. Please contact [GitHub Support](https://support.github.com/contact) with questions or concerns.'
|
||||
- heading: 'Eliminación de los servicios tradicionales de GitHub'
|
||||
notes:
|
||||
- '{% data variables.product.prodname_ghe_server %} 3.2 elimina los registros de base de datos de GitHub Service sin utilizar. Hay más información disponible en la [publicación del anuncio de obsoletización](https://developer.github.com/changes/2018-04-25-github-services-deprecation/).'
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user