Пулл реквест: git pull request — как правильно с ними работать?

Содержание

Что такое пул-реквесты и зачем они нужны?

Перевод статьи «What’s the Point of Pull Requests Anyway?»

Если вы еще новичок в мире Git и тесно связанных с ним платформ (например, GitHub или GitLab), то вы могли и не слышать таких терминов, как пул-реквест (pull request) или мерж-реквест (merge request). И даже если что-то такое слышали, то можете не знать, что означают эти термины и зачем нужны эти самые «реквесты».

Примечание. В статье я буду использовать термин «пул-реквест», но по сути это то же самое, что мерж-реквест, только последний используется на GitLab.

Пул-реквесты помогают командам создавать программы и распространять их. Чтобы вникнуть в саму идею, придется немного напрячься, но я уверен, что дело того стоит. Моя цель — помочь вам познакомиться с пул-реквестами и рассказать, какое место они занимают в процессе разработки ПО.

Что такое пул-реквест?

Пул-реквест это запрос (англ. request — «запрос») на интеграцию изменений из одной ветки в другую.

Причем в ветке может быть всего один коммит одного разработчика, а может быть несколько коммитов разных авторов. В большинстве случаев пул-реквест используется для интеграции нового функционала или для исправления бага в основной ветке проекта.

Пул-реквест также содержит короткое описание изменений и причин, по которым эти изменения вносятся. Обычно между автором пул-реквеста и ревьюерами происходит обсуждение этих изменений.

Ревьюеры — это другие разработчики, работающие над этим проектом и способные дать обратную связь по вносимым изменениям. В проектах с открытым исходным кодом в роли ревьюеров обычно выступают ключевые контрибьюторы или мейнтейнеры. В других случаях (например, в вашей команде на работе) ревьюерами бывают более опытные коллеги (разработчики-сеньоры).

Вот как выглядит пул-реквест с простым описанием и ссылкой на issue (проблему) на GitHub:

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

Коммуникация

По сути пул-реквесты облегчают процесс совместной работы с другими людьми. Они позволяют сделать прозрачной коммуникацию между авторами и ревьюерами путем показа дифф-ов (diffs), коммитов (commits) и комментариев, поясняющих изменения.

До пул-реквестов изменения подтверждались по электронной почте или в IRC-каналах. Там писали название ветки или указывали набор коммитов. Чтобы смержить (слить) изменения, мейнтейнер или выпускающий разработчик должен был сравнить изменения с текущей версией кода на собственном компьютере, дать фидбэк, а потом подождать ответа с дополнительными изменениями. Согласованные изменения мержил на своей локальной машине, а затем отправлял их в общую кодовую базу. Пул-реквесты существенно упрощают весь этот процесс.

Особенно это касается крупных проектов, над которыми работают тысячи контрибьюторов. Поэтому многие из подобных проектов придерживаются именно процедуры пул-реквестов. Часто они также применяют рабочий процесс под названием «GitHub flow».

GitHub flow предполагает форки целых проектов и создание пул-реквестов в этих форках.

Поначалу все это кажется страшным и непонятным, но не волнуйтесь! Просто помните, что основная идея остается прежней: вы запрашиваете разрешение на перенос изменений из одной ветки в другую.

Еще одно преимущество процедуры пул-реквестов в том, что всем сотрудникам видна вся коммуникация по изменениям. К вашим услугам поиск по внесенным изменениям и возможность использовать теги. В общем, отслеживать происходящее относительно легко. Контекст и предыдущие решения не теряются где-то в потоках электронных писем или окнах чатов. Любой разработчик, участвующий в проекте, может легко найти и просмотреть нужные сведения.

Автоматизация

Поскольку пул-реквесты приобрели огромную популярность в сообществе разработчиков, GitHub и другие подобные платформы создали обширный набор вебхуков (webhooks), спроектированных на основе GitHub flow. Эти вебхуки делают возможной автоматизацию работы. В наши дни распространена практика, когда задачи непрерывной интеграции выполняются при каждом коммите, и поэтому являются частью пул-реквеста. По своему опыту могу судить, что это одно из самых подходящих мест для автоматизации. Речь идет не только о запуске автоматизированных тестов. Из изменений в пул-реквесте можно разворачивать целые окружения, чтобы проверить, гладко ли все прошло.

Раньше подобные инструменты интеграции были дорогими. Команде или приходилось поддерживать инфраструктуру для задач автоматизации, либо платить за сервисы. В последнее время все больше инструментов становятся доступными, а значит, настройка автоматизированных задач облегчается. Например, вы можете воспользоваться бесплатными предложениями таких компаний как Netlify и Travis.

GitHub пошел даже еще дальше и выпустил GitHub Actions. Actions позволяют вам создавать рабочие процессы автоматизации из набора отдельных маленьких задач, пригодных для компоновки. Непременно попробуйте!

Проверки статуса

Последнее большое преимущество пул-реквестов это концепция проверок статуса (status checks). Проверки статуса это просто набор задач, выполняемых для каждого коммита в пул-реквесте, и выдающих результат «успех» (success) или «провал» (failure). Это буквально чек-листы для проверки того, готовы ли изменения к отправке в кодовую базу.

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

Стоит также остановиться на теме код-ревью. Поскольку пул-реквесты сильно улучшают возможности коммуникации и сотрудничества, естественно, что многие команды применят их в код-ревью. Таким образом прямо со страницы пул-реквеста можно осуществлять менеджмент ревьюеров, ревью и статуса запросов (одобрено или нет). Во многих крупных проектах есть даже автоматическая процедура добавления отдельных пользователей или групп к пул-реквесту — в зависимости от файлов, которые были изменены. Если хотите пример, посмотрите документацию CODEOWNERS.

Итоги

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

Если раньше репозиторий был просто местом, где хранится код, то с появлением пул-реквестов он стал местом, где хранятся знания об этом коде.

Также пул-реквесты играют большую роль в процессе обучения. Некоторые из самых важных уроков, касающихся разработки программ, я получил в фидбэках терпеливых ревьюеров моих пул-реквестов.

Как открыть пулл-реквест в Github и не облажаться

Расскажу, как быстро и просто открыть пулл-реквест, на что обратить внимание, и сделать так, чтобы ваш ревьюер не расстраивался. В конце статьи есть чеклист, чтобы быстро проверять по нему.

Предполагаю, что вы уже форкнули проект, склонировали себе форк, что-то там накоммитили и готовы открыть пулл-реквест. Лучше всего читать эту статью параллельно с открыванием пулл-реквеста.

Найдите кнопку «Pull Request»

Не суетитесь и не бегайте по репозиториям, переключая ветки. Сразу, как вы запушили, на главной страничке вашего репозитория появится жёлтая плашка с названием ветки и кнопкой «Compare & pull request».

Кнопка «Compare & pull request»

Эта кнопка — самый короткий путь к открытию пулл-реквеста. Жмите её.

Проверьте ветки

После нажатия кнопки у вас откроется подробная страничка о том, откуда и куда вы открываете пулл-реквест. Посмотрите, куда вольётся ваш код. Он должен попадать в главную ветку основного репозитория. Скорее всего это ветка master. И он должен быть из вашего форка и ветки, в которой вы делали работу.

Куда и откуда попадёт код

Скорее всего так и есть, если вы правильную кнопку нажали.

Проверьте конфликты

Прямо под ветками написано, есть конфликты или нет:

Вот тут нет конфликтов

Бывает, что конфликты есть:

Хорошим тоном считается открывать пулл-реквесты без конфликтов. Поэтому если у вас конфликт, решите его до того, как откроете пулл-реквест. Можно отребейзить вашу ветку от мастера главного репозитория, или можно влить мастер главного репозитория в вашу ветку.

Если вы работаете в команде и не умеете решать конфликты, попросите старшего товарища вам помочь. А если вы студент, попросите наставника 🙂 Вы так же можете сначала открыть пулл-реквест, пусть и с конфликтами, а потом эти конфликты решить.

Напишите заголовок и описание

В форме открытия пулл-реквеста напишите заголовок: коротко что вы сделали. И описание: что конкретно и зачем, а что ещё не доделано.

Проверьте изменённые файлы

Ниже формы с описанием пулл-реквеста есть difference — разница»>дифф — это то, что изменилось: новые файлы, удалённые файлы, изменённые строки в файлах.

Изменённые файлы (дифф)

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

На скриншоте выше файл npm-debug.log.1955635711 очевидно лишний. Значит нужно его удалить и закоммитить это, и снова запушить в эту ветку. Если вы нашли ошибку, то просто исправьте её, закоммитьте и запушьте. Потом обновите страничку с диффом и убедитесь, что всё в порядке.

Теперь жмите «Create pull request»! Ура!

Как открыть пулл-реквест:

После пуша зайдите в свой репозиторий и нажмите кнопку «Compare & pull request» на жёлтой плашке.
Проверьте, что открываете пулл-реквест из своей ветки в мастер главного репозитория.
Проверьте, нет ли конфликтов. Если есть, исправьте их.
Напишите заголовок и описание.
Проверьте, что в диффе нет ничего лишнего. Если что-то лишнее попало, уберите это.
Откройте пулл-реквест 🙂

Как оформить описание к Pull Request | Mad Devs Blog

Теперь рассмотрим как следует подобрать описание для PR, чтобы сделать его полезным.

Заголовок

Начать следует с заголовка — он должен отражать суть изменений. Если есть соответствующая задача или тикет, то заголовок PR может с ними перекликаться. В таком случае следует добавить к заголовку префикс с номером задачи. Примеры:

SLI-001, SLI-002 - Support for reading input from STDINSLI-002 - Bugfix for memory leak when input is supplied via STDIN

Заголовок предпочтительно делать содержательным и достаточно коротким.

Связанные задачи

Следует указать задачи, которые решает или к которым относится ваш PR. Лучше делать это в виде маркированного списка со ссылками на тикеты в трекере. В MarkDown это может выглядеть примерно так:

