# Pull requests

Propose, review, and merge code changes using pull requests to collaborate effectively and maintain code quality.

Pull requests are proposals to merge code changes into a project. A pull request is GitHub's key **collaboration feature**, letting you discuss and review changes before merging them. This helps teams work together, catch issues early, and maintain code quality.

<a href="https://github.com/pulls?ref_product=github&ref_type=engagement&ref_style=button" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>View your pull requests</span> <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-link-external" aria-label="link external icon" role="img"><path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path></svg></a>

## Working with pull requests

A pull request brings together the context reviewers need to understand a change. This context is organized into tabs:

* The **Conversation** tab shows the description, timeline, comments, and reviews.
* The **Commits** tab shows how the pull request branch changed over time.
* The **Checks** tab shows automated tests, builds, and other validations.
* The **Files changed** tab shows the diff that reviewers use to understand the proposed changes.
* The **Findings** tab shows automated code review results, such as code scanning alerts, for the proposed changes.

Separately from the tabs, the **merge status** highlights blockers, missing approvals, and other requirements before merging. It appears in the pull request header and in the merge box.

Together, these views help authors and reviewers discuss the change, track feedback, and decide when the pull request is ready to merge.

## Draft pull requests

When you create a pull request, you can choose to make it a draft pull request. Draft pull requests cannot be merged, and code owners are not automatically requested to review them. Drafts are useful when you want to share work-in-progress without formally requesting reviews.

끌어오기 요청에 대한 피드백을 받을 준비가 되면 초안 끌어오기 요청을 검토 준비 상태로 표시할 수 있습니다. 끌어오기 요청을 검토 준비 상태로 표시하면 모든 코드 소유자의 검토가 요청됩니다. You can convert a pull request to a draft at any time. See [Changing the stage of a pull request](/ko/enterprise-server@3.20/pull-requests/how-tos/create-pull-requests/changing-the-stage-of-a-pull-request).

## Pull request refs and merge branches

When you open a pull request, GitHub creates temporary Git references that point to the pull request's head branch and, when possible, to a simulated merge result. These refs help GitHub and integrations evaluate the pull request without changing the base branch.

For most contributors, these refs stay in the background. They are most relevant when you are building automation, debugging CI behavior, or fetching pull request state locally. For information about how GitHub Actions uses the merge branch, see [워크플로를 트리거하는 이벤트](/ko/enterprise-server@3.20/actions/reference/workflows-and-actions/events-that-trigger-workflows#how-the-merge-branch-affects-your-workflow).

## Differences between commits on compare and pull request pages

Compare pages and pull request pages can calculate changed files from different merge bases. As a result, the same branches can sometimes show different diffs in each place.

This usually matters when the base branch has changed since the pull request was created. Pull request pages focus on what the pull request introduced, while compare pages reflect the current comparison between two refs.

## Collaborative development models

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.

### Fork and pull model

In the fork and pull model, anyone can fork an existing ("upstream") repository if they have read access and the owner of the upstream repository allows it. Be aware that a fork and its upstream share the same Git data. This means that all content uploaded to a fork is accessible from the upstream and all other forks of that upstream.

You do not need permission from the upstream repository to push to a fork you created. You can optionally allow anyone with push access to the upstream repository to make changes to your pull request branch. This model is popular with open-source projects because it reduces friction for new contributors and lets people work independently without upfront coordination.

> \[!TIP]
> 오픈 소스, 특히 오픈 소스 프로젝트를 만들고 성장시키는 방법에 대한 자세한 내용을 제공하기 위해 건강한 오픈 소스 커뮤니티를 육성하는 데 도움이 되는 [오픈 소스 가이드](https://opensource.guide/)를 만들었습니다. 또한 오픈 소스 커뮤니티를 유지 관리하기에 관한 무료 [GitHub Skills](https://skills.github.com/) 과정을 이수할 수도 있습니다.

### Shared repository model

In the shared repository model, collaborators have push access to a single shared repository and create topic branches when they need to make changes. Pull requests are useful in this model because they start code review and general discussion about a set of changes before the changes are merged into the main development branch. This model is more common with small teams and organizations collaborating on private projects.

## Further reading

* [Creating a pull request](/ko/enterprise-server@3.20/pull-requests/how-tos/create-pull-requests/creating-a-pull-request)
* [Branches](/ko/enterprise-server@3.20/pull-requests/reference/branches)
* [Commenting on a pull request](/ko/enterprise-server@3.20/pull-requests/how-tos/review-pull-requests/commenting-on-a-pull-request)
* [Creating a pull request from a fork](/ko/enterprise-server@3.20/pull-requests/how-tos/create-pull-requests/creating-a-pull-request-from-a-fork)
* [Allowing changes to a pull request branch created from a fork](/ko/enterprise-server@3.20/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork)