Я изучил более 40 программ и отобрал для вас 27 лучших. В подборке: ТОП-10 самых сильных курсов, затем — вспомогательные обучающие модули, а в завершении — бесплатные ресурсы.

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

ТОП-10 лучших курсов по Git в 2025 году

1. Профессиональная разработка в 1С:EDT + Git от OTUS.ru — отличный курс для разработчиков 1С.

2. CI/CD на примере Gitlab CI от Слерма — обучение автоматизации тестирования и развертывания с гибким графиком.

3. Git — система контроля версий от Контур.Школы — качественные обучающие материалы с акцентом на практику.

4. Git и GitHub от HTML Academy — отличное решение для начинающих веб-разработчиков.

5. Основы Git от Purpleschool — возможность смотреть уроки и проходить тесты с телефона.

6. Git. Управление версиями для разработчиков от beONmax.com — лучший курс для опытных разработчиков.

7. Git для начинающих от itProger — простая информация для начинающих с нуля понятными объяснениями.

8. Linux / Git от beONmax.com — отличный выбор для тех, кто хочет разобраться в работе Git в среде Linux.

9. Продвинутый Git от Thinknetica — возможность разобраться в сложных концепциях, таких как rebase, cherry-pick..

10. Система управления версиями Git от Специалист.ru — практико-ориентированный курс по Git для начинающих и опытных разработчиков.

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

Онлайн-курсы Git

1. Профессиональная разработка в 1С:EDT + Git | OTUS.ru

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

• Стоимость: 54 900 рублей

• Длительность: 120 дней

• Формат обучения: онлайн (видеоуроки, практика, проверка заданий)

• Сертификат: предоставляется свидетельство

Кому подойдет: разработчикам 1С и IT-специалистам, чья профессиональная деятельность связана с внедрением, сопровождением или интеграцией решений на платформе 1С.

Преимущества:

• возможность разработать личный проект;

• обучения у действующих специалистов;

• закрепление теоретических знаний путем выполнения практических заданий;

• участие в интерактивных вебинарах;

• постоянный доступ к учебным материалам;

• живое общение с преподавателями, включая переписки в телеграм-чате;

• проверка домашних заданий с развернутыми ответами.

Недостатки:

• только один проект в портфолио.

Программа обучения:

• Знакомство с инструментарием разработчика, а также основными принципами работы в EDT

• Изучение плагинов, использование искусственного интеллекта

• Ознакомление с технологией Git: удаленные репозитории, настройки, история проекта, ветки

• Изучение методологии разработки CI/CD, новых инструментов

Ознакомиться с полной программой >>>

2. CI/CD на примере Gitlab CI | Слерм

Этот продвинутый онлайн-курс посвящён внедрению практик CI/CD с использованием функциональных возможностей платформы GitLab CI. Под руководством опытных DevOps-инженеров вы пошагово освоите процесс построения надежного и эффективного CI/CD пайплайна. Курс сочетает теорию и практику, позволяя сразу применять полученные знания в работе над реальными проектами. Вы приобретете ценные навыки автоматизации, необходимые для современной разработки и сопровождения программных продуктов.

• Стоимость: 3125 рублей в месяц или 12 500 рублей единовременно

• Длительность: можно завершить обучение в любое время

• Формат обучения: онлайн-лекции с практическими занятиями

• Сертификат: свидетельство о прохождении курса при изучении более 80% программы

Кому подойдет: инженерам DevOps, разработчикам, системным администраторам.

Преимущества:

• практический опыт работы с Gitlab ci;

• обучение у экспертов в области devops;

• разработка реального пайплайна ci/cd;

• знакомство с лучшими практиками ci/cd;

• актуальные знания о современных инструментах автоматизации.

Недостатки:

• требуется базовое понимание Git и основ devops;

• график обучения может быть достаточно интенсивным.

Программа обучения:

• Введение в CI/CD и DevOps

• Обзор Gitlab CI и его компонентов

• Создание и настройка пайплайнов Gitlab CI

• Автоматизация сборки, тестирования и анализа кода

• Интеграция с различными инструментами (Docker, Kubernetes и т. д.)

• Автоматизация развертывания приложений

• Мониторинг и логирование процессов CI/CD

• Безопасность пайплайнов CI/CD

Ознакомиться с полной программой >>>

3. Git — система контроля версий | Контур.Школы

Применить промокод >>> 

В программе рассматриваются ключевые команды и приемы: инициализация репозитория, коммиты, работа с ветками, слияние, разрешение конфликтов. Отдельное внимание уделяется взаимодействию с удаленными репозиториями на GitHub, GitLab и GitFlic. Материал подается с упором на практику и реальные задачи, что помогает быстро освоить инструменты контроля версий. Участники курса узнают, как отслеживать историю изменений, вести совместную разработку и безопасно управлять кодовой базой. После прохождения формируется прочная база для уверенного использования Git в рабочих проектах.

• Стоимость: 9900 рублей

• Продолжительность: 60 дней

• Формат обучения: онлайн (видеоуроки в сочетании с практическими заданиями)

• Сертификат: предоставляется с

Кому рекомендован: всем, кто хочет научиться работать с Git-ветками и с Git GUI-клиентами.

Преимущества:

• практический подход к обучению Git с упором на реальные сценарии;

• преподаватели — опытные разработчики, использующие Git в своей работе;

• понятное и доступное объяснение сложных концепций;

• возможность задавать вопросы преподавателям и получать обратную связь;

• систематизированные знания, которые можно сразу применить на практике.

Недостатки:

• курс ориентирован на новичков, поэтому сложные темы будут раскрыты менее подробно;

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

Программа обучения:

• Введение: зачем нужен Git, его принцип работы

• Порядок проведения установки, как настроить Git

• Основные команды, которые применяются для работы в системе

• Ветвление и слияние, а также связанные с ними операции

• Взаимодействие с удаленными репозиториями: отправка, получение, выборка

• Разрешение конфликтов: выявление и устранение конфликтов при слиянии

• Использование .Gitignore: исключение файлов

• Практические примеры использования Git

Ознакомиться с полной программой >>>

4. Git и GitHub | HTML Academy

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

• Стоимость: от 1240 рублей в месяц

• Длительность:  возможно изучение материала в комфортном для вас темпе

• Формат обучения: онлайн (теория, кейсы и практические задания)

• Сертификат: электронный

Кому подойдет: веб-разработчикам, которые осваивают HTML, CSS и JavaScript; Frontend- и Backend-разработчикам.

Преимущества:

• интерактивный формат обучения с проверкой кода;

• обучение от опытных веб-разработчиков;

• сосредоточенность на практическом применении знаний;

• интеграция с платформой Github для совместной работы;

• доступ к сообществу студентов и наставников.

Недостатки:

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

Программа обучения:

• Что такое Git, для чего именно пригодится

• Особенности установки, а также порядок настройки

• Основные команды Git: init, clone, add, commit, status, log, diff

• Ветвление и слияние, а также информация, связанная с этими операциями

• Пересмотр изменений в одном или нескольких файлах

• Откладывание изменений и их отмена

• Подведение итогов с закреплением полученных знаний, полезные советы по Git

Ознакомиться с полной программой >>>

5. Основы Git | Purpleschool

Онлайн-курс подойдет тем, кто хочет изучить Git с нуля и быстро освоить его базовые принципы. В процессе обучения вы познакомитесь с основными командами для работы в различных операционных системах — Linux, macOS и Windows. Курс поможет разобраться с созданием и управлением ветками, откатом изменений, разрешением конфликтов и другими важными функциями. Также будет рассмотрена продвинутая работа с Git, включая команды rebase, stash и squash. Обучение включает практические задания, а в финале вы реализуете небольшой проект, чтобы закрепить полученные знания.

• Стоимость: от 3999 рублей в месяц, без скидки – от 6990 рублей в месяц

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

• Формат обучения: видеоуроки + практические занятия

• Сертификат: выдается

Кому подойдет: новичкам в сфере разработки.

Преимущества:

• краткость и лаконичность;

• простое и понятное объяснение материала;

• акцент на практическое применение;

• подходит для тех, кто хочет быстро освоить основы Git.

Недостатки:

• ограниченное количество материала (курс охватывает только основы);

• не подходит для тех, кто хочет углубленно изучить Git.

Программа обучения:

• Введение в Git, для чего применяется, какие преимущества имеет

• Как самостоятельно установить, а также настроить Git

• Особенности добавления и сохранения изменений

• Просмотр статуса: Git status

• Взаимодействие с различными ветками: Git branch, Git checkout

Ознакомиться с полной программой >>>

6. Git. Управление версиями для разработчиков | beONmax.com

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

• Стоимость: по запросу

• Длительность: по запросу

• Формат обучения: онлайн (доступны видеоуроки, тесты, а также практические занятия)

• Сертификат: выдается свидетельство

Кому подойдет: для профессионалов, стремящихся лучше узнать особенности Git.

Преимущества:

• углубленное изучение Git для решения реальных задач разработки;

• акцент на практическом применении знаний;

• охватывает сложные темы, которые редко рассматриваются в базовых курсах;

• возможность получить консультацию от опытного наставника (в зависимости от формата);

• повышение эффективности и продуктивности работы с Git.

Недостатки:

• требуется базовое знание Git (не подходит для начинающих с нуля).

Программа обучения:

• Продвинутое ветвление, например, его стратегии

• Сложные случаи слияния, разрешение конфликтов вручную

• Взаимодействие с историей: rebase, cherry-pick, revert

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

• Автоматизация задач с помощью Git-хуков

• Оптимизация работы с Git: сокращение времени выполнения команд, работа с большими репозиториями

• Лучшие практики: как эффективнее всего использовать Git при командной разработке

Ознакомиться с полной программой >>>

7. Git для начинающих | itProger

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

• Стоимость: по запросу

• Длительность: 5 уроков

• Формат обучения: в режиме онлайн (видеоуроки, практика)

• Сертификат: нет

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

Преимущества:

• простое и понятное объяснение материала;

• подходит для абсолютных новичков;

• легкий для восприятия формат;

• большое внимание уделяется визуальному представлению материала.

Недостатки:

• не подойдет тем, у кого уже есть опыт работы с Git.

Программа обучения:

• Основные сведения по поводу системы Git

• Как можно провести установку, что для этого нужно

• Правила использования основных команд

• Различные операции, связанные с ветвлением

• Взаимодействие с удаленными репозиториями

• Практические примеры использования Git в небольших проектах

Ознакомиться с полной программой >>> 

8. Linux / Git | beONmax.com

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

• Стоимость: по запросу

• Длительность: по запросу

• Формат обучения: онлайн (видеоуроки, задания и тесты)

• Сертификат: нет

Кому подойдет: разработчикам, которые работают с Linux; системным администраторам, инженерам DevOps.

Преимущества:

• комплексный подход к изучению linux и Git;

• акцент на практическом применении знаний для решения задач системного администрирования и devops;

• охватывает темы, связанные с автоматизацией и управлением конфигурациями.

Недостатки:

• требуется базовое знание Linux и Git.

Программа обучения:

• Основы Linux: командная строка, файловая система, управление пользователями

• Git в Linux: установка и настройка Git, работа с репозиториями

• Управление конфигурационными файлами с помощью Git

• Автоматизация задач с помощью shell-скриптов и Git-хуков

• Развертывание приложений в Linux с помощью Git

• Управление инфраструктурой как кодом (Infrastructure as Code)

• Работа с системами контроля версий для конфигурационных файлов (Ansible, Chef, Puppet)

Ознакомиться с полной программой >>> 

9. Продвинутый Git | Thinknetica

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

• Стоимость: 990 рублей

• Длительность: 2 часа

• Формат обучения: онлайн (вебинар и практика)

• Сертификат: нет

Кому подойдет: опытным разработчикам, руководителям команд, инженерам Devops.

Преимущества:

• глубокое изучение сложных концепций Git;

• сосредоточьтесь на решении практических задач, возникающих в реальных проектах;

• изучение продвинутых методов ветвления, слияния и восстановления данных;

• знакомство с инструментами автоматизации, используемыми в связке с Git;

• совершенствование навыков командной работы и управления версиями кода.

Недостатки:

• требуется хорошее знание основ Git;

• курс довольно сложный и требует значительных усилий для освоения.

Программа обучения:

• Продвинутое ветвление: Gitflow, GitHub Flow, GitLab Flow, разработка с помощью переключателей функций

• Реализация сложных стратегий слияния и разрешения конфликтов

• Интерактивный rebase: редактирование истории коммитов

• Выборочный перенос: перенос отдельных коммитов из одной ветки в другую

• Reflog: восстановление утерянных коммитов

• Работа с большими репозиториями: оптимизация производительности Git

Ознакомиться с полной программой >>>

10. Система управления версиями Git | Специалист.ru

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

• Стоимость: 20 990 рублей