## Related tasks- [SLI-001](http://my. issue.tracker/project/SLI-001)
- [SLI-002](http://my.issue.tracker/project/SLI-002)

Такой подход значительно упростит навигацию, позволяя найти все задачи и связанные обсуждения без особых усилий. Для задач, которые ведутся в GitHub и GitLab, есть специальные формулировки, которые позволяют закрыть их при слиянии PR — ими следует воспользоваться (смотреть здесь для GH и здесь для GL).

Зависимость от других Pull Request

Если ваш PR основывается на других открытых PR, которые должны быть предварительно рассмотрены, то их следует перечислить. Это касается и PR для используемых пакетов и зависимостей. Пример в MarkDown:

## Depends on- #3             (другой открытый PR)
- dependency#55  (открытый PR в пакете или зависимости)

Это позволит оптимизировать процесс рассмотрения PR и сэкономить время ревьюерам. Если ваш PR ни от чего не зависит, секцию следует пропустить.

Предпосылки

Эта секция может быть посвящена тому, что предшествовало вносимым изменениям. Перечень того, что следует изложить приведён ниже.

Если вы делали выбор между возможными пакетами и выбирали более подходящий, то стоит привести ссылки на каждый пакет, затем описать его плюсы и минусы при решении задачи. Следует также изложить итоговую причину, по которой вы выбрали один из них для ввода в проект.
Если вы исследовали какую-то тему и искали наиболее подходящие пути решения задачи, то стоит привести ссылки на статьи, которые помогают в исследовании темы. Также можно описать ключевые тезисы, которые способствуют пониманию последующих изменений.
Если вы обнаружили, что вам мешает какой-то существующий код, то следует изложить ваши доводы. Если какая-то функция плохо оптимизирована или плохо реализована, и вам придётся её рефакторить, точно стоит упомянуть почему вы решили её затронуть более, чем ожидалось ранее.
Краткие итоги обсуждений с командой, которые позволят понять, почему приняты те или иные решения.

Пример может выглядеть так:

## PremiseAs we have grammar description and access to an assembly code even from AST, I considered to use PEG-based parser to generate custom AST from assembly code, then use adapter to make it compatible with current ASTReader processing logic.  As prerequisites I’ve looked through the following packages:- https://github.com/navstev0/nodebnf (npm) — I tried and in the end came to the conclusion, that it is not so stable to be used for our needs. Also, lacks proper documentation.
- https://github.com/lys-lang/node-ebnf (npm) — Has proper documentation and TypeScript definitions. Also, has a useful online sandbox. Chosen for the further implementation.

Эта секция служит для общих случаев, когда есть необходимость в рамках разумного изложить любые сведения, которые следует знать до того, как ревьюер (или любой другой коллега) приступит к изучению изменений с вашими правками. Если же такой необходимости нет, то секцию следует пропустить.

Изменения

В секции следует списком перечислить вносимые изменения. Если вы до этого подробно описывали вносимые изменения в сообщениях коммитов, то можно взять текст из них. Если вы считаете, что какие-то сообщения требуют дополнительного пояснения, то вы можете указать важные сведения в виде подпунктов.

## Changes- Added dependency [ebnf](https://www.npmjs.com/package/ebnf).
- Cleaned **package.json** from some obsolete commands. Introduced `ebnf:update` to copy BNF-files when post-install occurs.
- Introduced **src/ebnf** directory with components to parse code strings by BNF definitions.
- Tweaked configuration to be able to work with a new set of components.
- Introduced tests to cover new functionality.

Чем следует руководствоваться при формулировании содержимого секции? Подробный список приведен ниже.

Часть изменений доступна при просмотре изменений в файлах. Поэтому не стоит “микрить” — GIT это сделает за вас. Лучше обобщить изменения, изложив их смысл. Например:

- Обновлены версии зависимостей, потому что они сильно устарели и аудит показывал, что там есть уязвимости.
- Удалены файлы в каталоге X, потому как работавший с ними компонент был заменен на другой. Они оказались более не нужны.
- Внесены изменения в метод, потому что низкоуровневый API изменился.  Из-за этого метод больше не работал.

При обосновании действий, связанных с зависимостями, не стесняйтесь использовать ссылки на релизы, слияния багфиксов или фич — это очень полезно в будущем.
Если вводите новый класс, функцию, метод или другую рутину, то лучше описать ее предназначение (а еще лучше сделать это в док-блоке перед ее заголовком).
Старайтесь уделять чуть больше внимания именно тем действиям, которые невозможно прокомментировать в файлах с исходным кодом: перемещение файлов, удаление, программное изменение (те же настройки зависимостей, к примеру).

Отдельно стоит обратить внимание на пару возможностей:

Подумайте над использованием опции “task lists”, которая доступна в GitHub и GitLab. Пункты изменения таким образом можно сделать интерактивными.
Для наглядности не стесняйтесь ссылаться на сегменты кода, который имеете в виду. Как это делается, можете прочитать здесь для GitHub (для GitLab не нашел инструкции, буду рад, если кто-то поделится).

Проблемы

Если вы в чем-то сомневаетесь или замечаете противоречия, то лучше изложить их в этой секции. Не стесняйтесь изложить моменты, в которых вам бы не помешал совет от коллег. Вот краткий список моментов, которые могут стать поводом для упоминания:

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

Вот возможный пример в MarkDown:

## ConcernsIt appears that the compiler is trimming spaces and reducing indentation within assembly code strings in `Assembly` AST node.  This causes inability to generate proper `src` attributes for custom AST by simple math. Also, this is not fixable, because these dependencies are already released and can not be patched. Need to find another way to link `AssemblyIdentifier` to a top-level `VariableDeclaration` node. Currently, any `AssemblyItem` node will have the same `src` as parent `Assembly` node. Maybe I'm missing something... I would appreciate any suggestions that will help in solving the situation.

Если вы не обнаруживаете проблем, то не следует тратить время на данную секцию.

Примечания

Эта секция служит для перечисления моментов, которые не столь очевидны. Например, ввели новую команду сборки, которая производит копирование файлов, либо использовали какой-то функционал c “волшебными цифрами”. Лучше упомяните об этом заранее, потому что об этом всё равно спросят рано или поздно. Вот примеры:

## Notes- This PR changes major package API, which would result in a backward compatibility (BC) break. 
- When changes applied to grammar files, developer must run `npm run ebnf:update` to copy updated grammar files to **dist/**. Otherwise, components will not react to any changes. All grammar files are static assets, so they are not compiled or handled by **tsc** in any way.
- For some reason `process.stdin.fd` is not available in type definitions for the current node version. It seems that we should upgrade at some point. I resolved this via magic `fse.readFileSync(0, { encoding: "utf8" })` (as `0` should point to `STDIN` for each process) and left a comment with the reasoning.

pull request — Russian translation – Linguee

If such a

[…] system sends out a request for data (e.g. using spatial-temporal-parameter query) and collects together data from different databases, and then pulls all collected […]

data together, it would

..]

presently result in many different names for the same parameter.

unesdoc.unesco.org

Если такая система пошлет запрос о данных (например, с использованием вопросника, касающегося пространственно-временных аспектов и параметров измерений) и станет […]

собирать сведения из различных

[…]

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

unesdoc.unesco.org

The aim was to define new lines of emphasis, methods and strategies to promote the development of Africa in the twenty-first century in order to help the continent to pull out of the worrying situation in which it finds itself and thus enable it to hold a position and play a role that are consistent with its ambitions, particularly within the framework established by NEPAD (The New Partnership for Africa’s Development).

unesdoc.unesco.org

Этот семинар имел целью определить направления, методы и новые стратегии, способные содействовать развитию Африки в XXI веке, с тем чтобы помочь этому континенту выйти из тяжелого положения, в котором он находится, и таким образом дать ему возможность занять такое место и играть такую роль, которые соответствовали бы его устремлениям, в частности путем реализации приоритетов, установленных НЕПАД (Новое партнерство в интересах развития Африки).

unesdoc.unesco.org

Where the circumstances suggest that a request for interim measures may be reviewed before the consideration of the merits, a standard formulation is added to the request, stating that the request is made on the basis of the information contained in the complainant’s submission and may be reviewed, at the initiative […]

of the State party, in the light of information

[…]

and comments received from the State party and any further comments, if any, from the complainant.

daccess-ods.un.org

Когда обстоятельства позволяют предположить, что просьба о применении временных мер может быть изучена до рассмотрения существа жалобы, к такой просьбе следует добавлять стандартную фразу о том, что эта просьба формулируется на основе информации, содержащейся в представлении жалобщика, и что она может быть изучена […]

по инициативе государства-участника в свете

[…]

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

daccess-ods.un.org

The expert meeting will pull together the findings of the three previous meetings to draw the lessons that can be derived from making investment contribute to development from the policy perspective, and the special role of public–private partnerships.

daccess-ods.un.org

Совещание экспертов подытожит результаты работы предыдущих трех сессий в целях извлечения уроков из усилий, призванных обеспечить вклад инвестиций в процесс развития, с точки зрения политики и особой роли партнерства между государственным и частным секторами.

daccess-ods.un.org

Guyana recognizes that human trafficking is a complex transnational

[…]

problem with its roots in gender inequality,

[…] social-economic factors, push/pull migration factors and […]

criminal activity.

daccess-ods.un.org

Гайана признает, что торговля людьми является сложной транснациональной проблемой, корни

[…]

которой уходят в гендерное неравенство,

[…] социальноэкономические факторы, челночную миграцию […]

и криминальную деятельность.

daccess-ods.un.org

At the request of non-OECD countries participating […]

in the PISA project, training was provided on data analysis for the preparation of national reports.

unesdoc.unesco.org

По просьбе стран-участниц ПМОУУ, не являющихся […]

членами ОЭСР, Институт организовал обучение анализу данных для подготовки

[…]

национальных докладов.

unesdoc.unesco.org

Most involves hitting (“smacking”, “slapping”, “spanking”) children, with the hand or with an implement – a whip, stick, belt, shoe, wooden spoon, etc. But it can also involve, for example, kicking,

[…]

shaking or throwing children,

[…] scratching, pinching, biting, pulling hair or boxing ears, caning, […]

forcing children to stay in

[…]

uncomfortable positions, burning, scalding, or forced ingestion.

daccess-ods.un.org

В большинстве случаев речь идет о нанесении детям ударов («порка», «отшлепывание», «трепка») рукой или каким-либо предметом (кнутом, палкой, ремнем, туфлей, деревянной ложкой и т.д.). Но это также может предполагать пинки,

[…]

встряхивание или бросание детей

[…] на землю, царапание, щипание, кусание, таскание за волосы […]

или оплеухи, принуждение детей

[…]

находиться в неудобном положении, обжигание, ошпаривание или принудительное заглатывание.

daccess-ods.un.org

In response to a request for further elaboration […]

of the linkages among the Clean Development Mechanism, climate change and

[…]

human rights, Mr. Orellana pointed to the OHCHR analytical study on human rights and climate change (A/HRC/10/61), which contained an analysis of the human rights implications of mitigation and adaptation measures taken within the context of climate change, and stressed the importance of considering human rights concerns therein.

daccess-ods.un.org

В ответ на просьбу разъяснить взаимосвязь […]

между Механизмом чистого развития, изменением климата и правами человека, г-н

[…]

Орельяна сослался на проведенное УВКПЧ аналитическое исследование по вопросу о правах человека и изменений климата (A/HRC/10/61), в котором дается анализ правозащитных последствий принятия мер по предотвращению изменения климата и адаптации в контексте изменения климата, и особо отметил важное значение учета соображений, связанных с правами человека.

daccess-ods.un.org

Like in the case with baron Munchausen, when he pulled himself out with the help of his own hair, we had to identify the most important directions, which would help to pull us out to a caravan of regions, interesting for the Federal Government, Russia as a whole and other developed world countries.

ulregion.com

Нам надо было определить наиболее важные направления, которые могут помочь нам вытащить себя, как барон Мюнхгаузен, за волосы в череду регионов, которые будут интересны федеральному правительству, России в целом, другим развитым странам мира.

ulregion.com

On installations with rope pull upwards a protection […]

must be installed to prevent foreign bodies to entering between rope and traction sheave.

ziehl-abegg.com

При выпуске троса вверх заказчиком должна […]

быть установлена защита от попадания посторонних предметов между тросом и рабочим шкивом.

ziehl-abegg.com

The Committee is aware that a number of States parties have expressed concern that interim measures of protection have been requested in too large a number of cases alleging violations of article 3 of the Convention, especially where the complainant’s deportation is alleged to be imminent, and that there are insufficient factual elements to warrant a request for interim measures.

daccess-ods.un.org

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

daccess-ods.un.org

Many Member States made great efforts to pay their outstanding

[…] arrears so as to avoid the need to request voting rights at the General […]

Conference.

unesdoc.unesco.org

Многие государства-члены предприняли значительные усилия для выплаты

[…]

своей задолженности по

[…] взносам, с тем чтобы избежать необходимости просить о предоставлении […]

права голоса на Генеральной конференции.

unesdoc.unesco.org

Even though quite a few member states

[…]

encountered difficulties to

[…] supply all data requested, the main tenor was that the structure provided helpful guidance pulling together scattered […]

information on

[…]

wood energy at national level.

daccess-ods.un.org

Хотя с трудностями при представлении всех запрошенных данных столкнулись многие государства-члены, важно то, что […]

новая структура способствовала сведению

[…]

воедино имеющейся на национальном уровне разрозненной информации об энергии на базе древесины.

daccess-ods.un.org

Circular letters, together with all texts adopted so far in this respect, served as a reminder and clear reference for all forms of action that the

[…]

Organization is taking towards enhancing the operational capacities of

[…] National Commissions, as requested by its governing bodies.

unesdoc.unesco.org

Циркулярные письма наряду со всеми утвержденными ранее документами в этой области служили напоминаниями и четкими ориентирами для всех видов деятельности, которую Организация

[…]

проводит в целях расширения

[…] оперативных возможностей национальных комиссий, как это требовали […]

руководящие органы ЮНЕСКО.

unesdoc.unesco.org

Greater attention should

[…] moreover be paid to the numerous requests of national NGOs wishing […]

to work more actively with UNESCO

[…]

by strengthening their links with the National Commissions and the national branches of international NGOs maintaining formal relations with the Organization.

unesdoc.unesco.org

Кроме того, следовало бы уделять более

[…] пристальное внимание многочисленным запросам, поступающим от национальных […]

НПО, которые желают более активно

[…]

сотрудничать с ЮНЕСКО путем укрепления их связей с национальными комиссиями и национальными подразделениями международных НПО, имеющими официальные отношения с Организацией.

unesdoc.unesco.org

As the FOC could be pulled through at a later stage, […]

this method can be used all year round.

sakhalin-2.ru

Так как ВОК может протягиваться на более позднем […]

этапе, этот метод можно применять круглогодично.

sakhalin-2.ru

With respect to the missing molars, it can only be said of one of them that its absence is consistent with the alleged torture/assault, as the other molar was pulled by a dentist.

daccess-ods.un.org

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

daccess-ods.un.org

That presented the SRS team with a tough challenge, because platters are not designed to be pulled apart easily and then put back together.

seagate.com

Задача команды SRS была чрезвычайно сложна, ведь пластины невозможно легко разделить, а затем сложить вместе.

seagate.com

Beginning with orbital mechanics, Mr. del

[…]

Monte explained that any object in space near the Earth must keep moving

[…] to avoid being pulled down by the Earth’s […]

gravity.

daccess-ods.un.org

Начав с орбитальной механики, г-н дель Монте разъяснил, что

[…]

любой объект в космосе вблизи Земли должен

[…] продолжать движение во избежание стягивания […]

вниз под воздействием земного тяготения.

daccess-ods.un.org

In the latter case, the family had been told that

[…] another detainee had pulled out the camera cables.

daccess-ods.un.org

В последнем случае родственникам

[…] сообщили, что провода камеры выдернул другой заключенный.

daccess-ods.un.org

He then pulled open Mr. Zeynalov’s […]

shirt and struck on the left side of his chest several times with the knife, and then

[…]

he gave the knife to Mr. Genashilkin who struck Mr. Zeynalov’s stomach twice.

daccess-ods.un.org

Затем он разорвал рубашку г-на […]

Зейналова и несколько раз ударил его ножом в грудь, а затем передал нож г-ну Генашилкину,

[…]

которые дважды ударил г−на Зейналова ножом в живот.

daccess-ods.un.org

Danger from

[…] catching, entanglement, pulling in or entrapment […]

during machine operation due to accessible powered elements of the machine.

et.amazone.de

Опасности захватывания, наматывания, затягивания или улавливания незащищенными

[…] работающими элементами агрегата во время его эксплуатации!

et.amazone.de

During its thirty-fourth session, the Committee, through its Rapporteur for follow-up of decisions on complaints, decided that in cases in which it had found violations of the Convention, including decisions made by the Committee prior to the establishment

[…]

of the follow-up procedure, the

[…] States parties should be requested to provide information […]

on all measures taken by them to

[…]

implement the Committee’s recommendations made in the decisions.

daccess-ods.un.org

На своей тридцать четвертой сессии Комитет по предложению Докладчика по последующим действиям в отношении жалоб постановил, что в случаях установления Комитетом фактов нарушения Конвенции, включая решения, вынесенные Комитетом до учреждения

[…]

процедуры последующих действий,

[…] государствам-участникам следует направлять запрос о представлении […]

информации обо всех мерах,

[…]

принятых ими в целях выполнения рекомендаций, содержащих ся в принятых Комитетом решениях.

daccess-ods.un.org

It considered that the letter neither contained entirely

[…] new facts on which the requests were based and such as […]

to have caused the Working Group

[…]

to alter its decision had it been aware of them (paragraph 21 (a) of the methods of work), nor that facts had not been known or had not been accessible to the Government (paragraph 21 (b) of the methods of work).

daccess-ods.un.org

Она считала, что письмо не

[…]

содержит полностью новых фактов, на

[…] которых основывается просьба, и они не имеют такой характер, […]

чтобы убедить Рабочую группу

[…]

изменить свое решение, если бы ей было известно об этом (пункт 21 a) методов работы) или что такие факты не были известны правительству или оно не имело к ним доступа (пункт 21 b) методов работы).

daccess-ods.un.org

However, foreign ownership generally proved to be a stabilizing force as none pulled out of the region entirely and the only one that failed was Parex Bank in Latvia.

daccess-ods.un.org

Однако иностранное участие в целом оказало стабилизирующее влияние, так как никто полностью не ушел из региона, и единственным разорившимся банком стал латвийский «Парекс Банк».

daccess-ods.un.org

Satellites close to the Earth are affected by atmospheric drag which

[…] slows them down and eventually pulls them back to Earth.

daccess-ods.un.org

На спутниках вблизи Земли сказывается атмосферное сопротивление,

[…] которое замедляет их и в конечном счете тянет их обратно […]

на Землю.

daccess-ods.un.org

To the extent possible, such components should be made independent to prevent the project from

[…] falling apart if a single organisation pulls out.

crisisgroup.org

Такие компоненты должны быть

[…]

самостоятельными, в пределах возможного, чтобы весь проект не

[…] распался, в случае если одна организация прекратит […]

в нем участвовать.

crisisgroup.org

ADAZ was equipped with in-line 6-cylinder engine rated at 150 hp. with two carburetors and unusual for the military equipment of that time semi-automatic three-way

[…]

hydraulic transmission Foit, as well as a torque converter oil

[…] cooler, hydraulic brakes and a winch with a pulling force of 10 ton/force.

trucksplanet.com

ADAZ оборудовался рядным 6–цилиндровым двигателем мощностью 150 л. с. с двумя карбюраторами и необычной для военной техники того времени полуавтоматической 3–позиционной

[…]

гидромеханической коробкой передач Foit, а также

[…] охладителем масла гидротрансформатора, гидравлической тормозной системой и лебедкой […]

с тяговым усилием 10 тс.

trucksplanet.com

This conduit will generally be strapped to the oil pipeline and the fibre optic

[…] cable will later be pulled through the conduit.

sakhalin-2.ru

Такие кабелепроводы обычно крепятся

[…] хомутами к нефтепроводу, а кабель позднее протягивается […]

через кабелепровод.

sakhalin-2.ru

guides/how-to-pull-request.md at master · urfu-2015/guides · GitHub

Регистрация на GitHub

Если у вас нет аккаунта на Github – регистрируемся по ссылке http://github.com/join

Если есть – просто входим по ссылке http://github.com/login

Как сделать pull request прямо на GitHub

Шаг 1. Заходим в основной репозиторий задачи https://github.com/urfu-2015/verstka-tasks-1
И делаем форк задачи к себе. Для этого жмём «fork» в правом верхнем углу.

Форк (fork) можно расматривать, как личную копию основного репозитория.

Шаг 2. Заходим к себе https://github.com/gogoleff/verstka-tasks-1. Вместо gogoleff свой логин.

Шаг 3. Нажимаем на файл, который хотим изменить. Затем кнопку редактирования.

Шаг 4. Редактируем файл до готовности прямо здесь (или вставляем код из любимого редактора)

Шаг 5. Когда всё готов создадим коммит.
Для этого внизу в поле «summary» вводим поясняющий текст, и нажимаем «Commit changes».

Коммит (commit) – можно рассматривать, как утверждение кода, создание версии (как в wiki). К каждой версии можно вернуться. Каждый новый коммит – новая версия вашего кода.

Шаг 6. Создаём pull request. Для этого выбираем пункт меню справа «Pull requests».
И нажимаем кнопку «New pull request».

Пулл (pull request) — сравнение ветки в личном репозитории с кодом основного. Так мы увидим изменения, которые вы сделали. Обычно пулл затем вливают в основной репозиотрий, но мы этого делать не будем 🙂

Шаг 7. Нажимаем кнопку «Create pull request»

Шаг 8. Вводим своё ФИО и нажимаем кнопку «Create pull request»

Готово!

Если нужны правки, просто повторяем шаги со 2 по 5.

Как сделать pull request в windows

Форк (fork) можно расматривать, как личную копию основного репозитория.

Шаг 2. Затем скачивание приложение по ссылке https://desktop.github.com/

Шаг 3. Устанавливаем. После установки приложение попросит настроить его. Вводим логин и пароль.

Шаг 4. Затем полное имя и электронную почту (обычно уже верно заполнены).

Шаг 5. После настройки вы попадёте в приложение. Теперь клонируем репозиторий с задачей.
Для этого нажимаем «+» в левом верхнем углу, выбираем свой логин слева, и репозиторий verstka-tasks-1 справа.

Клон (clone) можно расматривать, как локальную копию личного репозитория.

Шаг 6. Выбираем рабочую директорию (обычно уже подходящая).

Шаг 7. Теперь заходим в директорию (там должны быть файлы index.html и README.md).

Шаг 9. Решаем задачу, редактируем файлы в любимом редакторе до полной готовности. В приложении видим изменения.

Шаг 10. Когда всё готов создадим коммит.
Для этого внизу в поле «summary» вводим поясняющий текст, и нажимаем «Commit to master».

Коммит (commit) – можно рассматривать, как утверждение кода, создание версии (как в wiki). К каждой версии можно вернуться. Каждый новый коммит – новая версия вашего кода.

В результате видим сообщение:

Шаг 11. Таким образом мы утвердили наши изменения в локальном (склонированном) репозитории. Теперь необходимо отправить ветку с изменениями в удалённый личный (форк) на github.com и сделать pull request. В качестве название пулл-реквеста вводим своё ФИО и нажимаем «Send Pull Request».

Пулл (pull request) — сравнение ветки в личном репозитории с кодом основного. Так мы увидим изменения, которые вы сделали. Обычно пулл затем вливают в основной репозиотрий, но мы этого делать не будем 🙂

В результате видим сообщение:

Готово!

Если нужны правки, повторяем шаги 9 и 10. Затем нажимаем «Sync» в правом верхнем углу. Приложение отправит коммит в удалённый личный репозиторий (форк), что автоматически обновит pull request.

Как сделать pull request в windows, используя Git Shell

Здесь два варианта:

Устанавливаем Git Bash https://git-scm.com/download/
После установки, запускаем Git Bash
(ярлык для запуска можно найти в меню Пуск).
Устанавливаем вместе с приложением Git Shell.
Для этого выполняем шаги со 2 по 4 раздела Как сделать pull request в windows
После установки приложения, запускаем Git Shell
(ярлык для запуска можно найти на рабочем столе).

Далее смотрим shell команды в разделе как сделать pull request в linux.

Как сделать pull request в linux

Заходим в основной репозиторий задачи https://github.com/urfu-2015/verstka-tasks-1
И делаем форк задачи к себе. Для этого жмём «fork» в правом верхнем углу.

В linux уже установлен git и обычно настроен.

Шаг 1. Выполняем следующие команды в терминале:

# Клонируем репозиторий (вместо gogoleff – ваш логин)
git clone https://github.com/gogoleff/verstka-tasks-1.git verstka-tasks-1

# Заходим в созданную папку с клоном
cd verstka-tasks-1

# Решаем задачу в любимом редакторе...

# Добавляем все изменённые файлы через пробел
git add index.html

# Коммитим (утверждаем изменения)
git commit -m "Моё решение задачи"

# Отправляем ветку с коммитом в удалённый личный (origin) репозиторий
# (может попросить ввод логина и пароля)
git push origin master

Шаг 2. Заходим в к себе в репозиторий.

Шаг 3. Создаём pull request. Для этого выбираем пункт меню справа «Pull requests».
И нажимаем кнопку «New pull request».

Пулл (pull request) — сравнение ветки в личном репозитории с кодом основного. Так мы увидим изменения, которые вы сделали. Обычно пулл затем вливают в основной репозиотрий, но мы этого делать не будем 🙂

Шаг 4. Нажимаем кнопку «Create pull request»

Шаг 5. Вводим своё ФИО и нажимаем кнопку «Create pull request»

Готово!

Если нужны правки. Вносим их в любимом редакторе, и снова делаем коммит.

# Добавляем все изменённые файлы через пробел
git add index.html

# Коммитим
git commit -m "Мои исправления"

# Отправляем новый коммит в удалённый репозиторий
git push

Полезные ссылки

Можно самостоятельно пройти курс по основам Git на GitHowTo

Что такое Pull Request Preview и с чем его едят

Работа над крупным проектом – это всегда командная работа. И в этой команде каждый программист занимается реализацией отдельной задачи, работая в своей функциональной ветке GitHub, GitLab, Bitbucket или любого другого репозитория.

После того как разработчик решит задачу, необходимо выполнить слияние результатов с основной веткой проекта для того, чтобы другие участники команды могли использовать разработанные им функции. Содержимое основной ветки собирается и доставляется в production, став достоянием коллег из других отделов или заказчиков.

Но это если не брать в расчет такой этап работы, как Pull Request…

Что такое Pull Request и зачем он нужен?

Как я уже отметил выше, каждый программист в команде занимается разработкой в своей функциональной ветке. Она не затрагивает главную ветку, поэтому изменения, внесенные в код конкретным разработчиком, не появляются в приложении автоматически.

Когда разработчик заканчивает работу над функцией или исправлением бага, он должен уведомить об этом других членов команды, чтобы те провели аудит кода.

По сути, такое уведомление – это и есть пул-реквест. То есть запрос на слияние написанного разработчиком кода с основной веткой для дальнейшей публикации.

Но пул-реквест – это не просто оповещение. Это целая платформа для обсуждения и дальнейшей доработки кода другими членами команды. При каждом пул-запросе формируется отдельная страница, где коллеги разработчика могут оставить комментарии или внести дополнительные изменения в его код.

Если другие разработчики заметят в коде ошибки, то смогут исправить их или предложить более элегантные варианты реализации ожидаемой функции. Если же все в порядке, то код из ветки разработки объединяют с основной (совершают так называемый мердж), а потом публикуют его (эту процедуру называют деплоем), и он попадает непосредственно в приложение. Но не факт, что все будет в порядке…

Почему одного пул-реквеста недостаточно?

Разработчикам приходится создавать отдельные структурные элементы продукта, минимально коммуницируя с другими сотрудниками команды. Да, за качеством кода следят программисты, и они действительно могут обнаружить логические ошибки во внедряемой функции или проконтролировать корректность оформления и структурированность кода.

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

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

В итоге это сильно усложняет процесс разработки в целом, потому что далеко не всегда тот код, что успешно прошел проверку на этапе пул-реквеста, становится тем кодом, который нравится заказчику и другим участникам команды.

И тогда программистам приходится начинать сначала или радикально менять написанный код. Из-за этого увеличивается срок сдачи проекта и затраты, а также нарастает необходимость в возможности проверить Pull Request не только отделом разработки.

На помощь приходит Pull Request Preview

У маркетологов, менеджеров, заказчиков и прочих членов команды, не связанных с разработкой, появилась возможность взглянуть на новые функции или изменения в коде до их внедрения в продукт.

Функция Pull Request Preview – это как деплой, но только в закрытое (временное) окружение, а не в production. Вы можете в полной мере оценить все обновления, что предлагают программисты, не зная кода. Попользоваться ими, проверить на практике или попробовать сломать. И все это – до объединения ветки разработки с основной веткой, то есть без угрозы для действующего продукта.

Такую функцию предлагает Hostman – хостинг для упрощенной публикации сайтов, приложений, баз данных и других продуктов прямо из GitHub или GitLab.

Принцип работы Pull Request Preview в Hostman

Хостинг-провайдер Hostman, партнер Timeweb, недавно запустил функцию Pull Request Preview для своих пользователей. И она позволяет без лишних движений проводить основательное тестирование внедряемых функций всей командой еще до деплоя.

Pull Request Preview в Hostman

Почему я делаю акцент на «без лишних движений»? Потому что все происходит в автоматическом режиме:

Программист делает Pull Request удобным для него способом.
Предлагаемый разработчиком код тут же публикуется на серверах Hostman. Причем на полноценный временный домен с бесплатным SSL-сертификатом и полным набором инструментов, необходимых для полноценного тестирования.
Вебмастер, заведующий сервером, получает временную ссылку, пройдя по которой можно увидеть разрабатываемый проект с уже внедренным кодом из Pull Request. Здесь все будет выглядеть и работать так, будто команда программистов сделала деплой и внедрила все изменения в основную ветку проекта.
После этого, независимо от того, сделали разработчики мердж или отправили код на доработку, временная ссылка самоустраняется.

Как работает Pull Request

Как работает Pull Request Preview

Рабочий процесс никак не затрагивает программистов. Они действуют по той же схеме, что и раньше, а другие сотрудники получают новые возможности:

Тестировщики могут взаимодействовать с кодом в реальном времени, видя все изменения, что вносит разработчик, и отлавливая баги в тот же момент без задержек. А как только найденные ошибки поправят, они могут приступать к повторному тестированию.
Дизайнеры в одно время с тестировщиками и другими разработчиками могут проверить свою зону ответственности, предлагая правки визуальной составляющей продукта еще на стадии работы с пул-реквестом, а не после деплоя, как это было раньше.
Заказчик приложения может вместе с его создателями отслеживать каждый этап разработки, предлагая изменения и дополнения еще до деплоя.

Вместо заключения

Возможность до мерджа всем штатом сотрудников опробовать продукт, найти в нем ошибки и принять решение о дальнейшем внедрении – отличное подспорье для бизнеса.

Pull Request Preview позволит ускорить процесс разработки, сократит количество времени, которое уходит на тестирование продукта, что повлечет за собой сокращение потраченных на разработку человеко-часов и бюджета компании. В итоге это позволит реализовывать даже самые смелые задумки (новые функции, масштабную смену дизайна) в короткие сроки и поможет «обогнать конкурентов на поворотах». Там, где другие компании находятся в невыгодном положении, тратя много времени на работу с каждым пул-реквестом, бизнес, использующий Pull Request Review, сможет быстрее принимать решения и идти в ногу с потребностями рынка.

Впрочем, оценить все прелести Pull Request Preview можно самостоятельно. Hostman предлагает новым клиентам бесплатно создать до трех статических сайтов, подключить GitHub и попробовать Pull Request Preview, чтобы на практике увидеть, как работает эта функция и как сильно она может помочь вашему бизнесу.

Jenkins: Github Pull-Request Builder плагин

Плагин Pull-Request Builder предназначен для запуска билдов, когда в Github репозитории создаётся новый pool request, что бы выполнить сборку до того, как PR будет добавлен в основную ветку.

Результат билда будет добавлен комментарием к этому реквесту, после чего можно принимать решение — принимать реквест, или нет.

Установка Jenkins и плагина

Устанавливаем Docker:

root@ip-172-31-10-151:/home/admin# curl https://get.docker.com/ | bash

Запускаем Jenkins в Docker:

root@ip-172-31-10-151:/home/admin# docker run -d -ti -p 8080:8080 jenkins/jenkins:lts

Тут просто быстрый запуск, более полные примеры есть тут>>> и тут>>>.

Заходим на страницу Jenkins, проводим обычную первоначальную установку, переходим в Plugins, устанавливаем Pull Request Builder:

Github user и API-токен

Для работы плагина требуется API токен. В случае использования organizations в Github — лучше создать отдельного пользователя в Github, у которого будут права owner на репозиторий, и создать ему токен.

В этом примере делается на обычном Github аккаунте, потому делаем API-токен для своего пользователя.

Переходим в https://github.com/settings/tokens, добавляем токен с правами repo и admin:repo_hook:

Сохраняем токен, т.к. больше его не увидим.

Переходим в Manage Jenkins > Configure System, в блоке GitHub Pull Request Builder настраиваем данные доступа, добавляем токен в Credentials, тип Secret text:

Оставляем Auto-manage webhooks, по желанию добавляем Use comments to report results when updating commit status fails и Use comments to report intermediate phases:

Тут же можно сразу протестировать токен и доступы:

Добавление билда

Создаём новую джобу:

В General добавляем GitHub project, в Build Triggers включаем GitHub Pull Request Builder, и в GitHub API credentials выбираем данные доступа — токен, который добавили ранее в настройках:

В Admin list добавляем пользователя, комментарии которого всегда билдить (если пользователя, который добавит комментарий в PR или создаст PR в Admins list нет — плагин создаст комментарий с просьбой заапрувить билд, см. документацию тут>>>).

Отмечаем Use github hooks for build triggering, что бы выполнять запуск, используя webhook Github-а, в PipelineScript описываем действия.

Плагин задаёт несколько полезных переменных:

ghprbActualCommit
ghprbActualCommitAuthor
ghprbActualCommitAuthorEmail
ghprbPullDescription
ghprbPullId
ghprbPullLink
ghprbPullTitle
ghprbSourceBranch
ghprbTargetBranch
ghprbCommentBody
sha1

Которые можно использовать в билдах.

Например — можно создать такой скрипт:

println("Building from branch ${ghprbSourceBranch}")

Сохраняем джобу, и в Settings репозитория должен появится созданный плагином webhook:

Создание Github PR

Клонируем репозиторий:

git clone [email protected]:setevoy2/tests.git

Создаём бранч:

cd tests/

git checkout -b pr-test

Switched to a new branch ‘pr-test’

Делаем изменения:

Коммитим, пушим:

git add test.file && git commit -m «testing PR» && git push -u origin pr-test

Создаём PR:

Github выполняет webhook к Jenkins-у:

Первый был создан после создания джобы в Jenkins, далее, после каждого комментария/нового PR — создаётся новый webhook, который триггерит билд.

Билд прошёл:

Лог Jenkins-а:

Результат добавляется в PR:

По ссылке Details можно перейти к билду в Jenkins.

Готово.

О запросах на вытягивание — GitHub Docs

Pull-запросы позволяют вам сообщать другим об изменениях, которые вы отправили в ветку репозитория на GitHub. После открытия запроса на вытягивание вы можете обсудить и просмотреть потенциальные изменения с соавторами и добавить последующие коммиты до того, как ваши изменения будут объединены в базовую ветку.

О запросах на вытягивание

Примечание: При работе с запросами на вытягивание помните следующее:

Если вы работаете в модели общего репозитория, мы рекомендуем использовать тематическую ветку для запроса на вытягивание.Хотя вы можете отправлять запросы на вытягивание из любой ветки или фиксации, с помощью тематической ветки вы можете отправлять последующие фиксации, если вам нужно обновить предлагаемые изменения.
При отправке коммитов в запрос на вытягивание не нажимайте принудительно. Принудительное нажатие может повредить ваш пул-реквест.

После инициализации запроса на вытягивание вы увидите страницу обзора, которая показывает высокоуровневый обзор изменений между вашей веткой (ветвью сравнения) и базовой веткой репозитория. Вы можете добавить сводку предлагаемых изменений, просмотреть изменения, внесенные коммитами, добавить ярлыки, этапы и исполнителей, а также @ упомянуть отдельных участников или команды.Для получения дополнительной информации см. «Создание запроса на вытягивание».

Создав пул реквест, вы можете отправлять коммиты из тематической ветки, чтобы добавить их в существующий пул реквест. Эти коммиты будут отображаться в вашем запросе на перенос в хронологическом порядке, а изменения будут видны на вкладке «Файлы изменены».

Другие участники могут просматривать предложенные вами изменения, добавлять комментарии к обзору, участвовать в обсуждении запроса на вытягивание и даже добавлять коммиты в запрос на вытягивание.

Вы можете просмотреть информацию о текущем статусе развертывания ветки и прошлых действиях по развертыванию на вкладке «Беседа».Дополнительную информацию см. В разделе «Просмотр действий по развертыванию репозитория».

После того, как вы будете довольны предложенными изменениями, вы можете объединить запрос на перенос. Если вы работаете в модели общего репозитория, вы создаете пул-реквест, и вы или кто-то другой объедините свои изменения из вашей функциональной ветки в базовую ветку, которую вы укажете в своем пул-реквесте. Дополнительные сведения см. В разделе «Объединение запроса на вытягивание».

Если для репозитория требуются проверки состояния, они должны пройти, прежде чем вы сможете объединить свою ветку с защищенной.Для получения дополнительной информации см. «О защищенных ветках».

Вы можете связать запрос на перенос с проблемой, чтобы показать, что исправление выполняется, и автоматически закрыть проблему, когда кто-то объединяет запрос на перенос. Для получения дополнительной информации см. «Связывание запроса на вытягивание с проблемой».

Советы:

Чтобы переключаться между сворачиванием и разворачиванием всех устаревших комментариев рецензии в запросе на вытягивание, удерживайте опцию Alt Alt и нажмите Показать устаревшие или Скрыть устаревшие .Дополнительные сочетания клавиш см. В разделе «Сочетания клавиш».
Вы можете сжать коммиты при объединении запроса на перенос, чтобы получить более оптимизированное представление об изменениях. Дополнительные сведения см. В разделе «О слиянии запросов на вытягивание».

Вы можете посетить свою панель управления, чтобы быстро найти ссылки на недавно обновленные запросы на вытягивание, над которыми вы работаете или на которые подписаны. Для получения дополнительной информации см. «О вашей личной панели инструментов».

Черновик запросов на вытягивание

Черновики запросов на вытягивание доступны в общедоступных репозиториях с GitHub Free для организаций и устаревших тарифных планов для каждого репозитория, а также в публичных и частных репозиториях с GitHub Team, GitHub Enterprise Server 2.17+ и GitHub Enterprise Cloud. Для получения дополнительной информации см. «Продукты GitHub».

Когда вы создаете пул реквест, вы можете выбрать создание пул реквеста, готового для проверки, или чернового пул реквеста. Черновики пул реквестов нельзя объединить, и владельцы кода не получают автоматический запрос на просмотр черновиков пул реквестов. Для получения дополнительной информации о создании черновика запроса на вытягивание см. Разделы «Создание запроса на вытягивание» и «Создание запроса на вытягивание из вилки».

Когда вы будете готовы получить отзыв по запросу на вытягивание, вы можете пометить черновик запроса на вытягивание как готовый к рассмотрению.Если пометить пулреквест как готовый к рассмотрению, все владельцы кода будут запрашивать рецензии. Вы можете преобразовать запрос на перенос в черновик в любое время. Дополнительные сведения см. В разделе «Изменение этапа запроса на вытягивание».

Различия между коммитами на страницах сравнения и запроса на вытягивание

На страницах сравнения и запроса на вытягивание используются разные методы для вычисления разницы для измененных файлов:

Страницы сравнения показывают разницу между кончиком ссылки головы и текущим общим предком (то есть базой слияния) головы и базовой ссылки.
Страницы запроса на вытягивание показывают разницу между вершиной ссылки головы и общим предком головы и базовой ссылки во время создания запроса на извлечение. Следовательно, база слияния, используемая для сравнения, может быть другой.

Дополнительная литература

Создание запроса на вытягивание — GitHub Docs

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

Любой человек с разрешениями на чтение репозитория может создать запрос на перенос, но для создания ветки у вас должны быть разрешения на запись. Если вы хотите создать новую ветку для своего пул-реквеста и у вас нет прав на запись в репозиторий, вы можете сначала разветвить репозиторий. Дополнительные сведения см. В разделах «Создание запроса на вытягивание из вилки» и «О вилках».

Вы можете указать, в какую ветку вы хотите объединить свои изменения при создании запроса на вытягивание.Запросы на извлечение могут быть открыты только между двумя разными ветвями.

Примечание : Чтобы открыть пулреквест в общедоступном репозитории, у вас должен быть доступ на запись к головной или исходной ветке, или, для репозиториев, принадлежащих организации, вы должны быть членом организации, которая владеет репозиторием, чтобы открыть запрос на вытягивание.

Вы можете связать запрос на перенос с проблемой, чтобы показать, что исправление выполняется, и автоматически закрыть проблему, когда кто-то объединяет запрос на перенос.Для получения дополнительной информации см. «Связывание запроса на вытягивание с проблемой».

Совет . Вы можете создать запрос на вытягивание с помощью интерфейса командной строки GitHub. Для получения дополнительной информации см. « gh pr create » в документации по интерфейсу командной строки GitHub.

Изменение диапазона веток и целевого репозитория

По умолчанию запросы на вытягивание основаны на ветке по умолчанию родительского репозитория. Для получения дополнительной информации см. «О ветвях».

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

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

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

Когда вы изменяете какую-либо информацию в диапазоне ветвления, области предварительного просмотра «Применить» и «Файлы изменены» будут обновлены, чтобы отобразить ваш новый диапазон.

Советы :

Используя режим сравнения, вы можете настроить сравнения за любой период времени. Для получения дополнительной информации см. «Сравнение коммитов».
Сопровождающие проекта могут добавить шаблон запроса на вытягивание для репозитория.Шаблоны включают запросы информации в теле запроса на вытягивание. Дополнительные сведения см. В разделе «О шаблонах задач и запросов на вытягивание».

Создание запроса на вытягивание

На GitHub перейдите на главную страницу репозитория.
В меню «Ветка» выберите ветку, содержащую ваши коммиты.
Над списком файлов щелкните Запрос на извлечение .
Используйте раскрывающееся меню base branch, чтобы выбрать ветку, в которую вы хотите объединить свои изменения, затем используйте раскрывающееся меню compare branch, чтобы выбрать ветку темы, в которой вы внесли свои изменения.
Введите заголовок и описание запроса на вытягивание.
Чтобы создать запрос на извлечение, готовый к рассмотрению, щелкните Создать запрос на извлечение . Чтобы создать черновик запроса на вытягивание, используйте раскрывающийся список и выберите Создать черновик запроса на извлечение , затем щелкните Черновик запроса на извлечение . Дополнительные сведения о черновиках запросов на вытягивание см. В разделе «О запросах на вытягивание».

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

Дополнительная литература

Объединение запроса на вытягивание — GitHub Docs

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

О слиянии запросов на вытягивание

В запросе на вытягивание вы предлагаете объединить изменения, внесенные в головную ветвь, в базовую ветвь. По умолчанию любой запрос на перенос может быть объединен в любое время, если только головная ветвь не конфликтует с базовой.Однако могут быть ограничения на то, когда вы можете объединить запрос на перенос в конкретную ветку. Например, вы можете объединить пул-реквест с ветвью по умолчанию только в том случае, если проходят необходимые проверки статуса. Для получения дополнительной информации см. «О защищенных ветках».

Вы можете настроить пул-реквест на автоматическое слияние, когда все требования слияния выполнены. Дополнительные сведения см. В разделе «Автоматическое объединение запроса на перенос».

Если запрос на перенос имеет конфликты слияния или если вы хотите протестировать изменения перед слиянием, вы можете проверить запрос на перенос локально и объединить его с помощью командной строки.

Вы не можете объединить черновик запроса на вытягивание. Дополнительные сведения о черновиках запросов на вытягивание см. В разделе «О запросах на вытягивание».

У вас может быть автоматическое удаление головных ветвей после объединения запросов на вытягивание в вашем репозитории. Для получения дополнительной информации см. «Управление автоматическим удалением ветвей».

Если вы решите, что не хотите, чтобы изменения в ветке темы были объединены с ветвью восходящего потока, вы можете закрыть запрос на перенос без объединения.

Совет . Вы также можете объединить пулреквест с помощью интерфейса командной строки GitHub.Для получения дополнительной информации см. « gh pr merge » в документации по интерфейсу командной строки GitHub.

Объединение запроса на вытягивание на GitHub

Под именем репозитория щелкните Запросы на извлечение .
В списке «Запросы на извлечение» щелкните запрос на извлечение, который нужно объединить.
В зависимости от параметров слияния, включенных для вашего репозитория, вы можете:
Примечание: Rebase и merge всегда обновляют информацию о коммиттере и создают новые SHA фиксации.Дополнительные сведения см. В разделе «О слиянии запросов на вытягивание».
При появлении запроса введите сообщение фиксации или примите сообщение по умолчанию.
Информацию о сообщениях фиксации по умолчанию для слияний сквоша см. В разделе «О слияниях запросов на вытягивание».
Если у вас есть более одного адреса электронной почты, связанного с вашей учетной записью GitHub, щелкните раскрывающееся меню адреса электронной почты и выберите адрес электронной почты, который будет использоваться в качестве адреса электронной почты автора Git. В этом раскрывающемся меню отображаются только подтвержденные адреса электронной почты.Если вы включили конфиденциальность адреса электронной почты, то @ users.noreply.github.com является адресом электронной почты автора фиксации по умолчанию. Дополнительные сведения см. В разделе «Настройка адреса электронной почты для фиксации».
Примечание: Селектор электронной почты недоступен для слияний с перебазированием, которые не создают фиксацию слияния, или для слияний сквоша, при которых пользователь, создавший запрос на извлечение, является автором сжатой фиксации.
Нажмите Подтвердите слияние , Подтвердите сжатие и слияние или Подтвердите перебазирование и слияние .
При желании удалите ветку. Благодаря этому список веток в вашем репозитории будет аккуратным.

Репозиторий можно настроить так, чтобы головная ветвь для запроса на вытягивание автоматически удалялась при объединении запроса на вытягивание. Для получения дополнительной информации см. «Управление автоматическим удалением ветвей».

Примечание: Если вы удалите головную ветвь после того, как ее запрос на вытягивание был объединен, GitHub проверит любые открытые запросы на вытягивание в том же репозитории, которые указывают удаленную ветвь в качестве своей базовой ветви.GitHub автоматически обновляет любые такие запросы на вытягивание, меняя их базовую ветвь на базовую ветвь объединенного запроса на вытягивание. Для получения дополнительной информации см. «О ветвях».

Pull-запросы объединяются с использованием опции --no-ff , за исключением пул-реквестов со сжатыми или перемещенными коммитами, которые объединяются с использованием опции быстрой перемотки вперед.

Вы можете связать запрос на перенос с проблемой, чтобы показать, что исправление выполняется, и автоматически закрыть проблему, когда кто-то объединяет запрос на перенос.Для получения дополнительной информации см. «Связывание запроса на вытягивание с проблемой».

Дополнительная литература

Что такое запрос на вытягивание?

— пользователем Марк Джонсон 8 ноября 2013 г.

Введение

Запрос на вытягивание — это метод отправки вкладов в открытый проект разработки.Часто это предпочтительный способ отправки вкладов в проект с использованием распределенной системы контроля версий (DVCS), такой как Git. Запрос на вытягивание происходит, когда разработчик запрашивает изменения, зафиксированные во внешнем репозитории, для рассмотрения для включения в основной репозиторий проекта.

Важно отметить, что «запросы на вытягивание» — это метод рабочего процесса, а не функция самой системы контроля версий. В этом документе будет представлен простой обзор запросов на вытягивание и того, как они создаются, на примере системы контроля версий Git и сайта хостинга GitHub.

Внесение изменений

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

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

Создание запроса на слияние

Метод определения запроса на вытягивание может отличаться в зависимости от проекта, поэтому не забудьте проверить документацию по проекту для получения подробной информации. Однако проекты, использующие GitHub, часто используют собственные инструменты GitHub для обработки запросов на вытягивание. Обычный рабочий процесс для отправки запроса на перенос с помощью GitHub будет выглядеть так:

Создайте / войдите в свою учетную запись GitHub
Перейдите на страницу репозитория кода, в который вы хотите внести свой вклад («восходящий поток»).
«Разветвите» репозиторий (это создаст клон вашей учетной записи GitHub)
Создайте локальный клон вашей вилки с помощью git clone
Создайте локальную ветку для ваших изменений
Внесите свои изменения и зафиксируйте их в своей локальной ветке с помощью git commit , обеспечивая включение описательного сообщения о фиксации
Вставьте ветку в вилку GitHub с помощью git push
Перейдите на страницу вышестоящего репозитория, перейдите на вкладку запросов на вытягивание
Нажмите кнопку «Новый запрос на извлечение».
Выберите ветку, которую вы хотите отправить, и напишите краткое изложение того, что ваше изменение, объяснив, для чего оно предназначено и как оно реализовано.

Другие проекты могут обрабатывать запросы на вытягивание вне github, например, Moodle управляет запросами на вытягивание как тикетами в своем трекере ошибок Jira.Однако вам всегда нужно отправлять свои изменения в общедоступный репозиторий, чтобы ваш код был доступен для проекта, поэтому наличие учетной записи на таком сайте, как GitHub или Bitbucket, — хорошая идея.

Применение запроса на слияние

После того, как участник отправил запрос на вытягивание, сопровождающие проекта должны оценить и, при необходимости, объединить его с вышестоящим репозиторием. В разных проектах используются разные подходы к рассмотрению и применению запросов на вытягивание.Однако у всех есть общие шаги:

Быстро оценить стоимость изменений
Подготовить оперативную и точную обратную связь для участника (при необходимости запросить повторную отправку)
Проверьте измененный код и запустите для него любые наборы тестов.
Сообщите о любых проблемах автору и запросите повторную отправку
Внесите изменения в исходный код

Квалифицированные разработчики могут читать различия (текстовые представления внесенных изменений) и понимать их значение, фактически не применяя их к базе кода.GitHub предоставляет представление о различиях, описывающих каждый запрос на перенос, чтобы упростить эту задачу. Это упрощает оперативную обратную связь с участником. Если сопровождающий проекта считает, что изменение выглядит значительным вкладом, он проверит ветку, для которой запрашивается извлечение, в свою локальную среду разработки и протестирует ее. Поскольку хороший вклад уже прошел обширное тестирование, это должно быть простым делом для сопровождающего. Однако могут быть сделаны ошибки, поэтому всегда следует проводить дальнейшее тестирование.

Как только запрос на перенос будет одобрен, сопровождающий перенесет его в запрошенную ветку вышестоящего репозитория, используя GitHub, команду git merge или git pull . Это сделает код доступным в общедоступной версии в исходном репозитории. Если это изменение связано с заявкой в системе отслеживания проблем, заявку следует обновить. GitHub позволяет этому происходить автоматически, ссылаясь на проблему в сообщении фиксации.

Неужели все так просто?

Важно, чтобы изменения были внесены в последнюю версию разрабатываемого кода.В git это обычно ветка под названием «master». Если есть стабильные выпуски, которые все еще получают исправления ошибок и обновления, вы можете подумать, следует ли вам также отправлять запрос на вытягивание для ваших изменений в отношении этих версий, которые часто будут иметь свои собственные ветви в системе управления версиями восходящего направления. Если изменения исправляют ошибку, которая только встречается в более старой версии, тогда может быть целесообразно отправить запрос на перенос только для более старой версии.

Также важно, чтобы участник следил за тем, чтобы внесенные изменения соответствовали любой документации и стандартам кодирования, принятым в проекте.Также крайне важно тщательно протестировать изменения в отношении любых наборов тестов, которые предоставляет проект. Наконец, каждый вклад должен быть четко задокументирован, как минимум, с указанием:

Для чего предназначен
Как это реализовано
Как это используется

Чтобы узнать больше о причинах этого и важности отправки ваших изменений вверх по течению, прочтите «Действительно ли это так просто? и почему я должен вносить патч? разделы нашего обзора, Что такое программный патч?

Дополнительная литература

Ссылки:

Связанная информация от OSS Watch:

Что такое запрос на вытягивание?

— пользователем Марк Джонсон 8 ноября 2013 г.

Введение

Внесение изменений

Создание запроса на слияние

Создайте / войдите в свою учетную запись GitHub
Перейдите на страницу репозитория кода, в который вы хотите внести свой вклад («восходящий поток»).
«Разветвите» репозиторий (это создаст клон вашей учетной записи GitHub)
Создайте локальный клон вашей вилки с помощью git clone
Создайте локальную ветку для ваших изменений
Внесите свои изменения и зафиксируйте их в своей локальной ветке с помощью git commit , обеспечивая включение описательного сообщения о фиксации
Вставьте ветку в вилку GitHub с помощью git push
Перейдите на страницу вышестоящего репозитория, перейдите на вкладку запросов на вытягивание
Нажмите кнопку «Новый запрос на извлечение».
Выберите ветку, которую вы хотите отправить, и напишите краткое изложение того, что ваше изменение, объяснив, для чего оно предназначено и как оно реализовано.

Применение запроса на слияние

Быстро оценить стоимость изменений
Подготовить оперативную и точную обратную связь для участника (при необходимости запросить повторную отправку)
Проверьте измененный код и запустите для него любые наборы тестов.
Сообщите о любых проблемах автору и запросите повторную отправку
Внесите изменения в исходный код

Неужели все так просто?

Для чего предназначен
Как это реализовано
Как это используется

Дополнительная литература

Ссылки:

Связанная информация от OSS Watch:

Как создать запрос на перенос в GitHub

Итак, вы знаете, как использовать git.У вас есть репозиторий GitHub, и вы можете на него нажимать. Все хорошо. Но как, черт возьми, вы вносите свой вклад в проекты GitHub других людей? Это то, что я хотел узнать после того, как изучил git и GitHub. В этой статье я объясню, как разветвить репозиторий git, внести изменения и отправить запрос на перенос.

Если вы хотите работать над проектом GitHub, первым делом нужно выполнить форк репо.

Воспользуйтесь моим демонстрационным репо, чтобы опробовать его.

Оказавшись там, нажмите кнопку Fork в правом верхнем углу.Это создает новую копию моего демонстрационного репо под вашей учетной записью GitHub с URL-адресом, например:

  https://github.com//demo

Копия включает весь код, ветки и коммиты из исходного репо.

Затем клонируйте репо, открыв терминал на своем компьютере и выполнив команду:

  git clone https://github.com//demo

После клонирования репо вам нужно сделать две вещи:

Создайте новую ветку, введя команду:
```
  git checkout -b новая_ветка  
```
Создайте новый пульт для восходящего репо с помощью команды:
```
  git remote добавить восходящий поток https: // github.com / kedark3 / demo  
```

В этом случае «восходящее репо» относится к исходному репо, из которого вы создали свою вилку.

Теперь вы можете вносить изменения в код. Следующий код создает новую ветку, вносит произвольное изменение и помещает ее в new_branch :

$ git checkout -b new_branch
Перешел на новую ветку 'new_branch'
$ echo «some test file»> test
$ cat test
Some test file
$ git status
На ветке new_branch
Пока нет коммитов
Неотслеженные файлы :
(используйте "git add <файл>... "включить в то, что будет зафиксировано)
test
ничего не добавлено для фиксации, но присутствуют неотслеживаемые файлы (для отслеживания используйте" git add ")
$ git add test
$ git commit -S -m" Добавление тестового файла в new_branch "
[new_branch (root-commit) 4265ec8] Добавление тестового файла в new_branch
1 файл изменен, 1 вставка (+)
режим создания 100644 тест
$ git push -u origin new_branch
Перечисление объектов: 3, готово.
Подсчет объектов: 100% (3/3), готово.
Запись объектов: 100% (3/3), 918 байт | 918.00 КиБ / с, готово.
Всего 3 (дельта 0), повторно используется 0 (дельта 0)
Remote: создайте запрос на вытягивание для 'new_branch' на GitHub, посетив:
Remote: http://github.com/example/Demo/pull/new/new_branch
Удаленный:
* [новая ветка] new_branch -> new_branch

После того, как вы внесете изменения в свое репо, в GitHub появится кнопка Сравнить и запрос на извлечение .

Щелкните по нему, и вы попадете на этот экран:

Откройте запрос на перенос, нажав кнопку Создать запрос на перенос .Это позволяет разработчикам репо просмотреть ваш вклад. Отсюда они могут объединить его, если это хорошо, или они могут попросить вас внести некоторые изменения.

TLDR

Таким образом, если вы хотите внести свой вклад в проект, самый простой способ — это:

Найдите проект, в который вы хотите внести свой вклад
Вилка
Клонировать его в вашу локальную систему
Сделайте новую ветку
Внесите изменения
Верните его в репо
Нажмите кнопку Сравнить и запрос на вытягивание кнопку
Нажмите Создать запрос на извлечение , чтобы открыть новый запрос на извлечение

Если рецензенты запрашивают изменения, повторите шаги 5 и 6, чтобы добавить больше коммитов в ваш запрос на вытягивание.

Удачного кодирования!

Проверка и объединение кода с запросами на вытягивание — Azure Repos

28.08.2020
26 минут для чтения

В этой статье

Azure Repos | Azure DevOps Server 2020 | Сервер Azure DevOps 2019 | TFS 2018 | TFS 2017 | TFS 2015 | VS 2017 | VS 2015

Создание запросов на вытягивание для проверки и объединения кода в проекте Git.Запросы на извлечение позволяют вашей команде проверять код и оставлять отзывы об изменениях, прежде чем объединять его в основную ветвь. Запросы на вытягивание могут поступать либо из тематических веток в одном репозитории, либо из ветки в ветке исходного репозитория. Рецензенты могут просматривать предлагаемые изменения, оставлять комментарии и голосовать за одобрение или отклонение кода.

Новичок в пул реквестах? Узнайте больше о том, как получить обратную связь с помощью запросов на вытягивание Git.

Руководство по запросам на вытягивание

Оставьте отличный отзыв

Высококачественные обзоры начинаются с качественных отзывов.Ключи к отличной обратной связи в запросе на вытягивание:

Попросите нужных людей просмотреть запрос на вытягивание
Убедитесь, что рецензенты знают, что делает код
Дайте полезный, конструктивный отзыв
Своевременно отвечать на комментарии

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

Рецензенты должны постараться предоставить отзывы об изменениях, с которыми они не согласны. Определите проблему и дайте конкретные предложения о том, что бы вы сделали иначе. Эта обратная связь имеет четкое намерение и ее легко понять. Владелец запроса на вытягивание должен ответить на комментарии, приняв предложение или объяснив, почему предлагаемое изменение не идеально.Иногда предложение хорошее, но изменения выходят за рамки запроса на вытягивание. Воспользуйтесь этими предложениями и создайте новые рабочие элементы и ветки функций отдельно от запроса на вытягивание, чтобы внести эти изменения.

Защитите филиалы с помощью политик

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

Добавьте дополнительные условия в запросы на вытягивание, чтобы обеспечить более высокий уровень качества кода в ключевых ветвях. Чистая сборка объединенного кода и одобрение нескольких рецензентов — вот некоторые дополнительные требования, которые вы можете установить для защиты своих ключевых веток.

Расширение рабочих процессов запросов на вытягивание с помощью статуса запроса на вытягивание

Запросы на извлечение

и политики ветвлений позволяют командам применять многие передовые практики, связанные с проверкой кода и запуском автоматических сборок, но у многих команд есть дополнительные требования и проверки для выполнения кода.Чтобы удовлетворить эти индивидуальные и настраиваемые потребности, Azure Repos предлагает статусы запросов на вытягивание. Статусы запроса на извлечение интегрируются в рабочий процесс PR и позволяют внешним службам программно подписывать изменение кода, связывая простую информацию о типе успеха / неудачи с запросом на извлечение.

Просмотр запросов на вытягивание

Чтобы просмотреть запросы на вытягивание в определенном репозитории проекта, перейдите в этот проект на веб-портале и выберите Репозиторий > Запросы на вытягивание .
Убедитесь, что вы выбрали правильный репозиторий.
Выберите Активный , чтобы показать все активные запросы на вытягивание для текущего репозитория. Выберите Завершено или Прервано , чтобы открыть историю закрытых запросов на вытягивание.
Вы можете просмотреть все свои запросы на вытягивание в различных проектах в вашей организации, выбрав Запросы на вытягивание в представлении Моя работа .

Управляйте запросами на вытягивание, которые принадлежат вам или которым назначены, с помощью вкладки Запросы на извлечение на странице Code в Интернете.

Выберите Активный , чтобы показать все активные запросы на вытягивание для текущего репо.

Выберите Завершено или Прервано , чтобы открыть историю закрытых запросов на вытягивание.

Вы можете просмотреть все свои запросы на вытягивание в своей организации по всем проектам, выбрав Мои запросы на вытягивание на странице Проекты .

Создать новый запрос на вытягивание

Создать новый запрос на вытягивание из:

После нажатия ветки

Когда вы публикуете или обновляете ветку компонентов, Azure Repos предлагает вам создать запрос на вытягивание. Этот запрос отображается в Pull Requests и Files .

Выберите Создайте запрос на вытягивание , чтобы перейти на страницу, где вы можете ввести данные своего запроса на вытягивание и создать запрос на вытягивание.

Когда вы публикуете или обновляете ветку компонентов, Azure Repos предлагает вам создать запрос на вытягивание в представлении Code в Интернете. Этот запрос отображается в Pull Requests и Files .

Из связанного рабочего элемента

Создайте запрос на вытягивание непосредственно из рабочего элемента, связанного с ветвью.

Из Backlogs или Запросы в представлении Work откройте рабочий элемент со связанной ветвью.
В области Разработка рабочего элемента выберите Создать запрос на вытягивание .

Ссылка приведет вас на страницу, где вы можете ввести данные своего запроса на вытягивание и создать запрос на вытягивание.

Со страницы запросов на вытягивание в Интернете

Создавайте запросы на вытягивание из любой ветви на странице Pull Request в Интернете.

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

из Visual Studio

Примечание

Visual Studio 2019 теперь включает новый инструмент Git, который обеспечивает улучшенный опыт при подключении к репозиторию Git. Когда вы включаете этот инструмент, инструмент Team Explorer эффективно отключается при подключении к репозиторию Git.Вы можете приобрести новый инструмент, загрузив Visual Studio 2019 версии 16.6. Чтобы включить и использовать новый инструмент, см. Раздел Git Experience в Visual Studio (предварительная версия).

Инициируйте запросы на вытягивание непосредственно из Visual Studio.

Подключитесь к своему проекту из Visual Studio.
Выберите View > Team Explorer , чтобы открыть Team Explorer. Вы также можете выбрать Ctrl + \, затем Ctrl + m.
Выберите Home , затем выберите Pull Requests .
Выберите Новый запрос на извлечение , чтобы открыть веб-браузер, в котором вы можете создать новый запрос на извлечение на веб-портале служб Azure DevOps.
В Pull Requests вы также можете просматривать запросы на вытягивание, открытые вами или назначенные вам.
Вы также можете инициировать запросы на вытягивание из Visual Studio из представления Ветви в Team Explorer, щелкнув правой кнопкой мыши имя ветки и выбрав Создать запрос на вытягивание при подключении к проекту.

из интерфейса командной строки Azure DevOps Services

Теперь вы можете управлять запросами на вытягивание и другими ресурсами из командной строки с помощью azure-DevOps. Azure Repos и Azure DevOps Server, ранее называвшаяся Team Foundation Server 2017 с обновлением 2 или более поздней версии, поддерживают запросы на вытягивание с помощью командной строки.

Список команд для создания запросов на вытягивание и управления ими см. В разделе Управление запросами на вытягивание.

Дополнительные сведения о работе с интерфейсом командной строки Azure DevOps Services см. В разделе Начало работы с интерфейсом командной строки.

Черновик запросов на вытягивание

Примечание

Черновик запросов на вытягивание был добавлен в обновление Azure DevOps Server 2019.1.

Иногда вам может потребоваться создать пул-реквест, но вы не готовы отправить его на рассмотрение всей команде. Черновик запроса на вытягивание указывает, что работа над запросом на вытягивание еще не завершена. Вам не нужно прибегать к таким префиксам заголовков, как WIP или DO NOT MERGE. Когда пул-реквест готов для проверки, вы можете опубликовать его и начать или возобновить полный процесс проверки.

Различия в запросах тяги

Черновики пул реквестов отличаются от опубликованных пул реквестов:

Политики проверки сборки включены, но не запускаются автоматически. Их можно поставить в очередь вручную, выбрав меню … рядом со сборкой в запросе на вытягивание.
Голосование отключено в черновом режиме.
Требуемые рецензенты не добавляются автоматически.
Уведомления отправляются в режиме черновика, но только рецензентам, которых вы явно добавляете в черновик запроса на вытягивание.
Черновики запросов на вытягивание отображаются в списке запросов на вытягивание со специальным значком.

Создать черновик запроса на вытягивание

Чтобы создать черновик запроса на вытягивание, выберите Создать как черновик при создании запроса на вытягивание.

Если вы начинаете заголовок запроса на вытягивание с WIP, по умолчанию выбирается Создать как черновик .

Публикация черновика запроса на вытягивание

Когда вы будете готовы к рассмотрению и выполнению запроса на вытягивание, вы можете его опубликовать.

Когда вы публикуете пул-реквест, назначаются и уведомляются необходимые рецензенты, оцениваются политики и начинается голосование.

Пометить как черновик

Чтобы пометить активный запрос на вытягивание как черновик, выберите Отметить как черновик . Если пометить пулреквест как черновик, все голоса будут сброшены. Если ваш запрос на вытягивание получил какие-либо голоса, вам будет предложено подтвердить.

Добавьте детали в запрос на перенос

Свяжите рабочие элементы и опишите изменения в ветке, чтобы другим было легче увидеть, какую проблему решают ваши изменения.Измените заголовок запроса на вытягивание, добавьте подробное описание, добавьте рецензентов, добавьте вложения, свяжите рабочие элементы и сделайте комментарии, чтобы объяснить свои изменения. Когда вы будете готовы создать запрос на вытягивание и проверить изменения, выберите Create .

Не беспокойтесь, если у вас нет всех рабочих элементов, рецензентов или деталей, готовых при создании запроса на вытягивание. Вы можете добавить их сейчас, когда создаете запрос на перенос. Вы также можете добавить или обновить все эти элементы после создания запроса на вытягивание.

Помощь рецензентам с помощью тегов запроса на вытягивание

Иногда важно сообщить рецензентам дополнительную информацию о запросе на вытягивание. Возможно, запрос на перенос все еще находится в стадии разработки или это исправление для предстоящего выпуска. Вы можете добавить в заголовок дополнительный текст, например, префикс «[WIP]» или «НЕ ОБЪЕДИНЯЙТЕСЬ». Теги позволяют предоставлять дополнительную информацию запросам на вытягивание. Используйте теги для передачи важных деталей и помощи в организации запросов на вытягивание.

Чтобы добавить тег при создании запроса на вытягивание, введите имя тега в разделе Теги .После создания запроса на перенос вы можете управлять его тегами в разделе Теги .

Помощь рецензентам, использующим метки запроса на вытягивание

Иногда важно сообщить рецензентам дополнительную информацию о запросе на вытягивание. Возможно, запрос на перенос все еще находится в стадии разработки или это исправление для предстоящего выпуска. Вы можете добавить в заголовок дополнительный текст, например, префикс «[WIP]» или «НЕ ОБЪЕДИНЯЙТЕСЬ». Ярлыки теперь позволяют помечать запросы на вытягивание дополнительной информацией.Используйте теги для передачи важных деталей и помощи в организации запросов на вытягивание.

Чтобы добавить метку при создании запроса на вытягивание, выберите Добавить метку . После создания запроса на перенос вы можете управлять его метками в разделе Labels .

Добавить и удалить рецензентов

Добавьте рецензентов в свой пул реквест:

Выберите Обзор в запросе на вытягивание.
Нажмите кнопку Добавить в области Reviewers , а затем выберите Требуется или Дополнительно .
Введите имя пользователя или группы, которые нужно добавить в список проверяющих для запроса на вытягивание. Если пользователь не является участником вашего проекта, вам необходимо его добавить.
При вводе имени или адреса электронной почты появляется список подходящих пользователей или групп. Выберите пользователя или группу из списка, чтобы добавить их в качестве рецензента.

Добавьте рецензентов в свой пул реквест:

Выберите Обзор в запросе на вытягивание.
Нажмите кнопку Добавить в области Reviewers .
Введите имя пользователя или группы, которые нужно добавить в список проверяющих для запроса на вытягивание. Если пользователь не является участником вашего проекта, вам необходимо его добавить.
При вводе имени или адреса электронной почты появляется список подходящих пользователей или групп. Выберите пользователя или группу из списка, чтобы добавить их в качестве рецензента.

Добавьте рецензентов в свой пул реквест:

Выберите вкладку Обзор в запросе на вытягивание.
Нажмите кнопку добавления в области Reviewers .
Введите имя пользователя или группы, которые нужно добавить в список проверяющих для запроса на вытягивание. Если пользователь не является участником вашего проекта, вам необходимо его добавить.
При вводе имени или адреса электронной почты появляется список подходящих пользователей или групп. Выберите пользователя или группу из списка, чтобы добавить их в качестве рецензента.

Связать рабочие элементы

Свяжите рабочие элементы с вашим запросом на вытягивание:

Выберите вкладку Обзор в запросе на вытягивание.
Нажмите кнопку добавления в области Рабочие элементы .
Введите идентификатор рабочего элемента или найдите рабочие элементы с заголовками, соответствующими вашему тексту. Выберите рабочий элемент из появившегося списка.

Удалите ссылки на рабочий элемент, нажав кнопку удаления, которая появляется при наведении курсора на рабочий элемент. При удалении ссылки удаляется только связь между рабочим элементом и запросом на вытягивание. Ссылки, созданные в ветке или из коммитов, остаются в рабочем элементе.

Свяжите рабочие элементы с вашим запросом на вытягивание:

Выберите вкладку Обзор в запросе на вытягивание.
Нажмите кнопку добавления в области Рабочие элементы .
Введите идентификатор рабочего элемента или найдите рабочие элементы с заголовками, соответствующими вашему тексту. Выберите рабочий элемент из появившегося списка.

Удалите ссылки на рабочий элемент, нажав кнопку удаления, которая появляется при наведении курсора на рабочий элемент.При удалении ссылки удаляется только связь между рабочим элементом и запросом на вытягивание. Ссылки, созданные в ветке или из коммитов, остаются в рабочем элементе.

Свяжите рабочие элементы с вашим запросом на вытягивание:

Выберите Обзор в запросе на вытягивание.
Нажмите кнопку добавления в области Рабочие элементы .
Введите идентификатор рабочего элемента или найдите рабочие элементы с заголовками, соответствующими вашему тексту.Выберите рабочий элемент из появившегося списка.

Изменить заголовок и описание запроса на вытягивание

Обновите заголовок запроса на перенос, щелкнув текущий заголовок и обновив текст. Нажмите кнопку «Сохранить», чтобы сохранить изменения, или выберите «Отменить», чтобы отменить изменения.

Отредактируйте описание запроса на вытягивание, щелкнув значок редактирования в разделе описания.

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

Просмотр запроса на вытягивание

Вкладка Overview позволяет быстро просмотреть текущее состояние запроса на вытягивание. Просмотрите заголовок, описание и обсуждение, чтобы понять предлагаемые изменения и увидеть проблемы, поднятые другими рецензентами.

Начиная с Visual Studio 2017 с обновлением 6, вы можете извлекать исходную ветвь из запроса на вытягивание непосредственно из Pull Requests в Team Explorer . Щелкните запрос на вытягивание правой кнопкой мыши и выберите Checkout Source Branch .

Фильтр запросов на вытягивание

Фильтрация позволяет находить и систематизировать запросы на вытягивание, позволяя расставлять приоритеты для наиболее важных файлов в рабочем процессе.

Создавать собственные запросы

Вы можете создать несколько настраиваемых запросов на странице запроса на вытягивание с дополнительными фильтрами, такими как состояние черновика.Эти запросы создают отдельные сворачиваемые разделы, чтобы повысить эффективность выполнения запросов на вытягивание. Запросы работают в репозиториях на вкладке Мои запросы на вытягивание на домашней странице организации.

Фильтр по комментариям

Используйте фильтры, связанные с комментариями, на странице сведений о запросе на вытягивание для более быстрой проверки:

Статус комментария: Активно (по умолчанию), Все , В ожидании , Решено , В соответствии с планом , Не исправит и Закрыто .
Комментарии: Фильтр комментариев, оставленных конкретным человеком.
Типы файлов: Показать все файлы (по умолчанию) и Показать только те файлы, которые были прокомментированы для .

Фильтр по целевой ветви

На странице запросов на извлечение щелкните значок Фильтр , а затем выберите Целевая ветка . В раскрывающемся списке выберите нужную ветку.

Просмотр изменений кода

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

Примечание

При просмотре разницы для одного выбранного файла существует ограничение на размер файла в 5 МБ. Для просмотра и сравнения файлов размером более 5 МБ вы можете загрузить файл и просмотреть его с помощью локального инструмента сравнения. При просмотре разницы для коллекции файлов в представлении «Файлы» ограничение на размер каждого файла составляет 0,5 МБ из соображений производительности.

Просмотрите предыдущие версии кода из раскрывающегося списка Все изменения .

Просмотрите предыдущие версии кода в раскрывающемся списке Все обновления .

Каждый раз, когда Azure Repos обновляет ветку, она добавляет новую версию в список и на вкладку Updates .

Просмотр различий обновляется по мере выбора различных изменений. Он показывает различия между файлами в выбранной и предыдущей версии в запросе на вытягивание.

Просмотрите метрики покрытия кода для изменений в представлении запроса на вытягивание.Это гарантирует, что вы должным образом протестировали свои изменения с помощью автоматических тестов. Статус покрытия отображается в виде комментария в обзоре запроса на вытягивание. Вы можете просмотреть подробную информацию о покрытии для каждой строки кода, которая была изменена в представлении сравнения файлов.

Выполняйте пул-реквест после того, как отошли от него, просматривая изменения, внесенные с момента вашего последнего просмотра.

Просмотрите список изменений от автора с помощью Updates .

Вы можете выбрать и просмотреть изменения, внесенные в коммиты в ветке в Commits .

Вы можете предварительно просмотреть, как будет выглядеть файл уценки, нажав кнопку View на файле, а затем выбрав Preview из раскрывающегося списка.

Оставить комментарии

Добавьте комментарии к запросу на вытягивание, чтобы вносить предложения, отвечать на предыдущие комментарии и указывать на проблемы с предлагаемыми изменениями. Добавьте комментарий на вкладке Files в вашем запросе на вытягивание, нажав кнопку комментария. Оставьте отзыв, не связанный с конкретным изменением кода, прокомментировав Обзор .Ответьте напрямую автору или другим рецензентам, используя @username , и ссылайтесь на рабочие задания, используя #workitemID в своих комментариях. Вы также можете ссылаться на другие запросы на вытягивание, используя ! PullrequestID .

Обновите статус комментария, чтобы рецензенты знали, что вы делаете для решения проблем, поднятых в их рецензии. Новые комментарии начинаются с Активный статус . Выберите Разрешить или Ответить и разрешить , чтобы обновить комментарии в беседе.

Дополнительные параметры доступны в раскрывающемся списке разрешения комментария.

Активно : Комментарий все еще рассматривается.
В ожидании : проблема в этом комментарии будет устранена, но еще не исправлена.
Решено : Проблема, поднятая в этом комментарии, была исправлена.
Не исправит : предложение в комментарии отмечено, но не будет вносить изменения в этот запрос на перенос для его решения.
Закрыто : Обсуждение этого комментария закрыто.

Отметить файлы как проверенные

Чтобы отслеживать файлы, которые уже были просмотрены, выберите значок с многоточием рядом с файлом в запросе на вытягивание, а затем выберите Отметить как проверенное в раскрывающемся списке.

Проголосовать за изменения

Используйте кнопку в правом верхнем углу, чтобы проголосовать за изменения в запросе на перенос. Параметр по умолчанию — Утвердить , но вы можете выбрать другие параметры из раскрывающегося списка:

Утвердить : согласиться с предлагаемыми изменениями в запросе на вытягивание как есть.
Утвердить с предложениями : Согласиться с запросом на вытягивание, но предоставить дополнительные предложения по улучшению кода.
Подождите автора : не одобряйте изменения и попросите автора просмотреть ваши комментарии. Автор должен сообщить вам, что нужно пересмотреть код еще раз после того, как он решит вашу проблему.
Отклонить : изменения неприемлемы. Если вы голосуете таким образом, оставьте комментарий в запросе на перенос, чтобы объяснить, почему.
Сбросить отзыв : выберите Сбросить отзыв , чтобы удалить свой голос.

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

При настройке политики ветви Требовать минимальное количество проверяющих выберите Сбросить голоса проверяющих при появлении новых изменений , чтобы сбрасывать голоса при отправке новых изменений.

Передовой опыт: как минимум два рецензента должны просмотреть и одобрить изменения в значительном запросе на вытягивание.

Код обновления в ответ на отзыв

Обновите свой код в ответ на комментарии. Затем создайте новую фиксацию с изменениями и отправьте обновления в ветку в вашем репозитории Git. Вы можете быстро обновлять свою ветку прямо из вкладки Files в Code в Интернете.

Изменить целевую ветвь запроса на вытягивание

Для большинства команд почти все запросы на вытягивание нацелены на одну и ту же ветку, например, main или development .Возможно, вам потребуется настроить таргетинг на другую ветку, но легко забыть изменить целевую ветвь по умолчанию. Чтобы изменить целевую ветвь активного запроса на вытягивание, см. Раздел Изменение целевой ветви запроса на вытягивание.

Завершите запрос на вытягивание

Выберите Завершить в правом верхнем углу представления запроса на вытягивание, чтобы завершить свой запрос на вытягивание после того, как рецензенты одобрит изменения.
- Завершить : Завершите запрос на вытягивание сейчас и объедините изменения в целевую ветвь.
- Установить автозаполнение : Если у вас есть политики ветвления, вы можете выбрать Установить автозаполнение , чтобы настроить запрос на перенос для закрытия, когда он соответствует всем политикам ветвления.
- Abandon : Закройте запрос на вытягивание без объединения изменений.
В Complete pull request введите сообщение для фиксации слияния и обновите описание pull request.
Выберите свой Тип слияния :
- Слияние (без перемотки вперед) : Нелинейная история с сохранением всех коммитов.
- Squash commit : Линейная история только с одной фиксацией на цели (сквош-слияние вашего запроса на вытягивание).
- Rebase and fast-forward : Rebase source фиксируется на цели и выполняется быстрая перемотка вперед.
- Полулинейное слияние : исходный код Rebase фиксируется на целевом объекте и создается слияние двух родителей.
Примечание
Существующие политики по-прежнему применяются. Например, если в вашей ветке в настоящее время действует политика «только сквош-слияние», вам придется отредактировать эту политику, чтобы использовать новые типы слияния.
Выберите любой из следующих параметров после завершения (некоторые параметры недоступны в зависимости от типа слияния):
- Завершите связанные рабочие элементы после объединения , чтобы завершить все связанные рабочие элементы.
- Удалите <имя ветки> после слияния , чтобы удалить исходную ветвь из запроса на вытягивание.
- Настройте сообщение фиксации слияния , чтобы добавить пользовательское сообщение фиксации слияния.
- Переопределить политики ветвления и включить слияние , чтобы заставить ветвь объединиться, даже если она не удовлетворяет всем политикам ветвления.Этот параметр доступен только в том случае, если у вас есть разрешения Освобождение от применения политики.
Выбрать Завершить слияние .

Связанные рабочие элементы также обновляются, показывая завершение запроса на вытягивание.

Есть несколько ситуаций, когда перебазирование во время выполнения запроса на вытягивание невозможно:

Если политика в целевой ветви запрещает использование стратегий перебазирования, вам потребуется разрешение «Переопределить политику ветви».
Если исходная ветвь запроса на вытягивание имеет политики, вы не сможете переустановить ее. При повторном размещении исходная ветка будет изменена без прохождения процесса утверждения политики.
Если вы использовали расширение конфликта слияния для разрешения конфликтов слияния. Разрешение конфликтов, применяемое к трехстороннему слиянию, редко бывает успешным (или даже действительным) при поочередном перемещении всех коммитов в запросе на вытягивание.

Во всех этих случаях у вас по-прежнему есть возможность локально переустановить ветку и отправить ее на сервер или сквош-слияние ваших изменений при выполнении запроса на вытягивание.

Выберите Завершить в правом верхнем углу представления запроса на вытягивание, чтобы завершить свой запрос на вытягивание после того, как рецензенты одобрит изменения.
- Завершить : Завершите запрос на вытягивание сейчас и объедините изменения в целевую ветвь.
- Установить автозаполнение : Если у вас есть политики ветвления, вы можете выбрать Установить автозаполнение , чтобы настроить запрос на перенос для закрытия, когда он соответствует всем политикам ветвления.
- Abandon : Закройте запрос на вытягивание без объединения изменений.
В Complete pull request введите сообщение для фиксации слияния и обновите описание pull request.
Выберите любой из следующих вариантов:
- Завершите связанные рабочие элементы после объединения , чтобы завершить все связанные рабочие элементы.
- Удалите <имя ветки> после слияния , чтобы удалить исходную ветвь из запроса на вытягивание.
- Сквош изменяет при слиянии , чтобы сквош объединить ваш запрос на вытягивание.
- Переопределить политики ветвления и включить слияние , чтобы заставить ветвь объединиться, даже если она не удовлетворяет всем политикам ветвления. Этот параметр доступен только в том случае, если у вас есть разрешения Освобождение от применения политики.
Примечание
Существующие политики по-прежнему применяются. Например, если в вашей ветке в настоящее время действует политика «только сквош-слияние», вам придется отредактировать эту политику, чтобы использовать новые типы слияния.
Выбрать Завершить слияние .

Связанные рабочие элементы также обновляются, показывая завершение запроса на вытягивание.

Есть несколько ситуаций, когда перебазирование во время выполнения запроса на вытягивание невозможно:

Если политика в целевой ветви запрещает использование стратегий перебазирования, вам потребуется разрешение «Переопределить политику ветви».
Если исходная ветвь запроса на вытягивание имеет политики, вы не сможете переустановить ее.При повторном размещении исходная ветка будет изменена без прохождения процесса утверждения политики.
Если вы использовали расширение конфликта слияния для разрешения конфликтов слияния. Разрешение конфликтов, применяемое к трехстороннему слиянию, редко бывает успешным (или даже действительным) при поочередном перемещении всех коммитов в запросе на вытягивание.

Выберите Завершить в правом верхнем углу представления запроса на вытягивание, чтобы завершить свой запрос на вытягивание после того, как рецензенты одобрит изменения.
- Завершить : Завершите запрос на вытягивание сейчас и объедините изменения в целевую ветвь.
- Установить автозаполнение : Если у вас есть политики ветвления, вы можете выбрать Установить автозаполнение , чтобы настроить запрос на перенос для закрытия, когда он соответствует всем политикам ветвления.
- Abandon : Закройте запрос на вытягивание без объединения изменений.
В Complete pull request введите сообщение для фиксации слияния и обновите описание pull request.
Выберите любой из следующих вариантов после завершения:
- Завершите связанные рабочие элементы после объединения , чтобы завершить все связанные рабочие элементы.
- Удалите <имя ветки> после слияния , чтобы удалить исходную ветвь из запроса на вытягивание.
- Сквош изменяет при слиянии , чтобы сквош объединить ваш запрос на вытягивание.
- Переопределить политики ветвления и включить слияние , чтобы заставить ветвь объединиться, даже если она не удовлетворяет всем политикам ветвления. Этот параметр доступен только в том случае, если у вас есть разрешения Освобождение от применения политики.
Выбрать Завершить слияние .

Связанные рабочие элементы также обновляются, показывая завершение запроса на вытягивание.

Разрешение конфликтов слияния

Необходимо разрешить любые конфликты слияния между ветвью запроса на вытягивание и целевой ветвью.Git добавляет новый коммит ( слияние коммит ) до конца основной ветки. Эта фиксация слияния связывает более раннюю историю как основной ветки, так и коммитов для ветки. который был объединен как часть запроса на вытягивание.

Завершить автоматически

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

После установки автозаполнения в запросе на вытягивание отображается баннер. Выберите Отменить автозаполнение , чтобы отключить автозаполнение и вернуть запрос на вытягивание в активное состояние. Начиная с TFS 2018 с обновлением 2, на баннере отображается список невыполненных критериев политики.

Примечание

Параметр Автозаполнение доступен в Azure Repos и TFS 2017 и более поздних версиях.Он присутствует только тогда, когда у вас есть политика ветвления, которая должна быть удовлетворена. Если вы не видите Автозаполнение , у вас нет политики ветвления. Дополнительные сведения см. В разделе Политики филиалов.

Отказаться от изменений

Выберите Abandon из раскрывающегося списка на кнопке Complete , чтобы отменить изменения. Вы все еще можете просмотреть брошенный запрос на перенос. Он остается связанным с рабочими элементами.

Повторно активировать брошенный запрос на вытягивание в любое время.Выберите запрос на извлечение на вкладке Abandoned в представлении Pull Request .

Получение уведомления об обновлениях запроса на вытягивание

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

Перейдите в свой проект и выберите Настройки проекта > Уведомления , чтобы просмотреть настройки уведомлений.

Выберите Новая подписка , чтобы подписаться на дополнительные уведомления.
Чтобы изменить уведомление, выберите … для уведомления и выберите Просмотр , чтобы изменить подписку.
Чтобы отказаться от уведомления, установите State на Off .

Нажмите кнопку настроек, когда ваш проект открыт, чтобы открыть страницу администрирования проекта.

Выберите вкладку Уведомления , чтобы просмотреть настройки уведомлений, и выберите Новая подписка , чтобы подписаться на дополнительные уведомления.
Чтобы изменить уведомление, выберите … для уведомления и выберите Просмотр , чтобы изменить подписку.
Чтобы отказаться от уведомления, установите State на Off .

Отменить запрос на вытягивание

Чтобы отменить изменения в запросе на вытягивание, выполните следующие действия:

Откройте завершенный запрос на вытягивание и выберите Вернуть .Когда вы возвращаете запрос на перенос таким образом, вы создаете новую ветку с изменениями, которые отменяют запрос на перенос для существующей целевой ветки в вашем репо.
В Целевая ветка выберите ветку, в которой вы хотите отменить изменения запроса на вытягивание.
В Тема ветки с именем выберите новую ветку, в которой создаются отмененные изменения, затем выберите Вернуть .
Выберите Создать запрос на перенос , чтобы объединить вновь созданную ветвь во втором запросе на перенос для завершения возврата.

Примечание

Ветвь, созданная во время этого отката, имеет одну фиксацию, которая отменяет изменения файла в запросе на вытягивание. Ветка не содержит отмененной фиксации для каждой из коммитов, объединенных в исходный запрос на перенос.

Cherry-pick запрос на вытягивание

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

В завершенном запросе на извлечение выберите Cherry-pick или для активного запроса на извлечение выберите Cherry-pick из … меню. При таком выборе пулл-реквеста создается новая ветка с скопированными изменениями. Слияние с целевой веткой во втором запросе на перенос.
В Целевая ветка введите ветку, в которой вы хотите объединить скопированные изменения.
В Тема ветки введите новую ветку, которая будет содержать скопированные изменения, затем выберите Cherry-pick .
Выберите Создать запрос на вытягивание , чтобы объединить тематическую ветку с целевой веткой, чтобы завершить выбор.

Установить новую ветку по умолчанию

Настройте репозиторий Git для использования другой ветки по умолчанию для слияния кода, когда ваша команда создает новые запросы на вытягивание. Вы можете использовать ветку, отличную от main , для новых изменений или изменить основную линию разработки в своем репо. Чтобы изменить имя ветки по умолчанию для новых репозиториев, см. Все настройки и политики репозиториев.

Перейдите в свой репозиторий и выберите Филиалов .
Выберите желаемую новую ветвь по умолчанию. Вам понадобится как минимум две ветки, чтобы изменить значение по умолчанию. Если есть только один, это уже будет ветвь по умолчанию. В этом случае вы должны создать второй, чтобы изменить значение по умолчанию.
Выберите … рядом с нужной веткой и выберите Установить как ветвь по умолчанию .
После того, как вы установили новую ветвь по умолчанию, вы можете удалить предыдущую, если хотите.

Нажмите кнопку настроек в открытом проекте, чтобы открыть страницу администрирования проекта.
Выберите Контроль версий .
Выберите репозиторий Git. Ваши ветки отображаются под вашим репо.
Выберите … рядом с веткой, которую вы хотите установить по умолчанию, затем выберите Установить как ветку по умолчанию .
No related posts.