Содержание

какие нужны документы, как подготовиться

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

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

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

Содержание

Проверка ГИТ

Проверки ГИТ бывают разные, к некоторым можно успеть подготовиться, а к другим – не особо. Мне все же кажется, что лучше максимально заранее все подготовить, чтобы не сидеть и переживать: “Найдет, не найдет?”

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

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

  1. Плановые 
  2. Внеплановые.

В любом случае, какая бы ни была проверка, она должна проходить в рамках Федерального Закона № 294-ФЗ от 26.12.2008 “О защите прав ЮЛ и ИП при осуществлении госконтроля (надзора) и муниципального контроля”.

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

Название “Плановая проверка ГИТ” говорит само за себя, проводится она по сводному плану проверок, который публикуется в конце года на сайте Прокуратуры на будущий год.

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

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

Конечно, хорошо, что время известно заранее, но все же радоваться этому пока рано.

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

Выездная плановая проверка ГИТ

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

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

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

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

А ведь это не правомерно, так как они не могут сейчас проверять не по проверочным листам, соответственно запрос должен быть по листу, а не по хотелке, время хотелок ушло и в подкреплении моих слов Генпрокуратура выпустило разъясняющее письмо 9 февраля 2018г.
№ 76/2-156-2018.

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

Документарная плановая проверка ГИТ

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

В данном случае все просто, получили запрос, подготовили копии документов, заверили – и в течение 10 дней отправили в ГИТ. 

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

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

Категория риска предприятия по охране труда

Начиная с 22 октября 2019 года, подготовка к проверке ГИТ должна проходить с учетом нового законодательства по регламенту (Приказ № 160 от 13.

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

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

Раньше все предприятия проверялись 1 раз в 3 года, теперь же периодичность проверок ГИТ зависит от категории, если ее не присвоили, значит, она низкая и планового приезда инспектора можно не ждать.

Категории риска и периодичность проверок

Категория риска предприятия по охране труда зависит от:

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

Вы можете самостоятельно рассчитать категорию риска по методике в Постановлении Правительства № 875 от 01. 09.2012г., но предупреждаю, что расчет там довольно сложный. Если вы сомневаетесь в своих силах по этому поводу, можно сделать запрос в ГИТ в свободной форме и в течение 15 рабочих дней вам дадут ответ (п. 13 Правил, утв. постановлением Правительства от 17.08.2016 № 806).

Отмена проверок ГИТ

Важная информация для субъектов малого предпринимательства (МП) – до конца 2020 года они освобождены от плановых проверок ( ч. 1 ст. 26.2 ФЗ № 294 от 26.12.2008г.), кроме:

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

А в остальном, если ваша организация относится к МП и включена в план проверок, вы имеете право написать письмо-заявление в ГИТ с просьбой отменить проверку. Такое же заявление можете направить в случае, если не согласны с присвоенной вам категорией риска.

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

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

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

О ее назначении вас уведомят лишь за 24 часа до начала ее проведения, а если поводом служит угроза жизни и здоровью работников – вообще без уведомления. 

Повод для назначения – это нарушение требований ТК РФ. Сейчас расскажу про некоторые из них, если вы захотите поделиться своим опытом, пишите об этом в комментариях.

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

Основания , при которых назначается внеплановая проверка при угрожающих ситуациях

Основания указывают в пунктах 6 и 9 распоряжений. Если законных оснований нет, то ее назначение можно обжаловать в вышестоящем органе или в суде (ч. 1 ст. 20, п. 4 ст. 21 Закона № 294). 

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

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

В рамках проведения проверки, работодатель должен предоставить все, что запросил инспектор, потому как за отказ можно поплатиться административной ответственностью в виде штрафа по ст. 19.7.и 19.4.1 КоАП.

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

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

Внеплановые проверки ГИТ делятся на несколько больше видов, чем плановые:

  1. Документарная – чаще всего по жалобе работника и ограничивается рассмотрением документов.
  2. Выездная назначается, если необходимо изучить соблюдение требований безопасности на месте.
  3. Если назначена комплексная, проверять инспектор будет все – от и до – соблюдение трудового законодательства в кадровых вопросах и касательно охраны труда.
  4. Целевая  – выездная проверка по жалобе работника, уволенного или еще работающего. Как я уже говорила, запрашиваются только те документы, которые требуются в соответствии с заявлением сотрудника.
  5. Тематическая проверка сейчас становится очень популярной, потому как назначают ее по обращению гражданина, который не желает, чтобы работодатель узнал его имя (ст. 358 ТК РФ). При таком виде проверки рассматривают материалы не касательно данного человека, а всю сферу, относительно которой была составлена жалоба. Например, пожаловался на плохое обеспечение СИЗ – проверяют всю организацию и обеспечение каждого работника спецодеждой.

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

Согласование ГИТ с прокуратурой внеплановых выездных проверок

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

Такое бывает крайне редко, но узнать, в каких случаях требуется согласование (п.5 ст.10 ФЗ № 294), будет явно не лишним. Если говорить в общем, то оно требуется, если возникла угроза жизни и здоровью работников. 

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

Причины для назначения внеплановой проверки

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

Достаточно много проверок не подлежит согласованию с прокуратурой (п.100 Регламента):

Примеры назначения внеплановой проверки ГИТ без согласования с прокуратурой

Прокуратура, рассмотрев материалы документы и материалы ГИТ, может и отказать в согласовании проведения проверки, например, из-за недостаточности информации или ряда других причин (п.103 Регламента). Надежды на это мало, но вероятность такая может быть.

Что проверяет ГИТ в ходе выездной проверки

Административным регламентом (п. 13 приказ № 160 от 13. 06.2019г.) закреплен перечень документов, которые могут быть затребованы инспектором, если вам назначена выездная проверка ГИТ, поэтому рекомендую ознакомиться с ним и быть готовым “во всеоружии”.

Ничего сверх этого списка инспектор по труду запрашивать не имеет права, а если все же это произошло, можно направить в ГИТ уточняющее письмо и попросить разъяснить основание для предоставления документа, не входящего п.13 Регламента.

Срок проведения проверки

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

Если ваша организация относится к субъектам малого предпринимательства (СМП) – не более 50 часов, для микропредприятий назначаются проверки продолжительностью не более 15 часов.

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

Если в ходе процедуры возникает необходимость провести дополнительные исследования, экспертизу и так далее по обоснованному требованию инспектора ГИТ, плановая проверка может быть продлена на 20 рабочих дней, для МСП – на 50 часов, микропредприятиям –на 15 часов.

рамка Для внеплановых выездных проверок срок один для всех – не более 20 рабочих дней и продлению не подлежит (п.107 Регламента).

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

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

Журнал учета проверок

В каждой организации в обязательном порядке должен быть журнал учета проверок ЮЛ и ИП, проводимых органами государственного контроля (п. 8 ст. 16 закона № 294-ФЗ).

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

Форму журнала можно посмотреть в Приложении 4 Приказа Минэкономразвития РФ  N 141 от 30 апреля 2009 г. Журнал учета проверок ведут одним экземпляром на все предприятие и желательно закрепить постоянное место хранения, как правило, это рабочее место секретаря организации.

Образец журнала учета проверок юридического лица

Образец журнала регистрации проверок в организации

Окончание проверки

До окончания срока (обычно это последние дни) проверяющий инспектор по труду составляет:

  1. Акт проверки в двух экземплярах (Приказ Минэкономразвития № 141). Его вам выдают под подпись о вручении, если вы с чем-то не согласны, можете указать свои замечания. Если у вас нет возможности явиться в ГИТ за актом, вам его вышлют почтой.
  2. Предписание об устранении нарушений. Если у вас все прошло без замечаний, то такой документ не получите, в противном случае инспектор укажет там свои замечания с отсылками на пункт и статью НПА, по которой было нарушение, с последующей проверкой выполнения. Рекомендую внимательно проверять соответствие указанных пунктов реалиям вашей организации, инспектор ведь тоже человек, может и ошибиться.
  3. Протокол об административном правонарушении, вместе с ним готовится постановление о назначении административного наказания, в котором будет указана сумма штрафа. Привлечь к ответственности, помимо юридического лица, могут и должностные.

Даже в своей практике я частенько видела, что представители организации не согласны с выписанными замечаниями и хотят их обжаловать. Обжалование акта проверки инспекции труда – обычное дело, вы можете обратиться в суд с жалобой в течение 10 календарных дней со дня получения списка нарушений (ч. 2 ст. 357 ТК РФ).

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

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

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

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

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

Инспекция рассмотрит ваше обращение и пойдет навстречу, если причина реальная и обоснованная. Главное – не затягивайте с обращением и не оставляйте его на последние дни.

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

Итоговые выводы

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

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

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

Как говорится, “готовь сани летом”, так и тут, прочитав статью и узнав обо всех нюансах, можно уже не так сильно переживать о посещении вашей организации инспектором 🙂

Желаю вам безопасной и эффективной работы!

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

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

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

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

Что нового предлагают?

До конца июля 2020 года депутаты Госдумы обещают рассмотреть законопроект, который уточнит сроки проведения проверок юридических лиц, у которых имеются филиалы, представительства и обособленные структурные подразделения. Авторы инициативы предлагают дополнить ч.4 ст.13 Федерального закона от 26 декабря 2008 года № 294-ФЗ «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля» правилом, что общий срок плановой проверки не может превышать 60 рабочих дней в течение трех лет.

Отметим, что в законодательстве подобную норму в отношении некоторых видов государственного и муниципального контроля ввели еще в 2011 году. Но из-за расплывчатости формулировок ситуация, когда компанию с обособленными подразделениями в разных регионах проверяют несколько раз и с превышением установленного срока в 60 дней, не изменилась. Чаще всего нарушают правило Россельхознадзор, Роспотребнадзор, МЧС, иногда затягивает сроки и Роструд, выяснили в Госдуме.

Чтобы снизить административную нагрузку на организации, которые имеют филиалы в различных субъектах РФ, в законе № 294-ФЗ предлагается четко указать, какие предусмотрены сроки проверки трудовой инспекции: в новом варианте они не могут превышать 60 рабочих дней независимо от наличия обособленных подразделений. И эта норма будет распространяться на все без исключения виды муниципального и государственного планового контроля.

Виды проверок

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

Плановая проверка

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

  • государственной регистрации юридического лица;
  • окончания проведения последней плановой проверки юридического лица;
  • начала осуществления юридическим лицом предпринимательской деятельности, связанной с выполнением работ или предоставлением услуг, требующих предоставления уведомления о начале такой деятельности. В частности, речь идет о гостиничных и бытовых услугах, сервисах общественного питания, розничной и оптовой торговле, некоторых видах услуг по перевозке пассажиров и грузов. Подробный список этих видов деятельности можно найти в утвержденном Правительством РФ Перечне работ и услуг (Постановление Правительства РФ от 16.07.2009 № 584).

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

До 31 декабря федеральные органы исполнительной власти, уполномоченные на осуществление контроля, составляют план проведения плановых проверок на следующий год и размещают его на своих официальных сайтах в сети Интернет. Найти списки проверок можно по адресам: http://git78.rostrud.ru/plan/, https://proverki. gov.ru, http://plan.genproc.gov.ru/. Это единственно достоверный способ, как узнать о проверке трудовой инспекции и неспешно подготовиться к ней.

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

В соответствии со статьей 26.1 Федерального закона от 26.12.2008 № 294-ФЗ «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля», с 01.01.2016 по 31.12.2018 не проводятся плановые проверки в отношении юридических лиц, индивидуальных предпринимателей, отнесенных к субъектам малого и среднего предпринимательства статьей 4 Федерального закона от 24.07.2007 № 209-ФЗ «О развитии малого и среднего предпринимательства в Российской Федерации». В связи с принятием Федерального закона от 25.12.2018 № 480-ФЗ, мораторий на проверки продлили до 31.12.2019, хотя есть и некоторые особенности. В частности, проверки, организованные надзорными органами, перешедшими на риск-ориентированный контроль, не запрещены.

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

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

Компания вправе подать в орган государственного контроля заявление об исключении из ежегодного плана проведения плановых проверок, если полагает, что проверка включена в план в нарушение положений указанной статьи. Порядок подачи и рассмотрения такого заявления определен Постановлением Правительства РФ от 26.11.2015 № 1268.

Внеплановая проверка

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

Внеплановая проверка осуществляется:

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

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

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

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

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

  • о плановой проверке — не позднее чем за три рабочих дня до ее начала;
  • о внеплановой проверке — не менее чем за 24 часа до начала ее проведения.

Документарные проверки

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

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

Выездные проверки

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

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

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

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

Срок проведения проверки трудовой инспекцией

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

При необходимости инспекция может продлить сроки проверки, но не более чем на 20 рабочих дней, а в отношении малых предприятий и микропредприятий — не более чем на 15 часов.

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

Продление срока внеплановой и документарной проверок не допускается.

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

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

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

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

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

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

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

Кадровые документы должны храниться в организации в соответствии со сроками, которые установлены в утвержденном Приказом Минкультуры России от 25.08.2010 № 558 «Перечне типовых управленческих архивных документов, образующихся в процессе деятельности государственных органов, органов местного самоуправления и организаций, с указанием сроков хранения». Соблюдать указанные в Перечне сроки должны все организации независимо от формы собственности (п. 1.2 Перечня, Решение ВАС РФ от 21.02.2012 № 14589/11).

Права и обязанности работодателя при проведении выездной проверки

Работодатель имеет право:

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

При выездной проверке работодатель обязан:

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

Результат проверки

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

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

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

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

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

Штрафы по результатам проверки

Привлечение к административной ответственности чаще всего выражается в наложении штрафа. Работодатели должны помнить, что выявленные в рамках одной проверки несколько нарушений норм законодательства о труде образуют самостоятельные составы административных правонарушений (Постановление Президиума Верховного суда РФ от 15. 08.2014 № 60-АД14-16). Это означает, что по итогам одной проверки при обнаружении нескольких разных нарушений штраф будет наложен за каждое.

Вместе с тем работодатели должны знать, что выявленные в ходе двух разных проверок одни и те же нарушения могут образовывать единый состав правонарушения, а значит, штраф в таком случае должен быть только один. Подобный случай разбирал Верховный суд РФ: несколько работников пожаловались в ГИТ на нарушение их прав при сокращении. В результате двух внеплановых проверок инспекторы вынесли два отдельных постановления о привлечении к ответственности должностного лица работодателя, при этом тип правонарушения был единый. Вынося решение по данному делу, судьи подчеркнули, что однотипные нарушения должны быть включены в единый состав административного правонарушения, а значит, и штраф должен быть один, а не два. То, что штрафы выписывались по результатам двух разных проверок, и то, что пострадавшими были разные люди, судьи не посчитали фактом, позволяющим назначить двойное наказание за одно и то же нарушение законодательства о труде (Постановление ВС РФ от 01. 10.2018 № 41-АД18-21).

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

Что изменилось в проверках ГИТ в 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 звезд - очень полезна. Мы хотим, чтобы вы получали только нужные материалы, и будем благодарны за обратную связь!

Статья 9. Организация и проведение плановой проверки / КонсультантПлюс

Перспективы и риски арбитражных споров и споров в суде общей юрисдикции. Ситуации, связанные со ст. 9

Арбитражные споры:

- Заявитель хочет признать незаконным предписание Роспотребнадзора

Споры в суде общей юрисдикции:

- Организация (ИП, заинтересованное лицо) хочет признать незаконным предписание (заключение) Гострудинспекции

 

1. Предметом плановой проверки является соблюдение юридическим лицом, индивидуальным предпринимателем в процессе осуществления деятельности совокупности предъявляемых обязательных требований и требований, установленных муниципальными правовыми актами, а также соответствие сведений, содержащихся в уведомлении о начале осуществления отдельных видов предпринимательской деятельности, обязательным требованиям.(в ред. Федерального закона от 14.10.2014 N 307-ФЗ)

(см. текст в предыдущей редакции)

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

(часть 1.1 в ред. Федерального закона от 25.12.2018 N 480-ФЗ)

(см. текст в предыдущей редакции)

1.2. Правительством Российской Федерации в отношении отдельных видов государственного контроля (надзора), определяемых в соответствии с частями 1 и 2 статьи 8.1 настоящего Федерального закона, может быть установлено, что в случае, если деятельность юридического лица, индивидуального предпринимателя и (или) используемые ими производственные объекты отнесены к определенной категории риска, определенному классу (категории) опасности, плановая проверка таких юридического лица, индивидуального предпринимателя не проводится.(часть 1.2 введена Федеральным законом от 13.07.2015 N 246-ФЗ)2. Плановые проверки проводятся не чаще чем один раз в три года, если иное не предусмотрено частями 9 и 9.3 настоящей статьи.(в ред. Федерального закона от 13.07.2015 N 246-ФЗ)

(см. текст в предыдущей редакции)

3. Плановые проверки проводятся на основании разрабатываемых и утверждаемых органами государственного контроля (надзора), органами муниципального контроля в соответствии с их полномочиями ежегодных планов.(в ред. Федерального закона от 03.07.2016 N 277-ФЗ)

(см. текст в предыдущей редакции)

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

(в ред. Федерального закона от 18.07.2011 N 242-ФЗ)

(см. текст в предыдущей редакции)

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

(в ред. Федеральных законов от 18.07.2011 N 242-ФЗ, от 14.10.2014 N 307-ФЗ)

(см. текст в предыдущей редакции)

2) цель и основание проведения каждой плановой проверки;