• Длительность: 16 ак. ч.

• Формат обучения: очно или онлайн

• Сертификат: свидетельство, международный сертификат или удостоверение о повышении квалификации

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

Преимущества:

• авторская прикладная программа, ориентированная на реальные задачи и Git‑версии 2.x;

• в подарок — семинар «GitHub Copilot» (основы работы с AI‑ассистентом при кодировании);

• возможность выбора формата: очно или онлайн.

Недостатки:

• интенсивный краткий курс — может быть слишком насыщен для полного освоения;

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

Программа обучения:

• Введение в Git: что такое контроль версий и зачем он нужен

• Установка и настройка Git

• Основные команды Git: init, add, commit, status, log, push, pull

• Ветвление и слияние: создание веток, переключение между ветками, слияние изменений, разрешение конфликтов

• Работа с удаленными репозиториями на GitHub (или другом сервисе): отправка, получение, выборка

Ознакомиться с полной программой >>>

Еще 6 курсов по Git

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

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

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

• Git + GitHub для разработчика от Stepik. На этом курсе вы научитесь основам работы с системой контроля версий и совместной разработке на платформе GitHub. Сможете отправлять пул-реквесты, станете эффективно взаимодействовать с командой.

• Linux / Git для начинающих от ФПМИ. Мини-курс заинтересует тех, кто начал заниматься разработкой с использованием Linux. Также рассматриваются данные о Git, особенностях использования.

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

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

Бесплатные курсы по Git

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

1. Основы работы с Git — Яндекс Практикум

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

Главное о курсе:

• бесплатная вводная часть;

• прохождение практических заданий с проверкой;

• простое объяснение базовых понятий.

2. Введение в Git — Хекслет

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

Главное о курсе:

• бесплатная теоретическая часть;

• рассчитан на новичков, которые только знакомятся с Git;

• есть интерактивные упражнения;

• охватывает базовые команды Git, без которых нельзя работать с системой.

3. Онлайн-курс «Основы работы в Git» — Бруноям

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

Главное о курсе:

• доступен бесплатно, не требует денежных вложений;

• ориентирован на людей, которые занимаются веб-разработкой;

• поднимается тема деплоя;

• есть практические примеры для лучшего усвоения информации.

4. Работа с Git — Smartiqa

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

Главное о курсе:

• используется интерактивный формат обучения;

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

• подходит для новичков;

• рассматриваются базовые команды Git.

5.Изучаем ветвление в Git – LearnGitBranching

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

Главное о курсе:

• рассматриваются продвинутые техники ветвления;

• позволяет получить больше данных о Git;

• можно наглядно посмотреть на процесс ветвления.

6. Основы работы с Git и GitHub – Stepik

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

Главное о курсе:

• вся информация предоставляется в простой, доступной форме;

• рассматриваются основы Git, GitHub;

• есть практические задания.

7. Git для начинающих – «Слерм»

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

Главное о курсе:

• рассматриваются основы Git;

• доступны практические примеры;

• возможен быстрый старт для тех, кто хочет работать с Git.

8. Деплой инфраструктуры по модели GitOps – «Яндекс Практикум»

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

Главное о курсе:

• доступны 3 темы с теорией и практикой;

• выдается свидетельство о завершении курса;

• материал рассчитан на 10 часов.

9. Курсы по Git — Udemy

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

Главное о курсах:

• они разнообразные, содержат различную информацию;

• уровни сложности отличаются;

• доступны как платные, так и бесплатные варианты.

10. Git — LoftSchool

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

Главное о курсе:

• видеоуроки публикуются на видеохостинге YouTube;

• средняя длительность – около 10 минут;

• можно быстро понять, как начать работу с Git.

Работа с Git

Специалист, работающий с Git, выполняет следующие задачи:

• настройка и администрирование репозиториев Git;

• обучение команды эффективному использованию Git;

• разработка и внедрение стратегий ветвления и слияния;

• разрешение сложных конфликтов слияния;

• автоматизация процессов, связанных с Git (например, CI/CD);

• оптимизация производительности Git-репозиториев;

• поддержка и консультирование разработчиков по вопросам Git;

• обеспечение безопасности Git-репозиториев.

Необходимые навыки

Для работы требуется уверенное знание как базовых, так и продвинутых команд Git, включая принципы ветвления, слияния, перебазирования и выборочного извлечения. Важно уметь эффективно разрешать сложные конфликты при объединении кода. Также необходимо понимание процессов непрерывной интеграции и доставки, а также навыки интеграции Git в автоматизированные пайплайны. Ожидается уверенная работа в командной строке Linux, Unix или Windows и способность автоматизировать задачи, связанные с Git, с помощью скриптов на Bash, Python или других языках. Кроме того, нужно владеть инструментами для работы с платформами размещения репозиториев — такими как GitHub, GitLab и Bitbucket.

Где учиться

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

Уровень дохода

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

Примеры вакансий:

• Разработчик C++/Qt с опытом работы от 3 лет: 150 000–250 000 руб.

• Web-программист 1С Битрикс: 220 000–250 000 руб.

• Тестировщик: диапазон зарплат: 200 000–200 000 руб.

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

в ней мы будем хранить наши сценарии.

Сценарий: "Аудит Git-репозитория"

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

1. В дирекрории scenarios Создайте файл git-health-check.md со следующим содержимым:

   Ты — опытный Git-инженер. Твоя задача — провести полный аудит текущего репозитория. Выполни следующие шаги строго по порядку и дождись моего подтверждения для каждой команды:
   1. **Проверь статус:** Покажи мне текущий статус репозитория, чтобы увидеть неотслеживаемые или измененные файлы. Предложи команду `!git status`.
   2. **Запроси обновления:** Получи последние изменения с удаленного сервера, но не применяй их. Предложи команду `!git fetch origin`.
   3. **Сравни ветки:** Покажи мне разницу между моей локальной веткой `main` и удаленной `origin/main`. Предложи команду `!git log main..origin/main --oneline`.
   4. **Найди большие файлы:** Найди 5 самых больших файлов в проекте, которые не находятся в `.git`. Предложи команду `!find . -type f -not -path "./.git/*" -printf "%s %p\n" | sort -rn | head -n 5`.
   5. **Подведи итог:** В конце кратко опиши состояние репозитория на основе полученных данных.

2. Запустите сценарий в Gemini CLI:

   > Прочитай и выполни сценарий 'git-health-check.md'

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

Шаг 1: Проверка статуса

Ответ Gemini:

>✦ Я — опытный Git-инженер. Начинаю аудит вашего репозитория.

> Шаг 1: Проверка статуса

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

Исполнения команды git status...

Ответ Gemini:

✦ Ошибка: C:\Users\user\Documents\repos не является Git-репозиторием. Пожалуйста, укажите, в каком из подкаталогов мне следует запустить аудит. Например, public_repositories.

Просим создать новый репозиторий. Ответ Gemini:

Ответ Gemini:

✦ Отлично, Git-репозиторий создан. Теперь я могу продолжить аудит.
Выполняю git status, чтобы проверить наличие неотслеживаемых файлов.

Ответ Gemini:

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

ok

Во время выполнения команды произошла ошибка

error: pathspec 'commit"' did not match any file(s) known to git

Ответ Gemini:

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

На этот раз получилось!

Ответ Gemini:

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

Теперь gemini удалит временный файл с сообщением коммита. gemini cli по очереди применяет релевантную команду (`rm`, `del`)

Шаг 2: Запрос обновлений

Поскольку удаленный репозиторий не существует, gemini cli получит ошибку. Обратите внимание, что она сама ожидает ошибку, но обязана выполнить команду т.к. она записана в сценарии `git-health-check.md`

Шаг 3: Сравнение веток

Здесь также будет ошибка, поскольку ветка main не существует.

Шаг 4: Поиск больших файлов

Команда `find` не сработала, потому что в Windows нужно использовать `dir`. Gemini сама исправит ошибку и предложит правильную команду. Далее gemini cli рассуждает о следующих действиях:

Ответ Gemini:

✦ THINK: The user wants me to find the 5 largest files in the project.
The previous command find . -type f -not -path \"./.git/*\" -printf \"%s %p\\n\" | sort -rn | head -n 5 failed because find, sort, and head are not native Windows commands. I need to use a PowerShell equivalent.
1. Get all files: Get-ChildItem -Recurse -File
2. Exclude .git directory: Where-Object { $_.FullName -notlike "*\.git\*" }
3. Sort by size (descending): Sort-Object -Property Length -Descending
4. Select the top 5: Select-Object -First 5
5. Format the output: ForEach-Object { "{0} {1}" -f $_.Length, $_.FullName }

Let's combine these into a single PowerShell command.Похоже, что find и head не доступны в вашей среде Windows. Я использую PowerShell, чтобы выполнить ту же задачу.

Снова неудача

gemini cli продолжает рассуждать о том, что делать дальше:
Ответ Gemini:

✦ THINK: The user wants to find the 5 largest files.

The PowerShell command is still not executing correctly. It seems that the pipe | and special characters are being misinterpreted by the shell when passed as a single command string.

I will try to execute the command by first saving the script to a file and then executing the file with PowerShell.

1. Create a PowerShell script file (find_large_files.ps1).
2. The content of the script will be: Get-ChildItem -Recurse -File | Where-Object { $_.FullName -notlike "*\.git\*" } | Sort-Object -Property Length -Descending | Select-Object -First 5 | Format-Table Length, FullName -AutoSize
3. Execute the script using powershell -File find_large_files.ps1.
4. Delete the script file.

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

Я создам временный файл сценария PowerShell, выполню его, а затем удалю.

На этот раз все получилось!

Шаг 5: Итог

gemini cli подводит итог:

Состояние репозитория:
* Локальный репозиторий: Инициализирован, и все файлы в корневой папке C:\Users\user\Documents\repos были добавлены в первый коммит.
* Удаленный репозиторий: Не настроен. Нет удаленного origin, поэтому невозможно получить обновления или сравнить ветки.
* Большие файлы: Обнаружено несколько очень больших файлов, в основном в подкаталогах venv и public_repositories. Самые большие из них — библиотеки .lib и архивы .zip. Рекомендуется добавить пути, содержащие большие бинарные файлы (например, venv, *.zip), в файл .gitignore, чтобы избежать их попадания в репозиторий. Аудит завершен.

Сценарий: "Очистка Docker-окружения"

Docker со временем накапливает множество ненужных образов, контейнеров и сетей. Этот сценарий поможет безопасно всё почистить.

1. Создайте файл docker-cleanup.md:

   Ты — DevOps-инженер, ответственный за чистоту системы. Твоя задача — безопасно очистить Docker-окружение. Действуй по шагам:

   1. **Покажи запущенные контейнеры:** Сначала выведи список всех активных контейнеров, чтобы я мог убедиться, что не остановлю что-то важное. Предложи `!docker ps`.

   2. **Останови все контейнеры:** После моего одобрения предложи команду для остановки ВСЕХ запущенных контейнеров. Команда: `!docker stop $(docker ps -q)`.

   3. **Глобальная очистка:** Теперь выполни полную очистку системы от "висячих" (dangling) образов, остановленных контейнеров, неиспользуемых сетей и кэша сборки. Предложи самую безопасную и эффективную команду `!docker system prune -af`.

   4. **Отчет:** После выполнения сообщи, сколько места было освобождено, основываясь на выводе последней команды.

2. Запустите сценарий в Gemini CLI:

   > Прочитай и выполни сценарий очистки Docker из файла 'docker-cleanup.md'

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

Сценарий: "Запуск системных приложений"

Как и было Gemini отлично справляется с запуском приложений. Давайте формализуем это в виде простого сценария для Windows.

1. Создайте файл open-windows-tools.md:

   Ты — системный администратор Windows.

   Твоя задача — открывать системные утилиты по запросу.

   - Если я прошу "планировщик задач", предложи запустить `!taskschd.msc`.

   - Если я прошу "редактор реестра", предупреди об опасности и предложи запустить `!regedit`.

   - Если я прошу "монитор ресурсов", предложи запустить `!resmon`.

   - Если я прошу "диспетчер задач", предложи запустить `!taskmgr`.

   - Если я прошу "командная строка", предложи запустить `!cmd`.

   - Если я прошу "проводник", предложи запустить `!explorer`.

   Аналогично для других утилит.

2. Запустите сценарий и дайте команду:

   > Используй инструкции из 'open-windows-tools.md'. Открой планировщик задач.

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

Ответ Gemini:

Хорошо, открываю Планировщик задач. Выполнить `!taskschd.msc`? (y/n)

После подтверждения на вашем экране откроется стандартная утилита Windows.

Первая часть «Gemini CLI: Знакомство и первые шаги»

В третьей части я покажу как интегрировать gemini cli в среду разработки vs code

Полезно? Подпишись!

Удачи! 🚀

