➤ Проверки ГИТ в 2020 году

В октябре 2019 года Роструд утвердил и зарегистрировал в Минюсте новый административный регламент, в котором приведен порядок проведения плановых и внеплановых проверок работодателей. В статье мы рассказали, как правильно подготовиться к проверке ГИТ в 2020 году и достойно встретить проверяющих, а также дадим готовые решения по устранению замечаний и продлению срока исполнения предписания.

Скачайте сейчас:

План проведения плановых проверок на 2020 год в городе Москве

План проведения плановых проверок на 2020 год по Московской области

План проведения плановых проверок на 2020 год в Санкт-Петербурге

План проверок гит на 2020 год формирует Роструд и направляет для официальной публикации в Генеральную прокуратуру. Генпрокуратура является оператором единого реестра проверок (ст. 13.3 Федерального закона от 26.12.2008 № 294-ФЗ в редакции от 02. 08.2019).

Чтобы узнать, ожидает ли вашу компанию плановая проверка, нужно проверить график проверок ГИТ на 2020 год. Сделать это вы можете на сайте Генпрокуратуры.

Вам понадобится номер ИНН вашей организации. Эту информацию специалист по охране труда может запросить в бухгалтерии, взять из отчета о проведении СОУТ или договоров компании.

Перейдя по ссылке, введите ИНН вашей компании или название организации.

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

Если вашей компании в плане проверок на 2020 год нет, то вы увидите надпись на экране: «Найдено 0 КНМ». Это значит, что контрольно-надзорных мероприятий в адрес вашего юридического лица не запланировано.

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

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

Если вы нашли свою организацию в плане проверок ГИТ на 2020 год, то у вас еще есть время подготовиться и встретить инспекторов с полным пакетом документов, с наведенным порядком на территории и в помещениях. Какие документы при проверке трудинспекции нужно подготовить, указано в пункте 13 нового регламента проверок ГИТ, который вступил в силу 22 октября 2019 года (Приказ Роструда от 13.06.2019 № 160).

Также мы рекомендуем проверочные листы и провести самопроверку до прихода в вашу компанию инспектора. Чек листы ГИТ на 2020 год можно найти на сайтах Роструда.

Вы можете активно использовать сервис Роструда онлайнинспекция.рф.

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

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

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

Приказ Роструда от 13.06.2019 № 160, зарегистрированный в Минюсте России 10 октября 2019 года регламентирует алгоритм назначения и проведения контрольных мероприятий, обязательный для каждого инспектора ГИТ. Новый регламент проверок ГИТ написан по нормам международных конвенций, Федерального закона от 26. 12.2008 № 294-ФЗ. Никаких новых правил для работодателя в нем нет, но есть новые требования для инспекторов, о которых полезно знать каждому работодателю и специалисту по охране труда.

• Информацию о плановых проверках теперь должны публиковать гораздо раньше, чем в начале января того года, в котором должна быть проведена проверка, и не позже 10 ноября года, предыдущего проверке. Сделано это, возможно для того, чтобы работодатели смогли тщательнее подготовиться к проверке (п .41 приказа Роструда от 13.06.2019 № 160).
• Инспектору прямо запрещено требовать выполнения нормативных актов советского периода и документов Российской Федерации, не прошедших соответствующую регистрацию в Минюсте России и не опубликованных на официальном портале нормативно-правовой документации. (п. 8 приказа Роструда от 13.06.2019 № 160).

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

Также, если предприятие не указало в своих ЛНА, что следует определенным ГОСТам, инспектору запрещено требовать от работодателя ведения документации или бланков по форме этих ГОСТ.

Обратите внимание! Некоторые инспекторы ГИТ по старинке указывают в предписаниях следовать, например, Положению о проведении планово-предупредительного ремонта производственных зданий и сооружений МДС 13-14.2000, утвержденному постановлением Госстроя СССР от 29 декабря 1973 года № 279. Этот документ действительно отлично составлен, и аналогов ему в современных НПА нет. Но применять ли его в работе как методическую рекомендацию, или нет, решает только сам работодатель. Поэтому ссылка на этот документ в предписании запрещена.

В пункте 46 регламента № 160 указано, что проведение плановых контрольных мероприятий проводится в зависимости от категории риска компании.

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

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

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

Если работодатель не выдает работникам СИЗ, средства коллективной защиты, не проводит вовремя спецоценку, не разрабатывает положение о СУОТ или не проводит оценку профрисков, даже не стоит надеяться на смягчение наказания.

Проверка ГИТ в 2019 году: подготовка к плановой проверке

Кому ждать в гости инспекцию по труду

Деятельности каждого работодателя присваивается категория риска. Их всего пять (постановление Правительства РФ от 16.02.2017 № 197). Периодичность плановых проверок зависит от категории:

• для категорий высокого риска — 1 раз в 2 года;
• для категорий значительного риска — 1 раз в 3 года;
• для категорий среднего риска — не чаще чем 1 раз в 5 лет;
• для категорий умеренного риска — не чаще 1 раза в 6 лет.

Организациям и ИП, деятельность которых отнесена к низкой категории риска, плановые проверки не грозят.

С 1 января по 1 июля 2018 года ГИТ использовала проверочные листы только при плановых проверках тех работодателей, которые были отнесены к умеренной категории риска. С 1 июля 2018 года ГИТ применяет проверочные листы в обязательном порядке при проверках всех работодателей.

Исключение: субъекты малого предпринимательства освобождены от плановых проверок ГИТ до 31 декабря 2018 года (ст. 26.1 Федерального закона от 26.12.2008 № 294-ФЗ).

Где работодателю узнать о плановых проверках ГИТ

Надо зайти на сайт ГИТ того субъекта, где осуществляет свою деятельность работодатель. В декабре на сайте вывешивают проверки на очередной год.

Не нашли себя в списке? Ура, плановой проверки не будет. Но это не означает, что проверка не может быть внеплановой.

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

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

Подготовка к плановой проверке ГИТ

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

Евгения Конюхова, ведущая вебинара «10 самых важных проверочных листов.

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

Алгоритм таков: надо пройти тест из вопросов. По его итогам программа сообщит, есть ли нарушения, какой штраф за это ожидает, и выдает рекомендации, как исправить эти нарушения. Когда компания устранит нарушения, можно пройти повторную проверку. Такую самопроверку и ее результаты работодатель получает «для себя», чтобы выявить и исправить возможные нарушения. Это повод задуматься и устранить нарушения раньше инспекторов.

Второй инструмент — это проверочные листы (утверждены Приказом Роструда от 10.11.2017 № 655). Выбирайте те, которые подходят именно вашей компании. Например, есть листы, которые касаются иностранных работников. Если у вас их нет, то этот проверочный лист можно не рассматривать. На вебинаре в Школе бухгалтера я рассказала про 10 самых важных листов, по которым надо пройти самопроверку всем работодателям, будь то крупная компания или ИП.

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

Номера проверочных листов, которые должны посмотреть все работодатели: 1-7, 13-17, 19, 32. Например, лист № 1 затрагивает вопросы оформления приема на работу, лист № 4 — прекращения трудового договора, а лист № 7 — установления и выплаты зарплаты.

Итоговое количество проверочных листов, которые будут предложены работодателю, определяет ГИТ. Это количество зависит от предмета проверки и не может выходить за ее пределы».

Вопрос участника вебинара: у нас в 2018 году была внеплановая проверки ГИТ. Уменьшает ли этот факт вероятность плановой проверки? Или наоборот?

Ответ: у плановых и внеплановых проверок разные основания и предмет проверки. Поэтому проведение внеплановой не влияет на проведение плановой. Повторимся, о плановой проверке ГИТ можно узнать на сайте ГИТ своего региона или на сайте прокуратуры.

Читайте ответы на все вопросы участников вебинара про проверочные листы ГИТ. 

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

Что такое проверочные листы ГИТ?

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

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

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

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

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

Пример: вопрос из проверочного листа: со всеми ли сотрудниками компания заключила письменные трудовые договоры? Если хоть с одним из работников нет трудового договора на бумаге, то это прямое нарушение трудового законодательства. В этом случае проверяющий поставит галочку в графе «Нет». Ответы «Нет» — это и есть нарушение.

Если вопрос не относится к компании, например, если она не нанимает сезонных сотрудников, то в трудовом договоре и не будет условия о сезонном характере работ. В таком случае контролер поставит отметку в графе «Не относится». Это значит, что у компании нет такой ситуации.

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

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

Проверочный лист № 1. Порядок оформления приема на работу

Из этого видео вы узнаете, какие вопросы зададут инспекторы по проверочному листу ГИТ № 1 «Порядок оформления приема на работу»:

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

План проверок трудовой инспекции на 2021 год

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

Для подготовки к плановой проверке трудовой инспекции ГИТ, необходимо прежде всего обучить ответственного по охране труда очно или дистанционно, с выдачей удостоверения о проверке знаний требований охраны труда в объёме программы 40 часов.
Для организаций осуществляющих производственную деятельность, численность работников которых превышает 50 человек, создается служба охраны труда или вводится должность специалиста по охране труда, имеющего соответствующую подготовку или опыт работы в этой области. Профессиональной подготовкой является: высшее образование по специальности – охрана труда или непрофильное высшее образование с прохождением дополнительной профессиональной переподготовки по программе 256 часов. Для такой категории сотрудников назначенных на должность руководителей и специалистов служб охраны труда, работников, на которых приказом работодателя возложены функции специалиста по охране труда регулярно проводится повышение квалификации (72 часа) с периодичностью 1 раз в 5 лет.

01.01.2018 вступило в силу постановление Правительства РФ от 08.09.2017 № 1080, обязывающее государственных инспекторов труда использовать проверочные чек-листы при проведении аудита работодателей. Чек-лист – это список контрольных вопросов, которые касаются особо значимых требований трудового законодательства. В ходе проверки инспекторы смогут задавать только те вопросы, которые входят в указанные чек-листы (их опубликовано 132 листа). Ознакомиться с перечнем вопросов для подготовки к проверке.

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

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