3) дата начала и сроки проведения каждой плановой проверки;

(в ред. Федерального закона от 18.07.2011 N 242-ФЗ)

(см. текст в предыдущей редакции)

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

5. Утвержденный руководителем органа государственного контроля (надзора) или органа муниципального контроля ежегодный план проведения плановых проверок доводится до сведения заинтересованных лиц посредством его размещения на официальном сайте органа государственного контроля (надзора) или органа муниципального контроля в сети "Интернет" либо иным доступным способом.

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

(часть шестая в ред. Федерального закона от 27.12.2009 N 365-ФЗ)

(см. текст в предыдущей редакции)

6.1. Органы прокуратуры рассматривают проекты ежегодных планов проведения плановых проверок на предмет законности включения в них объектов государственного контроля (надзора), объектов муниципального контроля в соответствии с частью 4 настоящей статьи и в срок до 1 октября года, предшествующего году проведения плановых проверок, вносят предложения руководителям органов государственного контроля (надзора), органов муниципального контроля об устранении выявленных замечаний и о проведении при возможности в отношении отдельных юридических лиц, индивидуальных предпринимателей совместных плановых проверок.(часть шестая.1 введена Федеральным законом от 27.12.2009 N 365-ФЗ; в ред. Федерального закона от 03.07.2016 N 277-ФЗ)

(см. текст в предыдущей редакции)

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

(часть шестая.2 введена Федеральным законом от 27.12.2009 N 365-ФЗ, в ред. Федерального закона от 18.07.2011 N 242-ФЗ)

(см. текст в предыдущей редакции)

6.3. Порядок подготовки ежегодного плана проведения плановых проверок, его представления в органы прокуратуры и согласования, а также типовая форма ежегодного плана проведения плановых проверок устанавливается Правительством Российской Федерации.(часть шестая.3 введена Федеральным законом от 27.12.2009 N 365-ФЗ)

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

(часть шестая.4 введена Федеральным законом от 27.12.2009 N 365-ФЗ)

КонсультантПлюс: примечание.

7. Генеральная прокуратура Российской Федерации формирует ежегодный сводный план проведения плановых проверок и размещает его на официальном сайте Генеральной прокуратуры Российской Федерации в сети "Интернет" в срок до 31 декабря текущего календарного года.(часть седьмая в ред. Федерального закона от 27.12.2009 N 365-ФЗ)

(см. текст в предыдущей редакции)

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

(часть 7.1 введена Федеральным законом от 18.07.2011 N 242-ФЗ)7.2. Федеральные органы исполнительной власти, уполномоченные на осуществление федерального государственного контроля (надзора), до 31 декабря года, предшествующего году проведения плановых проверок, составляют ежегодные планы проведения плановых проверок в соответствующей сфере деятельности, включающие сведения утвержденных ежегодных планов проведения плановых проверок, представленных территориальными органами государственного контроля (надзора), указанными в части 7.1 настоящей статьи. Ежегодные планы проведения плановых проверок размещаются федеральными органами исполнительной власти на своих официальных сайтах в сети "Интернет", за исключением информации, свободное распространение которой запрещено или ограничено в соответствии с законодательством Российской Федерации.(часть 7.2 введен Федеральным законом от 18.07.2011 N 242-ФЗ)

8. Основанием для включения плановой проверки в ежегодный план проведения плановых проверок является истечение трех лет со дня:

1) государственной регистрации юридического лица, индивидуального предпринимателя;

2) окончания проведения последней плановой проверки юридического лица, индивидуального предпринимателя;

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

(в ред. Федерального закона от 23.04.2018 N 94-ФЗ)

(см. текст в предыдущей редакции)

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

(см. текст в предыдущей редакции)

9.1 - 9.2. Утратили силу с 1 августа 2011 года. - Федеральный закон от 18.07.2011 N 242-ФЗ.

(см. текст в предыдущей редакции)

9.3. Правительством Российской Федерации может быть установлена иная периодичность проведения плановых проверок при осуществлении видов государственного контроля (надзора), определяемых в соответствии с частями 1 и 2 статьи 8.1 настоящего Федерального закона, в зависимости от отнесения деятельности юридического лица, индивидуального предпринимателя и (или) используемых ими производственных объектов к определенной категории риска, определенному классу (категории) опасности.(часть 9.3 введена Федеральным законом от 13.07.2015 N 246-ФЗ)

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

11. Плановая проверка проводится в форме документарной проверки и (или) выездной проверки в порядке, установленном соответственно статьями 11 и 12 настоящего Федерального закона.

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

(часть 11.1 введена Федеральным законом от 03.07.2016 N 277-ФЗ)11.2. Обязанность использования проверочных листов (списков контрольных вопросов) может быть предусмотрена при проведении плановых проверок всех или отдельных юридических лиц, индивидуальных предпринимателей, обусловлена типом (отдельными характеристиками) используемых ими производственных объектов, а в случае осуществления видов государственного контроля (надзора), определяемых в соответствии с частями 1 и 2 статьи 8.1 настоящего Федерального закона, также отнесением деятельности юридического лица, индивидуального предпринимателя и (или) используемых ими производственных объектов к определенной категории риска, определенному классу (категории) опасности.(часть 11.2 введена Федеральным законом от 03.07.2016 N 277-ФЗ)11.3. Проверочные листы (списки контрольных вопросов) разрабатываются и утверждаются органом государственного контроля (надзора), органом муниципального контроля в соответствии с общими требованиями, определяемыми Правительством Российской Федерации, и включают в себя перечни вопросов, ответы на которые однозначно свидетельствуют о соблюдении или несоблюдении юридическим лицом, индивидуальным предпринимателем обязательных требований, требований, установленных муниципальными правовыми актами, составляющих предмет проверки. В соответствии с положением о виде федерального государственного контроля (надзора), порядком организации и осуществления вида государственного регионального контроля (надзора), муниципального контроля перечень может содержать вопросы, затрагивающие все предъявляемые к юридическому лицу, индивидуальному предпринимателю обязательные требования, требования, установленные муниципальными правовыми актами, либо ограничить предмет плановой проверки только частью обязательных требований, требований, установленных муниципальными правовыми актами, соблюдение которых является наиболее значимым с точки зрения недопущения возникновения угрозы причинения вреда жизни, здоровью граждан, вреда животным, растениям, окружающей среде, объектам культурного наследия (памятникам истории и культуры) народов Российской Федерации, музейным предметам и музейным коллекциям, включенным в состав Музейного фонда Российской Федерации, особо ценным, в том числе уникальным, документам Архивного фонда Российской Федерации, документам, имеющим особое историческое, научное, культурное значение и входящим в состав национального библиотечного фонда, безопасности государства, а также угрозы чрезвычайных ситуаций природного и техногенного характера.(часть 11.3 в ред. Федерального закона от 03.08.2018 N 316-ФЗ)

(см. текст в предыдущей редакции)

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

(часть 11.4 введена Федеральным законом от 03.07.2016 N 277-ФЗ)

11.5. При проведении проверки с использованием проверочного листа (списка контрольных вопросов) заполненный по результатам проведения проверки проверочный лист (список контрольных вопросов) прикладывается к акту проверки.

(часть 11.5 введена Федеральным законом от 03.07.2016 N 277-ФЗ)

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

(в ред. Федерального закона от 03.07.2016 N 277-ФЗ)

(см. текст в предыдущей редакции)

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

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

Как в 2021 году ГИТ будет проверять работодателей

Как в 2021 году ГИТ будет проверять работодателей?

Плановые проверки отменили. Не для всех.

Мораторий на плановые проверки продлили на 2021 год только для малых предприятий. Средние предприятия ГИТ проверит по плану наравне с крупными компаниями. Также запрет на проверки не стали продлевать некоммерческим организациям, в которых трудится до 200 человек (п. 7 постановления Правительства от 30.11.2020 № 1969, далее — Постановление № 1969).

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

Выезжать на предприятия станут чаще

Инспекторы будут сами определять: выезжать им на предприятие или проводить проверку дистанционно. Дистанционный формат проверок - это не обязанность, а право контролеров (п. 1 Постановления № 1969).

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

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

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

Мораторий действует не на все виды контроля

Запрет действует только для плановых проверок по Закону о госконтроле. Он не касается проверок в области использования атомной энергии. Кроме того, мораторий не распространяется на административные расследования, по статье 28.7 КоАП.

Инспектор ГИТ вправе проводить административное расследование при нарушениях трудового законодательства. Чтобы начать его, достаточно  обращения работника или других данных, которые указывают на нарушение. Расследование используют, когда нужно провести экспертизу или другие действия, которые займут много времени. Максимальный срок на расследование - один месяц. Уведомлять работодателя о расследовании и согласовывать процедуру с прокурорами контролеры не обязаны. Например, Роструд может проводить мероприятия без взаимодействия, чтобы отследить, как провели СОУТ и оформили ее результаты (приказ Минтруда от 16.01.2019 № 13н).

