jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-04 09:06:46 -05:00
Code Issues Projects Releases Wiki Activity

directory deletions and creations with new index

Browse Source
This commit is contained in:
Jules Parker
2021-10-06 14:26:53 +02:00
parent 31ecb49aea
commit 78271efc74
63 changed files with 22 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
content/github/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts.md
View File

@@ -1,41 +0,0 @@
---
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
versions:
fpt: '*'
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.
![merge conflict error message](/assets/images/help/pull_requests/merge_conflict_error_on_github.png)
## 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 %}](/articles/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](/articles/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](/articles/resolving-a-merge-conflict-using-the-command-line)"
- "[Resolving a merge conflict on GitHub](/articles/resolving-a-merge-conflict-on-github)"

19
content/github/collaborating-with-pull-requests/addressing-merge-conflicts/index.md
View File

@@ -1,19 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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
---

61
content/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github.md
View File

@@ -1,61 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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**.
![Resolve merge conflicts button](/assets/images/help/pull_requests/resolve-merge-conflicts-button.png)
{% 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](/articles/resolving-a-merge-conflict-using-the-command-line)."
{% endtip %}
{% data reusables.pull_requests.decide-how-to-resolve-competing-line-change-merge-conflict %}
![View merge conflict example with conflict markers](/assets/images/help/pull_requests/view-merge-conflict-with-markers.png)
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**.
![Click mark as resolved button](/assets/images/help/pull_requests/mark-as-resolved-button.png)
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.
![Select next conflicting file if applicable](/assets/images/help/pull_requests/resolve-merge-conflict-select-conflicting-file.png)
1. Once you've resolved all your merge conflicts, click **Commit merge**. This merges the entire base branch into your head branch.
![Resolve merge conflicts button](/assets/images/help/pull_requests/merge-conflict-commit-changes.png)
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.
![Prompt to review the branch that will be updated](/assets/images/help/pull_requests/conflict-resolution-merge-dialog-box.png)
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](/articles/about-pull-request-merges)"

129
content/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line.md
View File

@@ -1,129 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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](/articles/about-merge-conflicts)"
- "[Checking out pull requests locally](/articles/checking-out-pull-requests-locally/)"

70
content/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks.md
View File

@@ -1,70 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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.
![List of commits and statuses](/assets/images/help/pull_requests/commit-list-statuses.png)
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.
![Status checks within a pull request](/assets/images/help/pull_requests/checks.png)
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.
![Details of a status check](/assets/images/help/pull_requests/checks-detailed.png)
You can navigate between the checks summaries for various commits in a pull request, using the commit drop-down menu under the **Conversation** tab.
![Check summaries for different commits in a drop-down menu](/assets/images/help/pull_requests/checks-summary-for-various-commits.png)
### 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"
```

19
content/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/index.md
View File

@@ -1,19 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
topics:
- Pull requests
children:
- /about-status-checks
- /working-with-pre-receive-hooks
shortTitle: Code quality features
---

32
content/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/working-with-pre-receive-hooks.md
View File

@@ -1,32 +0,0 @@
---
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
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'
```
![Error message for failed pre-receive hook](/assets/images/help/pull_requests/pre-receive-hook-failed-error.png)
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)."

35
content/github/collaborating-with-pull-requests/getting-started/about-collaborative-development-models.md
View File

@@ -1,35 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/about-pull-requests)"
- "[Creating a pull request from a fork](/articles/creating-a-pull-request-from-a-fork)"
- "[Allowing changes to a pull request branch created from a fork](/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)"

20
content/github/collaborating-with-pull-requests/getting-started/index.md
View File

@@ -1,20 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
topics:
- Pull requests
- Issues
- Discussions
- Fundamentals
children:
- /about-collaborative-development-models
---

58
content/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges.md
View File

@@ -1,58 +0,0 @@
---
title: About pull request merges
intro: 'You can [merge pull requests](/articles/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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/addressing-merge-conflicts)"

52
content/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request.md
View File