Москва
Московская область
Санкт-Петербург
Ленинградская область
Алтайский край – Барнаул
Забайкальский край
Камчатский край – Петропавловск-Камчатский
Краснодарский край – Краснодар
Красноярский край – Красноярск
Приморский край – Владивосток
Пермский край – Пермь
Ставропольский край – Ставрополь
Хабаровский край – Хабаровск

Доступно дистанционное обучение,
удостоверение получаете по почте.

Амурская область – Благовещенск
Архангельская область – Архангельск
Астраханская область – Астрахань
Белгородская область – Белгород
Брянская область – Брянск
Владимирская область – Владимир
Волгоградская область – Волгоград
Вологодская область – Вологда
Воронежская область – Воронеж
Ивановская область – Иваново
Иркутская область – Иркутск
Калининградская область – Калининград
Калужская область – Калуга
Кемеровская область – Кемерово
Кировская область – Киров
Костромская область – Кострома
Курганская область – Курган
Курская область – Курск
Липецкая область – Липецк
Магаданская область – Магадан
Мурманская область – Мурманск
Нижегородская область – Нижний Новгород
Новгородская область – Новгород
Новосибирская область – Новосибирск
Омская область – Омск
Оренбургская область – Оренбург

ВНИМАНИЕ – плановые проверки трудовой инспекции, действительны на начало 2021 года.

Что изменилось в проверках ГИТ в 2020 году

Приказ Минтруда № 160 от 13.06.2019 ввёл новые требования для инспекторов Государственной инспекции труда. Правила проведения проверок стали более прозрачны для работодателя. Теперь не только инспектор может проверять вашу документацию, но и вы можете контролировать правильность и обоснованность его действий. В статье разберём основные нововведения.

Раньше план проверок на следующий год размещали на сайте ГИТ не позднее 1 декабря текущего года. Теперь это будут делать до 10 ноября (п. 41 Административного регламента осуществления Федеральной службой по труду и занятости федерального государственного надзора за соблюдением трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права). Так работодатели получат больше времени на подготовку к проверке и доработку внутренней документации. 

По новым правилам единый реестр проверок находится в ведении Генпрокуратуры (ст. 13.3 от 26.12.2008 № 294-ФЗ). План, сформированный Рострудом, публикуется на официальном сайта Генеральной прокуратуры. Именно там можно посмотреть график плановых проверок и выяснить, стоит ли ждать инспектора в гости в ближайшие месяцы.

Инициировать внеплановую проверку ГИТ вправе, если получит жалобу на нарушение трудового законодательства. Подать её может работник предприятия или другое лицо. Если в жалобе говорится, что здоровью или жизни работников что-либо угрожает (п.90 Регламента), проверка будет наверняка.

Чтобы снизить риск прихода инспекции, работодателю нужно:

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

Если поступила жалоба об угрозе жизни или здоровью, проверка проходит без уведомления (п. 98 Регламента). При этом если гражданин захочет отозвать заявление, инспектор всё равно придёт (п. 29 Регламента). 

Если комиссия выявит нарушение, которое может стать причиной нанесения ущерба здоровью или жизни работников, штраф невозможно будет заменить на предупреждение. Например, раньше работодатель мог задерживать зарплату сотрудникам и получить от ГИТ только предупреждение. Теперь за такое нарушение точно будет штраф. 

Для малого и среднего бизнеса в 2020 году предусмотрены надзорные “каникулы”. Проверки ГИТ проводиться не будут (от 01.04.2020 №98-ФЗ). Но есть исключения. Если жизни или здоровью работников что-то угрожает, либо инцидент уже случился — прихода инспектора избежать не удастся. Также следует ждать комиссию, если возникнет чрезвычайная ситуация природного или техногенного характера.

Плановые проверки возможны для предприятия и ИП, если (ст. 26.2 Закона № 294-ФЗ):

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

Работодатель может по своей инициативе прекратить проверку. Для этого нужно направить в ГИТ заявление (п. 27 Регламента). Например, проверку следует прекратить, если в ходе её проведения и организации инспектором были допущены грубые нарушения.

К таким нарушениям можно отнести несоблюдение сроков уведомления. Если ГИТ сообщила о проверке менее, чем за три дня  (п. 53 Регламента), то её результаты не будут действительны (ст. 20 Закона № 294-ФЗ). Если проверка с нарушением уже происходит, её следует прекратить.

Ещё одним весомым поводом для прекращения может быть анонимность обращения, которое послужило поводом для прихода комиссии. Если информация в обращении заведомо ложная, проверку также следует прекратить (п. 27 и 104 Регламента, ст. 10 Закона № 294-ФЗ).

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

Важный момент для работодателей! Данный список содержит указания только на группы документов. Если инспектор запросил данные, которых в нём нет, работодателю нужно направить в ГИТ вежливый отказ в выполнении запроса со ссылкой на пункт регламента.  

В перечне документы разделены на группы. Вот наиболее важные из них: 

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

Документы из п. 14 Регламента инспектор не вправе требовать у работодателей, потому что может получить их от других ведомств (п. 8 Регламента).

Закон запрещает инспектору требовать выполнения нормативных актов советского периода, а также документов РФ, которые не зарегистрированы в Минюсте России и не опубликованы (п. 8 приказа Роструда от 13.06.2019 № 160). 

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

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

Если проверка занимает слишком много времени, это вредит бизнесу. Чтобы обезопасить предприятия от потерь из-за нерасторопности проверяющих органов, законодательство ввело ограничения. Теперь проверка не может длиться больше 20 рабочих дней (ст. 13 №294 ФЗ). Проверять малые предприятия можно не дольше 50 часов в год. Для микропредприятий действует ограничение в 15 часов в год.

Для предприятий с филиалами в нескольких субъектах РФ закон закрепляет срок проверки общей длительностью не более 60 рабочих дней (пп. 24 и 62 Регламента и ч. 4 ст. 13 № 294-ФЗ).

Если проверка требует длительных расследований, экспертиз и испытаний, срок её проведения могут увеличить не более, чем в 2 раза (п. 24 Регламента). Внеплановые проверки при этом не могут длиться более 20 дней (п. 107 Регламента).

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

Вместе с актом нужно обязательно хранить пояснения, проверочные листы и иные доказательства результатов проверки (п. 69, 70, 72, 74 Регламента). 

Акт проверки передают лично в руки, либо направляют электронным документом с усиленной квалифицированной электронной подписью, если на проверяемом предприятии организован электронный документооборот. По почте простым письмом отправлять этот документ запрещается (п. 78, 81 Регламента).

Если работодатель не получил акт проверки, он может обратиться в ГИТ с заявлением и результаты проверки отменят (ч. 4 ст. 16 Закона № 294-ФЗ и ст. 20 Закона № 294-ФЗ).

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

Если статья была вам полезна, пожалуйста, оцените ее на “звездной” шкале внизу, где 5 звезд – очень полезна. Мы хотим, чтобы вы получали только нужные материалы, и будем благодарны за обратную связь!

Проверка ГИТ в 2020: подготовка по чек-листам

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

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

Плановые проверки ГИТ

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

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

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

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

Узнать, посетит ли инспекция вашу компанию в этом году можно на сайтах региональных ГИТ, где до 10 ноября должны опубликовать ежегодный план проверок (Приказ Роструда от 13.06.2019 N 160). Таким образом, у работодателей есть время подготовиться к приходу проверяющих.

Внеплановые проверки ГИТ

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

О проведении внеплановой проверки компанию уведомят не позже чем за 24 часа до ее начала. Но если основанием стала жалоба работника на условия труда, заранее о приходе инспектора не сообщается.

Действия проверяющего и работодателя

Ход инспектирования ГИТ регламентирован (Приказ Минтруда от 30 октября 2012 года N 354н, Приказ Минтруда от 21 апреля 2017 года N 377н).

Инспектор труда должен предъявить удостоверение и распоряжение о проведении проверки, а также вручить заверенную копию распоряжения работодателю. Затем он запрашивает необходимые документы, которые руководитель должен представить в виде оригиналов и копий. Проверяющий изучает документы с помощью проверочных листов. Руководители или уполномоченные представители компании должны присутствовать при проведении проверки. По результатам контрольного мероприятия составляется акт с подписями обеих сторон – ГИТ и работодателя.

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

Компания имеет право на обжалование предписания и постановления о привлечении к административной ответственности.

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

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

Проверочные листы

Проверочные листы (Приказ Роструда от 10. 11.2017 N 655) представляют собой списки контрольных вопросов, которые используют проверяющие для осуществления контроля по определенной теме. Каждый документ предназначен для оценки трудовых отношений сотрудника и нанимателя и определяет требования трудового законодательства. В ходе проверки инспектор имеет право задавать вопросы только из чек-листа по предмету инспектирования. Некоторые листы содержат общеобязательные требования, поэтому предназначены для всех нанимателей. Например, предметом проверки может стать заключение и прекращение трудового договора (№4), установление и выплата заработной платы (№7), проведение спецоценки условий труда (№ 21), обучение по охране труда (№ 28) и т.д.

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

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

Подготовка к плановой проверке ГИТ

Проверочные листы не только упрощают работу инспекторам, но и дают возможность работодателям заранее подготовиться к визиту ГИТ. Суть подготовки состоит в том, чтобы на каждое контрольное требование поставить отметку «Да, исполнено». Тематика чек-листа должна соответствовать предмету плановой проверки. Полный список проверочных листов размещен на сайте Роструда.