Появятся новые виды контроля

Инспекционные визиты можно будет проводить дистанционно (ч. 5 ст. 56 Закона № 248-ФЗ). Выездное обследование, в ходе которого инспекторы могут прийти на предприятие без предупреждения и осмотреть общедоступные производственные объекты, будет длиться максимум один рабочий день. Наблюдать за тем, как работодатели соблюдают обязательные требования, начнут в рамках мониторинга безопасности, данные для него будут получать из государственных систем и других ведомств. Эти виды контроля инспекторы смогут использовать с 1 июля 2021 года, когда вступит в силу Федеральный закон от 31.07.2020 № 248-ФЗ, он заменит Закон № 294-ФЗ.

С 1 июля контролеры смогут заменить запланированные проверки на инспекционные визиты. Главное преимущество инспекционного визита - он не должен длиться больше одного рабочего дня. Но визиты будут внезапными, инспекторы не будут уведомлять о них работодателей (ч. 4 и 5 ст. 70 Закона № 248-ФЗ).

Максимальный срок для проверок с 1 июля сократят вдвое: с 20 рабочих дней до 10 (п. 7 ст. 72, п. 7 ст. 73 Закона № 248-ФЗ). Если контролеры не заменят запланированную проверку на инспекционный визит, максимальный срок на нее — тоже 10 рабочих дней. Сроки для структурных подразделений в других регионах по-прежнему считают отдельно. В ежегодных планах должны скорректировать сроки на проверки (пп. 2–4 Постановления № 1969).

Отменили согласование проверок по факту или угрозе вреда жизни и здоровью

В прошлом году инспекторы согласовывали с прокурорами проверки по факту вреда жизни и здоровью или угрозы вреда, а также проверку исполнения предписаний по таким нарушениям. Теперь это условие не действует. ГИТ реагирует быстрее на угрожающие жизни и здоровью нарушения и внеплановые проверки по ним проводит сразу. Прокуратуру о проверках извещают, но не согласовывают с ней мероприятия. Инспекторы руководствуются частью 9 статьи 360 ТК, она позволяет не применять норму о согласовании из части 5 статьи 10 Закона № 294-ФЗ (п. 12 ч. 4 ст. 1 Закона № 294-ФЗ; п. 105 Регламента, утв. приказом Роструда от 13.06.2019 № 160, далее — Регламент № 160).

Жалобы об угрозе жизни и здоровью инспекция получает от работников или иных лиц, которые решили сообщать о нарушении, например, СМИ, граждане, госорганы и пр. Проверку без согласования проведут, если поступила информация, что компания (п. 91 Регламента № 160):

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

проверки ГИТ | Охрана труда

Государственной инспекцией труда (ГИТ) в городе Санкт-Петербурге в связи с нештатным происшествием на заводе «Ниссан», где работники жаловались на невыносимую жару в цехах, проанализированы карты замеров температуры в производственных помещениях. В результате проверки, как сообщает ГИТ, был установлен факт превышения максимально допустимых температурных показателей. В норме плюсовой уровень температуры в помещениях, где работают люди, не должен превышать 28,5 градусов. Согласно СанПиНу, если температура в рабочем помещении приблизилась к отметке 28,5 градусов, рекомендуется сокращать продолжительность рабочего дня на один час. При повышении температуры до 29 градусов – на два часа, при температуре 30,5 градусов – на четыре часа. В цехах завода столбик термометра перешагнул отметку в 29 градусов С.

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

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

Напомним, совместные надзорные мероприятия на территории  завода «Ниссан» в Санкт-Петербурге представители  Государственной инспекции труда в городе Санкт- Петербурге, прокуратуры Выборгского района Санкт-Петербурга, администрации  Выборгского района Санкт-Петербурга и Роспотребнадзора начали в связи  с тем, что некоторые рабочие смены А участка шасси-1 7 августа вечером, в 21.50, прекратили работу из-за жары в цеху, где температура превысила 29,5. При этом работа работа цеха не приостанавливалась.

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

Государственной инспекцией труда в Санкт-Петербурге была назначена проверка.

Насколько правомерна досрочная плановая проверка?

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

Ответ: Периодичность проведения плановых проверок зависит от присвоенной деятельности работодателя категории риска (п. 20 Положения N 875, п. 46 Административного регламента N 160, п. 30 Административного регламента N 234):

  • для категорий высокого риска - один раз в два года;
  • для категорий значительного риска - один раз в три года;
  • для категорий среднего риска - не чаще чем один раз в пять лет;
  • для категорий умеренного риска - не чаще чем один раз в шесть лет.

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

Решение об отнесении работодателя к той или иной категории риска принимается ежегодно (п. 21 Положения N 875).

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

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

В случае несогласия с присвоенной категорией риска работодатель вправе обратиться с соответствующим заявлением в Федеральную службу по труду и занятости (Роструд), если присвоена высокая категория риска, в остальных случаях - в Государственную инспекцию труда (п. п. 18, 24 Положения N 875). (Источник -Вопрос: Какой установлен порядок проведения плановой проверки ГИТ? (Консультация эксперта, Государственная инспекция труда в Кировской обл., 2021) {КонсультантПлюс})

Как узнать, что будет плановая проверка ГИТ

ГИТ проводит плановые проверки в соответствии с утвержденным ежегодным планом. Если хотите узнать, будет ли ГИТ проверять вас, посмотрите, включена ли ваша организация в такой план проверок. При составлении плана проверок применяется риск-ориентированный подход к деятельности работодателей, что влияет на периодичность плановых проверок - зная свою категорию риска, вы сможете еще до публикации плана проверок спрогнозировать вашу проверку (например, при низкой категории риска проверки не предусмотрены вообще). Но в любом случае вас должны уведомить о плановой проверке минимум за три рабочих дня до ее начала (ч. 3, 12 ст. 9 Закона N 294-ФЗ, п. 4 Перечня, утвержденного Постановлением Правительства РФ от 17.08.2016 N 806, п. п. 34, 46, 53 Административного регламента, утвержденного Приказом Роструда от 13.06.2019 N 160).

Найти информацию о плане проверок ГИТ и ознакомиться с ним вы можете на сайте ГИТ вашего региона. Сводный план проверок организаций по всем регионам есть и на сайте Роструда - http://www.rostrud.ru. Также на сайте Генпрокуратуры России есть удобный сервис, с помощью которого вы можете проверить, будет у вас плановая проверка ГИТ или нет - http://plan.genproc.gov.ru/. Для этого достаточно указать, например, ИНН или название организации. На этих сайтах разместить план должны до 31 декабря года, предшествующего году проведения плановых проверок (ч. 5, 7, 7.2 ст. 9, ч. 1 ст. 13.3 Закона N 294-ФЗ, пп. "а" п. 2, п. п. 5, 6 Правил, утвержденных Постановление Правительства РФ от 30.06.2010 N 489, п. 34 Административного регламента, утвержденного Приказом Роструда от 13.06.2019 N 160).

На сайте Роструда и ГИТ вы увидите план проверок по типовой форме. Например, в ней указано, в каком месяце будет проверка, в какой форме (документарной или выездной), сколько рабочих дней (часов) на нее отведено.

Также вы всегда можете обратиться в вашу ГИТ или Роструд и запросить там выписку из плана проверок (информацию о включении или невключении вас в план проверок). Ее должны предоставить в течение 30 дней со дня регистрации вашего обращения (ч. 4 ст. 1, ч. 1 ст. 2, ч. 1 ст. 9, ч. 1 ст. 12 Федерального закона от 02.05.2006 N 59-ФЗ).

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

В 2021 г. проверки проводятся с учетом особенностей, предусмотренных Постановлением Правительства РФ от 30.11.2020 N 1969, в частности:

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

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

(Источник - Готовое решение: Как снизить категорию риска деятельности организации, чтобы сократить плановые проверки ГИТ (КонсультантПлюс, 2021) {КонсультантПлюс})

Опыт Git в Visual Studio 2019

  • 10 минут на чтение

В этой статье

Git теперь является средством управления версиями по умолчанию в Visual Studio 2019. Начиная с версии 16.6, мы работали над созданием набора функций и его повторением на основе ваших отзывов. В выпуске версии 16 новый интерфейс Git включен по умолчанию для всех.8.

Подсказка

Git - это наиболее широко используемая современная система контроля версий, поэтому независимо от того, являетесь ли вы профессиональным разработчиком или учитесь программировать, Git может быть вам очень полезен. Если вы новичок в Git, веб-сайт https://git-scm.com/ - хорошее место для начала. Там вы найдете шпаргалки, популярную онлайн-книгу и видеоролики по основам Git.

Как использовать Git в Visual Studio

Мы расскажем, как использовать новый интерфейс Git в Visual Studio 2019, но если вы хотите сначала пройти краткий обзор, посмотрите следующее видео:

Длина видео: 5.27 минут

Есть три способа начать использовать Git с Visual Studio для повышения производительности:

  • Откройте существующий репозиторий Git. Если ваш код уже находится на вашем компьютере, вы можете открыть его, используя File > Open > Project / Solution (или Folder ), и Visual Studio автоматически определит, есть ли у него инициализированный репозиторий Git.
  • Создайте новый репозиторий Git. Если ваш код не связан с Git, вы можете создать новый репозиторий Git.
  • Клонировать существующий репозиторий Git. Если код, над которым вы хотели бы работать, отсутствует на вашем компьютере, вы можете клонировать любые существующие удаленные репозитории.

Примечание

Начиная с версии 16.8, Visual Studio 2019 включает полностью интегрированную учетную запись GitHub. Теперь вы можете добавить учетные записи GitHub и GitHub Enterprise в свою связку ключей. Вы сможете добавлять и использовать их так же, как и в случае с учетными записями Microsoft, а это значит, что вам будет легче получить доступ к своим ресурсам GitHub через Visual Studio.Дополнительные сведения см. На странице Работа с учетными записями GitHub в Visual Studio.

Создать новый репозиторий Git

Если ваш код не связан с Git, вы можете начать с создания нового репозитория Git. Для этого выберите Git > Create Git Repository в строке меню. Затем в диалоговом окне Create a Git repository введите свою информацию.

Диалоговое окно Create a Git repository упрощает отправку вашего нового репозитория на GitHub.По умолчанию ваш новый репозиторий является частным, что означает, что вы единственный, кто может получить к нему доступ. Если вы снимите этот флажок, ваш репозиторий будет общедоступным, а это значит, что любой пользователь GitHub сможет его просмотреть.

Подсказка

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

Вы можете создать только локальный репозиторий Git, используя опцию Local only .Или вы можете связать свой локальный проект с существующим пустым удаленным репозиторием в Azure DevOps или любом другом поставщике Git, используя опцию Existing Remote .

Клонировать существующий репозиторий Git

Visual Studio включает простой интерфейс клонирования. Если вам известен URL-адрес репозитория, который вы хотите клонировать, вы можете вставить этот URL-адрес в раздел Расположение репозитория , а затем выбрать расположение на диске, в которое Visual Studio должна клонировать.

Если вы не знаете URL-адрес репозитория, Visual Studio упрощает просмотр и последующее клонирование существующего репозитория GitHub или Azure DevOps.

Открыть существующий локальный репозиторий

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

Просмотр файлов в обозревателе решений

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

Visual Studio корректирует свое представление в зависимости от того, какой файл представления загружается в обозреватель решений:

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

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

Окно изменений Git

Git отслеживает изменения файлов в вашем репозитории во время вашей работы и разделяет файлы в вашем репозитории на три категории. Эти изменения эквивалентны тому, что вы увидите, введя команду git status в командной строке:

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

По мере того, как вы выполняете свою работу, Visual Studio отслеживает изменения файлов в вашем проекте в разделе Changes окна Git Changes .

Когда вы будете готовы подготовить изменения, нажмите кнопку + (плюс) на каждом файле, который вы хотите обработать, или щелкните файл правой кнопкой мыши и затем выберите Stage .Вы также можете обработать все ваши измененные файлы одним щелчком мыши, используя кнопку stage all + (плюс) в верхней части раздела Changes .

Когда вы вводите изменение, Visual Studio создает раздел Staged Changes . В следующую фиксацию добавляются только изменения в разделе Staged Changes , что можно сделать, выбрав Commit Staged . Эквивалентная команда для этого действия: git commit -m "Ваше сообщение фиксации" . Изменения также можно отключить, нажав кнопку - (минус).Эквивалентная команда для этого действия: git reset для деактивации одного файла или git reset для деактивации всех файлов в каталоге.

Вы также можете отказаться от размещения измененных файлов, пропустив промежуточную область. В этом случае Visual Studio позволяет фиксировать изменения напрямую, не выполняя их. Просто введите сообщение о фиксации и выберите Commit All . Эквивалентная команда для этого действия: git commit -a .

Visual Studio также упрощает фиксацию и синхронизацию одним щелчком мыши с помощью ярлыков Commit All и Push и Commit All и Sync . Если дважды щелкнуть любой файл в разделах Changes и Staged changes , вы можете увидеть построчное сравнение с неизмененной версией файла.

Подсказка