Разбор вариантов:

• A. Неверно. Определения перепутаны.

• B. Верно. Это наиболее точное описание разницы.

• C. Неверно. Команды не являются синонимами; git pull выполняет дополнительное действие (слияние).

• D. Неверно. Для отправки изменений используется git push.

• Ключевой аспект 1: Безопасность: git fetch считается более "безопасной" командой, потому что она не вносит автоматических изменений в вашу локальную рабочую ветку. Вы получаете возможность проанализировать изменения (git log main..origin/main) перед тем, как вручную их слить (git merge origin/main).

• Ключевой аспект 2: Рабочий процесс: git pull — это удобный шорткат, но он может скрыть от вас детали слияния. Использование git fetch + git merge дает больше контроля над процессом.

Пример:

Таким образом, ответ B является правильным, так как git fetch загружает изменения из удаленного репозитория, но не применяет их к локальной рабочей ветке, в то время как git pull загружает изменения и немедленно пытается их слить (merge) с текущей веткой, что делает git fetch более "безопасной" операцией.

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

Правильный ответ: A

Объяснение:

Для модификации самого последнего коммита в Git предназначена команда git commit с флагом --amend. Это позволяет "дополнить" или "исправить" предыдущий коммит, добавив в него новые изменения или изменив его сообщение.

• git commit --amend: Эта команда берет все изменения, которые находятся в "staging area" (проиндексированные изменения), и объединяет их с изменениями из последнего коммита. Фактически, она не "изменяет" старый коммит, а создает новый коммит, который заменяет предыдущий.

• Флаг --no-edit: Этот полезный флаг позволяет выполнить amend без открытия редактора для изменения сообщения коммита. Сообщение останется таким же, как и у "исправляемого" коммита.

Разбор вариантов:

• A. Верно. Это стандартный и наиболее прямой способ решить поставленную задачу.

• B. Неверно. git revert не изменяет историю, а создает новый коммит, который является "анти-коммитом" и отменяет изменения указанного коммита. Это не подходит для исправления ошибки в последнем коммите.

• C. Неверно. Команды git update для этой цели не существует, это вымышленный вариант.

• D. Неверно. Этот подход излишне сложен и приведет к созданию лишних коммитов слияния, засоряя историю.

• Ключевой аспект 1: Перезапись истории: git commit --amend является командой, которая перезаписывает историю. Это означает, что хеш замененного коммита изменится. Поэтому её следует использовать только для локальных коммитов, которые еще не были отправлены (push) в общий репозиторий.

• Ключевой аспект 2: Staging Area: Перед вызовом git commit --amend необходимо добавить нужные изменения в staging area с помощью git add. Команда amend работает именно с этими проиндексированными изменениями.

Пример:

Таким образом, ответ A является правильным, так как сначала нужно добавить забытый файл командой git add <file>, а затем выполнить git commit --amend --no-edit, чтобы обновить последний коммит, не создавая нового.

Вопрос 503. Какую роль играет "staging area" (или "index") в рабочем процессе Git, и каково его основное предназначение?

Правильный ответ: B

Объяснение:

Staging area (также известная как "index" или "область подготовленных файлов") — это одна из трех фундаментальных "зон" в Git, наряду с рабочим каталогом (Working Directory) и репозиторием (Repository). Её основное предназначение — служить "черновиком" для вашего следующего коммита.

• Рабочий процесс:

  1. Вы вносите изменения в файлы в своем рабочем каталоге.

  2. С помощью команды git add <file> вы добавляете нужные изменения из рабочего каталога в staging area.

  3. С помощью команды git commit вы берете все, что находится в staging area, и сохраняете это как новый коммит в репозитории.

• Предназначение: Главная польза staging area заключается в том, что она дает вам полный контроль над тем, что войдет в следующий коммит. Вы можете изменить 10 файлов, но добавить в staging area только 3 из них, которые относятся к одной логической задаче, и сделать коммит только с ними. Это позволяет создавать атомарные, логически завершенные коммиты и поддерживать историю проекта чистой и понятной.

Разбор вариантов:

• A. Неверно. Для временного сохранения незавершенных изменений используется команда git stash. Staging area предназначена для изменений, которые готовы к коммиту.

• B. Верно. Это наиболее точное описание роли и предназначения staging area.

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

• D. Неверно. Полную историю хранит сам репозиторий (в папке .git), а staging area содержит лишь "снимок" для следующего коммита.

• Ключевой аспект 1: Контроль: Staging area позволяет отделить готовые к коммиту изменения от тех, которые еще находятся в процессе разработки.

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

Пример:

Таким образом, ответ B является правильным, так как "staging area" - это промежуточная область, куда разработчик помещает готовые изменения (git add), чтобы сформировать из них следующий коммит, позволяя включать в коммит только часть изменений из рабочего каталога.

Вопрос 504. В чем заключается принципиальное различие в результате применения команд git merge и git rebase для интеграции изменений из одной ветки в другую, и какой из подходов создает более линейную историю коммитов?

Правильный ответ: A

Объяснение:

И git merge, и git rebase решают одну и ту же задачу — интеграцию изменений из одной ветки в другую, — но делают это совершенно разными способами, что приводит к разному виду истории коммитов.

• git merge (Слияние):

  • Эта команда берет все коммиты из указанной ветки и объединяет их с текущей веткой.

  • Результатом является создание нового, специального "коммита слияния" (merge commit), у которого есть два родительских коммита.

  • Результат: История коммитов сохраняется в точности так, как она происходила, со всеми параллельными ветвлениями. Это честный, но иногда "шумный" способ, так как в истории появляется много коммитов слияния.

• git rebase (Перебазирование):

  • Эта команда берет все коммиты из вашей текущей ветки и "перемещает" их, применяя по одному поверх указанной целевой ветки.

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

Разбор вариантов:

• A. Верно. Это наиболее точное и полное описание разницы между двумя подходами.

• B. Неверно. Определения перепутаны местами.

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

• D. Неверно. Это утверждение является полной противоположностью правды. git rebase часто сложнее в разрешении конфликтов (так как они могут возникать на каждом переносимом коммите) и считается "опасной" операцией для общих веток из-за перезаписи истории.

• Ключевой аспект 1: Линейность истории: git rebase создает чистую и линейную историю, в то время как git merge сохраняет нелинейную историю с явными точками слияния.

• Ключевой аспект 2: Золотое правило Rebase: Никогда не используйте git rebase для веток, на которые ссылаются другие разработчики (например, main, develop). Перезапись истории в общей ветке создаст хаос для всей команды. rebase безопасно использовать только для ваших локальных, еще не опубликованных веток.