В помощь работодателям создан интернет-сервис «Электронный инспектор», где можно пройти самопроверку по чек-листам ГИТ в онлайн-формате почти по всем процедурам. На данный момент доступно 200 проверочных листов. При прохождении тестирования можно указывать реальное наименование компании или выдуманное. Если на некоторые вопросы были даны неверные ответы, в итоговом акте появятся рекомендации по устранению обнаруженных нарушений.

Правовой сборник для кадровика

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

Что проверяет трудовая инспекция в 2019 году

Законодательная база

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

Что проверяют специалисты трудовой инспекции? Основная цель проверок — контроль соблюдения предпринимателями и должностными лицами трудового законодательства. Порядок проведения и нормативы этого контроля регламентированы на законодательном уровне. В частности, этому посвящены статьи из главы 57 Трудового Кодекса.

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

• ФЗ №294 от 26.12.2008 направлен на защиту юрлиц и ИП при проверках. Он регламентирует процедуру госнадзора, устанавливает сроки проведения, содержит другую важную для предпринимателей информацию.
• Правительственное постановление № 875 от 01.09.2012 утверждает Положение о госнадзоре в области трудового права.

Основания для контроля

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

Далее рассмотрим подробно основания для каждой категории проверок.

Плановые визиты ГИТ

Основание для плановых проверок из ГИТ служит установленная законом необходимость госнадзора за исполнением трудового законодательства. Контроль осуществляется периодически, в зависимости от категории риска, которая присвоена предприятию. Такой подход обусловлен ФЗ №294 и пунктами 17–24 Положения о надзоре по труду.

Как часто и за какой период трудовая инспекция проверяет планово:

• 1 раз в 2 года — компании из категории высокого риска.
• 1 раз в 3 года — организации, которым присвоена значительная категория риска.
• 1 раз в 5 лет — компании со средним риском.
• 1 раз в 6 лет — предприятия из категории с умеренным риском.

Юридические лица, попавшие в сегмент с низким риском, плановым проверкам не подлежат.

Внеплановые проверки

Основания для внеплановых проверок описаны в статье 360 ТК РФ.  В их числе:

• Обращение в ГИТ с жалобами на нарушение трудовых норм. Например, поводом может стать задержка зарплаты или если ее уровень ниже МРОТ, пренебрежение условиями охраны труда, неправильном оформлении трудовых отношений и др.
• Окончание срока, который был установлен предыдущей проверкой для исправления выявленных недочетов.
• Инициатива Правительства, Президента или прокуратуры. При этом начальник инспекции издает соответствующий приказ.

Что проверяет ГИТ: порядок проведения

Схематично регламент проведения надзорных мероприятий можно отразить так:

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

Проверка документов. С 2018 года проверка происходит в формате опросника. Полномочия и права инспекторов не изменились, но регламент их действий стал более структурированным: результаты контроля заносятся в проверочные листы, сформированные по темам (например, в теме «Трудовой договор» трудовая инспекция проверяет при проверке наличие контрактов, правильность их составления, своевременность подписания).

Институт профессионального кадровика записал несколько роликов о работе с проверочными листами. Посмотрите вводную часть и другие видео.

О том, какие документы проверяет трудовая инспекция далее поговорим подробно.

Составление акта с итогами. Иногда его составляют на предприятии, но чаще всего за ним нужно идти в ГИТ.

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

Что проверяет трудовая инспекция при плановой проверке

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

• Трудовые договоры.
• Личные дела и личные карточки.
• Трудовые книжки и реестры их учета.
• Табель учета рабочего времени.
• Рабочий распорядок и график отпусков.
• Расчетные листы и бухгалтерские ведомости.
• ПВТР и некоторые другие локальные акты.
• Реестры ознакомления с ЛНА, кадровыми и бухгалтерскими документами.

Что проверяет трудовая инспекция при внеплановой проверке

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

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

Особый случай — что проверяет трудовая инспекция при жалобе работника, который пожелал, чтобы его имя осталось неизвестным работодателю. Такое право дает труженикам статья 358 ТК РФ. В этой ситуации инспектор, чтобы сохранить инкогнито заявителя перед компанией может запросить документы нескольких сотрудников.

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

Что проверяет трудовая инспекция: границы полномочий

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

Чего не может делать инспектор: 3 ограничения

1. Проверять больше, чем предусмотрено опросниками.
2. Требовать документы или информацию, которая не относится к теме проверки.
3. Изымать оригиналы документов.

Если есть нарушения, админответственность может быть применена не только на руководителя, но и на ответственных исполнителей высшего звена. Например, на главного бухгалтера. А вот рядовых сотрудников привлекать к ответственности по результатам проверки из ГИТ нельзя.

Как подготовиться: инструкция

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

ТОП-лист ошибок работодателей при проверке

1. Не со всеми работниками оформлены трудовые договоры (ТД). Если на договоре нет подписи работника, он тоже считается не заключенным.
2. В ТД не прописаны обязательные параметры. Например, условия труда или зарплатная ставка.
3. Нет обязательных ЛНА. Например, правил внутреннего трудового распорядка. Или они есть, но нет свидетельств, что сотрудники ознакомлены с ними до подписания ТД.
4. Слишком поздно составлен график отпусков (меньше чем за 14 дней до начала календарного года).
5. Неправильно разбит отпуск одного или нескольких работников: все части меньше 14 дней.
6. Зарплаты выплачивается реже, чем каждые 15 дней без письменного согласия работника. Посмотрите наше видео о подготовке к кадровым проверкам.

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

ПРОВЕРКИ ГИТ 2019 и не только.

6 февраля 2019 в 14:26

ПРОВЕРКИ ГИТ 2019 и не только.

Руководителям и специалистам по ОТ предприятий.

Напомним, что Государственная инспекция труда, Ростехнадзор, Роспотребнадзор, МЧС   ежегодно составляют план проверок юридических лиц и индивидуальных предпринимателей – работодателей. 
Узнать информацию о включении вашей организации или ИП  в план проверок на 2019 год, вы можете на сайте  Прокураторы Российской Федерации http://plan.genproc.gov.ru/plan2019/

Если вашей организации в 2019 году предстоит проверка Государственной инспекцией по труду (ГИТ), к ней стоит хорошо и лучше заранее подготовиться: выявить и устранить все недочеты. 
При численности сотрудников в вашей организации до 50 человек функции по охране труда могут быть возложены на одного из сотрудников или руководителя с проведением обязательного обучения по программе ОТ, в аккредитованном учебном центре. Если численность сотрудников организации превышает 50 человек, то в штат организации должна быть введена единица специалиста по охране труда или  заключен договор с аккредитованной  организацией, предоставляющей услуги по охране труда.

Подробную информацию и консультацию о том, как правильно организовать работу по охране труда, в вашей организации, Вы всегда можете получить. 
по телефону +7 952-58-68-743
или  [email protected]

Компания PROOT поможет полноценно подготовиться к предстоящей проверке ГИТ.

Создать систему охраны труда, разработать все необходимые документы, обучить сотрудников, провести СОУТ и внедрить систему «Нулевой травматизм»

С уважением к вам и вашему бизнесу PROOT

г. Ростов-на-Дону Ул. Вавилова 62В оф. 216

+7 952-58-68-743 Нина Юрьевна

проверок – GitHub Docs

Параметры

Примеры кода

Оболочка

  завиток \
  -X POST \
  -H "Принять: application / vnd.github.v3 + json" \
  https://api.github.com/repos/octocat/hello-world/check-suites \
  -d '{"head_sha": "head_sha"}'  