Вы можете связать рабочий элемент Azure DevOps с фиксацией с помощью символа «#», если вы подключены к репозиторию Azure DevOps.Вы можете подключить репозиторий Azure DevOps через Team Explorer > Управление подключениями .

Выбрать существующий филиал

Visual Studio отображает текущую ветвь в селекторе в верхней части окна Git Changes .

Текущая ветвь также доступна в строке состояния в правом нижнем углу интегрированной среды разработки Visual Studio.

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

Создать новую ветку

Вы также можете создать новую ветку. Эквивалентная команда для этого действия: git checkout -b .

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

Вы можете выбрать существующую локальную или удаленную ветку в качестве основы. Флажок Checkout branch автоматически переключает вас на вновь созданную ветку. Эквивалентная команда для этого действия: git checkout -b .

Окно репозитория Git

В

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

Управление филиалами

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

Входящие и исходящие коммиты

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

Индикатор также работает как ссылка для перехода к истории фиксации этой ветки в окне Git Repository . В верхней части истории теперь отображаются детали этих входящих и исходящих коммитов. Отсюда вы также можете выбрать «Вытягивать» или «Выталкивать» коммиты.

Детали фиксации

Если дважды щелкнуть Commit , Visual Studio откроет сведения о нем в отдельном окне инструмента. Отсюда вы можете отменить фиксацию, сбросить фиксацию, изменить сообщение фиксации или создать тег для фиксации.Когда вы щелкаете измененный файл в фиксации, Visual Studio открывает параллельное представление Diff фиксации и ее родительского элемента.

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

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

Visual Studio упрощает выявление и разрешение конфликта слияния. Во-первых, окно Git Repository показывает золотую информационную панель в верхней части окна.

В окне Git Changes также отображается сообщение « Выполняется слияние, возникают конфликты », а неслитые файлы находятся в отдельном разделе под ним.

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

  <<<<<<< ГОЛОВКА
    =======
    >>>>>>> главная
  

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

Редактор слияния

Редактор слияния в Visual Studio - это трехсторонний инструмент слияния, который отображает входящие изменения, текущие изменения и результат слияния. Вы можете использовать панель инструментов на верхнем уровне редактора слияния для перехода между конфликтами и автоматически объединенными различиями в файле.

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

Персонализируйте настройки Git

Чтобы персонализировать и настроить параметры Git на уровне репозитория, а также на глобальном уровне, перейдите к Git > Настройки в строке меню или к Инструменты > Параметры > Source Control на в строке меню.Затем выберите нужные параметры.

Как использовать все возможности Team Explorer в Visual Studio

Новый интерфейс Git - это система управления версиями по умолчанию в Visual Studio 2019, начиная с версии 16.8. Однако, если вы хотите выключить его, вы можете. Перейдите в Инструменты > Параметры > Среда > Предварительные возможности и затем установите флажок Новый опыт пользователя Git , который вернет вас обратно в Team Explorer для Git.

Что дальше?

Хотя новый интерфейс Git теперь включен по умолчанию в Visual Studio 2019 версии 16.8, мы продолжаем добавлять новые функции для улучшения взаимодействия. Если вы хотите проверить новые обновления Git в предварительной версии, вы можете загрузить и установить ее со страницы предварительной версии Visual Studio.

Важно

Если у вас есть предложения для нас, дайте нам знать! Мы ценим возможность обсудить с вами проектные решения через портал Developer Community .

См. Также

Использование Git с Visual Studio 2019: полное руководство

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

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

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

Установить Git & Learn Git

Git изначально работает в Windows, Mac и Linux.При использовании Windows вы, скорее всего, будете использовать инструменты, включенные в инициативу Git for Windows (Git BASH, Git GUI и Git Shell Integration). Несмотря на то, что Git полностью кроссплатформенный, Visual Studio 2019 работает только в Windows.

Чтобы начать, перейдите на страницу загрузки Git или прямо по ссылке для загрузки для Windows, так как вы застряли в Windows с Visual Studio.

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

Установить Visual Studio 2019

Microsoft иногда использует странные способы наименования своих продуктов (Azure DevOps, мы смотрим на вас). Был период, когда все называлось префиксом Visual Studio. Тем не менее, не путайте Visual Studio 2019 с Visual Studio Code. В этом руководстве используется только Visual Studio 2019.

Приступим.

Загрузите Visual Studio 2019 Community Edition (бесплатно). Прочтите наше руководство по ценам для более подробного сравнения выпусков.Мы предлагаем версию для сообщества, потому что вам не понадобятся функции, предлагаемые более дорогими (а они могут быть дорогими) уровнями.

Visual Studio 2019 Community Edition (не путать с Visual Studio Code).

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

В любом случае вам не понадобятся тысячи опций, которые доступны вам в процессе начальной установки.В этом руководстве используется только группа «Кроссплатформенная разработка .NET Core» и ее необходимые зависимости. Не стесняйтесь выбирать все, что вам кажется интересным, но имейте в виду, что вам придется скачать все. Некоторые из этих параметров могут увеличить размер загрузки на 5+ ГБ.

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

Пусть установщик сделает свое дело. Устройтесь поудобнее, расслабьтесь и ждите волшебства. Пока он загружается, вы можете ознакомиться с нашей статьей о 5 основных расширениях Visual Studio.При правильном использовании расширения могут повысить вашу производительность и эффективность разработки.

Создать новый репозиторий Git

У вас есть Visual Studio, и вы готовы к работе. Если вы хотите узнать, как пользовательский интерфейс Visual Studio Git взаимодействует с Git изнутри, прочтите наше введение в Git, чтобы узнать основы командной строки.

Visual Studio пытается помочь при запуске, но иногда не торопится. В этом случае мы не хотим создавать какие-либо проекты на старте.Вместо этого мы хотим создать новый репозиторий, но он скрыт за крошечной ссылкой в ​​правом нижнем углу: «Продолжить без кода». Щелкните по нему.

Пропустить создание проекта, так как в первую очередь нам нужен репозиторий.

Для создания нового репозитория:

  1. Щелкните Файл -> Создать -> Репозиторий…
  2. Справа открывается Team Explorer
  3. Выберите папку, в которой вы хотите создать репозиторий, в

Это эквивалентно запуску git init из командной строки.

Создайте и подтвердите, где будет располагаться репозиторий.

Создать проект в новом репозитории Git

Репозиторий готов к работе, но он пуст. Убедитесь, что репозиторий теперь отображается в разделе «Локальные репозитории Git» в Team Explorer.

Запустите мастер создания проекта, щелкнув File -> New -> Project. Да, для этого есть быстрые клавиши, но они не очень удобны. Вы можете переназначить их, но на самом деле, как часто вы собираетесь создавать новые проекты, чтобы оправдать удобный ярлык?

Подтвердите успешное создание репозитория.Запустить мастер нового проекта.

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

Найдите «консоль», чтобы отфильтровать только консольные приложения. Выберите «Консольное приложение C # (.NET Core)», чтобы создать новое консольное приложение на основе той версии SDK .NET Core, которая была установлена ​​с Visual Studio 2019. Обратите внимание, что существуют шаблоны для других языков (VB и F #), которых нет. относится к этому руководству.

Нажмите Далее.

Создайте новое консольное приложение .NET Core.

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

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

Зафиксировать новый проект в Git

Visual Studio имеет закрепленную боковую панель «Team Explorer» (ее можно перетаскивать, чтобы переместить), которая позволяет управлять локальным репозиторием Git и подключенными пультами дистанционного управления.

Измените раскрывающийся список раздела Team Explorer на «Изменения», чтобы вы могли просматривать изменения в своей активной ветке (которая на данный момент является главной ветвью).

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

Используйте Team Explorer для управления вашими вкладами в локальный и удаленный репозиторий.

Окно «Изменения» на вкладке Team Explorer разбивает изменения двумя способами: «Изменения» и «Поэтапные изменения».

  • Изменения - это список ожидающих изменений файлов, над которыми вы не выполняли никаких действий. То есть вы не запускали git add для этих файлов, чтобы подготовить их для фиксации.
  • Поэтапные изменения - это список файлов, которые были добавлены в список поэтапного отслеживания Git для фиксации.На этом этапе мастер создания репозитория Visual Studio автоматически разместил файлов .gitattributes и файлов .gitignore на основе встроенных шаблонов.

В частности, файл .gitignore был получен из репозитория GitHub gitignore.

Поэтапные и «регулярные» изменения разделены в пользовательском интерфейсе Visual Studio.

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

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

Подтвердите свои изменения перед постановкой.

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

Если что-то не так на этом этапе, вы можете Деактивировать , щелкнув файл правой кнопкой мыши и выбрав «Деактивировать».

Дважды проверьте поэтапные изменения перед принятием обязательств.

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

У вас есть три варианта:

  • Commit Staged , чтобы зафиксировать поэтапные изменения в локальном репозитории
  • Поэтапная фиксация и push для фиксации поэтапных изменений в локальном репозитории и отправки в удаленный репозиторий (например, GitHub или Bitbucket)
  • Поэтапная фиксация и синхронизация для фиксации поэтапных изменений в локальном репозитории, извлечение изменений из удаленного репозитория, а затем передача ваших изменений в этот удаленный репозиторий

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

Напишите хорошее сообщение о фиксации и выполните фиксацию в локальном репозитории.

На данный момент проект привязан к Git и навсегда вошел в историю. Теперь займемся постепенными изменениями.

Зафиксировать изменение в Git

Каждый раз, когда вы добавляете или изменяете файл в отслеживаемом репозитории, Visual Studio Team Explorer автоматически обнаруживает и отображает изменения на вкладке «Изменения».

Добавьте строку в файл Program.cs и наблюдайте, как изменение отобразится автоматически.

Изменения обнаруживаются и отображаются автоматически.

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

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

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

Ранее выбранный вариант запустит средство просмотра различий Visual Studio, которое отображает изменения между HEAD (слева, неизмененное состояние вашей ветки) и текущим состоянием (справа, ожидающие изменения, которые еще не были зафиксированы).

Красные линии слева указывают на предыдущее состояние. Зеленые линии справа показывают текущее состояние.

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

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

Если все в порядке, как и раньше, щелкните + , чтобы внести изменения. Введите сообщение фиксации (хорошее). Нажмите «Commit Staged», чтобы зафиксировать в локальном репозитории.

Этап, сообщение, фиксация - это обычный рабочий процесс.

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

Создание и привязка к локальному филиалу

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

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

Измените раскрывающийся список раздела Team Explorer на «Ветви», чтобы вы могли просматривать все ветки в локальном репозитории.

Просматривайте ветки с помощью вкладки «Ветви» в Team Explorer.

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

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

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

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

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

  • Префикс feature / указывает, что работа, переданная в ветку, представляет собой изменения для новой функции. Пример: feature / add-new-questions-to-ui .
  • Префикс bugfix / указывает, что работа, переданная в ветку, представляет собой изменения для исправления ошибки. Пример: bugfix / fix-broken-login .
  • Префикс hotfix / указывает на то, что ветка будет иметь расширенный путь выпуска из-за включенных в нее критических исправлений. Пример: hotfix / 2020-14-02-fix-broken-login .
  • Префикс выпуска / указывает на стандартную ветку выпуска, которая включает протестированные и готовые к использованию функции и исправления. Пример: release / 2020-14-02-new-login-process .

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

Правильные соглашения об именах для филиалов повышают производительность.

Подтвердите, что ветка была создана и теперь является активной ветвью (выделенной жирным шрифтом) на вкладке «Ветви» в Team Explorer.

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

Вкладка «Ветви» позволяет просматривать все ветки в репозитории и управлять ими.

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

Как и в предыдущих разделах, добавьте новую строку в Program.cs . Вы должны увидеть изменения, обнаруженные автоматически и отображаемые на вкладке «Изменения».

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

Фиксация в новую ветку - это тот же процесс, что и фиксация в главной.

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

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

Объединить ветку в главную

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

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

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

Дважды щелкните ветку, чтобы проверить ее.

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

Всегда выполнять слияние из источника в активную ветку.

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

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

Наконец, нажмите «Объединить», чтобы завершить операцию.

Убедитесь, что все в порядке, прежде чем нажимать «Объединить». Развернуть это сложно.

Если операция слияния прошла успешно (конфликтов нет, см. Ниже), то все готово. Вы все еще должны находиться в ветке master и видеть изменения из вашей функциональной ветки, доступные вам.

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

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

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

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

Так что, если вы добавите еще один оператор Console.WriteLine к Program.cs в одной ветке, а ваш коллега также добавит оператор Console.WriteLine в ту же строку в программе .cs в другой ветке? Будет конфликт.

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

Либо прервите слияние (не рекомендуется, если вы не знаете, как решить проблему), либо щелкните ссылку «Конфликты», чтобы отобразить конфликтующие файлы.

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

  • Кнопка слияния открывает редактор различий для ручного разрешения конфликтующих строк
  • Ссылка Diff покажет различия между файлами для видимости
  • Take Source проигнорирует изменения в активной ветви и перезапишет изменения во входящей исходной ветви
  • Keep Target проигнорирует изменения в исходной ветви и перезапишет изменения в активной ветви.

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

В редакторе различий вы увидите три окна.

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

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

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

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

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

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

Подтвердите изменения в нижнем окне перед принятием слияния.

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