@@ -1,52 +0,0 @@
---
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: '*'
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
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 %}
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)."
!["Enable auto-merge" drop-down menu](/assets/images/help/pull_requests/enable-auto-merge-drop-down.png)
1. Click **Enable auto-merge**.
![Button to enable auto-merge](/assets/images/help/pull_requests/enable-auto-merge-button.png)
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.
![Fields to enter commit message and description and choose commit author email](/assets/images/help/pull_requests/pull-request-information-fields.png)
1. Click **Confirm auto-merge**.
![Button to confirm auto-merge](/assets/images/help/pull_requests/confirm-auto-merge-button.png)
## 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**.
![Button to disable auto-merge](/assets/images/help/pull_requests/disable-auto-merge-button.png)

25
content/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/closing-a-pull-request.md
View File

@@ -1,25 +0,0 @@
---
title: Closing a pull request
intro: 'You may choose to *close* a pull request without [merging it into the upstream branch](/articles/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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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**.
![The close Pull Request button](/assets/images/help/pull_requests/pullrequest-closebutton.png)
4. Optionally, [delete the branch](/articles/deleting-unused-branches). This keeps the list of branches in your repository tidy.

21
content/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/index.md
View File

@@ -1,21 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
topics:
- Pull requests
children:
- /about-pull-request-merges
- /merging-a-pull-request
- /automatically-merging-a-pull-request
- /closing-a-pull-request
- /reverting-a-pull-request
shortTitle: Incorporate changes
---

104
content/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request.md
View File

@@ -1,104 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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](/articles/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](/articles/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**.
![merge-pull-request-button](/assets/images/help/pull_requests/pullrequest-mergebutton.png)
- [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.
![click-squash-and-merge-button](/assets/images/help/pull_requests/select-squash-and-merge-from-drop-down-menu.png)
- [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.
![select-rebase-and-merge-from-drop-down-menu](/assets/images/help/pull_requests/select-rebase-and-merge-from-drop-down-menu.png)
{% 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 %}
![Commit message field](/assets/images/help/pull_requests/merge_box/pullrequest-commitmessage.png)
{% 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](/articles/about-pull-request-merges)"
- "[Addressing merge conflicts](/articles/addressing-merge-conflicts)"

36
content/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request.md
View File

@@ -1,36 +0,0 @@
---
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
- /articles/reverting-a-pull-request
- /github/collaborating-with-issues-and-pull-requests/reverting-a-pull-request
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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**.
![Revert pull request link](/assets/images/help/pull_requests/revert-pull-request-link.png)
4. Merge the resulting pull request. For more information, see "[Merging a pull request](/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request)."

27
content/github/collaborating-with-pull-requests/index.md
View File

@@ -1,27 +0,0 @@
---
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/
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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
---

84
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches.md
View File

@@ -1,84 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 {% ifversion fpt or ghes > 2.22 or ghae %}`main`{% else %}`master`{% endif %} in any new repository.
{% data reusables.branches.change-default-branch %}
{% ifversion fpt or ghes > 2.22 or ghae %}
{% data reusables.branches.set-default-branch %}
{% endif %}
## 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](/articles/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 `master` 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`.
![merge-pull-request-button](/assets/images/help/branches/pr-retargeting-diagram1.png)
In the next diagram, someone has merged the pull request for `feature1` into the `master` 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 `master`.
![merge-pull-request-button](/assets/images/help/branches/pr-retargeting-diagram2.png)
Now when you merge the `feature2` pull request, it'll be merged into the `master` 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](/articles/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](/articles/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](/articles/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

72
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests.md
View File

@@ -1,72 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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.
{% ifversion ghes < 3.0 %}
![Pull Request Files changed tab](/assets/images/enterprise/2.22/pull-request-tabs-changed-files.png){% else %}
![Pull Request Files changed tab](/assets/images/help/pull_requests/pull-request-tabs-changed-files.png){% endif %}
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.
![Diff viewing options menu](/assets/images/help/pull_requests/diff-settings-menu.png)
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](/articles/filtering-files-in-a-pull-request)."
![File filter drop-down menu](/assets/images/help/pull_requests/file-filter-menu.png)
## 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](/articles/about-pull-requests)"
- "[About forks](/articles/about-forks)"

74
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests.md
View File

@@ -1,74 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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 %}
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](/articles/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](/articles/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](/articles/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](/articles/about-branches)"
- "[Commenting on a pull request](/articles/commenting-on-a-pull-request)"
- "[Closing a pull request](/articles/closing-a-pull-request)"

