How to accept pull request github

Proposing changes to your work with pull requests

About branches

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.

Creating and deleting branches within your repository

You can create or delete branches directly on GitHub.

About pull requests

Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. 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.

About comparing branches in pull requests

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.

Creating a pull request

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.

Creating a pull request from a fork

You can create a pull request to propose changes you’ve made to a fork of an upstream repository.

Using query parameters to create a pull request

Use query parameters to create custom URLs to open pull requests with pre-populated fields.

Changing the stage of a pull request

You can mark a draft pull request as ready for review or convert a pull request to a draft.

Requesting a pull request review

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.

Keeping your pull request in sync with the base branch

After you open a pull request, you can update the head branch, which contains your changes, with any changes that have been made in the base branch.

Changing the base branch of a pull request

After a pull request is opened, you can change the base branch to compare the changes in the pull request against a different branch.

Committing changes to a pull request branch created from a fork

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.

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Pull requests

Learn how to use pull requests to suggest changes to a project, receive suggested changes to your own projects, and address issues in pull requests, such as merge conflicts.

Guides

Changing a commit message

If a commit message contains unclear, incorrect, or sensitive information, you can amend it locally and push a new commit with a new message to GitHub. You can also change a commit message to add missing information.

Resolving a merge conflict using the command line

You can resolve merge conflicts using the command line and a text editor.

Creating and deleting branches within your repository

You can create or delete branches directly on GitHub.

Creating a pull request

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.

Popular

What’s new

Approving a pull request with required reviews

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.

Reverting a pull request

You can revert a pull request after it’s been merged to the upstream branch.

Why are my commits linked to the wrong user?

GitHub uses the email address in the commit header to link the commit to a GitHub user. If your commits are being linked to another user, or not linked to a user at all, you may need to change your local Git configuration settings, add an email address to your account email settings, or do both.

Approving a pull request with required reviews

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.

For more information about required reviews, see «About protected branches.»

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.»

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.»

Under your repository name, click

Pull requests.

In the list of pull requests, click the pull request you’d like to review.

On the pull request, click

Files changed.

Review the changes in the pull request, and optionally, comment on specific lines.

Type a comment summarizing your feedback on the proposed changes.

Select Approve to approve merging the changes proposed in the pull request.

Click Submit review.

Tips:

Merging a pull request

In this article

Merge a pull request into the upstream branch when work is completed. Anyone with push access to the repository can complete the merge.

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.»

You can configure a pull request to merge automatically when all merge requirements are met. For more information, see «Automatically merging a pull request.»

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 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.»

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.»

Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request’s base branch. For more information, see «About branches.»

You can link a pull request to an issue to show that a fix is in progress and to automatically close the issue when someone merges the pull request. For more information, see «Linking a pull request to an issue.»

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 without merging.

Merging a pull request

Under your repository name, click

Pull requests.

In the «Pull Requests» list, click the pull request you’d like to merge.

Depending on the merge options enabled for your repository, you can:

Note: Rebase and merge will always update the committer information and create new commit SHAs. For more information, see «About pull request merges.»

If prompted, type a commit message, or accept the default message.

For information about the default commit messages for squash merges, see «About pull request merges.»

If you have more than one email address associated with your account on GitHub.com, click the email address drop-down menu and select the email address to use as the Git author email address. Only verified email addresses appear in this drop-down menu. If you enabled email address privacy, then @users.noreply.github.com is the default commit author email address. For more information, see «Setting your commit email address.»

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.

Click Confirm merge, Confirm squash and merge, or Confirm rebase and merge.

Optionally, delete the branch. This keeps the list of branches in your repository tidy.

To learn more about GitHub CLI, see «About GitHub CLI.»

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.

Follow the interactive prompts to complete the merge. For more information about the merge methods that you can choose, see «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.

Pull request’ы на GitHub или Как мне внести изменения в чужой проект

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub’а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request’ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Немного о моделях совместной разработки

Делаем копию репозитория

Рассматривая первую модель разработки, необходимо иметь свою копию изначального репозитория, в которой и будет вестись работа, и изменения из которой и будут предлагаться затем автору изначального репозитория.

В рамках руководства, будем считать, что мы работаем над репозиторием Spoon-Knife пользователя octocat, а ваше имя пользователя — username.

Сделать это очень просто: на странице репозитория имеется кнопочка «Fork», которую и следует нажать.

После чего, эту свою копию уже можно «стянуть» на свой компьютер:

Склонированный репозиторий имеет одну привязку к удалённому репозиторию, названную origin, которая указывает на вашу копию на GitHub, а не на оригинальный репозиторий, чтобы отслеживать изменения и в нём, вам нужно будет добавить другую привязку, названную, например, upstream.

Делаем работу

Итак, в этой точке мы уже можем править код и делать коммиты. Если вы сделали все предыдущие шаги, чтобы потом вернуть ваши изменения в оригинальный репозиторий, то я настоятельно советую делать всю работу в отдельной тематической ветви разработки. Полезность этого станет ясна на этапе посылки pull request’а. Пускай она будет называться feature.