Просмотр истории фиксации файла

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

При щелчке правой кнопкой мыши по любому файлу в обозревателе решений отображается параметр «Просмотр журнала».

Щелкните правой кнопкой мыши -> Просмотреть историю, чтобы просмотреть историю файлов в Git.

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

Используйте средство просмотра истории файлов, чтобы просмотреть все коммиты в истории.

Щелчок правой кнопкой мыши по фиксации откроет параметры:

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

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

Щелкните правой кнопкой мыши, чтобы просмотреть параметры фиксации в истории.

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

Настройка удаленных репозиториев

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

Подключитесь к GitHub

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

Чтобы подключить репозиторий к GitHub, измените окно Team Explorer на «Синхронизировать». По какой-то причине Visual Studio будет отображать эту вкладку как «Push». Нажмите «Опубликовать на GitHub», чтобы начать процесс входа в систему с использованием ваших учетных данных GitHub. Нет? Не волнуйтесь, GitHub бесплатен!

Опубликуйте на GitHub, Azure DevOps или на других пультах дистанционного управления.

Как только что было сказано, войдите или зарегистрируйтесь на GitHub.

Войдите или зарегистрируйтесь на GitHub.

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

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

Назовите и опишите ваш репозиторий так, как вы хотите, чтобы он отображался на GitHub.

И, наконец, если создание удаленного репозитория прошло успешно, вы должны увидеть сообщение об успешном завершении. Вы можете дважды подтвердить, проверив вкладку «Ветви» в Team Explorer, чтобы увидеть, что новая ветка master в удаленном репозитории remotes / origin была создана и теперь доступна в вашем локальном репозитории.

Подтвердите добавление пультов на вкладке веток.

Подключиться к другим пультам

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

При появлении запроса введите удаленный URL-адрес (обычно заканчивается расширением .git ), чтобы отправить изменения. Вам может быть предложено ввести учетные данные при отправке в защищенную систему.

Вы также можете опубликовать в любом удаленном репозитории, поддерживающем Git.

Push & Pull Changes

Что хорошего в подключении ваших репозиториев, если вы не знаете, как протолкнуть свои изменения и вытащить изменения вашей команды? К счастью, Visual Studio делает это очень просто.

Перейдите на вкладку «Синхронизация» в Team Explorer, чтобы увидеть разделы входящих и исходящих коммитов.

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

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

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

Краткое примечание : если вы видите ошибку с сообщением об отсутствии соответствующей удаленной ветки при попытке отправки, это обычно означает, что в вашем локальном репозитории нет коммитов для отправки. Это связано с тем, что Git не создает ветку master до тех пор, пока вы не зафиксируете хотя бы один раз, поэтому нет ветвей, с которыми Visual Studio может сопоставить и отправить.

Клонировать удаленный репозиторий

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

К сожалению, Visual Studio не делает поиск этого параметра интуитивно понятным. Щелкните маленькую зеленую заглушку в верхней части окна Team Explorer, чтобы перейти на вкладку «Подключения». Мы не знаем, почему эта вкладка скрыта из обычного раскрывающегося списка вкладок.

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

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

Клонировать удаленный репозиторий на вкладке подключений.

Начало работы с GitHub с помощью Visual Studio 2019

Home / Начало работы с GitHub с помощью Visual Studio 2019 Редактировать на GitHub

Обзор

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

Если вы хотите узнать больше об основах Git, посетите эту лабораторную работу.

Предварительные требования

Для выполнения этой лабораторной работы вам понадобится виртуальная машина Azure DevOps Server 2019, предоставленная Microsoft. Нажмите кнопку ниже, чтобы запустить виртуальную машину на портале Microsoft Hands-on-Labs.

Запустить виртуальную машину

Вы также можете скачать виртуальную машину отсюда.

Упражнение 1: Начало работы с GitHub с использованием Visual Studio 2019

Задача 1: Настройка проекта GitHub

  1. Войти как Sachin Raj (VSALM \ Sachin) . Все пароли пользователей: P2ssw0rd .

  2. Установите Google Chrome со страницы https://google.com/chrome. GitHub не поддерживает Internet Explorer, поэтому до конца этой лабораторной работы используйте Chrome.

  3. Создайте вилку проекта по адресу https: // github.com / Microsoft / PartsUnlimitedE2E в свою учетную запись.

  4. Выберите вкладку Настройки .

  5. Включите Issues , установив соответствующий флажок.

  6. Выберите вкладку Issues .

  7. Щелкните Новый выпуск .

  8. Создайте новый выпуск под названием «Обновление до v2.0 ” и нажмите Отправить новый выпуск . Устранению этой проблемы и будет посвящена данная лабораторная работа.

  9. Обратите внимание на идентификатор вновь созданной задачи.

Задача 2: Клонирование и настройка проекта GitHub в Visual Studio

  1. Откройте Visual Studio .

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

  3. В Team Explorer нажмите кнопку Управление подключениями .

  4. В разделе GitHub щелкните Connect . Завершите процесс, чтобы войти в свою учетную запись GitHub.

  5. Щелкните Клонировать .

  6. Выберите клонированный ранее проект и нажмите Клонировать .

  7. После входа в систему Team Explorer загорается множеством ярлыков и функций, чтобы сделать вашу работу с GitHub максимально удобной. Многие кнопки являются ярлыками для страницы портала GitHub для этого проекта, например Pulse , Graphs и Wiki . Щелкните Настройки .

  8. Вы можете настраивать параметры на двух уровнях. Щелкните Global Settings , чтобы просмотреть их в первую очередь.

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

  10. Щелкните Настройки репозитория .

  11. Эти настройки относятся к текущему проекту.Щелкните кнопку Home .

Задача 3: Изучение интеграции системы управления версиями GitHub

  1. Чтобы начать работу с созданным ранее рабочим элементом, щелкните Ветви . Работа будет выполнена в отдельной ветке и объединена после проверки.

  2. Щелкните правой кнопкой мыши главную ветвь и выберите Новая локальная ветвь из .

  3. Задайте имя «dev» и щелкните Create Branch .

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

  5. Щелкните правой кнопкой мыши ветку dev и выберите Push Branch . Это отправит локально созданную ветку на сервер.

  6. В обозревателе решений найдите «_layout» и откройте _Layout.cshtml из проекта PartsUnlimitedWebsite .

  7. Добавьте «v2.0» к тексту тега h2 и Сохраните файл.

  8. В Team Explorer перейти на Изменения .

  9. Здесь будет показано изменение источника, сделанное ранее. Введите сообщение фиксации «Обновлено до версии 2.0» и выберите Commit All | Зафиксировать все и синхронизировать .Это зафиксирует ваше изменение и отправит его на сервер.

Задача 4: Изучение интеграции запросов на вытягивание GitHub

  1. Хотя ветка dev была обновлена ​​с необходимыми изменениями, ей все еще нужно вернуться к master . Это можно сделать с помощью запроса на извлечение . Щелкните кнопку Home .

  2. Щелкните Pull Requests , чтобы запустить процесс pull request.

  3. Щелкните Create New , чтобы создать новый запрос на вытягивание.

  4. Настройте ветвь для слияния с master из вашего проекта. Обратите внимание, что по умолчанию будет использоваться проект Microsoft, который вы не хотите использовать. Установите для комментария значение «Исправления №1». . Обратите внимание, что вам может потребоваться заменить № 1 идентификатором, созданным ранее, если он был другим. Пометив запрос на вытягивание идентификатором проблемы, вы можете автоматизировать закрытие проблемы позже, когда запрос будет объединен.Щелкните Создать запрос на вытягивание .

  5. В раскрывающемся списке проекта выберите разветвленную версию в своей учетной записи GitHub.

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

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

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

  9. Вы также можете оставлять комментарии на уровне строки. Нажмите кнопку Добавить комментарий в измененной строке и добавьте комментарий. Щелкните Начать просмотр .

  10. Ваш отзыв теперь отображается как часть запроса на вытягивание. Щелкните Продолжить просмотр .

  11. Введите сводку обзора и выберите Отправить отзыв | Только комментарий .

  12. В окне браузера GitHub выберите вкладку Pull requests .

  13. Щелкните запрос на перенос, чтобы открыть его.

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

  15. Щелкните Запрос на объединение .

  16. Подтвердите слияние.

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

Начало работы с Git с использованием Azure DevOps Server 2019

Home / Начало работы с Git с использованием Azure DevOps Server 2019 Редактировать на GitHub

Обзор

В этой лабораторной работе вы узнаете о поддержке Git в Azure DevOps Server 2019 и Visual Studio 2019.Git - это распределенная система контроля версий с репозиториями, которые находятся как локально (например, на компьютере разработчика), так и на сервере Azure DevOps. И если у вас есть какие-либо сомнения в масштабируемости Git, будьте уверены, что поддержка Azure DevOps Server для Git Virtual File System (GVFS) дает вам практически неограниченное масштабирование. Просто спросите команду Windows - они используют ее для управления более чем 300 ГБ в 3,5 миллионах файлов.

Предварительные требования

Для выполнения этой лабораторной работы вам понадобится виртуальная машина Azure DevOps Server 2019, предоставленная Microsoft.Нажмите кнопку ниже, чтобы запустить виртуальную машину на портале Microsoft Hands-on-Labs.

Запустить виртуальную машину

Вы также можете скачать виртуальную машину отсюда.

Упражнение 1: Начало работы с Git

В этом упражнении вы узнаете, как создавать, клонировать и отправлять коммиты в репозиторий Git на сервере Azure DevOps Server.

Задача 1: Удаление существующего исходного клона

  1. Войти как Sachin Raj (VSALM \ Sachin) .Все пароли пользователей: P2ssw0rd .

  2. В Explorer перейдите к C: \ Users \ Julia \ Source \ Repos и удалите папку PartsUnlimited . Это удалит существующий клон репо, чтобы вы могли начать все заново.

Задача 2: Клонирование существующего репозитория

  1. Откройте окно браузера и перейдите на портал PU DevOps Portal .

  2. Перейдите к хабу Repos .

  3. Щелкните Клонировать и нажмите кнопку Копировать в буфер обмена , чтобы скопировать путь клонирования Git.

  4. Откройте Visual Studio с панели задач.

  5. Нажмите Clone или проверьте код .

  6. Вставьте местоположение репозитория и щелкните Клонировать .

  7. После клонирования проекта используйте Solution Explorer , чтобы дважды щелкнуть PartsUnlimited.sln , чтобы открыть решение. Вы можете игнорировать предупреждения о неподдерживаемых типах проектов.

  8. Выбрать сборку | Постройте Решение , чтобы построить решение.

Упражнение 2: Сохранение работы с коммитами

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

Что в коммите?

Коммиты Git состоят из следующего:

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

  • Ссылка на родительский коммит (и). Git управляет историей кода, используя эти ссылки.

  • Сообщение с описанием фиксации. Вы передаете это сообщение Git при создании фиксации. Это хорошая идея, чтобы это сообщение было описательным, но по делу.

Задача 1: Фиксация изменений

  1. Откройте Controllers / AccountController.cs из проекта PartsUnlimitedWebsite .

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

  3. Из Team Explorer перейдите к представлению Изменения .

  4. Введите комментарий из «Моя фиксация» и щелкните Зафиксировать все . Это создаст новую фиксацию в локальном репо со всеми включенными изменениями.

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

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

Задача 2: Синхронизация изменений

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

  2. Поскольку изменений нет, нажмите «Синхронизировать», чтобы получить последние коммиты локально (в данном случае нет), а затем вытолкните свои коммиты.

  3. Синхронизация должна пройти быстро, так как нужно отправить только одну фиксацию.

  4. Вы можете просмотреть последние коммиты в Azure DevOps на вкладке Commits в хабе Repos .

  5. Последняя фиксация должна быть вверху.

Задача 3: Постановка изменений

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

  1. Вернуться в Visual Studio .

  2. Обновите открытый AccountController.cs , отредактировав ранее сделанный комментарий.

  3. Откройте также CheckoutController.cs .

  4. Добавьте новый комментарий к CheckoutController.cs , чтобы было два файла с изменениями. Нажмите Ctrl + Shift + S , чтобы сохранить все файлы.

  5. В раскрывающемся списке Team Explorer выберите Изменения .

  6. Щелкните правой кнопкой мыши AccountController.cs и выберите Stage.

  7. Это подготовит AccountController.cs к фиксации без CheckoutController.cs .

  8. Введите комментарий «Добавлены комментарии» и выберите Поэтапная фиксация | Выполнение поэтапной фиксации и синхронизация . Это зафиксирует подготовленный файл и синхронизирует его с сервером в одном процессе.

Упражнение 3: Просмотр истории

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

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

Задача 1: Сравнение файлов

  1. В обозревателе решений щелкните правой кнопкой мыши AccountController.cs и выберите Просмотреть историю .

  2. В представлении «История » для AccountController.cs , щелкните правой кнопкой мыши самую последнюю фиксацию (вверху) и выберите Сравнить с предыдущей .

  3. Это откроет представление Diff во временном файле, в котором указано, что именно изменилось во время этой фиксации.

