Проблемы с github: This pull request contains merge conflicts that must be resolved
Обновил некоторые классы для чужого проекта и сделал pull request. Но в conversation есть проблема: «This pull request contains merge conflicts that must be resolved. Only those with write access to this repository can merge pull requests.» Как её решить? И автор тоже пишет в conversation: «Please merge from master first and i’ll accept the pull-request».
Отслеживать
32.1k 19 19 золотых знаков 79 79 серебряных знаков 106 106 бронзовых знаков
Практическое занятие «Процесс Pull request на GitHub»
На предыдущем занятии Используем клиент GitHub для десктопа, мы использовали Github Desktop для управления рабочим процессом коммитов, ветвления и слияния. На этом занятии мы будем выполнять аналогичные действия, но с использованием браузерного интерфейса, который предоставляет Github, вместо использования терминала или Github Desktop.
Понимание процесса Pull request является важным для анализа изменений в опен-сорс проекте с несколькими участниками. Использование интерфейса GitHub также удобно, если рецензенты не знакомы с терминалом или Github Desktop.
Создание изменение в отдельной ветке
По умолчанию в новом репозитории есть одна ветка с именем «Master». Обычно, когда при внесении изменений или просмотра / редактировании, создается новая ветка и вносятся все изменения в ветку. Затем, по окончании, владелец репо объединяет изменения из новой ветки в «Master» через «pull request».
Note: Можно выполнять эти операции, используя команды Git в терминале, а также Можно выполнять их в интерфейсе браузера. Интерфейс браузера может быть полезен, если людей, вносящих изменения в ваш контент.
Для создания изменений в отдельной ветке:
- Со стороны рецензента переходим к тому же репозиторию GitHub, который был создан на предыдущем занятии (можно создать новый репо). Создаем новую ветку, выбрав раскрывающееся меню ветки и введя имя новой ветки, например «sme-review». Затем нажмите клавишу Enter.
При создании новой ветки, содержимое из главной (или любой другой ветки, которая сейчас просматривается) копируется в новую ветку. Процесс похож на «Сохранить как» с существующим документом.
- Кликаем в область ввода текста, а затем кликаем по иконке карандаша («Edit this file»), чтобы отредактировать файл.
- Вносим изменения в контент и прокручиваем вниз экрана до области Commit changes. Поясняем причину изменений и подтверждаем изменения в своей ветке sme-review, нажав кнопку Commit changes .
Рецензенты могут продолжать вносить изменения таким образом, пока не закончат просмотр всей документации. Все изменения делаются в этой новой ветке, а не в мастере.
Создание Pull request
Теперь представим, что процесс проверки завершен, и пришло время объединить ветку с мастером. Ветка объединяется с “Master” через Pull request . Любой «соавтор» в команде с правами на запись может инициировать и завершить Pull request (добавлять соавторов можете в «Настройки»> «Соавторы)
Для создания Pull request:
- Находим на экране вкладку “Pull request”.
- Кликаем по кнопке New pull request
- Выбираем ветку (sme-review), которую хотим сравнить с веткой “Master”
Когда мы сравниваем ветку с мастером, мы увидим список всех изменений. Мы можем просмотреть изменения в двух режимах просмотра: Unified или Split (это вкладки, показанные справа от содержимого). Unified показывает правки вместе в одной области содержимого, тогда как split показывает два файла рядом.
- Кликаем на кнопку Create pull request .
- Поясняем pull request и снова кликаем кнопку Create pull request .
Владелец репозитория увидит pull request и сможет принять меры для его объединения.
Процесс Pull request
Теперь посмотрим на процесс со стороны владельцем проекта, который получил новый Pull request. Владельцу нужно обработать Pull request и объединить ветку sme-review с “Master”.
- Переходим на вкладку “Pull requests”, чтобы увидеть ожидающие запросы на извлечение.
- Кликаем по запросу и смотрим изменения, выбрав вкладку Files changed.
Note: Для реализации выборочных изменений, переходим в ветку sme-review и вносим обновления перед обработкой pull request. Pull request не дает построчную информацию о том, какие изменения мы хотим принять или отклонить (например, в Microsoft Word «Отслеживать изменения»). Слияние запросов — это процесс «все или ничего». Можно нажать кнопку Review changes , добавить несколько комментариев, а затем установить переключатель «Request changes», попросив рецензента внести изменения.
Также стоит обратить внимание, что если запрос на извлечение выполняется для более старой версии мастера, где исходное содержимое мастера больше не существует или перемещено в другое место, процесс слияния будет более трудным для выполнения.
- Переходим на вкладку “Conversation” и кликаем кнопку Merge pull request .
- кликаем Confirm merge .
Ветка sme-review объединяется с мастером. Теперь “Master” и ветка sme-review совпадают (ветки “смержены”).
- Кликаем кнопку Delete branch для удаления ветки sme-review.
Не обязательно удалять ветку сразу. Старые ветки всегда можете удалить , щелкнув ссылку на ветки при просмотре репозитория Github, а затем нажмите кнопку Delete (корзина) рядом с веткой.
Если посмотреть на список веток, то после удаления ветка sme-review больше не отображается.
Добавление участников в проект
Иногда необходимо добавлять соавторов в проект Github, чтобы они могли вносить изменения в ветку. Если другие участники проекта, не являясь соавторами, захотят внести изменения, они получат сообщение об ошибке. (Inviting collaborators to a personal repository)
Человек без прав на запись, может “форкнуть” (скопировать) репо, а не вносить изменения в ветку в том же проекте. Однако копирование проекта клонирует весь репозиторий, а не создает ветку в том же репозитории. Форк (копия) будет существовать в учетной записи пользователя GitHub. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.
Для добавления соавторов в проект:
- В репозитории проекта переходи на вкладку “Settings”.
- Нажимаем на кнопку Collaborators в левой части.
- Вводим имена пользователей Github тех, кому хотим дать доступ в области Collaborator.
- Нажимаем на кнопку Add collaborator .
Комментирование в запросе на вытягивание
После открытия запроса на вытягивание в репозитории участники совместной работы или участники группы могут комментировать сравнение файлов между двумя указанными ветвями или добавлять комментарии общего характера к проекту в целом.
About pull request comments
You can comment on a pull request’s Conversation tab to leave general comments, questions, or props. You can also suggest changes that the author of the pull request can apply directly from your comment.
You can also comment on specific files or sections of a file in a pull request’s Files changed tab in the form of individual line or file comments, or as part of a pull request review. Adding line or file comments is a great way to discuss questions about implementation or provide feedback to the author. For more information about pull request reviews, see «About pull request reviews.»
For more information on adding line or file comments to a pull request review, see «Reviewing proposed changes in a pull request.»
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.
To reply to an existing line or file comment, you’ll need to navigate to the comment on either the Conversation tab or Files changed tab and add an additional comment below it.
Tips:
- Pull request comments support the same formatting as regular comments on GitHub, such as @mentions, emoji, and references.
- You can add reactions to comments in pull requests in the Files changed tab.
Adding comments to a pull request
- Under your repository name, click
Pull requests.
Files changed.
Hover over the line of code where you’d like to add a comment, and click the blue comment icon. To add a comment on multiple lines, click and drag to select the range of lines, then click the blue comment icon.
, then edit the text within the suggestion block.
and type your comment.
Anyone watching the pull request or repository will receive a notification of your comment.
Resolving conversations
You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.
To indicate that a conversation on the Files changed tab is complete, click Resolve conversation.
The entire conversation will be collapsed and marked as resolved, making it easier to find conversations that still need to be addressed.
If the suggestion in a comment is out of your pull request’s scope, you can open a new issue that tracks the feedback and links back to the original comment. For more information, see «Creating an issue.»
Discovering and navigating conversations
You can discover and navigate to all the conversations in your pull request using the Conversations menu that’s shown at the top of the Files Changed tab.
From this view, you can see which conversations are unresolved, resolved, and outdated. This makes it easy to discover and resolve conversations.
Further reading
- «Writing on GitHub»
- «Reporting abuse or spam»
Сведения о проверках запроса на вытягивание
Проверки позволяют участникам совместной работы комментировать изменения, предложенные в запросах на включение внесенных изменений, утверждать изменения или создавать запросы на дальнейшие изменения до объединения запросов на включение внесенных изменений. Администраторы репозитория могут требовать утверждения всех запросов на вытягивание перед слиянием.
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.»
By default, in public repositories, any user can submit reviews that approve or request changes to a pull request. Organization owners and repository admins can limit who is able to give approving pull request reviews or request changes. For more information, see «Managing pull request reviews in your organization» and «Managing pull request reviews in your repository.»
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.» You can specify a subset of team members to be automatically assigned in the place of the whole team. For more information, see «Managing code review settings for your team.»
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.»
For an introduction to requesting and providing pull request reviews, see the Review pull requests GitHub Skills course.
You can schedule reminders for pull requests that need to be reviewed. For more information, see «Managing scheduled reminders for your team.»
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.
Tips:
- If a collaborator with admin , owner , or write access to the repository submits a review requesting changes, the pull request cannot be merged until the same collaborator submits another review approving the changes in the pull request.
- Repository owners and administrators can merge a pull request even if it hasn’t received an approving review, or if a reviewer who requested changes has left the organization or is unavailable.
- If both required reviews and stale review dismissal are enabled and a code-modifying commit is pushed to the branch of an approved pull request, the approval is dismissed. The pull request must be reviewed and approved again before it can be merged.
- When several open pull requests each have a head branch pointing to the same commit, you won’t be able to merge them if one or both have a pending or rejected review.
- If your repository requires approving reviews from people with write or admin permissions, then any approvals from people with these permissions are denoted with a green check mark, and approvals from people without these permissions have a gray check mark. Approvals with a gray check mark do not affect whether the pull request can be merged.
- Pull request authors cannot approve their own pull requests.
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.
Tip: You can find a pull request where you or a team you’re a member of is requested for review with the search qualifier review-requested:[USERNAME] or team-review-requested:[TEAMNAME] . For more information, see «Searching issues and pull requests.»
Resolving conversations
You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.
To indicate that a conversation on the Files changed tab is complete, click Resolve conversation.
The entire conversation will be collapsed and marked as resolved, making it easier to find conversations that still need to be addressed.
If the suggestion in a comment is out of your pull request’s scope, you can open a new issue that tracks the feedback and links back to the original comment. For more information, see «Creating an issue.»
Discovering and navigating conversations
You can discover and navigate to all the conversations in your pull request using the Conversations menu that’s shown at the top of the Files Changed tab.
From this view, you can see which conversations are unresolved, resolved, and outdated. This makes it easy to discover and resolve conversations.
Re-requesting a review
You can re-request a review, for example, after you’ve made substantial changes to your pull request. To request a fresh review from a reviewer, in the sidebar of the Conversation tab, click the
Required reviews
Repository administrators or custom roles with the «edit repository rules» permission can require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch. You can require approving reviews from people with write permissions in the repository or from a designated code owner. For more information, see «About protected branches.»
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.»
Further reading
- «Reviewing proposed changes in a pull request»
- «Viewing a pull request review»
- «Setting guidelines for repository contributors»