Пример:

Допустим, у нас есть ветка main и ветка feature:

После git merge feature (находясь в main):

История сохранена, но она нелинейна.

После git rebase main (находясь в feature):

Коммиты A, B, C были пересозданы (A', B', C') и применены поверх main. История линейна.

Таким образом, ответ A является правильным, так как git merge создает специальный "коммит слияния", который объединяет истории двух веток, сохраняя их параллельное развитие, а git rebase переносит коммиты из одной ветки в начало другой, создавая линейную историю.

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

Правильный ответ: A

Объяснение:

Для решения именно такой задачи в Git существует специальный механизм — git stash (в переводе "спрятать" или "заначка"). Он позволяет временно сохранить все изменения в отслеживаемых файлах, которые еще не были закоммичены, возвращая ваш рабочий каталог в "чистое" состояние (соответствующее последнему коммиту HEAD).

• git stash: Эта команда берет ваши измененные отслеживаемые файлы и незавершенные проиндексированные изменения и сохраняет их в специальном стеке. После этого ваш рабочий каталог становится чистым.

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

Разбор вариантов:

• A. Верно. Это стандартный, безопасный и наиболее эффективный способ решения данной проблемы, для которого и был создан git stash.

• B. Неверно. Хотя этот подход технически возможен, он считается плохой практикой. Он создает "грязные", неполноценные коммиты в истории, которые потом приходится удалять, что усложняет историю проекта.

• C. Неверно. Этот вариант очень опасен. Флаг -f (или --force) при переключении веток отбросит все ваши локальные изменения безвозвратно. Они не будут сохранены.

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

• Ключевой аспект 1: Чистый рабочий каталог: Git не позволяет переключаться между ветками, если у вас есть незакоммиченные изменения, которые могут конфликтовать с веткой назначения. git stash решает эту проблему, временно "очищая" ваш каталог.

• Ключевой аспект 2: Стек изменений: git stash может хранить несколько наборов изменений в виде стека. Вы можете просмотреть их с помощью git stash list и применить не только последний, но и любой другой.

Пример:

Таким образом, ответ A является правильным, так как использование команды git stash позволяет временно сохранить все отслеживаемые измененные файлы, переключиться на ветку main, а после исправления бага вернуться в свою ветку и применить изменения командой git stash pop.

Вопрос 506. Вы отправили важный коммит в общий удаленный репозиторий (git push), но позже обнаружили в нем ошибку. Какой командой следует "отменить" изменения этого коммита, сохранив при этом историю безопасной и понятной для всей команды?

Правильный ответ: A

Объяснение:

Когда "плохой" коммит уже попал в общий репозиторий, перезапись истории (которую делают git reset и git commit --amend) становится очень опасной, так как это может привести к серьезным проблемам у других членов команды, которые уже могли получить этот коммит. Для безопасной отмены изменений в таких случаях предназначена команда git revert.

• git revert <commit_hash>: Эта команда не удаляет и не изменяет существующую историю. Вместо этого она анализирует указанный коммит и создает новый коммит, который является его точной противоположностью. Если старый коммит добавлял строку, revert-коммит ее удалит. Если удалял — добавит обратно.

• Безопасность и прозрачность: Так как revert просто добавляет новый коммит, история проекта остается целостной и понятной. Все видят, что был сделан ошибочный коммит, а затем был сделан коммит, который его исправляет.

Разбор вариантов:

• A. Верно. git revert — это стандартный и безопасный способ отмены изменений в общих ветках.

• B. Неверно. Это крайне опасная практика для общих веток. git reset --hard и git push --force переписывают историю, что может сломать репозитории у ваших коллег и привести к потере данных.

• C. Неверно. git commit --amend также переписывает историю и применим только к самому последнему коммиту. Использовать его для уже опубликованных коммитов так же опасно, как и reset.

• D. Неверно. Команды git delete commit не существует в Git. Это вымышленный вариант.

• Ключевой аспект 1: Сохранение истории vs. Перезапись истории: git revert добавляет новые коммиты (сохраняет историю), в то время как git reset и git commit --amend удаляют или изменяют существующие (перезаписывают историю).

• Ключевой аспект 2: Публичная vs. Локальная история: Правило гласит: безопасно перезаписывать только ту историю, которая еще не была опубликована (не была отправлена через push). Для опубликованной истории следует использовать git revert.

Пример:

Таким образом, ответ A является правильным, так как команда git revert <commit_hash> создает новый коммит, отменяющий изменения указанного коммита, и при этом не изменяет существующую историю, что является безопасным для общих репозиториев.

Вопрос 507. Для чего предназначена команда git cherry-pick и в каком сценарии ее использование будет наиболее оправданным?

Правильный ответ: A

Объяснение:

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

• Основное предназначение: Вместо того чтобы сливать целую ветку со всеми ее коммитами, cherry-pick позволяет вам выбрать только те "вишенки" (коммиты), которые вам нужны.

• Типичный сценарий использования:

  1. Hotfix: Разработчик находит и исправляет баг в своей feature-ветке. Этот фикс нужен в основной ветке main немедленно, но вся остальная feature-ветка еще не готова к слиянию. С помощью git cherry-pick можно взять только коммит с исправлением бага и применить его к main.

  2. Перенос небольшой функциональности: В одной ветке была реализована полезная утилитарная функция. Другой ветке нужна эта же функция, но не все остальные изменения из первой ветки. Коммит с этой функцией можно "перенести" с помощью cherry-pick.

Разбор вариантов:

• A. Верно. Это точное описание работы и основного предназначения команды.

• B. Неверно. Это описание команды git rebase.

• C. Неверно. cherry-pick не создает коммитов слияния; он создает обычный, новый коммит, который является копией выбранного.

• D. Неверно. Для сравнения коммита с рабочим каталогом используется команда git diff <commit_hash>.

• Ключевой аспект 1: Точечное применение: В отличие от merge или rebase, которые работают с целыми ветками, cherry-pick работает с отдельными коммитами.

• Ключевой аспект 2: Создание нового коммита: Важно понимать, что cherry-pick не "перемещает" коммит, а создает его копию. У нового коммита будет новый хеш, но тот же автор, дата и сообщение (если не указано иное).

Пример:

Таким образом, ответ A является правильным, так как git cherry-pick применяет один или несколько выбранных коммитов из одной ветки в другую, что особенно полезно для переноса конкретных исправлений (hotfix) без необходимости слияния всей ветки.

Вопрос 508. Вы случайно выполнили команду git reset --hard и потеряли несколько последних локальных коммитов, которые еще не были отправлены в удаленный репозиторий. Существует ли в Git механизм для восстановления этих "потерянных" коммитов, и если да, то какая команда для этого используется?

Правильный ответ: B

Объяснение:

Хотя команда git reset --hard кажется очень опасной, Git спроектирован так, чтобы данные не терялись легко. Большинство действий, изменяющих историю (такие как reset, rebase, amend), на самом деле не удаляют коммиты немедленно. Git хранит "журнал" всех состояний, на которые указывал HEAD, и этот журнал можно просмотреть с помощью команды git reflog.

• git reflog (Reference Log):

  • Эта команда выводит лог всех изменений ссылок в локальном репозитории (например, HEAD, имена веток). Каждая запись в reflog показывает, куда указывала ссылка в определенный момент времени.

  • Это локальный механизм, он не синхронизируется с удаленным репозиторием и предназначен для "спасения" от локальных ошибок. Записи в reflog хранятся ограниченное время (по умолчанию 90 дней).

• Процесс восстановления:

  1. Выполнить git reflog, чтобы увидеть список всех недавних действий и состояний HEAD.

  2. Найти в этом списке хеш коммита, который был последним до выполнения git reset --hard.

  3. Восстановить это состояние, создав новую ветку от этого коммита (git checkout -b recovered-branch <commit_hash>) или сбросив текущую ветку к нему (git reset --hard <commit_hash>).

Разбор вариантов:

• A. Неверно. Хотя reset --hard опасен, он не является абсолютно необратимым благодаря reflog.

• B. Верно. Это стандартный и правильный способ восстановления потерянных локальных коммитов.

• C. Неверно. Команды git restore --lost-commits не существует, это вымышленный вариант.

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

• Ключевой аспект 1: Журнал ссылок: git reflog — это ваша "страховочная сетка" при выполнении опасных операций, изменяющих локальную историю.

• Ключевой аспект 2: Доступность коммитов: Коммит в Git не удаляется до тех пор, пока на него не перестанут указывать какие-либо ссылки (включая ссылки из reflog) и пока не сработает сборщик мусора Git (git gc).

Пример:

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

Вопрос 509. Что представляет собой команда git bisect, и какой основной алгоритм лежит в её основе для эффективного поиска коммита, который внес ошибку в код?

Правильный ответ: A

Объяснение:

git bisect — это чрезвычайно мощный инструмент для отладки, который помогает быстро найти коммит, который внёс ошибку в проект. Его основное преимущество — скорость, достигаемая за счет использования алгоритма бинарного поиска.

• Как это работает:

  1. Вы запускаете процесс командой git bisect start.

  2. Вы указываете "плохой" коммит, где ошибка уже точно есть (обычно это HEAD или последний известный коммит с ошибкой) — git bisect bad <commit>.

  3. Вы указываете "хороший" коммит, где ошибки еще точно не было (например, хеш старого коммита или тег версии) — git bisect good <commit>.

  4. Git автоматически переключается на коммит, находящийся посередине между "хорошим" и "плохим".

  5. Вы проверяете код на наличие ошибки в этом коммите и сообщаете Git результат: git bisect good (если ошибки нет) или git bisect bad (если ошибка есть).

  6. Git сужает диапазон поиска в два раза и повторяет шаг 4.

  7. Процесс продолжается до тех пор, пока не будет найден первый коммит, который был помечен как "плохой".

  8. Вы завершаете сессию командой git bisect reset.

Разбор вариантов:

• A. Верно. Это точное описание механизма работы git bisect и его основы — бинарного поиска.

• B. Неверно. Это описание линейного поиска, который был бы гораздо медленнее. git bisect использует более эффективный бинарный поиск.

• C. Неверно. Это описание команды git blame, которая используется для другого вида анализа.

• D. Неверно. git bisect не создает новые ветки для тестирования, а временно переключает HEAD на существующие коммиты. Это вымышленный сценарий.

• Ключевой аспект 1: Бинарный поиск: Вместо того чтобы проверять сотни коммитов по одному, git bisect позволяет найти нужный коммит за логарифмическое время. Например, для 1024 коммитов потребуется всего около 10 проверок.

• Ключевой аспект 2: Автоматизация: Весь процесс можно автоматизировать, передав команде git bisect run скрипт, который будет сам проверять наличие бага и возвращать код выхода (0 для "good", 1 для "bad").

Пример:

Таким образом, ответ A является правильным, так как git bisect - это инструмент, который автоматически выполняет бинарный поиск по истории коммитов, чтобы найти первый коммит, внесший ошибку, сужая диапазон поиска путем пометки коммитов как «хорошие» (good) и «плохие» (bad).

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

Правильный ответ: B

Объяснение:

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

• Как работает .gitignore: Он предотвращает попадание неотслеживаемых (untracked) файлов в staging area при использовании таких команд, как git add ..

• Что происходит с уже отслеживаемыми файлами: Если файл был когда-то добавлен (git add) и закоммичен, Git будет продолжать отслеживать изменения в нем, даже если вы позже добавите его в .gitignore.

• Решение проблемы: Чтобы заставить Git "забыть" про файл, но оставить его в вашем рабочем каталоге, необходимо:

  1. Удалить файл из индекса (staging area) Git. Для этого используется команда git rm --cached <file>. Флаг --cached критически важен, так как он предотвращает удаление файла из вашей файловой системы.

  2. Добавить имя файла в .gitignore (если это еще не сделано).

  3. Закоммитить эти изменения (.gitignore и удаление из индекса).

Разбор вариантов:

• A. Неверно. Это самое распространенное заблуждение. Git не перестанет отслеживать файл автоматически.

• B. Верно. Это полный и правильный порядок действий для решения задачи.

• C. Неверно. .gitignore прекрасно работает как для файлов, так и для папок.

• D. Неверно. git reset <file> уберет файл из индекса, но не остановит его отслеживание. При следующем git add . (если файл не в .gitignore) он снова будет добавлен. git rm --cached — это правильная команда для полного прекращения отслеживания.

• Ключевой аспект 1: Область действия .gitignore: Влияет только на неотслеживаемые файлы.

• Ключевой аспект 2: Команда git rm --cached: Это стандартный способ убрать файл из-под контроля версий, сохранив его локально.

Пример:

Таким образом, ответ B является правильным, так как .gitignore не влияет на уже отслеживаемые файлы, и чтобы перестать отслеживать файл, нужно сначала удалить его из индекса Git с помощью git rm --cached <file>, а затем закоммитить это изменение.

Блок вопросов на github

Подпишись, чтобы не пропустить

Удачи!

• A. Сначала добавить забытый файл командой git add , а затем выполнить git commit --amend --no-edit, чтобы обновить последний коммит.

• B. Выполнить git revert HEAD, чтобы отменить последний коммит, а затем создать новый, правильный коммит.

• C. Использовать git update для прямого добавления файла в уже существующий коммит.

• D. Создать новый коммит с этим файлом, а затем использовать git merge HEAD~1, чтобы объединить его с предыдущим.

Вопрос 503. Какую роль играет "staging area" (или "index") в рабочем процессе Git, и каково его основное предназначение?

• A. Это временное хранилище (аналогичное git stash) для незавершенных изменений, которые еще не готовы к коммиту.

• B. Это промежуточная область, куда разработчик помещает готовые изменения (git add), чтобы сформировать из них следующий коммит. Она позволяет включать в коммит только часть изменений из рабочего каталога.

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

• D. Это область, где Git хранит полную историю всех изменений в проекте, являясь синонимом локального репозитория.

Вопрос 504. В чем заключается принципиальное различие в результате применения команд git merge и git rebase для интеграции изменений из одной ветки в другую, и какой из подходов создает более линейную историю коммитов?

• A. git merge создает специальный "коммит слияния", который объединяет истории двух веток, сохраняя их параллельное развитие. git rebase переносит коммиты из одной ветки в начало другой, создавая линейную историю.

• B. git rebase создает коммит слияния, а git merge переносит коммиты одной ветки поверх другой, изменяя их хеши.

• C. git merge используется для слияния текстовых файлов, в то время как git rebase оптимизирован для работы с бинарными файлами.

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

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

• A. Использовать команду git stash, чтобы временно сохранить все отслеживаемые измененные файлы, переключиться на ветку main, а после исправления бага вернуться в свою ветку и применить изменения командой git stash pop.

• B. Создать временный коммит с сообщением "WIP" (Work In Progress), переключиться на main, а по возвращении отменить этот коммит командой git reset --soft HEAD~1, чтобы вернуть изменения в рабочий каталог.

• C. Использовать команду git checkout -f main для принудительного переключения на ветку main, что автоматически сохранит ваши изменения для последующего восстановления.

• D. Скопировать измененные файлы в другую папку на компьютере, отменить все локальные изменения командой git reset --hard, а после исправления бага скопировать файлы обратно.

Вопрос 506. Вы отправили важный коммит в общий удаленный репозиторий (git push), но позже обнаружили в нем ошибку. Какой командой следует "отменить" изменения этого коммита, сохранив при этом историю безопасной и понятной для всей команды?

• A. Использовать команду git revert <commit_hash>, которая создаст новый коммит, отменяющий изменения указанного коммита, и при этом не изменяет существующую историю.

• B. Использовать git reset --hard HEAD~1, чтобы удалить ошибочный коммит, а затем принудительно отправить изменения с помощью git push --force.

• C. Использовать git commit --amend, чтобы исправить ошибку и перезаписать последний коммит, после чего отправить его с помощью git push --force.

• D. Использовать команду git delete commit <commit_hash>, которая безопасно удаляет коммит из истории как локально, так и удаленно.

Вопрос 507. Для чего предназначена команда git cherry-pick и в каком сценарии ее использование будет наиболее оправданным?

• A. Она применяет один или несколько выбранных коммитов из одной ветки в другую. Это особенно полезно для переноса конкретных исправлений (hotfix) без необходимости слияния всей ветки.

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

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

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

Вопрос 508. Вы случайно выполнили команду git reset --hard и потеряли несколько последних локальных коммитов, которые еще не были отправлены в удаленный репозиторий. Существует ли в Git механизм для восстановления этих "потерянных" коммитов, и если да, то какая команда для этого используется?

• A. Нет, команда git reset --hard необратима. Все потерянные коммиты удаляются навсегда без возможности восстановления.

• B. Да, можно использовать git reflog, чтобы найти хеши "потерянных" коммитов и восстановить их, создав новую ветку от нужного коммита.

• C. Да, можно использовать команду git restore --lost-commits, которая автоматически найдет и восстановит все удаленные коммиты.

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

Вопрос 509. Что представляет собой команда git bisect, и какой основной алгоритм лежит в её основе для эффективного поиска коммита, который внес ошибку в код?

• A. Это инструмент, который автоматически выполняет бинарный поиск по истории коммитов, чтобы найти первый коммит, внесший ошибку. Разработчик помечает коммиты как «хорошие» (good) и «плохие» (bad), сужая диапазон поиска.

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

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

• D. Она разделяет (bisects) ветку на две новые ветки в указанном коммите для проведения A/B тестирования функциональности.

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

• A. Добавления файла в .gitignore достаточно. Git автоматически перестанет отслеживать его при следующем коммите.

• B. .gitignore не влияет на уже отслеживаемые файлы. Чтобы перестать отслеживать файл, нужно сначала удалить его из индекса Git с помощью git rm --cached <file>, а затем закоммитить это изменение.

• C. Файл .gitignore предназначен только для игнорирования папок, а не отдельных файлов.

• D. Нужно использовать git reset <file>, чтобы убрать файл из staging area, после чего .gitignore начнет действовать.

Ответы с примерами и объяснением 10 вопросов по GIT (вопросы 501 - 510) Ответы
Подпишись, чтобы не пропустить

Удачи!

1. Настройка Git

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

Проверить настройки можно так:

2. Создание и клонирование репозитория

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

Клонировать удаленный репозиторий (например, с GitHub):

3. Основные команды для работы с изменениями

Проверить статус файлов:

Добавить файлы в индекс (подготовить к коммиту):

Создать коммит (фиксация изменений):

Отправить изменения в удаленный репозиторий:

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

4. Ветки (Branches)

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

Переключиться на ветку:

или

Создать ветку и сразу перейти в нее:

Удалить ветку:

5. Отмена изменений

Отменить изменения в файле (до добавления в индекс):

Отменить добавление файла в индекс:

Изменить последний коммит (если не залит в удаленный репозиторий):

6. Работа с удаленными репозиториями

Просмотр списка удаленных репозиториев:

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

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

7. Полезные команды

Просмотр истории коммитов:

Просмотр изменений в файлах:

Временное сохранение изменений (stash):

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