Задача 2: Получение файлов

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

  2. Это была первая фиксация, выполненная в этой лабораторной работе, и она содержала только одно изменение. В Team Explorer щелкните правой кнопкой мыши AccountController.cs и выберите Открыть .

  3. Версия файла, связанного с этой конкретной фиксацией, открывается во временном файле. Теперь вы можете просмотреть его содержимое, например, комментарий от первого коммита.

Упражнение 4: Управление ветвями из Visual Studio

Вы можете управлять работой в репозитории Azure DevOps Git из представления Branch в Интернете.Вы также можете настроить представление для отслеживания наиболее важных для вас ветвей, чтобы быть в курсе изменений, внесенных вашей командой.

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

Задача 1: Создание новой ветки в локальном репозитории

  1. В раскрывающемся списке Team Explorer выберите Branch .

  2. В настоящее время существует только одно локальное отделение, которое является главным. Щелкните его правой кнопкой мыши и выберите New Local Branch From , чтобы создать новую.

  3. Назовите новую ветку «dev» и щелкните Create Branch .

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

Задача 2: Проверка и публикация филиалов

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

  1. В Team Explorer щелкните правой кнопкой мыши ветку master и выберите Checkout , чтобы переключиться на нее.

  2. Щелкните правой кнопкой мыши ветку dev и выберите Push Branch . Это передаст его серверу.

  3. Успешная отправка ветки может занять некоторое время.

  4. В Azure DevOps перейдите на вкладку Ветви .

  5. Вы должны увидеть новую ветку dev .

  6. Вернувшись в Visual Studio , разверните remotes / origin . Здесь вы можете увидеть все удаленные ветки, в том числе те, которые не были отключены локально.

Задача 3. Удаление веток локально и удаленно

  1. Когда вы ранее создавали ветку dev , Visual Studio переключила вас на нее.Затем вы вручную переключились обратно на master . Поскольку вы не работаете с dev и больше не нуждаетесь в нем, щелкните его правой кнопкой мыши и выберите Удалить .

  2. Обратите внимание, что, хотя вы удалили локальную ветвь dev , удаленная ветка все еще существует.

  3. Чтобы удалить удаленную ветку, щелкните ее правой кнопкой мыши в разделе «Remote / origin» и выберите « Удалить ветвь из удаленного ».

  4. Удаленная ветка должна быть удалена довольно быстро.

  5. Вы можете подтвердить, что он исчез, обновив страницу Ветви в Azure DevOps.

Упражнение 5: Управление ветвями из Azure DevOps

Задача 1: Создание новой ветви

  1. В Azure DevOps щелкните Новая ветка .

  2. Введите имя «выпуск» для новой ветви.Используйте Рабочие элементы, чтобы связать раскрывающийся список , чтобы выбрать один или несколько рабочих элементов для связи с этой новой ветвью. Вы можете найти некоторые из них по идентификатору на странице Boards . Щелкните Create branch , чтобы создать его.

  3. После того, как ветка будет создана, она будет доступна в списке.

  4. Вернитесь в Visual Studio и используйте раскрывающийся список Team Explorer , чтобы переключиться в представление Sync .

  5. Щелкните Получить , чтобы получить данные новой ветви.

  6. Перейти к представлению Ветви .

  7. Пришло время создать локальную версию этой ветки. Щелкните его правой кнопкой мыши в разделе remotes / origin и выберите New Local Branch From .

  8. Примите значения по умолчанию и нажмите Create Branch .

  9. Теперь у вас есть локальная версия этой ветки для работы, и она проверена.

Задача 2: Удаление ветки

  1. Вернитесь в Azure DevOps и нажмите кнопку Удалить , которая появляется при наведении курсора на ветку выпуска , чтобы удалить ее.

  2. Однако, возможно, нам стоит подержать его еще немного.В его контекстном меню выберите Восстановить ветку .

Задача 3: Блокировка ветки

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

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

  1. В контекстном меню master выберите Lock .

  2. Филиал заблокирован.

  3. Теперь Разблокируйте ветку, используя тот же процесс.

Упражнение 6: Работа с запросами на вытягивание

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

Задача 1: Создание нового запроса на вытягивание из Visual Studio

  1. Вернитесь в Visual Studio и перейдите к представлению Изменения в Team Explorer .

  2. В лабораторной работе все еще есть незавершенные изменения по сравнению с предыдущими изменениями, поэтому введите комментарий «Изменения контроллера оформления заказа» и выберите Зафиксировать все | Зафиксировать все и синхронизировать .

  3. После успешной синхронизации перейдите к представлению Pull Requests .

  4. Щелкните Новый запрос на слияние , чтобы продолжить процесс в Azure DevOps.

  5. Форма New Pull Request уже должна содержать ключевую информацию, которая понадобится рецензентам, а также то, кем должны быть эти рецензенты. Вы можете настроить все это, и некоторые из них могут потребоваться в зависимости от политики.Щелкните Создать .

  6. Вновь созданный запрос на перенос будет загружен, но пока не утверждать его. Мы вернемся позже.

Задача 2: Управление запросами на вытягивание

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

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

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

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

  5. Выберите вкладку Files , чтобы просмотреть файлы, участвующие в фиксации.

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

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

  8. Новый комментарий помещается в строку с кодом.Это упрощает обсуждение строк и участков кода в их надлежащем контексте.

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

  10. Обновите комментарий, чтобы пометить его как Решено .

  11. Обратите внимание, что теперь это также обновляет отслеживание.

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

  13. Выберите вкладку Commits , где вы можете просмотреть коммиты, сделанные в ветке.

  14. Поскольку вроде бы все в порядке, Утвердите запрос на перенос.

  15. После того, как утверждающие подписались, Завершите запрос на перенос.

  16. Вы можете принять сообщения по умолчанию в диалоговом окне запроса на вытягивание. Обратите внимание, что у вас также есть возможность удалить целевую ветвь после слияния, а также возможность сжимать изменения во время границы. Сквош-слияние - это вариант слияния, который позволяет вам сжать историю Git веток темы при выполнении запроса на вытягивание.Вместо того, чтобы каждая фиксация в ветке темы добавлялась в историю ветки по умолчанию, слияние сквоша берет все изменения файлов и добавляет их в одну новую фиксацию в ветке по умолчанию. Слияние Squash сохраняет ваши истории ветвей по умолчанию чистыми и легкими для отслеживания, не требуя каких-либо изменений рабочего процесса в вашей команде. Щелкните Завершить слияние.

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

  18. Вернуться на главную страницу запросов на вытягивание.

  19. Выберите вкладку Завершено и щелкните запрос на вытягивание, как если бы вы открыли его заново.

  20. Вы можете просмотреть запрос на извлечение, а также Cherry-pick или Вернуть при необходимости.

Задача 3. Добавление тегов к выпуску

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

  2. Щелкните Create Tag .

  3. Введите имя «v1.1» и Описание «Отличный выпуск!» . Щелкните Создать .

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

Упражнение 7: Управление репозиториями

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

Задача 1. Создание нового репо из Azure DevOps

  1. В раскрывающемся списке проекта Добавить выберите Новый репозиторий .

  2. Установите имя репозитория на «Новое репо» и нажмите Создать .

  3. Вот и все. Ваше репо готово. Теперь вы можете клонировать его с помощью Visual Studio или других инструментов.

Задача 2: Удаление и переименование репозиториев Git

  1. Иногда вам нужно переименовать или удалить репо, что так же просто. Откройте Настройки проекта .

  2. Выберите Хранилища под кодом .

  3. В контекстном меню New Repo выберите Delete repository . Кроме того, вы можете переименовать его здесь.

  4. Введите имя «Новое репо» , чтобы подтвердить репо, и нажмите Удалить .

Задача 3: Управление политиками репо и филиалов

  1. Выберите репо PartsUnlimited .Как и все остальное в Azure DevOps, вы можете управлять безопасностью с очень высокой степенью детализации. Выберите вкладку Options . Это позволяет вам установить некоторые полезные политики, например, хотите ли вы разрешить пользователям разветвлять репо, связаны ли обсуждаемые рабочие элементы автоматически и т. Д.

  2. Выберите ветку master . Как и в случае с репо, у вас есть большой контроль над его настройками безопасности. Вы также можете определить широкий спектр политик для принудительного применения веткой.Щелкните Branch Policies .

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

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

  5. Щелкните Добавить автоматических рецензентов .

  6. Добавьте Sachin как Reviewer и установите для фильтра пути значение “/ PartsUnlimited-aspnet45 / src / PartsUnlimitedWebsite / Controllers / *“ .Наличие требования Обязательно гарантирует, что вам потребуется подписывать любые изменения, предлагаемые в коде контроллеров в веб-приложении. Нажмите Сохранить .

  7. Щелкните Сохранить изменения, чтобы сохранить изменения в политике.

Начало работы с Git и Azure DevOps: полное руководство

Если вам понравилась эта статья, возможно, вам понравится наш курс Microsoft Certified DevOps Engineer.

Согласно докладу State of DevOps 2019, передовая практика использования контроля версий является одной из основ повышения производительности доставки и эксплуатации программного обеспечения (SDO). В этой первой части руководства из трех частей вы будете работать с Git и Azure DevOps, чтобы настроить репозиторий, который вы будете использовать для управления версиями. Контроль версий, также известный как контроль версий, имеет много преимуществ, каждое из которых объединяется, чтобы создать цикл обратной связи для команды, работающей над кодом в рамках контроля версий.Эти преимущества включают:

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

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

Предварительные требования

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

  • Подписка Azure, вы можете создать бесплатную учетную запись.

  • Организация Azure DevOps, базовый план начинается с первых пяти пользователей бесплатно.

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

  • Локальная установка Visual Studio Code (VSCode)

  • Локальная установка Git в соответствии с руководством по установке для вашей ОС. Если вы используете Windows, убедитесь, что установлен флажок Включить диспетчер учетных данных Git .

    Если вы установили VSCode до Git, вам также будет представлена ​​эта опция:

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

Шаг 1. Настройка репозитория в Azure Devops

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

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

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

Вариант «Выбрать Начать бесплатно с GitHub» предназначен для команд, уже использующих систему управления версиями в GitHub.В этом руководстве у вас нет кода с контролируемой версией и вы хотите, чтобы репозитории находились в Azure DevOps, поэтому выберите Начать бесплатно .

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

Проект создан и открыта страница проекта для dotnetcoredemo:

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

Это вид пустого репозитория, для работы с этим репозиторием локально, либо из командной строки, либо из клиента, вам нужно будет сгенерировать учетные данные.На этой странице вы можете увидеть кнопку с пометкой Generate Git Credentials , это позволит вам установить имя пользователя и простой пароль для работы с репозиторием. Однако это не рекомендуется, поскольку эти учетные данные имеют полный доступ к репозиторию вместе с другими службами и не имеют срока действия. В статье Microsoft Docs «Обзор проверки подлинности для Azure DevOps» рекомендуется использовать токен персонального доступа, где можно задать объем доступа и срок действия.

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

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

Отображается форма для создания персонального токена доступа:

Работая с опциями, Имя - это имя вашего личного токена доступа, оно должно быть уникальным для ваших токенов. Организация - это ваша организация Azure DevOps, на данный момент она у вас есть.Однако, если вошедшему в систему пользователю предоставлен доступ к нескольким организациям, вы можете выбрать «Все доступные организации» в этом раскрывающемся списке. Области действия , здесь вы выбираете, с какими службами может работать этот токен личного доступа. Выберите Custom defined , так как вы хотите использовать принципал с наименьшими привилегиями. Каждая область соответствует набору разрешений для одной из служб, которые вы видели слева при первом входе в Azure Devops. В этом руководстве вы хотите работать с кодом, читать и писать из репозитория, поэтому выберите Чтение, запись и управление и статус в разделе Код .Прокрутите области вверх и вниз, чтобы получить представление о том, как можно настроить токен личного доступа, оставьте все остальные области неотмеченными. Щелкните Создать .

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

Экран успеха отображается еще раз, и регенерированный жетон можно скопировать.

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

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

Прокрутите страницу репо вниз до раздела Инициализировать с помощью README или gitignore . Убедитесь, что установлен флажок Добавить README , это создаст файл readme в корне репозитория. Обычно файл readme дает инструкции по использованию репозитория, файл readme - это файл разметки.Вы также захотите добавить файл .gitignore, этот файл инструктирует git игнорировать каталоги и типы файлов, которые требуются для вашего проекта, но не должны храниться в системе управления версиями в вашем репозитории. В этой части руководства мы собираемся использовать простые текстовые файлы, но для примера работающего .gitignoe мы настроим проект для .NET, поэтому используйте раскрывающийся список, чтобы выбрать VisualStudio . Щелкните Инициализировать .

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

Шаг 2. Клонирование Azure Repo

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

При работе с кодом, хранящимся в распределенной системе, такой как Git, которая является серверной частью для репозитория Azure DevOps, вы берете полную копию репозитория путем клонирования репозитория.Это воссоздает всю историю репозитория локально на машине пользователя. Щелкните Clone в правом верхнем углу:

В разделе IDE есть опция Clone в VS Code , это запустит VSCode, предложит локально сохранить репозиторий и откроет сеанс VSCode с новым загруженным репозиторием, открытым как папка в VSCode. Глядя на снимок экрана ниже, вы также можете увидеть, что та же функция доступна в других IDE:

В этом руководстве вы собираетесь использовать Git в командной строке, это позволит вам понять механизм того, что делает каждая команда, поскольку она не будет скрыта IDE.Для этого нажмите кнопку копирования (показана красным выше).

Откройте командную строку локально и cd в каталог, в который вы хотите клонировать репозиторий. Введите в командной строке git clone , это команда git для клонирования, а затем вставьте URL-адрес, скопированный из репозитория клонирования выше, это укажет Git, откуда следует клонировать репозиторий: Нажмите return, и вам будет предложено ввести пароль. При запросе пароля вставьте токен личного доступа, который вы сохранили ранее, и нажмите клавишу возврата еще раз.Если учетные данные верны, репо клонируется:

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

Если вы перечислите содержимое структуры каталогов с помощью dir / b ( ls на Mac), вы увидите первый объект, папку, содержащую репозиторий. cd в папку репозитория и еще раз перечислите содержимое. В списке перечислены второй и третий объекты, два файла, которые вы создали на портале Azure DevOps. Немного изменив команду list для вывода всех файлов и папок с использованием dir / a / b ( ls -al на Mac), отобразится скрытый каталог .git. Это четвертый объект, в котором Git отслеживает локальные изменения. Обратите внимание, что на Mac .gitignore не будет отображаться в списке содержимого папки без ls -al , он рассматривается как скрытый файл.

Примечание

- при первом подключении к репозиторию в ОС Windows вам будет предложено ввести учетные данные, которые вы используете для входа в Azure DevOps:

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

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

Теперь у вас есть локально клонированный репозиторий, в котором нет изменений по сравнению с репозиторием на сервере. Вы можете проверить это с помощью команды git status :

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

Шаг 3 - Сохранение изменений с фиксацией и нажатием

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

Чтобы увидеть это в действии, вам нужно отредактировать файлы локального репозитория, для этого вы можете запустить VSCode из папки репозитория в командной строке, используя код . команда:

VSCode открывается с репозиторием dotnetcoredemo, открытым в представлении проводника с левой стороны. При нажатии на readme.md в редакторе открывается файл:

Измените заголовок, измените текст на # Introduction to Azure Repos и сохраните изменения. Вернитесь в командную строку и еще раз запустите git status из каталога dotnetcoredemo:

Статус Git обнаружил, что в отслеживаемом файле в файловой системе есть модификация, и отобразил это, если бы было более одного изменения, все изменения были бы перечислены здесь.На данный момент репозиторий не отслеживает перечисленные изменения, уведомление о том, что изменения не поставлены для фиксации , указывает на то, что это так. Для отслеживания изменений вам сначала нужно этап изменений. Для этого вам нужно выполнить команду git add . Вы можете обработать один файл, используя его имя файла с помощью команды git add filename , или, если у вас есть несколько изменений для этапа, вы можете использовать точку git add. , чтобы добавить все изменения.Если вы сейчас перезапустите git status :

Имя файла теперь отображается зеленым цветом, оно подготовлено и готово к фиксации в репозитории для локального отслеживания. Выполните команду фиксации git commit -m «сообщение фиксации» , где сообщение фиксации описывает изменение или детализирует рабочий элемент, например номер дефекта:

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

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

.

Вы можете увидеть, как команда git push сжимает зафиксированные изменения и отправляет их в репозиторий Azure DevOps. После завершения этого процесса, если вы повторно выпустите git status , сообщение Ваша ветка обновлена ​​с 'origin / master' указывает на то, что локальный репозиторий и репозиторий Azure DevOps снова синхронизированы.

Вернитесь на портал Azure DevOps, на этот раз щелкните Commits в пункте меню Repos слева:

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

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

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

Шаг 4. Обновление кода с помощью выборки и извлечения

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

  • fetch - загружает изменения из вашего удаленного репо, но не применяет их к вашему коду. Это позволяет вам ознакомиться с изменениями перед их применением.

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

  • pull - объединяет вышеперечисленное, выполняет выборку , а затем слияние .

Чтобы смоделировать, что другой разработчик вносит изменение и отправляет его в репозиторий Azure, вернитесь на портал Azure DevOps, щелкните Files в пункте меню Repos слева и щелкните имя файла README.md открыть файл в Preview :

Если Azure DevOps знает, как отображать тип файла, например Markdown, он откроется в режиме предварительного просмотра файла с соответствующим форматированием.Чтобы отредактировать файл, нажмите Изменить вверху справа:

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

Введите сообщение о фиксации и нажмите Commit внизу, в фоновом режиме Azure DevOps выполняет ту же команду git commit -m , которую вы использовали на предыдущем шаге. Разница в том, что Azure DevOps фиксирует изменения в репозитории Azure, а не локально.Поэтому, если вы снова переключитесь на VSCode и отредактируете файл README.md, вы увидите, что в заголовке все еще написано «Начало работы».

Локальный репозиторий и репозиторий Azure теперь не синхронизированы, чтобы изменения отражались в локальном репозитории, вы извлекаете изменения в локальный репозиторий. Это выполнит git fetch и git merge :

Изменение, внесенное в Azure DevOps, теперь перенесено в локальный репозиторий. Если вы вернетесь к VSCode, изменение строки заголовка станет видимым.

Шаг 5. Отправка выходящего репозитория из командной строки

Вы изучили работу с репозиторием, созданным с помощью Azure DevOps, путем локального клонирования этого репозитория, отправки и получения изменений из репозитория Azure. Что произойдет, если у вас уже есть локальный репозиторий и вам нужно отправить его в новый проект Azure DevOps? Чтобы смоделировать это, вам нужно инициализировать новый репозиторий git локально, затем добавить README в этот репозиторий и отправить его в новый проект Azure DevOps.

При инициализации репозитория создается пустой репозиторий с использованием того же метода, который используется в Azure DevOps на шаге 1. Оба эти процесса используют команду git init . При локальном выполнении команды она должна выполняться в папке, которая еще не содержит репозиторий git, однако папка не обязательно должна быть пустой:

Процесс здесь состоит в том, чтобы создать новую пустую папку, используя mkdir в командной строке, cd в эту папку, а затем выполнить git init .Выделенный выше раздел показывает, что репозиторий Git инициализируется, а затем dir / a / b ( ls -al на Mac), чтобы показать, что репозиторий пуст, за исключением вновь созданной папки .git.

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

Введите текст в файл и сохраните.Вернитесь в командную строку и выполните команду git status , чтобы убедиться, что Git уловил изменение в файловой системе. Теперь выполните git add. , чтобы подготовить все изменения к фиксации, затем зафиксируйте изменение с помощью git commit -m и добавьте соответствующее сообщение:

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

Отображаемая страница создания проекта немного отличается от страницы, отображаемой для новой организации Azure DevOps.Вам нужно будет ввести имя проекта , сделав его таким же, как имя папки вашего локального репозитория. Если вы прокрутите страницу вниз, вы также можете выбрать Контроль версий , который всегда по умолчанию Git, но может быть изменен на Team Foundation Server. Щелкните Create , чтобы создать новый проект. Когда новый проект будет создан, щелкните Repos в меню служб слева, вы увидите ту же пустую страницу репо, что и на шаге 1. Прокрутите вниз до Нажмите существующий репозиторий из командной строки :

Здесь вы можете увидеть URL-адрес удаленного с именем origin.Удаленный репозиторий в Git - это версия проекта, размещенная в Интернете или в локальной сети, в случае этого руководства, в Azure DevOps. Origin - это просто имя по умолчанию для URL-адреса, это сокращенное имя. Если вы выполните git remote из репозитория, будут перечислены все пульты для репозитория:

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

Удаленный пульт был добавлен, и при повторной выдаче git remote происхождение отображается как удаленное.Теперь вам нужно подтолкнуть свои изменения к источнику, для этого выполните git push origin master , это подтолкнет все изменения из локальной главной ветки к источнику:

Вернитесь на портал Azure DevOps, щелкните Repos , а затем Files в меню служб для проекта localgitinitdemo, теперь Repo отражает репозиторий, выдвинутый из локального:

Шаг 6 - Работа с GitHub

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

Войдите в GitHub с учетными данными, использованными для создания входа в GitHub на этапе предварительных запросов:

Это пустой проект, в нем пока нет репозиториев.Щелкните New вверху справа, чтобы добавить новый репозиторий:

Содержимое, необходимое для этой страницы, такое же, как и для репозитория Azure. Введите имя репозитория , оставьте значение репозитория по умолчанию Public , вы также можете инициализировать README.md и .gitignore. Дополнительный раскрывающийся список позволяет вам выбрать лицензию с открытым исходным кодом для этого репозитория, что очень часто встречается на GitHub. Нажмите Создать репозиторий , репозиторий будет создан, и автоматически загрузится страница репозитория:

Прокручивая страницу репозитория вниз, вы можете увидеть команды git для создания нового репозитория или отправки нового репозитория из командной строки.Эти команды точно такие же, как и для Azure DevOps, разница заключается в адресе пульта дистанционного управления, который указывает на ваше репозиторий GitHub. Чтобы изучить это, начните с инициализации локального репозитория:

Используемые здесь команды идентичны командам Azure DevOps, сначала создайте пустую папку с mkdir githubdemo , используя то же имя, что и репозиторий, созданный в GitHub. Затем cd в папку и инициализируйте с помощью git init . Используйте команду echo , чтобы быстро создать README с одним заголовком. echo # Добро пожаловать в GitHub >> README.md ( echo "# Добро пожаловать в GitHub" >> README.md на Mac). Выполните git add. и git commit -m "message" для обработки и фиксации ваших изменений локально. Теперь вы готовы к отправке изменений в репозиторий GitHub, однако, несмотря на то, что это общедоступный репозиторий, вам все равно нужны разрешения для доступа к репозиторию. Вернитесь в репозиторий GitHUb в своем браузере, щелкните значок профиля в правом верхнем углу и выберите Настройки :

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

Еще раз вы можете увидеть сходство с Azure DevOps Repos. Вам нужно ввести Note , чтобы указать, для кого предназначен токен, и предоставить Scope , в этом случае отметив репо , чтобы предоставить доступ к общедоступным и частным репозиториям с этим токеном.

Прокрутите страницу вниз и нажмите Создать токен , чтобы сгенерировать токен:

Сгенерированная страница токена предупреждает вас, что вы должны сделать копию, поскольку токен не может быть восстановлен. После того, как вы взяли копию токена, вернитесь на страницу репо и возьмите копию первой команды для … или нажмите существующий репозиторий из командной строки * . Вернитесь в окно терминала и выполните эту команду внутри папки, в которой был запущен git init и README.md файл создан. Это создает пульт с именем origin, который указывает на ваш пульт GitHub. Теперь вы можете выполнить git push origin master , чтобы отправить локальную главную ветку на ваш удаленный компьютер:

Примечание. В ОС Windows вам будет предложено ввести учетные данные github, при отображении страницы введите свое имя пользователя и пароль, как если бы вы входили в GitHub в своем браузере:

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

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

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

Введенное сообщение фиксации отображается напротив фиксации, а тест, добавленный к уценке, можно увидеть в README.md

Заключение

В этой статье вы узнали, как работать с репозиториями Git и Azure DevOps / GitHubs.Как настроить пустой репозиторий, а затем вставить в него текущую строку кода или создать с нуля на портале или в командной строке. Вы смоделировали обновление своего кода после смены члена команды и то, как использовать токены доступа для отправки кода из командной строки или IDE.

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


Николь Стивенс - технический директор независимого поставщика программного обеспечения в Великобритании. Николь более двадцати лет проработала в сфере разработки программного обеспечения, начиная с должности администратора баз данных Oracle, занимаясь поиском и устранением неполадок производительности, проектированием и интеграцией для крупных предприятий в регионе EMEA. Переход на стартап независимого поставщика программного обеспечения привел к новым вызовам, и в его обязанности входили ИТ-специалисты, технические консультации / предпродажная подготовка и разработка программного обеспечения. Как сертифицированный архитектор решений Microsoft, Николь в настоящее время занимается реконструкцией устаревших программных решений в облаке.

Самое простое из возможных: Git и Visual Studio

Мы всегда могли разместить исходный код нашего решения на основе Visual Studio в Git. Проблема заключалась в том, что, в отличие от Team Foundation Sever (TFS), Git страдал из-за отсутствия интеграции с Visual Studio IDE. Сегодня отсутствие интеграции осталось в прошлом! Недавно Microsoft сделала Git первоклассным специалистом в области TFS. Сегодня мы можем выбрать TFS или Git в качестве поставщика управления исходным кодом (SCC) в наших командных проектах.Чтобы все работало с Git, Visual Studio 2013 в рамках своей установки также устанавливает Git. Означает ли это, что вам нужно использовать TFS или Visual Studio Online, чтобы воспользоваться преимуществами Git в Visual Studio? Ответ - нет. В этой статье я покажу вам, как оживить Git в Visual Studio, используя только то, что Visual Studio предоставляет вам в комплекте.

Что делать, если у вас не установлен Git?

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

Рисунок 1. Страница загрузки git-scm windows и командная строка для проверки git install

Впервые в Git?