38
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.md
View File

@@ -1,38 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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**. ![Pull Request edit button](/assets/images/help/pull_requests/pull-request-edit.png)
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). ![Base branch drop-down menu ](/assets/images/help/pull_requests/pull-request-edit-base-branch.png)
5. Read the information about changing the base branch and click **Change base**. ![Base branch change confirmation button ](/assets/images/help/pull_requests/pull-request-base-branch-confirm.png)
{% 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](/articles/about-pull-requests)"
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"

52
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request.md
View File

@@ -1,52 +0,0 @@
---
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 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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 %}
{% 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**.
![Ready for review button](/assets/images/help/pull_requests/ready-for-review-button.png)
{% ifversion fpt or ghae or ghes %}
## 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**.
![Convert to draft link](/assets/images/help/pull_requests/convert-to-draft-link.png)
4. Click **Convert to draft**.
![Convert to draft confirmation](/assets/images/help/pull_requests/convert-to-draft-dialog.png)
{% endif %}
## Further reading
- "[About pull requests](/github/collaborating-with-issues-and-pull-requests/about-pull-requests)"

93
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork.md
View File

@@ -1,93 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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](/articles/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.
![compare-branch-example](/assets/images/help/pull_requests/compare-branch-example.png)
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](/articles/about-forks)"

40
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork.md
View File

@@ -1,40 +0,0 @@
---
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
permissions: Anyone with write access to a repository can create a pull request from a user-owned fork.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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**.
![Compare across forks link](/assets/images/help/pull_requests/compare-across-forks-link.png)
4. In the "base branch" drop-down menu, select the branch of the upstream repository you'd like to merge changes into.
![Drop-down menus for choosing the base fork and branch](/assets/images/help/pull_requests/choose-base-fork-and-branch.png)
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.
![Drop-down menus for choosing the head fork and compare branch](/assets/images/help/pull_requests/choose-head-fork-compare-branch.png)
{% data reusables.repositories.pr-title-description %}
{% data reusables.repositories.allow-maintainers-user-forks %}
![allow-maintainers-to-make-edits-checkbox](/assets/images/help/pull_requests/allow-maintainers-to-make-edits.png)
{% 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](/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)"

176
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request.md
View File