Вот, теперь творите добро (и пусть оно будет выражаться в коммитах).

Как только вы сделали работу (или её часть), отправьте её в свою копию репозитория на GitHub:

Возвращаем изменения: Pull request

Итак, всё сделано. Вы написали код, он у вас в ветви feature как у вас на компьютере, так и на GitHub’е. Осталось только «заслать» его в оригинальный репозиторий.

Идите на страницу вашей копии репозитория на GitHub, выбирайте ветвь feature и жмите кнопку Pull Request.

Далее вы попадёте на предпросмотровую страницу, на которой сможете ввести название и описание ваших изменений (название потом попадёт в описание мёрдж-коммита и станет достоянием общественности, учтите это).

Там же вы можете посмотреть, какие коммиты попали в пулл реквест:

А так же общий diff всех изменений в пулл реквесте:

По умолчанию, пулл реквесты считаются основанными на самой часто интегрируемой ветви родительского репозитория. В этом случае username/Spoon-Knife был скопирован с octocat/Spoon-Knife, так что pull request считается основанным на ветке master репозитория octocat/Spoon-Knife. В большинстве случаев, это будет корректно, но если не так, то вы можете нажать на кнопку «Change Commits»

Вы попадёте в форму выбора базовой и исходной ветвей:

Слева выбираете в какую ветку будут вливаться изменения в родительском репозитории, справа — какие изменения будут браться с вашего репозитория. По примеру: справа octocat/Spoon-Knife/master, слева username/Spoon-Knife/feature. Здесь вы можете указывать не только ветки, но так же теги и id отдельных коммитов в соответствующем репозитории.
ВАЖНО: Договоритесь с владельцем «родительского» репозитория, в какую ветку будете вливать изменения (он может написать это в README)

Изменение базового репозитория меняет и список людей, кто получит уведомление о пулл реквесте. Каждый, кто имеет право «на запись» в базовый репозиторий, получит письмо и увидит уведомление на главной GitHub’а, в следующий раз, как на него зайдёт.
Как только список коммитов вас удовлетворит, нажмите кнопку Update Commit Range.

Когда вы ввели название и описание и перепроверили список коммитов и изменения в файлы, попавшие в пулл реквест, нажмите кнопку Send pull request. Пулл реквест будет создан незамедлительно.

Что дальше?

Следите за вашим пулл-реквестом. Что прокомментируют люди, что скажет мэйнтэйнер, примет или нет ваш пулл реквест.

Когда ваш pull request примут, не забудьте слить изменения в свой репозиторий (или удалить его, если больше не нужен):

Так же можно удалить ветку, в которой велась разработка:

Что следует делать, если работа заняла большое время и оригинальный репозиторий успел уйти вперёд?

Можно просто влить изменения из оригинального репозитория к себе:

Однако хозяину оригинального репозитория или, может быть, даже вам, не понравится наличие мёрж-коммитов и коммитов из master’а в списке коммитов на пулл. В таком случае вам стоит воспользоваться git rebase.

Прочитать про то, как работает rebase можно в официальном руководстве. Там имеются и очень понятные иллюстрации. Так же есть статья в помощи GitHub.
ВНИМАНИЕ: Пожалуйста, учтите, что git rebase меняет id коммитов! Поэтому, все действия с этой командой стоит выполнять только на локальном репозитории, до того, как эти коммиты станут общедоступны, т.е. до того, как вы их push’нули на гитхаб.

Если вы хозяин: Как принять pull request

Если пулл реквест удовлетворяет всем условиям, то кто-либо с правом «на запись» (т.е. может сделать push) в целевой репозиторий, должен принять pull request одним из многих методов. Ниже описаны три наиболее популярных метода:

Auto Merge (автослияние)

Во многих случаях можно попросить github автоматически принять пулл реквест, используя большую зелёную кнопку Merge Pull Request, которая сама вольёт изменения, создаст мёрж-коммит и закроет пулл реквест.

Подробнее можно почитать в этом хабратопике: Кнопка слияния на GitHub.

Fetch and Merge (скачать и слить)

Основной метод вливания изменений. Он требует добавления remote, ведущего к репозиторию человека, отправившего pull request, скачивания изменений с этого репозитория, объединения нужной ветви, исправления конфликтов и выгрузки обновлённой ветви обратно в исходный репозиторий:

Patch and Apply (пропатчить и принять)

Предыдущий метод работает хорошо, когда вы работаете в команде или постоянно принимаете изменения от одной и той же группы людей. Другой метод немного быстрее в единичных случаях при использовании git-am.

Закрытие пулл реквеста

Запросы на пулл автоматически закрываются, когда запрошенные коммиты вливаются в репозиторий назначения. При этом генерируется событие, информирующее всех участников разработки, что пулл реквест был принят и влит в основную ветвь.

Так же возможно вручную закрыть пулл реквест в случае, если он был отклонён. Иногда это необходимо в случаях, когда изменения были приняты с помощью git-cherry-pick или другого механизма, который не позволяет обнаружить факт слияния (merge).