В оставшейся части этой статьи предполагается, что у вас есть хотя бы рабочее знание Git. Если нет, ничего страшного. Хорошая новость заключается в том, что с Visual Studio вам не нужно сразу понимать, как работает Git, хотя в какой-то момент вы захотите познакомиться с тем, как работает Git и его синтаксисом командной строки.Одним из лучших ресурсов для изучения Git является бесплатная электронная книга Скотта Чакона «Pro Git», показанная на рис. 2 .

Рисунок 2: Pro Git Скотта Чакона - это бесплатная электронная книга, доступная на сайте git-scm.com.

Git Version Control и TFS Version Control

Основное различие между Git и TFS Version Control (VC) заключается в их соответствующем типе. Если TFS является централизованным, распространяется Git. В распределенной системе VC каждый клиент имеет свой собственный локальный репозиторий, который синхронизируется с одним или несколькими удаленными репозиториями.Каждый локальный репозиторий, помимо прочего, имеет возможность ветвления, слияния и фиксации. В централизованной системе VC есть только один репозиторий, размещенный на сервере. Только с тем централизованным сервером, на котором происходят операции ветвления, слияния и фиксации. В централизованной модели разработчики должны иметь постоянное подключение к центральному репозиторию, чтобы пользоваться преимуществами VC. В распределенной модели разработчикам требуется подключение только тогда, когда им нужно синхронизировать свои изменения. Признавая ценность распределенного венчурного капитала и популярность Git, Microsoft встроила Git в TFS.Теперь, когда вы создаете TFS или Visual Studio Online Team Project, вы выбираете поставщика управления версиями: Git или TFS.

Поддержка Git в Visual Studio не является какой-то специальной версией Git. Скорее, это поддержка самого Git. Кроме того, есть поддержка распространенных удаленных хостеров Git, таких как GitHub и BitBucket. Если ваш проект находится в каталоге, в котором есть инициализированный репозиторий git, Git функционирует в Visual Studio, как вы сейчас увидите: «Загорится». Конечно, чтобы связать рабочие элементы с коммитами исходного кода, вам нужно использовать TFS или Visual Studio Online.

Начало работы: создание удаленного репозитория на GitHub

На рисунках 3 и 4 показан новый репозиторий GitHub.

Рисунок 3. Когда вы создаете репозиторий в GitHub, вы можете указать ряд параметров. Рисунок 4: Основная страница GitHub для репозитория

После создания репозитория GitHub следующим шагом будет клонирование репозитория в локальный репозиторий Git. Для этого вы будете использовать Visual Studio и, в частности, консоль диспетчера пакетов NuGet.

Поддержка Git в Visual Studio не является какой-то специальной версией Git. Скорее, это поддержка самого Git.

Клонирование репозитория GitHub с помощью PowerShell в Visual Studio

PowerShell - мощный инструмент; Visual Studio поставляется с командным окном PowerShell. Вы знаете его как консоль диспетчера пакетов NuGet. Рисунок 5 показывает, что PowerShell не имеет проблем с командой Git и, как видите, клонировать удаленный репозиторий довольно просто.

Рисунок 5: Выполнение команды Git Clone из консоли PowerShell диспетчера пакетов NuGet

Рисунок 6 подтверждает, через проводник, клонированный репозиторий.

Рисунок 6: Клонированный репозиторий, как показано в проводнике. Обратите внимание, что в контекстном меню, распознающем каталог, есть репозиторий Git.

На следующем этапе Visual Studio Team Explorer будет подключен к локальному репозиторию.

Подключение Visual Studio к Git

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

Рисунок 7: Новый проект будет сохранен в домашнем каталоге нового репозитория Git.

Вы еще не закончили. Вы должны указать Visual Studio добавить текущее решение в систему управления версиями. Рисунок 8 показывает, как вызвать этот параметр меню.

Рисунок 8: Чтобы добавить решение в систему управления версиями Git, необходимо выбрать пункт меню «Добавить в систему управления версиями».

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

Рисунок 9. Когда выбран пункт меню «Добавить в систему управления версиями», Visual Studio обнаруживает существующий репозиторий Git.

Если вы решите добавить проект в элемент управления исходным кодом, вам будет предложено выбрать между TFS и Git. Рисунок 10 показывает, как это работает. Окно вывода подтверждает создание нового локального репозитория Git (при условии, что вы выбрали именно этот вариант). В этой последовательности вы должны связать локальный репозиторий Git с удаленным репозиторием. Для этого вы вводите следующую команду:

  git remote add origin https://github.com/user/repo.git

  
Рисунок 10. После выбора параметра Git создается новый репозиторий Git.Отсюда легко указать удаленный репозиторий в консоли PowerShell диспетчера пакетов.

Теперь, когда проект Visual Studio находится в системе управления исходным кодом Git, пора обратить ваше внимание на Team Explorer.

Работа с Git и Team Explorer

Рисунок 11 иллюстрирует несколько вещей. Во-первых, Visual Studio не подключена ни к одной TFS. Когда-то для использования Team Explorer требовалось активное подключение к TFS. Эта новая встроенная поддержка Git меняет все это.TFS - отличная среда, но она не для всех. Почему встроенная и интегрированная поддержка управления исходным кодом должна зависеть от TFS?

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

Отсюда, если вы знакомы с тем, как использовать Team Explorer для фиксации изменений в репозитории исходного кода, вы уже знаете, что делать. Рисунок 12 иллюстрирует основной рабочий процесс.Сначала вы нажимаете кнопку «Изменения» в Team Explorer. Как только вы предоставите сообщение о фиксации, вы можете зафиксировать эти изменения в своем локальном репозитории. Есть три варианта:

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

Рисунок 12: Фиксация изменений исходного кода в Team Explorer работает так же, как фиксация изменений в репозитории исходного кода TFS.

На рисунке 13 показаны результаты первой фиксации.Это действительно так просто. Все, что было сделано с помощью Team Explorer, можно было сделать с помощью команд Git через командную строку, Git Bash или, как было показано ранее, с помощью консоли PowerShell диспетчера пакетов NuGet.

Рисунок 13: Используя историю фиксации в качестве примера, внутри Visual Studio вы можете выбрать использование Team Explorer, командной строки или какой-либо комбинации при взаимодействии с Git.

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

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

Рисунок 14: Из Team Explorer очень легко синхронизировать локальные и удаленные репозитории Git.

Это все, что нужно для синхронизации с удаленным репозиторием Git.Локальный репозиторий знает об удаленном репозитории, потому что локальный репозиторий был создан путем клонирования удаленного репозитория. С другой стороны, если вы сначала создаете локальный репозиторий, вам нужно вызвать команду git remote add .

О ветвлении и слиянии

Ветвление и слияние очень легко выполнить в Team Explorer. Для демонстрации создадим ветку под названием development. Рисунок 15 иллюстрирует этот рабочий процесс. Обратите внимание, что установлен флажок «Ветка оформления заказа».Когда вы проверяете ветку, она делает эту ветку выбранной в данный момент веткой. Вы всегда на ветке. Когда вы впервые создаете репозиторий, есть одна ветка с именем master . Это корневая ветвь или то, что часто называют стволом. Идея состоит в том, что со временем на стволе появятся ветви, как у дерева. В конце концов, активность в этих ветвях со временем переносится обратно в магистраль. Прежде чем вы сможете переключаться между ветвями, вы должны либо зафиксировать, либо спрятать свою работу. Сохранение работы помещает вашу работу во временное хранилище без необходимости фиксировать ее в текущей ветке.

Рисунок 15. Из Team Explorer очень легко создавать локальные ветви и публиковать их в удаленном репозитории.

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

Рисунок 16. Когда ветка опубликована, она становится доступной в удаленном репозитории.
Сегодня, независимо от того, используете ли вы Team Foundation Server или Visual Studio Online, вы можете использовать Team Explorer для управления исходным кодом Git и взаимодействия с ним.

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

  1. Оформить заказ на ветку, в которой вы хотите работать. Вы можете использовать команду git checkout или выбрать ветку в Team Explorer.
  2. Внесите свои изменения.
  3. Синхронизируйте локальный репозиторий с удаленным репозиторием, убедившись, что ваша локальная копия мастера обновлена.
  4. Зафиксируйте изменения в ветке.
  5. Объедините ваши изменения из ветки (источника) в главную (цель). Вы также можете слить из одной ветки в другую. Или вы можете выполнить слияние от мастера к ветке.
  6. Если нет конфликтов слияния, синхронизируйте изменения с удаленным репозиторием.

Рисунок 17 показывает, где и как инициировать слияние в Team Explorer. Как и во всем остальном, у вас есть возможность инициировать эти операции с помощью команд git в командной строке.

Рисунок 17: Слияние, как и ветвление, можно инициировать в Team Explorer.

Заключение

Как видите, Git теперь является первоклассным гражданином Visual Studio. Вы всегда могли контролировать свои проекты на основе Visual Studio в Git. Этот процесс не был интегрирован, и вам приходилось полагаться на внешнюю командную строку или какой-либо другой пользовательский интерфейс Git. Сегодня, независимо от того, используете ли вы Team Foundation Server или Visual Studio Online, вы можете использовать Team Explorer для управления исходным кодом Git и взаимодействия с ним.До этих последних изменений, чтобы использовать Team Explorer, вам также приходилось подключаться и использовать командный проект TFS. Сегодня ваш удаленный репозиторий Git можно разместить где угодно. В этой статье использовался GitHub, но можно было использовать и другой сервис, например BitBucket.

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

С Visual Studio вам не нужно беспокоиться о том, чтобы стать ниндзя командной строки Git. Вместо этого вы можете использовать Team Explorer для большинства своих функций. Со временем, чтобы получить максимальную отдачу от Git, вы захотите познакомиться с необработанными командами. Хорошая новость заключается в том, что вы можете усвоить эти знания, оставаясь продуктивным с Team Explorer.

Функциональность Git Stash в Visual Studio 2019 - Томас Клавдиус Хубер

Если вы уже просматривали страницу изменений в Team Explorer в Visual Studio 2019, вы могли заметить, что на ней есть новый раздел Тайники. Это показано на скриншоте ниже. Но для чего нужен этот раздел Тайники?

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

Просто введите сообщение в окне «Изменения» в Team Explorer. Сообщение не является обязательным для тайника, я ввел на снимке экрана под сообщением «Первый черновик входа клиента». Теперь нажмите кнопку тайника:

В раскрывающемся списке нажмите «Спрятать все». Это создаст тайник, содержащий все незафиксированные изменения. Итак, тайник похож на локальную копию ваших незафиксированных изменений. Нажатие на «Stash All» также отменит все незафиксированные изменения в вашей ветке.Если вы хотите сохранить изменения в ветке, которые вы уже подготовили для фиксации, вы выбираете «Stash All and Keep Staged». Но в моем случае выше я не размещал файл Program.cs. Таким образом, оба варианта тайника будут иметь одинаковый эффект. Выберем «Спрятать все».

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

Теперь можно например перейти в другую ветку. Позже вы можете вернуться в свою ветку функций, и там вы можете щелкнуть правой кнопкой мыши этот тайник на странице изменений в Team Explorer.В появившемся контекстном меню (вы можете увидеть его ниже) вы можете просмотреть изменения. Вместо использования контекстного меню для просмотра изменений вы также можете дважды щелкнуть тайник.

Как вы можете видеть на картинке выше, помимо меню «Просмотр изменений» в контекстном меню тайника также есть следующие параметры:

  • Применить - это применит изменения к ветке и сохранит тайник
  • Drop - это удалит тайник
  • Pop - это приведет к Применить изменения и Удалить тайник

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

  • Pop / Apply and Restore Staged - это вызовет / применяет изменения к вашей ветке, а также гарантирует, что файлы, которые вы разместили ранее, снова будут размещены
  • Pop / Apply All as Unstaged - это появится / примените изменения к вашей ветке, и она не будет размещать файлы, которые вы разместили ранее.

Если у вас не было промежуточных файлов до создания тайника, то вы не увидите разницы между двумя вариантами.Итак, давайте выберем в моем случае «Pop All as Unstaged», и тогда мы вернемся к состоянию, которое было у нас в начале этого сообщения в блоге. Изменение в файле Program.cs:

Итак, кэширование отлично подходит для хранения изменений, которые вы еще не хотите фиксировать.

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

Давайте посмотрим на это в действии. Как вы видели на скриншоте выше, я внес изменения в файл Program.cs. На картинке ниже вы видите страницу веток Team Explorer.В проверенной ветке feature / customerLogin есть локальные изменения, и она также не указывает на ту же фиксацию, что и ветка master (вы не можете увидеть это на скриншоте, так что просто поверьте мне :)). Итак, давайте посмотрим, что произойдет, когда мы попытаемся проверить основную ветку с помощью контекстного меню, как показано ниже:

Visual Studio замечает проблему и показывает следующее окно:

В этом окне вы можете выполнить принудительную проверку, что означает, что Visual Studio отменит локальные изменения и выполнит проверку основной ветки.Это означает, что ваши незафиксированные изменения будут потеряны. Но Visual Studio показывает вам другое диалоговое окно после нажатия «Force Checkout», чтобы убедиться, что вы действительно уверены, что отмените локальные изменения.

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

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

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