@@ -1,176 +0,0 @@
---
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.'
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: '*'
topics:
- Pull requests
---
Anyone with read permissions to a repository can create a pull request, but you must have write permissions to create a branch. If you want to create a new branch for your pull request and don't 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.
![Pull Request editing branches](/assets/images/help/pull_requests/pull-request-review-edit-branch.png)
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](/github/committing-changes-to-your-project/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.
![Branch dropdown menu](/assets/images/help/pull_requests/branch-dropdown.png)
{% 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.
![Drop-down menus for choosing the base and compare branches](/assets/images/help/pull_requests/choose-base-and-compare-branches.png)
{% 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](/articles/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 %}.
![The Create Pull Request button](/assets/images/help/desktop/mac-create-pull-request.png)
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.
![Drop-down menus for choosing the base and compare branches](/assets/images/help/desktop/base-and-compare-branches.png)
{% 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 %}.
![The Create Pull Request button](/assets/images/help/desktop/windows-create-pull-request.png)
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.
![Drop-down menus for choosing the base and compare branches](/assets/images/help/desktop/base-and-compare-branches.png)
{% data reusables.repositories.pr-title-description %}
{% data reusables.repositories.create-pull-request %}
{% endwindows %}
{% enddesktop %}
{% ifversion fpt %}
{% codespaces %}
1. Once you've committed changes to your local copy of the repository, click the **Create Pull Request** icon.
![Source control side bar with staging button highlighted](/assets/images/help/codespaces/codespaces-commit-pr-button.png)
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.
![Source control side bar with staging button highlighted](/assets/images/help/codespaces/codespaces-commit-pr.png)
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](/articles/creating-a-pull-request-from-a-fork)"
- "[Changing the base branch of a pull request](/articles/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)"

52
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository.md
View File

@@ -1,52 +0,0 @@
---
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: '*'
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:
![Branches link on overview page](/assets/images/help/branches/branches-link.png)
1. Click the branch selector menu.
![branch selector menu](/assets/images/help/branch/branch-selection-dropdown.png)
1. Type a unique name for your new branch, then select **Create branch**.
![branch creation text box](/assets/images/help/branch/branch-creation-text-box.png)
## 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](/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request)" or "[Closing a pull request](/github/collaborating-with-issues-and-pull-requests/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" %}.
![delete the branch](/assets/images/help/branches/branches-delete.png)
{% 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](/github/collaborating-with-issues-and-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)"

27
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/index.md
View File

@@ -1,27 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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
---

42
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review.md
View File

@@ -1,42 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 %}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 assignment for your team](/organizations/organizing-members-into-teams/managing-code-review-assignment-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**.
![Reviewers request icon in the right sidebar](/assets/images/help/pull_requests/request-suggested-review.png)
5. Optionally, to request a review from someone other than a suggested person, click **Reviewers**, then click on a name in the dropdown menu.
![Reviewers gear icon in the right sidebar](/assets/images/help/pull_requests/request-a-review-not-suggested.png)
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.
![Field to enter a reviewer's username and drop-down with reviewer's name](/assets/images/help/pull_requests/choose-pull-request-reviewer.png)
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.
![Re-review sync icon in the right sidebar](/assets/images/help/pull_requests/request-re-review.png)
## Further reading
- "[About pull request reviews](/articles/about-pull-request-reviews)"

33
content/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/using-query-parameters-to-create-a-pull-request.md
View File

@@ -1,33 +0,0 @@
---
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.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 permission levels for an organization](/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-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)."

63
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews.md
View File

@@ -1,63 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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](/articles/requesting-a-pull-request-review)." {% ifversion fpt or ghae or ghes %}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 assignment for your team](/organizations/organizing-members-into-teams/managing-code-review-assignment-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 %}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 %}
![Header of review requesting changes with line comments](/assets/images/help/pull_requests/review-header-with-line-comment.png)
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.
![Image of review statuses](/assets/images/help/pull_requests/pull-request-review-statuses.png)
{% 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.
![Image of reviews in a merge box](/assets/images/help/pull_requests/merge_box/pr-reviews-in-merge-box.png)
{% 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](/articles/dismissing-a-pull-request-review)."
{% endtip %}
## Further reading
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
- "[Viewing a pull request review](/articles/viewing-a-pull-request-review)"
- "[Setting guidelines for repository contributors](/articles/setting-guidelines-for-repository-contributors)"

42
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews.md
View File

@@ -1,42 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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](/articles/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](/articles/reviewing-proposed-changes-in-a-pull-request)"
- "[Commenting on a pull request](/articles/commenting-on-a-pull-request)"

100
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally.md
View File