JavaScript (@ octokit / core.

  await octokit.request ('POST / repos / {owner} / {repo} / check-suites', {
  владелец: 'octocat',
  репо: 'hello-world',
  head_sha: 'голова_ша'
})
  

, когда пакет уже существовал

  Статус: 200 ОК  

  {
  "id": 5,
  "node_id": "MDEwOkNoZWNrU3VpdGU1",
  "head_branch": "мастер",
  "head_sha": "d6fde92930d4715a2b49857d24b940956b26d2d3",
  "статус": "завершено",
  «вывод»: «нейтральный»,
  "url": "https: // api.github.com/repos/github/hello-world/check-suites/5 ",
  "до": "146e867f55c26428e5f9fade55a9bbf5e95a7912",
  "после": "d6fde92930d4715a2b49857d24b940956b26d2d3",
  "pull_requests": [],
  "created_at": "2017-07-08T16: 18: 44-04: 00",
  «updated_at»: «2017-07-08T16: 18: 44-04: 00»,
  "приложение": {
    "id": 1,
    "слизняк": "октоапп",
    "node_id": "MDExOkludGVncmF0aW9uMQ ==",
    "владелец": {
      "логин": "github",
      "id": 1,
      "node_id": "MDEyOk9yZ2FuaXphdGlvbjE =",
      "url": "https://api. github.com/orgs/github",
      "repos_url": "https: // api.github.com/orgs/github/repos ",
      "events_url": "https://api.github.com/orgs/github/events",
      "avatar_url": "https://github.com/images/error/octocat_happy.gif",
      "gravatar_id": "",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https: // api.github.com/users/octocat/starred{/owner}{/repo} ",
      "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
      "organization_url": "https://api.github.com/users/octocat/orgs",
      "receive_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "Пользователь",
      "site_admin": правда
    },
    "name": "Приложение Octocat",
    "описание": "",
    "external_url": "https://example. com",
    "html_url": "https://github.com/apps/octoapp",
    "created_at": "2017-07-08T16: 18: 44-04: 00",
    «updated_at»: «2017-07-08T16: 18: 44-04: 00»,
    "разрешения": {
      "метаданные": "читать",
      "содержимое": "читать",
      "issues": "написать",
      "single_file": "написать"
    },
    "События": [
      "толкать",
      "pull_request"
    ]
  },
  "репозиторий": {
    "id": 1296269,
    "node_id": "MDEwOlJlcG9zaXRvcnkxMjk2MjY5",
    "name": "Hello-World",
    "full_name": "octocat / Hello-World",
    "template_repository": {
      "id": 1296269,
      "node_id": "MDEwOlJlcG9zaXRvcnkxMjk2MjY5",
      "name": "Шаблон Hello-World",
      "full_name": "octocat / Hello-World-Template",
      "владелец": {
        "логин": "octocat",
        "id": 1,
        "node_id": "MDQ6VXNlcjE =",
        "avatar_url": "https: // github.com / images / error / octocat_happy.gif ",
        "gravatar_id": "",
        "url": "https://api.github.com/users/octocat",
        "html_url": "https://github. com/octocat",
        "followers_url": "https://api.github.com/users/octocat/followers",
        "following_url": "https://api.github.com/users/octocat/following{/other_user}",
        "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
        "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
        "subscriptions_url": "https: // api.github.com/users/octocat/subscriptions ",
        "organization_url": "https://api.github.com/users/octocat/orgs",
        "repos_url": "https://api.github.com/users/octocat/repos",
        "events_url": "https://api.github.com/users/octocat/events{/privacy}",
        "receive_events_url": "https://api.github.com/users/octocat/received_events",
        "type": "Пользователь",
        "site_admin": ложь
      },
      "частный": ложь,
      "html_url": "https://github.com/octocat/Hello-World-Template",
      "description": "Это ваше первое репо!",
      "вилка": ложь,
      "url": "https: // api.github.com/repos/octocat/Hello-World-Template ",
      "archive_url": "https://api. github.com/repos/octocat/Hello-World-Template/{archive_format}{/ref}",
      "assignees_url": "https://api.github.com/repos/octocat/Hello-World-Template/assignees{/user}",
      "blobs_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/blobs{/sha}",
      "branch_url": "https://api.github.com/repos/octocat/Hello-World-Template/branches{/branch}",
      "Collaborators_url": "https://api.github.com/repos/octocat/Hello-World-Template/collaborators{/collaborator}",
      "comments_url": "https: // api.github.com/repos/octocat/Hello-World-Template/comments{/number} ",
      "commits_url": "https://api.github.com/repos/octocat/Hello-World-Template/commit{/sha}",
      "compare_url": "https://api.github.com/repos/octocat/Hello-World-Template/compare/{base}...{head}",
      "content_url": "https://api.github.com/repos/octocat/Hello-World-Template/contents/{+path}",
      "Contributors_url": "https://api.github.com/repos/octocat/Hello-World-Template/contributors",
      "deployments_url": "https: // api. github.com/repos/octocat/Hello-World-Template/deployments ",
      "downloads_url": "https://api.github.com/repos/octocat/Hello-World-Template/downloads",
      "events_url": "https://api.github.com/repos/octocat/Hello-World-Template/events",
      "forks_url": "https://api.github.com/repos/octocat/Hello-World-Template/forks",
      "git_commit_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/commit{/sha}",
      "git_refs_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/refs{/sha}",
      "git_tags_url": "https: // api.github.com/repos/octocat/Hello-World-Template/git/tags{/sha} ",
      "git_url": "git: github.com/octocat/Hello-World-Template.git",
      "issue_comment_url": "https://api.github.com/repos/octocat/Hello-World-Template/issues/comments{/number}",
      "issue_events_url": "https://api.github.com/repos/octocat/Hello-World-Template/issues/events{/number}",
      "issues_url": "https://api.github.com/repos/octocat/Hello-World-Template/issues{/number}",
      "keys_url": "https://api. github.com/repos/octocat/Hello-World-Template/keys{/key_id}",
      "label_url": "https: // api.github.com/repos/octocat/Hello-World-Template/labels{/name} ",
      "languages_url": "https://api.github.com/repos/octocat/Hello-World-Template/languages",
      "merges_url": "https://api.github.com/repos/octocat/Hello-World-Template/merges",
      "milestones_url": "https://api.github.com/repos/octocat/Hello-World-Template/milestones{/number}",
      "notifications_url": "https://api.github.com/repos/octocat/Hello-World-Template/notifications{?since,all,participating}",
      "pulls_url": "https: // api.github.com/repos/octocat/Hello-World-Template/pulls{/number} ",
      "Release_url": "https://api.github.com/repos/octocat/Hello-World-Template/releases{/id}",
      "ssh_url": "[email protected]: octocat / Hello-World-Template.git",
      "stargazers_url": "https://api.github.com/repos/octocat/Hello-World-Template/stargazers",
      "statuses_url": "https://api.github.com/repos/octocat/Hello-World-Template/statuses/{sha}",
      "subscribers_url": "https://api. github.com/repos/octocat/Hello-World-Template/subscribers",
      "subscription_url": "https: // api.github.com/repos/octocat/Hello-World-Template/subscription ",
      "tags_url": "https://api.github.com/repos/octocat/Hello-World-Template/tags",
      "team_url": "https://api.github.com/repos/octocat/Hello-World-Template/teams",
      "tree_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/trees{/sha}",
      "clone_url": "https://github.com/octocat/Hello-World-Template.git",
      "mirror_url": "git: git.example.com/octocat/Hello-World-Template",
      "hooks_url": "https: // api.github.com/repos/octocat/Hello-World-Template/hooks ",
      "svn_url": "https://svn.github.com/octocat/Hello-World-Template",
      "домашняя страница": "https://github.com",
      "язык": ноль,
      «вилок»: 9,
      "forks_count": 9,
      "stargazers_count": 80,
      "watchers_count": 80,
      «наблюдателей»: 80,
      «размер»: 108,
      "default_branch": "мастер",
      "open_issues": 0,
      "open_issues_count": 0,
      "is_template": истина,
      "лицензия": {
        "ключ": "мит",
        "name": "Лицензия MIT",
        "url": "https: // api. github.com/licenses/mit ",
        "spdx_id": "MIT",
        "node_id": "MDc6TGljZW5zZW1pdA ==",
        «html_url»: «https://api.github.com/licenses/mit»
      },
      "темы": [
        "октокэт",
        "атом",
        "электрон",
        "api"
      ],
      "has_issues": правда,
      "has_projects": правда,
      "has_wiki": правда,
      "has_pages": ложь,
      "has_downloads": правда,
      "в архиве": ложь,
      "отключен": ложь,
      "видимость": "общедоступная",
      "p Push_at": "2011-01-26T19: 06: 43Z",
      "created_at": "2011-01-26T19: 01: 12Z",
      "updated_at": "2011-01-26T19: 14: 43Z",
      "разрешения": {
        "админ": ложь,
        "push": ложь,
        "тянуть": правда
      },
      "allow_rebase_merge": правда,
      "temp_clone_token": "ABTLWHOULUVAXGTRYU7OC2876QJ2O",
      "allow_squash_merge": правда,
      "delete_branch_on_merge": правда,
      "allow_merge_commit": правда,
      "subscribers_count": 42,
      "network_count": 0
    },
    "владелец": {
      "логин": "octocat",
      "id": 1,
      "node_id": "MDQ6VXNlcjE =",
      "avatar_url": "https: // github. com / images / error / octocat_happy.gif ",
      "gravatar_id": "",
      "url": "https://api.github.com/users/octocat",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
      "subscriptions_url": "https: // api.github.com/users/octocat/subscriptions ",
      "organization_url": "https://api.github.com/users/octocat/orgs",
      "repos_url": "https://api.github.com/users/octocat/repos",
      "events_url": "https://api.github.com/users/octocat/events{/privacy}",
      "receive_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "Пользователь",
      "site_admin": ложь
    },
    "частный": ложь,
    "html_url": "https://github.com/octocat/Hello-World",
    "description": "Это ваше первое репо!",
    "вилка": ложь,
    "url": "https: // api. github.com/repos/octocat/Hello-World ",
    "archive_url": "https://api.github.com/repos/octocat/Hello-World/{archive_format}{/ref}",
    "assignees_url": "https://api.github.com/repos/octocat/Hello-World/assignees{/user}",
    "blobs_url": "https://api.github.com/repos/octocat/Hello-World/git/blobs{/sha}",
    "branch_url": "https://api.github.com/repos/octocat/Hello-World/branches{/branch}",
    "Collaborators_url": "https://api.github.com/repos/octocat/Hello-World/collaborators{/collaborator}",
    "comments_url": "https: // api.github.com/repos/octocat/Hello-World/comments{/number} ",
    "commits_url": "https://api.github.com/repos/octocat/Hello-World/commit{/sha}",
    "compare_url": "https://api.github.com/repos/octocat/Hello-World/compare/{base}...{head}",
    "contents_url": "https://api.github.com/repos/octocat/Hello-World/contents/{+path}",
    "Contributors_url": "https://api.github.com/repos/octocat/Hello-World/contributors",
    "deployments_url": "https://api.github.com/repos/octocat/Hello-World/deployments",
    "downloads_url": "https: // api. github.com/repos/octocat/Hello-World/downloads ",
    "events_url": "https://api.github.com/repos/octocat/Hello-World/events",
    "forks_url": "https://api.github.com/repos/octocat/Hello-World/forks",
    "git_commit_url": "https://api.github.com/repos/octocat/Hello-World/git/commit{/sha}",
    "git_refs_url": "https://api.github.com/repos/octocat/Hello-World/git/refs{/sha}",
    "git_tags_url": "https://api.github.com/repos/octocat/Hello-World/git/tags{/sha}",
    "git_url": "git: github.com/octocat/Hello-World.мерзавец ",
    "issue_comment_url": "https://api.github.com/repos/octocat/Hello-World/issues/comments{/number}",
    "issue_events_url": "https://api.github.com/repos/octocat/Hello-World/issues/events{/number}",
    "issues_url": "https://api.github.com/repos/octocat/Hello-World/issues{/number}",
    "keys_url": "https://api.github.com/repos/octocat/Hello-World/keys{/key_id}",
    "labels_url": "https://api.github.com/repos/octocat/Hello-World/labels{/name}",
    "languages_url": "https://api. github.com/repos/octocat/Hello-World/languages",
    "merges_url": "https: // api.github.com/repos/octocat/Hello-World/merges ",
    "milestones_url": "https://api.github.com/repos/octocat/Hello-World/milestones{/number}",
    "notifications_url": "https://api.github.com/repos/octocat/Hello-World/notifications{?since,all,participating}",
    "pulls_url": "https://api.github.com/repos/octocat/Hello-World/pulls{/number}",
    "Release_url": "https://api.github.com/repos/octocat/Hello-World/releases{/id}",
    "ssh_url": "[email protected]: octocat / Hello-World.git",
    "stargazers_url": "https: // api.github.com/repos/octocat/Hello-World/stargazers ",
    "statuses_url": "https://api.github.com/repos/octocat/Hello-World/statuses/{sha}",
    "subscribers_url": "https://api.github.com/repos/octocat/Hello-World/subscribers",
    "subscription_url": "https://api.github.com/repos/octocat/Hello-World/subscription",
    "tags_url": "https://api.github.com/repos/octocat/Hello-World/tags",
    "team_url": "https://api. github.com/repos/octocat/Hello-World/teams",
    "tree_url": "https://api.github.com/repos/octocat/Hello-World/git/trees{/sha}",
    "clone_url": "https: // github.com / octocat / Hello-World.git ",
    "mirror_url": "git: git.example.com/octocat/Hello-World",
    "hooks_url": "https://api.github.com/repos/octocat/Hello-World/hooks",
    "svn_url": "https://svn.github.com/octocat/Hello-World",
    "домашняя страница": "https://github.com",
    "язык": ноль,
    "forks_count": 9,
    "stargazers_count": 80,
    "watchers_count": 80,
    «размер»: 108,
    "default_branch": "мастер",
    "open_issues_count": 0,
    "is_template": ложь,
    "темы": [
      "октокэт",
      "атом",
      "электрон",
      "api"
    ],
    "has_issues": правда,
    "has_projects": правда,
    "has_wiki": правда,
    "has_pages": ложь,
    "has_downloads": правда,
    "в архиве": ложь,
    "отключен": ложь,
    "видимость": "общедоступная",
    "p Push_at": "2011-01-26T19: 06: 43Z",
    "created_at": "2011-01-26T19: 01: 12Z",
    "updated_at": "2011-01-26T19: 14: 43Z",
    "разрешения": {
      "админ": ложь,
      "push": ложь,
      "тянуть": правда
    },
    "temp_clone_token": "ABTLWHOULUVAXGTRYU7OC2876QJ2O",
    "delete_branch_on_merge": правда,
    "subscribers_count": 42,
    "network_count": 0
  },
  "head_commit": {
    "id": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d",
    "tree_id": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d",
    "message": "Объединить пул-реквест №6 из Spaceghost / patch-1 \ n \ nНовая строка в конце файла. ",
    "timestamp": "2016-10-10T00: 00: 00Z",
    "author": {
      "name": "Октокот",
      "электронная почта": "[email protected]"
    },
    "коммиттер": {
      "name": "Октокот",
      "электронная почта": "[email protected]"
    }
  },
  "latest_check_runs_count": 1,
  "check_runs_url": "https://api.github.com/repos/octocat/Hello-World/check-suites/5/check-runs"
}
  

Ответ при создании пакета

  Статус: 201 Создан  

  {
  "id": 5,
  "node_id": "MDEwOkNoZWNrU3VpdGU1",
  "head_branch": "мастер",
  "head_sha": "d6fde92930d4715a2b49857d24b940956b26d2d3",
  "статус": "завершено",
  «вывод»: «нейтральный»,
  "url": "https: // api.github.com/repos/github/hello-world/check-suites/5 ",
  "до": "146e867f55c26428e5f9fade55a9bbf5e95a7912",
  "после": "d6fde92930d4715a2b49857d24b940956b26d2d3",
  "pull_requests": [],
  "created_at": "2017-07-08T16: 18: 44-04: 00",
  «updated_at»: «2017-07-08T16: 18: 44-04: 00»,
  "приложение": {
    "id": 1,
    "слизняк": "октоапп",
    "node_id": "MDExOkludGVncmF0aW9uMQ ==",
    "владелец": {
      "логин": "github",
      "id": 1,
      "node_id": "MDEyOk9yZ2FuaXphdGlvbjE =",
      "url": "https://api. github.com/orgs/github",
      "repos_url": "https: // api.github.com/orgs/github/repos ",
      "events_url": "https://api.github.com/orgs/github/events",
      "avatar_url": "https://github.com/images/error/octocat_happy.gif",
      "gravatar_id": "",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https: // api.github.com/users/octocat/starred{/owner}{/repo} ",
      "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
      "organization_url": "https://api.github.com/users/octocat/orgs",
      "receive_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "Пользователь",
      "site_admin": правда
    },
    "name": "Приложение Octocat",
    "описание": "",
    "external_url": "https://example. com",
    "html_url": "https://github.com/apps/octoapp",
    "created_at": "2017-07-08T16: 18: 44-04: 00",
    «updated_at»: «2017-07-08T16: 18: 44-04: 00»,
    "разрешения": {
      "метаданные": "читать",
      "содержимое": "читать",
      "issues": "написать",
      "single_file": "написать"
    },
    "События": [
      "толкать",
      "pull_request"
    ]
  },
  "репозиторий": {
    "id": 1296269,
    "node_id": "MDEwOlJlcG9zaXRvcnkxMjk2MjY5",
    "name": "Hello-World",
    "full_name": "octocat / Hello-World",
    "template_repository": {
      "id": 1296269,
      "node_id": "MDEwOlJlcG9zaXRvcnkxMjk2MjY5",
      "name": "Шаблон Hello-World",
      "full_name": "octocat / Hello-World-Template",
      "владелец": {
        "логин": "octocat",
        "id": 1,
        "node_id": "MDQ6VXNlcjE =",
        "avatar_url": "https: // github.com / images / error / octocat_happy.gif ",
        "gravatar_id": "",
        "url": "https://api.github.com/users/octocat",
        "html_url": "https://github. com/octocat",
        "followers_url": "https://api.github.com/users/octocat/followers",
        "following_url": "https://api.github.com/users/octocat/following{/other_user}",
        "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
        "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
        "subscriptions_url": "https: // api.github.com/users/octocat/subscriptions ",
        "organization_url": "https://api.github.com/users/octocat/orgs",
        "repos_url": "https://api.github.com/users/octocat/repos",
        "events_url": "https://api.github.com/users/octocat/events{/privacy}",
        "receive_events_url": "https://api.github.com/users/octocat/received_events",
        "type": "Пользователь",
        "site_admin": ложь
      },
      "частный": ложь,
      "html_url": "https://github.com/octocat/Hello-World-Template",
      "description": "Это ваше первое репо!",
      "вилка": ложь,
      "url": "https: // api.github.com/repos/octocat/Hello-World-Template ",
      "archive_url": "https://api.github.com/repos/octocat/Hello-World-Template/{archive_format}{/ref}",
      "assignees_url": "https://api.github.com/repos/octocat/Hello-World-Template/assignees{/user}",
      "blobs_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/blobs{/sha}",
      "branch_url": "https://api.github.com/repos/octocat/Hello-World-Template/branches{/branch}",
      "Collaborators_url": "https://api.github.com/repos/octocat/Hello-World-Template/collaborators{/collaborator}",
      "comments_url": "https: // api.github.com/repos/octocat/Hello-World-Template/comments{/number} ",
      "commits_url": "https://api.github.com/repos/octocat/Hello-World-Template/commit{/sha}",
      "compare_url": "https://api.github.com/repos/octocat/Hello-World-Template/compare/{base}...{head}",
      "content_url": "https://api.github.com/repos/octocat/Hello-World-Template/contents/{+path}",
      "Contributors_url": "https://api.github.com/repos/octocat/Hello-World-Template/contributors",
      "deployments_url": "https: // api.github.com/repos/octocat/Hello-World-Template/deployments ",
      "downloads_url": "https://api.github.com/repos/octocat/Hello-World-Template/downloads",
      "events_url": "https://api.github.com/repos/octocat/Hello-World-Template/events",
      "forks_url": "https://api.github.com/repos/octocat/Hello-World-Template/forks",
      "git_commit_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/commit{/sha}",
      "git_refs_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/refs{/sha}",
      "git_tags_url": "https: // api.github.com/repos/octocat/Hello-World-Template/git/tags{/sha} ",
      "git_url": "git: github.com/octocat/Hello-World-Template.git",
      "issue_comment_url": "https://api.github.com/repos/octocat/Hello-World-Template/issues/comments{/number}",
      "issue_events_url": "https://api.github.com/repos/octocat/Hello-World-Template/issues/events{/number}",
      "issues_url": "https://api.github.com/repos/octocat/Hello-World-Template/issues{/number}",
      "keys_url": "https://api.github.com/repos/octocat/Hello-World-Template/keys{/key_id}",
      "label_url": "https: // api.github.com/repos/octocat/Hello-World-Template/labels{/name} ",
      "languages_url": "https://api.github.com/repos/octocat/Hello-World-Template/languages",
      "merges_url": "https://api.github.com/repos/octocat/Hello-World-Template/merges",
      "milestones_url": "https://api.github.com/repos/octocat/Hello-World-Template/milestones{/number}",
      "notifications_url": "https://api.github.com/repos/octocat/Hello-World-Template/notifications{?since,all,participating}",
      "pulls_url": "https: // api.github.com/repos/octocat/Hello-World-Template/pulls{/number} ",
      "Release_url": "https://api.github.com/repos/octocat/Hello-World-Template/releases{/id}",
      "ssh_url": "[email protected]: octocat / Hello-World-Template.git",
      "stargazers_url": "https://api.github.com/repos/octocat/Hello-World-Template/stargazers",
      "statuses_url": "https://api.github.com/repos/octocat/Hello-World-Template/statuses/{sha}",
      "subscribers_url": "https://api.github.com/repos/octocat/Hello-World-Template/subscribers",
      "subscription_url": "https: // api.github.com/repos/octocat/Hello-World-Template/subscription ",
      "tags_url": "https://api.github.com/repos/octocat/Hello-World-Template/tags",
      "team_url": "https://api.github.com/repos/octocat/Hello-World-Template/teams",
      "tree_url": "https://api.github.com/repos/octocat/Hello-World-Template/git/trees{/sha}",
      "clone_url": "https://github.com/octocat/Hello-World-Template.git",
      "mirror_url": "git: git.example.com/octocat/Hello-World-Template",
      "hooks_url": "https: // api.github.com/repos/octocat/Hello-World-Template/hooks ",
      "svn_url": "https://svn.github.com/octocat/Hello-World-Template",
      "домашняя страница": "https://github.com",
      "язык": ноль,
      «вилок»: 9,
      "forks_count": 9,
      "stargazers_count": 80,
      "watchers_count": 80,
      «наблюдателей»: 80,
      «размер»: 108,
      "default_branch": "мастер",
      "open_issues": 0,
      "open_issues_count": 0,
      "is_template": истина,
      "лицензия": {
        "ключ": "мит",
        "name": "Лицензия MIT",
        "url": "https: // api.github.com/licenses/mit ",
        "spdx_id": "MIT",
        "node_id": "MDc6TGljZW5zZW1pdA ==",
        «html_url»: «https://api.github.com/licenses/mit»
      },
      "темы": [
        "октокэт",
        "атом",
        "электрон",
        "api"
      ],
      "has_issues": правда,
      "has_projects": правда,
      "has_wiki": правда,
      "has_pages": ложь,
      "has_downloads": правда,
      "в архиве": ложь,
      "отключен": ложь,
      "видимость": "общедоступная",
      "p Push_at": "2011-01-26T19: 06: 43Z",
      "created_at": "2011-01-26T19: 01: 12Z",
      "updated_at": "2011-01-26T19: 14: 43Z",
      "разрешения": {
        "админ": ложь,
        "push": ложь,
        "тянуть": правда
      },
      "allow_rebase_merge": правда,
      "temp_clone_token": "ABTLWHOULUVAXGTRYU7OC2876QJ2O",
      "allow_squash_merge": правда,
      "delete_branch_on_merge": правда,
      "allow_merge_commit": правда,
      "subscribers_count": 42,
      "network_count": 0
    },
    "владелец": {
      "логин": "octocat",
      "id": 1,
      "node_id": "MDQ6VXNlcjE =",
      "avatar_url": "https: // github.com / images / error / octocat_happy.gif ",
      "gravatar_id": "",
      "url": "https://api.github.com/users/octocat",
      "html_url": "https://github.com/octocat",
      "followers_url": "https://api.github.com/users/octocat/followers",
      "following_url": "https://api.github.com/users/octocat/following{/other_user}",
      "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
      "subscriptions_url": "https: // api.github.com/users/octocat/subscriptions ",
      "organization_url": "https://api.github.com/users/octocat/orgs",
      "repos_url": "https://api.github.com/users/octocat/repos",
      "events_url": "https://api.github.com/users/octocat/events{/privacy}",
      "receive_events_url": "https://api.github.com/users/octocat/received_events",
      "type": "Пользователь",
      "site_admin": ложь
    },
    "частный": ложь,
    "html_url": "https://github.com/octocat/Hello-World",
    "description": "Это ваше первое репо!",
    "вилка": ложь,
    "url": "https: // api.github.com/repos/octocat/Hello-World ",
    "archive_url": "https://api.github.com/repos/octocat/Hello-World/{archive_format}{/ref}",
    "assignees_url": "https://api.github.com/repos/octocat/Hello-World/assignees{/user}",
    "blobs_url": "https://api.github.com/repos/octocat/Hello-World/git/blobs{/sha}",
    "branch_url": "https://api.github.com/repos/octocat/Hello-World/branches{/branch}",
    "Collaborators_url": "https://api.github.com/repos/octocat/Hello-World/collaborators{/collaborator}",
    "comments_url": "https: // api.github.com/repos/octocat/Hello-World/comments{/number} ",
    "commits_url": "https://api.github.com/repos/octocat/Hello-World/commit{/sha}",
    "compare_url": "https://api.github.com/repos/octocat/Hello-World/compare/{base}...{head}",
    "contents_url": "https://api.github.com/repos/octocat/Hello-World/contents/{+path}",
    "Contributors_url": "https://api.github.com/repos/octocat/Hello-World/contributors",
    "deployments_url": "https://api.github.com/repos/octocat/Hello-World/deployments",
    "downloads_url": "https: // api.github.com/repos/octocat/Hello-World/downloads ",
    "events_url": "https://api.github.com/repos/octocat/Hello-World/events",
    "forks_url": "https://api.github.com/repos/octocat/Hello-World/forks",
    "git_commit_url": "https://api.github.com/repos/octocat/Hello-World/git/commit{/sha}",
    "git_refs_url": "https://api.github.com/repos/octocat/Hello-World/git/refs{/sha}",
    "git_tags_url": "https://api.github.com/repos/octocat/Hello-World/git/tags{/sha}",
    "git_url": "git: github.com/octocat/Hello-World.мерзавец ",
    "issue_comment_url": "https://api.github.com/repos/octocat/Hello-World/issues/comments{/number}",
    "issue_events_url": "https://api.github.com/repos/octocat/Hello-World/issues/events{/number}",
    "issues_url": "https://api.github.com/repos/octocat/Hello-World/issues{/number}",
    "keys_url": "https://api.github.com/repos/octocat/Hello-World/keys{/key_id}",
    "labels_url": "https://api.github.com/repos/octocat/Hello-World/labels{/name}",
    "languages_url": "https://api.github.com/repos/octocat/Hello-World/languages",
    "merges_url": "https: // api.github.com/repos/octocat/Hello-World/merges ",
    "milestones_url": "https://api.github.com/repos/octocat/Hello-World/milestones{/number}",
    "notifications_url": "https://api.github.com/repos/octocat/Hello-World/notifications{?since,all,participating}",
    "pulls_url": "https://api.github.com/repos/octocat/Hello-World/pulls{/number}",
    "Release_url": "https://api.github.com/repos/octocat/Hello-World/releases{/id}",
    "ssh_url": "[email protected]: octocat / Hello-World.git",
    "stargazers_url": "https: // api.github.com/repos/octocat/Hello-World/stargazers ",
    "statuses_url": "https://api.github.com/repos/octocat/Hello-World/statuses/{sha}",
    "subscribers_url": "https://api.github.com/repos/octocat/Hello-World/subscribers",
    "subscription_url": "https://api.github.com/repos/octocat/Hello-World/subscription",
    "tags_url": "https://api.github.com/repos/octocat/Hello-World/tags",
    "team_url": "https://api.github.com/repos/octocat/Hello-World/teams",
    "tree_url": "https://api.github.com/repos/octocat/Hello-World/git/trees{/sha}",
    "clone_url": "https: // github.com / octocat / Hello-World.git ",
    "mirror_url": "git: git.example.com/octocat/Hello-World",
    "hooks_url": "https://api.github.com/repos/octocat/Hello-World/hooks",
    "svn_url": "https://svn.github.com/octocat/Hello-World",
    "домашняя страница": "https://github.com",
    "язык": ноль,
    "forks_count": 9,
    "stargazers_count": 80,
    "watchers_count": 80,
    «размер»: 108,
    "default_branch": "мастер",
    "open_issues_count": 0,
    "is_template": ложь,
    "темы": [
      "октокэт",
      "атом",
      "электрон",
      "api"
    ],
    "has_issues": правда,
    "has_projects": правда,
    "has_wiki": правда,
    "has_pages": ложь,
    "has_downloads": правда,
    "в архиве": ложь,
    "отключен": ложь,
    "видимость": "общедоступная",
    "p Push_at": "2011-01-26T19: 06: 43Z",
    "created_at": "2011-01-26T19: 01: 12Z",
    "updated_at": "2011-01-26T19: 14: 43Z",
    "разрешения": {
      "админ": ложь,
      "push": ложь,
      "тянуть": правда
    },
    "temp_clone_token": "ABTLWHOULUVAXGTRYU7OC2876QJ2O",
    "delete_branch_on_merge": правда,
    "subscribers_count": 42,
    "network_count": 0
  },
  "head_commit": {
    "id": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d",
    "tree_id": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d",
    "message": "Объединить пул-реквест №6 из Spaceghost / patch-1 \ n \ nНовая строка в конце файла.",
    "timestamp": "2016-10-10T00: 00: 00Z",
    "author": {
      "name": "Октокот",
      "электронная почта": "[email protected]"
    },
    "коммиттер": {
      "name": "Октокот",
      "электронная почта": "[email protected]"
    }
  },
  "latest_check_runs_count": 1,
  "check_runs_url": "https://api.github.com/repos/octocat/Hello-World/check-suites/5/check-runs"
}
  

Банкноты

сборок GitHub Pages теперь используют Checks API

Представьте, что вы обновляете свой сайт GitHub Pages.Вы нажимаете фиксацию, и начинается новая сборка. Сборка не выполняется, и сайт не развертывается. Но вы не знаете, как исправить ошибку, пока не получите уведомление по электронной почте со ссылками на документацию по устранению неполадок вашей сборки – так это работало, когда статусы были основным способом для GitHub Pages сообщать о статусах сборки. Когда все было построено успешно, было здорово. Когда возникала ошибка, было трудно понять, какая строка кода была виновата. Теперь, чтобы у всех была нужная информация для более быстрого продвижения вперед, мы интегрировали Checks API с GitHub Pages.

Обычно мы видим около 125 000 сборок GitHub Pages, и иногда вам нужна небольшая помощь в понимании ошибки, если что-то пойдет не так. Возможно, вы что-то опечатали в своем _config.yml или имеете недопустимый синтаксис в шаблоне Liquid. Это нормальная часть процесса, и именно для этих типов ошибок мы создали Checks API. Предоставление нашему сообществу контекста, необходимого для работы с ошибками сборки, экономит время на устранение неполадок, отладку и обращение в службу поддержки за помощью.

Что нового

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

Сообщите нам, что вы думаете

Мы развертываем эту интеграцию в течение следующих нескольких дней, и вскоре пользователи GitHub Pages будут автоматически запускать свои сборки с помощью Checks API. Мы очень рады этому изменению и надеемся, что вы тоже. Не стесняйтесь обращаться в Twitter, если у вас есть какие-либо отзывы о том, как GitHub Pages и Checks API работают на вас, или ознакомьтесь с документацией по продукту, если у вас есть вопросы.

Защитите свои ветки Git с помощью политик – Azure Repos

• 01.04.2021
• 15 минут на чтение

В этой статье

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

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

Настроить политики филиалов

Выберите Repos > Branch , чтобы открыть страницу Branch на веб-портале.

Найдите свой филиал на странице. Вы можете просмотреть список или найти свою ветку с помощью поля Искать во всех ветвях в правом верхнем углу.

Нажмите кнопку … . Выберите Branch policy из контекстного меню.

Настройте политики на странице Параметры . См. Следующие разделы для описания каждого типа политики.

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

Требуется минимальное количество рецензентов

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

Базовая политика требует, чтобы определенное количество рецензентов одобрили код без отклонений.

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

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

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

Примечание

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

• Минимальное количество рецензентов требует двух рецензентов.
• Запрашивающие могут утверждать свои изменения. не задано.
• Группа Fabrikam Team является обязательным рецензентом, и Джамал является членом этой группы.

В этом примере, поскольку Джамал является частью группы Fabrikam Team , его голос Approve удовлетворяет требуемой политике рецензента.Запрос на вытягивание по-прежнему требует двух дополнительных голосов Утвердить , чтобы соответствовать политике Минимальное количество проверяющих , поскольку его голос не учитывается в этой политике.

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

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

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

Дополнительные сведения о работе с комментариями к запросу на вытягивание см. В разделе Запросы на вытягивание – оставлять комментарии.

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

Дополнительные сведения о работе с комментариями к запросу на вытягивание см. В разделе Запросы на вытягивание – оставлять комментарии.

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

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

• Базовое слияние (без перемотки вперед) – создает фиксацию слияния в целевом объекте, родителями которого являются целевая и исходная ветки.
• Squash merge – создает линейную историю с одной фиксацией в целевой ветке с изменениями из исходной ветки.Узнайте больше о слиянии сквоша и о том, как оно влияет на историю вашей ветки.
• Rebase and fast-forward – создает линейную историю, воспроизводя исходные фиксации в целевой ветке без фиксации слияния.
• Rebase with merge commit – воспроизводит исходные коммиты на целевом объекте и по-прежнему создает коммит слияния.

Применение стратегии слияния

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

• Нет быстрого слияния вперед – этот параметр объединяет историю фиксации исходной ветки при закрытии запроса на извлечение и создает фиксацию слияния в целевой ветке.
• Слияние сквоша – Завершите все запросы на вытягивание слиянием сквоша, создав единую фиксацию в целевой ветке с изменениями из исходной ветки.Узнайте больше о слиянии сквоша и о том, как оно влияет на историю вашей ветки.

Проверка сборки

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

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

Важно

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

Нажмите кнопку + рядом с Проверка сборки .

1. Выберите конвейер сборки .

2. Дополнительно установите Path filter . Узнайте больше о фильтрах пути в политиках ветвления.

3. Выберите тип Триггер . Выберите Автоматический (при обновлении исходной ветви) или Ручной .

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

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

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

6. Введите необязательное Отображаемое имя для этой политики сборки. Это имя определяет политику на странице Политика ветвления .Если вы не укажете отображаемое имя, политика будет использовать имя конвейера сборки.

7. Выберите Сохранить .

Когда владелец отправляет изменения, успешно построенные, статус политики обновляется. Если у вас есть Сразу после обновления имени ветки или После n часов, если имя ветки было обновлено , выбрана политика сборки , статус политики обновляется, когда обновляется защищенная ветка, если самая последняя сборка более не действительно.

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

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

Важно

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

Выберите Добавить политику сборки и настройте параметры в Добавить политику сборки .

1. Выберите определение сборки .

2. Выберите тип Триггер . Выберите Автоматический (при обновлении исходной ветви) или Ручной .

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

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

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

5. Введите необязательное Отображаемое имя для этой политики сборки. Это имя определяет политику на странице Политика ветвления . Если вы не укажете отображаемое имя, политика будет использовать имя определения сборки.

6. Выберите Сохранить .

Когда владелец отправляет изменения, успешно построенные, статус политики обновляется.Если у вас есть Сразу после обновления имени ветки или После n часов, если имя ветки было обновлено , выбрана политика сборки , статус политики обновляется, когда обновляется защищенная ветка, если самая последняя сборка более не действительно.

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

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

Инструкции по настройке этой политики см. В разделе Настройка политики ветвления для внешней службы.

Требуется одобрение внешних служб

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

Инструкции по настройке этой политики см. В разделе Настройка политики ветвления для внешней службы.

Автоматически включать рецензентов кода

Выберите рецензентов для определенных каталогов и файлов в вашем репо.

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

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

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

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

Вы можете выбрать Разрешить запрашивающим утверждать свои изменения .

Вы можете выбрать Запрашивающие могут утверждать свои изменения .

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

Обход политики ветвления

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

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

Это заменяет предыдущее одиночное разрешение.

В TFS 2015 – TFS 2018 с обновлением 2 разрешение Освобождено от применения политики позволяет пользователям с этим разрешением выполнять следующие действия:

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

Важно

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

Пути фильтры

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

Вы можете указать абсолютные пути и символы подстановки. Примеры:

• /WebApp/Models/Data.cs
• / WebApp / *
• * .cs

Вы можете указать несколько путей с помощью ; в качестве разделителя. Пример:

• / Веб-приложение / Модели / Данные.cs; ClientApp / Models / Data.cs

Пути с префиксом ! исключаются, если они были бы включены в ином случае. Пример:

• / WebApp / *;! / WebApp / Tests / * – включает все файлы в / WebApp , кроме файлов в / WebApp / Tests
• ! / WebApp / Tests / * – не указывает файлов, так как сначала ничего не включается

Порядок фильтров имеет значение. Они применяются слева направо.

Вопросы и ответы

Могу ли я отправить изменения непосредственно в ветвь после настройки политики ветвления?

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

Примечание

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

Что такое автозаполнение?

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

Когда проверяются условия, установленные в политиках филиалов?

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

Могу ли я использовать определения сборки XAML в политиках филиалов?

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

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

Одинарные звездочки ( * ) и соответствуют любому количеству символов, включая косую черту (/) и обратную косую черту ( \ ). Вопросительные знаки (? ) соответствуют любому одиночному символу.

Примеры:

• * .sql соответствует всем файлам с расширением .sql
• / ConsoleApplication / * соответствуют всем файлам в папке с именем ConsoleApplication
• /.gitattributes соответствует файлу .gitattributes в корне репо
• * /. Gitignore соответствует любому файлу .gitignore в репо

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

Нет, в настоящее время в политиках филиалов не учитывается регистр.

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

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

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

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

Где я могу получить дополнительную информацию о расширенных настройках политик?

Дополнительные сведения см. В документации по REST API.

Проверка и объединение кода с запросами на вытягивание – 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 ветка . Требовать пул-реквест для внесения любых изменений в эти ветки Разработчики, отправляющие изменения непосредственно в защищенные ветви, будут отклонены.

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

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

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

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

1. Чтобы просмотреть запросы на вытягивание в определенном репозитории в проекте, перейдите в этот проект на веб-портале и выберите Repos > Pull requests .

2. Убедитесь, что вы выбрали правильный репозиторий.

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

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

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

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

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

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

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

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

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

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

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

Когда вы публикуете или обновляете ветку компонентов, Azure Repos предлагает вам создать запрос на вытягивание в представлении Code в Интернете. Это приглашение отображается в запросах на извлечение и в файлах .

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

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

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

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

2. В области Разработка рабочего элемента выберите Создать запрос на вытягивание .

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

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

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

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

из Visual Studio

Примечание

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

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

1. Подключитесь к своему проекту из Visual Studio.

2. Выберите View > Team Explorer , чтобы открыть Team Explorer. Вы также можете выбрать Ctrl + \, затем Ctrl + m.

3. Выберите Home , затем выберите Pull Requests .

4. Выберите New Pull Request , чтобы открыть веб-браузер, в котором вы можете создать новый запрос на вытягивание на веб-портале Azure DevOps Services.

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

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

Добавьте рецензентов в запрос на включение:

1. Выберите Обзор в запросе на вытягивание.

2. Нажмите кнопку Добавить в области Проверяющие , а затем выберите Требуется или Дополнительно .

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

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

Добавьте рецензентов в запрос на включение:

1. Выберите Обзор в запросе на вытягивание.

2. Нажмите кнопку Добавить в области Проверяющие .

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

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

Добавьте рецензентов в запрос на включение:

1. Выберите вкладку Обзор в запросе на вытягивание.

2. Нажмите кнопку добавления в области Рецензенты .

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

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

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

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

1. Выберите вкладку Обзор в запросе на вытягивание.

2. Нажмите кнопку добавления в области Рабочие элементы .

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

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

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

1. Выберите вкладку Обзор в запросе на вытягивание.

2. Нажмите кнопку добавления в области Рабочие элементы .

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

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

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

1. Выберите Обзор в запросе на вытягивание.

2. Нажмите кнопку добавления в области Рабочие элементы .

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

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

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

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

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

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

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

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

Начиная с 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 .Возможно, вам потребуется настроить таргетинг на другую ветку, но легко забыть изменить целевую ветвь по умолчанию. Чтобы изменить целевую ветвь активного запроса на вытягивание, см. Раздел Изменение целевой ветви запроса на вытягивание.

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

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

   • Complete : завершите запрос на вытягивание сейчас и объедините изменения в целевую ветвь.
   • Установить автозаполнение : Если у вас есть политики ветвления, вы можете выбрать Установить автозаполнение , чтобы настроить запрос на закрытие, когда он соответствует всем политикам ветвления.
   • Abandon : Закройте запрос на вытягивание без объединения изменений.

2. В Завершить запрос на извлечение введите сообщение для фиксации слияния и обновите описание запроса на извлечение.

3. Выберите свой Тип слияния :

   • Слияние (без перемотки вперед) : нелинейная история с сохранением всех коммитов.
   • Squash commit : линейная история только с одной фиксацией на цели (сквош-слияние вашего запроса на вытягивание).
   • Rebase and fast-forward : Rebase source фиксируется на цели и выполняется быстрая перемотка вперед.
   • Полулинейное слияние : Rebase source фиксируется на целевом объекте и создает слияние двух родителей.

   Примечание

   Существующие политики все еще применяются. Например, если в вашей ветке в настоящее время действует политика «только сквош-слияние», вам придется отредактировать эту политику, чтобы использовать новые типы слияния.

4. Выберите любой из следующих параметров после завершения (некоторые параметры недоступны в зависимости от типа слияния):

   • Завершите связанные рабочие элементы после объединения , чтобы завершить все связанные рабочие элементы.
   • Удалите <имя ветки> после слияния , чтобы удалить исходную ветвь из запроса на вытягивание.
   • Настройте сообщение фиксации слияния , чтобы добавить пользовательское сообщение фиксации слияния.
   • Переопределить политики ветвления и включить слияние , чтобы заставить ветвь объединиться, даже если она не удовлетворяет всем политикам ветвления.Этот параметр доступен только в том случае, если у вас есть разрешения Освобождение от применения политики.

5. Выбрать Завершить слияние .

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

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

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

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

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

   • Complete : завершите запрос на вытягивание сейчас и объедините изменения в целевую ветвь.
   • Установить автозаполнение : Если у вас есть политики ветвления, вы можете выбрать Установить автозаполнение , чтобы настроить запрос на закрытие, когда он соответствует всем политикам ветвления.
   • Abandon : Закройте запрос на вытягивание без объединения изменений.

2. В Завершить запрос на извлечение введите сообщение для фиксации слияния и обновите описание запроса на извлечение.

3. Выберите любой из следующих вариантов:

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

   Примечание

   Существующие политики все еще применяются. Например, если в вашей ветке в настоящее время действует политика «только сквош-слияние», вам придется отредактировать эту политику, чтобы использовать новые типы слияния.

4. Выбрать Завершить слияние .

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

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

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

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

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

   • Complete : завершите запрос на вытягивание сейчас и объедините изменения в целевую ветвь.
   • Установить автозаполнение : Если у вас есть политики ветвления, вы можете выбрать Установить автозаполнение , чтобы настроить запрос на закрытие, когда он соответствует всем политикам ветвления.
   • Abandon : Закройте запрос на вытягивание без объединения изменений.

2. В Завершить запрос на извлечение введите сообщение для фиксации слияния и обновите описание запроса на извлечение.

3. Выберите любой из следующих вариантов после завершения:

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

4. Выбрать Завершить слияние .

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

• Выберите Новая подписка , чтобы подписаться на дополнительные уведомления.

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

• Чтобы отказаться от уведомления, установите State на Off .

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

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

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

• Чтобы отказаться от уведомления, установите State на Off .

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

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

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

2. В Целевая ветка выберите ветку, в которой вы хотите отменить изменения запроса на вытягивание.

3. В Имя ветки темы выберите новую ветку, в которой создаются отмененные изменения, затем выберите Вернуть .

4. Выберите Создать запрос на перенос , чтобы объединить вновь созданную ветвь во второй запрос на перенос для завершения возврата.

Примечание

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

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

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

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

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

3. В Имя ветки темы введите новую ветку, которая будет содержать скопированные изменения, затем выберите Cherry-pick .

4. Выберите Создать запрос на перенос , чтобы объединить тематическую ветвь с целевой веткой, чтобы завершить выбор.

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

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

1. Перейдите в свой репозиторий и выберите Ветви .

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

3. Выберите … рядом с нужной веткой и выберите Установить как ветку по умолчанию .

4. После того, как вы установили новую ветку по умолчанию, вы можете удалить предыдущую, если хотите.

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

2. Выберите Контроль версий .

3. Выберите репозиторий Git. Ваши ветки отображаются под вашим репо.

4. Выберите … рядом с веткой, которую вы хотите установить по умолчанию, затем выберите Установить как ветку по умолчанию .

5. После того, как вы установили новую ветку по умолчанию, вы можете удалить предыдущую, если хотите.

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

Использование шаблонов запросов на вытягивание Github и проверок для реализации контрольных списков безопасности

Это сообщение в блоге покажет один из способов включения контрольных списков безопасности в анализ кода и Поток запросов на вытягивание в GitHub.

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

Вчера я добавил это в процесс нашей организации примерно за 90 секунд, используя существующая функциональность GitHub. Бесплатно.

Я должен поблагодарить моего коллегу Джо Керби за это сообщение в блоге (@iamjoeker), который указал мне на обе составляющие, которые заставляют эту идею работать.

Контрольный список

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

• Предотвращенное внедрение (команды и SQL – параметризованные запросы)
• Prevented XSS (Используемый фреймворк, который выполняет экранирование и не обходится)
• Реализована авторизация
• Выявление любых конфиденциальных данных и обработка в соответствии с классификацией данных

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

Использование шаблона запроса на слияние

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

Итак, в этом случае мы можем создать такой файл:

  ## Контрольный список безопасности

- [] Авторизация была реализована для этих изменений
- [] Внедрение было предотвращено (параметризованные запросы, без eval или системных вызовов)
- [] Любой веб-интерфейс экранирует вывод (для предотвращения XSS)
- [] Конфиденциальные данные были идентифицированы и должным образом защищены.

## Дополнительные шаги развертывания

В этом разделе перечислены любые дополнительные шаги по развертыванию PR.

  

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

Я могу редактировать и устанавливать эти флажки прямо в пользовательском интерфейсе при создании запроса на перенос.

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

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

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

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

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

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

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

Заключение

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

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

Список литературы

Мэтт – инженер-программист. Он наш генеральный директор, бывший председатель и член правления OWASP.

  {
"действие": "повторно запрошено",
"check \ _run": {
    ...,
"выход": {
"title": "Защита временной шкалы: отсутствуют фрагменты истории",
"summary": "Ой.\\\\ ./] +) \ * $ ') шаблон добавлен ",
"аннотации \ _count": 0,
"annotations \ _url": "https://api.github.com/repos/aio-libs/aiohttp/check-runs/163078825/annotations"},
"name": "Защита хронологии",
"check \ _suite": {
"id": 157188790,
"узел \ _id": "MDEwOkNoZWNrU3VpdGUxNTcxODg3OTA =",
"head \ _branch": null,
"head \ _sha": "df644394d03c0076678f4ebc95c5d99d743ab3f2",
"статус": "завершено",
"вывод": "сбой",
"url": "https://api.github.com/repos/aio-libs/aiohttp/check-suites/157188790",
«до»: ноль,
"после": ноль,
"pull \ _requests": [

      ],
      ...,
"created \ _at": "2019-07-06T16: 45: 49Z",
"updated \ _at": "2019-07-06T16: 45: 50Z"},
    ...,
"pull \ _requests": [

    ]
  },
  ...
}
  

  {
"действие": "повторно запрошено",
"check \ _run": {
    ...,
"name": "Защита хронологии",
"check \ _suite": {
      ...,
"pull \ _requests": [
        {
"url": "https://api.github.com/repos/sanitizers/browntruck/pulls/1",
"id": 235276563,
"номер 1,
"глава": {
"ref": "feature / github-app-aiohttp",
"ша": "f2114ef3a920b908d091aaeb9377a119807f0380",
"репо": {
"id": 160039456,
"url": "https: // api.github.com/repos/sanitizers/browntruck ",
"name": "browntruck"}
          },
"база": {
"ref": "master",
"sha": "6869c0bad05e74c5de5aaa6ff9f74e35b9626b6d",
"репо": {
"id": 160039456,
"url": "https://api.github.com/repos/sanitizers/browntruck",
"name": "browntruck"}
          }
        }
      ],
      ...
    },
    ...,
"pull \ _requests": [
      {
"url": "https://api.github.com/repos/sanitizers/browntruck/pulls/1",
"id": 235276563,
"номер 1,
"глава": {
"ref": "feature / github-app-aiohttp",
"ша": "f2114ef3a920b908d091aaeb9377a119807f0380",
"репо": {
"id": 160039456,
"url": "https: // api.github.com/repos/sanitizers/browntruck ",
"name": "browntruck"}
        },
"база": {
"ref": "master",
"sha": "6869c0bad05e74c5de5aaa6ff9f74e35b9626b6d",
"репо": {
"id": 160039456,
"url": "https://api.github.com/repos/sanitizers/browntruck",
"name": "browntruck"}
        }
      }
    ]
  },
  ...
}