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

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

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

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

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

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

• 17.06.2021
• 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 (бесплатно). Прочтите наше руководство по ценам для более подробного сравнения выпусков.Мы предлагаем версию для сообщества, потому что вам не понадобятся функции, предлагаемые более дорогими (а они могут быть дорогими) уровнями.

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 #), которых нет. относится к этому руководству.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Измените раскрывающийся список раздела 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, проблема в том, что они только локальные. Воспользовавшись услугами удаленных репозиториев, таких как GitHub, Bitbucket и Azure DevOps, вы можете поддерживать резервные копии и позволять другим вносить свой вклад.

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

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

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

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

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

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

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

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

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

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

Push & Pull Changes

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

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

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

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

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

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

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

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

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

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

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

  git remote add origin https://github.com/user/repo.git