@@ -1,100 +0,0 @@
---
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
permissions: Anyone with write access to a repository can pull a remote pull request down locally.
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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 %}
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.
![Link to access command line pull request instructions](/assets/images/help/pull_requests/open-with-button.png){% else %}
3. In the merge box, click **command line instructions**. Follow the sequence of steps to bring down the proposed pull request.
![Link to access command line pull request instructions](/assets/images/help/pull_requests/pull_request_show_command_line_merge.png)
4. Optionally, to view proposed changes in {% data variables.product.prodname_desktop %}, click **open this in {% data variables.product.prodname_desktop %}**.
![Link to open a pull request locally in Desktop](/assets/images/help/desktop/open-pr-in-desktop.png){% 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.
![Pull Requests ID number](/assets/images/help/pull_requests/pull_request_id_number.png)
{% 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 %}

64
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request.md
View File

@@ -1,64 +0,0 @@
---
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
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: '*'
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.
![Pull Request conversation](/assets/images/help/pull_requests/conversation.png)
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](/articles/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."](/articles/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**.
![Inline comment window](/assets/images/help/commits/inline-comment.png)
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 %}- "[Reporting abuse or spam](/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam)"
{% endif %}

33
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review.md
View File

@@ -1,33 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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" %}. ![Chevron icon in the merge box](/assets/images/help/pull_requests/merge_box/pull-request-open-menu.png)
4. Click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %}, then click **Dismiss review**.
![Kebab icon in merge box](/assets/images/help/pull_requests/merge_box/pull-request-dismiss-review.png)
5. Type your reason for dismissing the review, then click **Dismiss review**.
![Dismiss review button](/assets/images/help/pull_requests/merge_box/pull-request-dismiss-review-button.png)
## Further reading
- "[About pull request reviews](/articles/about-pull-request-reviews)"
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"
- "[About protected branches](/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)"

36
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/filtering-files-in-a-pull-request.md
View File

@@ -1,36 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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.
![File filter option above pull request diff](/assets/images/help/pull_requests/file-filter-option.png)
5. Optionally, to clear the filter selection, under the **Files changed** tab, click **Clear**.
![Clear file filter selection](/assets/images/help/pull_requests/clear-file-filter.png)
## Further reading
- "[About comparing branches in a pull request](/articles/about-comparing-branches-in-pull-requests)"
- "[Finding changed methods and functions in a pull request](/articles/finding-changed-methods-and-functions-in-a-pull-request)"

45
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/finding-changed-methods-and-functions-in-a-pull-request.md
View File

@@ -1,45 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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...**.
![Jump to drop-down menu](/assets/images/help/pull_requests/jump-to-menu.png)
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.
![Filter function and methods](/assets/images/help/pull_requests/filter-function-and-methods.png)
{% 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.
![view function or method in files changed](/assets/images/help/pull_requests/view-selected-function-or-method.png)
## Further reading
- "[About comparing branches in a pull request](/articles/about-comparing-branches-in-pull-requests)"
- "[Filtering files in a pull request by file type](/articles/filtering-files-in-a-pull-request)"

50
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request.md
View File

@@ -1,50 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request)" and "[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)."
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**.
![Commit suggestion button](/assets/images/help/pull_requests/commit-suggestion-button.png)
- 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**.
![Add suggestion to batch button](/assets/images/help/pull_requests/add-suggestion-to-batch.png)
4. In the commit message field, type a short, meaningful commit message that describes the change you made to the file or files.
![Commit message field](/assets/images/help/pull_requests/suggested-change-commit-message-field.png)
5. Click **Commit changes.**
![Commit changes button](/assets/images/help/pull_requests/commit-changes-button.png)
## 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](/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request)"
- "[Commenting on a pull request](/github/collaborating-with-issues-and-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)"

28
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/index.md
View File

@@ -1,28 +0,0 @@
---
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
intro: 'After a pull request has been opened, you can review and discuss the set of proposed changes.'
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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
---

75
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-dependency-changes-in-a-pull-request.md
View File

@@ -1,75 +0,0 @@
---
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.'
versions:
fpt: '*'
ghes: '>= 3.2'
product: '{% data reusables.gated-features.dependency-review %}'
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
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 file filter menu](/assets/images/help/pull_requests/file-filter-menu-json.png)
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.
![The rich diff button](/assets/images/help/pull_requests/dependency-review-rich-diff.png)
{% note %}
**Note:** The dependency review provides a clearer view of what has changed in large lock files, where the source diff is not rendered by default.
{% endnote %}
1. Check the dependencies listed in the dependency review.
![Vulnerability warnings in a dependency review](/assets/images/help/pull_requests/dependency-review-vulnerability.png)
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 %}

98
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request.md
View File

@@ -1,98 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 %}
{% data reusables.repositories.start-line-comment %}
{% data reusables.repositories.type-line-comment %}
{% data reusables.repositories.suggest-changes %}
5. When you're done, click **Start a review**. If you have already started a review, you can click **Add review comment**.
![Start a review button](/assets/images/help/pull_requests/start-a-review-button.png)
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**.
![Cancel review button](/assets/images/help/pull_requests/cancel-review-button.png)
{% endwebui %}
{% ifversion fpt %}
{% 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 %}
## 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](/github/collaborating-with-issues-and-pull-requests/reviewing-dependency-changes-in-a-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.
![The rich diff button](/assets/images/help/pull_requests/dependency-review-rich-diff.png)
{% 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**.
![Viewed checkbox](/assets/images/help/pull_requests/viewed-checkbox.png)
## 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:
![Radio buttons with review options](/assets/images/help/pull_requests/pull-request-review-statuses.png)
- 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)"

28
content/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/viewing-a-pull-request-review.md
View File

@@ -1,28 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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**.
![Review header with link to full review](/assets/images/help/pull_requests/view-full-review-view-changes.png)
## Further reading
- "[About pull request reviews](/articles/about-pull-request-reviews)"
- "[Reviewing proposed changes in a pull request](/articles/reviewing-proposed-changes-in-a-pull-request)"

37
content/github/collaborating-with-pull-requests/working-with-forks/about-forks.md
View File

@@ -1,37 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 %}
{% 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 %} 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](/articles/about-collaborative-development-models)"
- "[Creating a pull request from a fork](/articles/creating-a-pull-request-from-a-fork)"
- [Open Source Guides](https://opensource.guide/){% ifversion fpt %}
- [{% data variables.product.prodname_learning %}]({% data variables.product.prodname_learning_link %}){% endif %}

35
content/github/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork.md
View File

@@ -1,35 +0,0 @@
---
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
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: '*'
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](/articles/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](/articles/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](/articles/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**.
![Issues and pull requests tab selection](/assets/images/help/repository/repo-tabs-pull-requests.png)
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 %}
![allow-maintainers-to-make-edits-sidebar-checkbox](/assets/images/help/pull_requests/allow-maintainers-to-make-edits-sidebar-checkbox.png)
## Further reading
- "[Committing changes to a pull request branch created from a fork](/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork)"

34
content/github/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-for-a-fork.md
View File

@@ -1,34 +0,0 @@
---
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](/articles/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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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)
```

21
content/github/collaborating-with-pull-requests/working-with-forks/index.md
View File

@@ -1,21 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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
---

32
content/github/collaborating-with-pull-requests/working-with-forks/merging-an-upstream-repository-into-your-fork.md
View File

@@ -1,32 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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](/articles/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>
```

73
content/github/collaborating-with-pull-requests/working-with-forks/syncing-a-fork.md
View File

@@ -1,73 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
topics:
- Pull requests
---
{% ifversion fpt or ghes > 3.1 or ghae-next %}
## 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.
!["Fetch upstream" drop-down](/assets/images/help/repository/fetch-upstream-drop-down.png)
1. Review the details about the commits from the upstream repository, then click **Fetch and merge**.
!["Fetch and merge" button](/assets/images/help/repository/fetch-and-merge-button.png)
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](/articles/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 %}

85
content/github/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility.md
View File

@@ -1,85 +0,0 @@
---
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
versions:
fpt: '*'
ghes: '*'
ghae: '*'
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 %}
## 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 %}
## 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 %}
## 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](/articles/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)"
- "{% ifversion fpt %}[Enforcing repository management policies in your enterprise account](/github/setting-up-and-managing-your-enterprise/enforcing-repository-management-policies-in-your-enterprise-account#enforcing-a-policy-on-forking-private-or-internal-repositories){% else %}[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){% endif %}"