Git: что это, где применяется и как освоить

Главное, что стоит понять сразу: Git и GitHub — разные вещи. Git работает на вашем компьютере и не требует интернета: история хранится в скрытой папке .git внутри проекта. GitHub, GitLab, GitVerse и похожие сервисы — площадки, куда эту историю отправляют, чтобы работать вместе, обсуждать правки и запускать проверки. Поэтому учиться удобнее в таком порядке: сначала локальная история, потом общий репозиторий.

Чем Git отличается от облачного диска

Облачный диск тоже хранит версии, но он запоминает файлы целиком и по времени сохранения. Git запоминает осмысленные шаги: вы сами решаете, какие изменения войдут в коммит и как его назвать. Через месяц по истории видно не «версия от 14:32», а «исправил расчёт выручки без учёта возвратов». Команда git diff показывает построчно, что именно поменялось, а git blame — кто и в каком коммите написал каждую строку.

Второе отличие — ветки. На облачном диске двое, правящие один файл, плодят копии «отчёт_финал_2». В Git каждый работает в своей ветке, а при слиянии правки в разных местах файла объединяются автоматически. Если двое изменили одну строку, Git останавливается и просит выбрать вариант. Это и есть конфликт — не авария, а вопрос к человеку.

Граница применимости: Git хорошо работает с текстом и плохо — с бинарными файлами. Для макета Figma, документа Word или PSD он не покажет разницу между версиями, а сохранит копию целиком, и репозиторий быстро разрастётся. Дизайнеру, который рисует только в графическом редакторе, Git почти ничего не даст, а верстальщику, переводящему макет в HTML и CSS, — очень много.

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

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

Технический писатель всё чаще работает по схеме docs as code: документация пишется в Markdown, лежит в том же репозитории, что и продукт, и проходит ревью вместе с кодом. Студенту Git нужен для командных проектов, где преподаватель видит вклад каждого участника по коммитам, а не по словам в отчёте.

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

Условная ситуация. Технический писатель ведёт руководство пользователя к внутреннему сервису. Документация лежит в GitLab в папке docs, главная ветка защищена: изменения попадают в неё только после проверки. В сервисе появился экспорт в CSV, и писателю нужно описать новую кнопку. Шаги идут в таком порядке, чтобы главная ветка до проверки оставалась нетронутой, а ревьюер видел одно завершённое изменение.

1. Писатель обновляет локальную копию командой git pull, чтобы начать с актуального состояния.
2. Создаёт ветку командой git switch -c docs/export-csv — название подсказывает коллегам, о чём правка.
3. Дописывает раздел в файле docs/export.md, проверяет изменения через git diff и фиксирует их: git add docs/export.md, затем git commit -m "Описать экспорт в CSV".
4. Отправляет ветку командой git push -u origin docs/export-csv и открывает в GitLab запрос на слияние.
5. Разработчик замечает, что кнопка называется «Выгрузить», а не «Экспорт». Писатель исправляет текст и отправляет второй коммит в ту же ветку — запрос обновится сам.
6. Пока шло ревью, коллега поменял оглавление в том же файле, и GitLab сообщает о конфликте. Писатель подтягивает главную ветку, находит спорный фрагмент между маркерами Git, оставляет обе правки, удаляет маркеры и фиксирует результат.

После слияния в истории остаётся запись, кто и зачем изменил раздел, а обсуждение привязано к запросу. Через полгода вопрос «почему кнопка описана так» решается за минуту.

Master или main: что изменится в Git 3.0

Старые учебники и статьи пишут git push origin master, а площадки при создании репозитория называют главную ветку main. Новичок, скопировавший команду, получает ошибку «src refspec master does not match any» и не понимает, что сделал не так. Путаница связана с тем, что сам Git до сих пор создаёт ветку master: в документации к git init сказано, что имя по умолчанию сейчас master и сменится на main с выходом Git 3.0.

Список несовместимых изменений будущей версии проект ведёт открыто в документе BreakingChanges. Кроме смены имени ветки, там записано, что новые репозитории по умолчанию будут использовать хеш-функцию SHA-256 вместо SHA-1: NIST признал SHA-1 устаревшей ещё в 2011 году, а на практике для неё уже находили коллизии. Условие перехода — готовность экосистемы: библиотек, приложений и площадок. Даты выхода Git 3.0 пока нет; последняя версия на конец сентября 2026 года — 2.56.0 от 28 сентября.

Отсюда три практических вывода. Первое: не угадывайте имя ветки, а проверяйте его командой git branch и один раз задайте правило командой git config —global init.defaultBranch main. Второе: идентификатор коммита при SHA-256 длиннее — 64 шестнадцатеричных символа вместо 40, поэтому шаблоны и скрипты, которые рассчитывают на 40 знаков, придётся поправить. Третье: документация к git init прямо предупреждает, что сейчас репозитории на SHA-1 и SHA-256 между собой несовместимы. Создавать учебный репозиторий с флагом —object-format=sha256 ради эксперимента можно, но для общего проекта сначала убедитесь, что его поддерживают площадка и ваш редактор.

В каком порядке осваивать Git

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

1. Локальная история: git init, git status, git add, git commit, git log и git diff на папке с обычными текстовыми заметками.
2. Отмена изменений: git restore для файла, git commit —amend для последнего коммита, git revert для уже отправленного.
3. Ветки и слияние: создать две ветки, изменить в них одну строку и самостоятельно разрешить конфликт.
4. Удалённый репозиторий: git clone, git push, git pull, запрос на слияние на GitHub, GitLab или GitVerse.
5. Работа в команде: ревью, правила названия веток, файл .gitignore, чтобы в историю не попадали пароли и временные файлы.

Терминал на этом этапе полезнее кнопок в редакторе: сообщения Git подсказывают, что происходит, а графический интерфейс их прячет. Начать можно с бесплатного онлайн-курса «Основы Git» от Хекслета: в нём 15 уроков, 13 упражнений в тренажёре и четыре испытания, где нужно самому выбраться из типичной ситуации. Всё выполняется в браузере, устанавливать Git не нужно.

Упражнения и частые ошибки

Хорошая тренировка — вести в Git то, что вы и так пишете: конспект, список SQL-запросов, резюме в Markdown. Раз в день делайте коммит с понятным сообщением, раз в неделю читайте git log и проверяйте, можно ли по истории восстановить ход работы. Для конфликтов заведите два клона одного репозитория в разных папках и изобразите двух авторов, правящих одну строку.

Типичные ошибки новичков: коммитить всё подряд командой git add ., включая пароли и выгрузки на сотни мегабайт; писать сообщения вроде «правки», по которым историю не прочитать; работать прямо в главной ветке; исправлять отправленную историю через git push —force и стирать коммиты коллег. И помните: пароль, попавший в коммит, остаётся в истории, даже если удалить его из файла.

Тем, кому нужен разбор с проверкой, подойдёт онлайн-курс «Обучение Git» от Skillbox: программа идёт от локального репозитория через ветки и конфликты к запросам на слияние, ревью, rebase, cherry-pick и stash, а работы проверяет куратор-разработчик. По описанию он рассчитан в том числе на тестировщиков, аналитиков и технических писателей и включает три проекта для портфолио.

Как понять, что навык освоен

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

Как Git влияет на доход

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

Хорошо это видно на верстальщиках. По исследованию Хабр Карьеры за первое полугодие 2026 года (45 226 зарплат из калькулятора сервиса, то есть данные самих специалистов, а не вакансий) медианная зарплата в IT по России составила 191 000 ₽, а средняя у HTML-верстальщиков — 80 000 ₽. Разрыв объясняется набором задач, а не одним Git: для перехода от вёрстки к фронтенд-разработке нужны JavaScript, фреймворк и опыт командной работы, а последнего без Git не получить. Цифры для своего города смотрите в калькуляторе Хабр Карьеры с фильтром по специализации и квалификации.

Что дальше и как выбрать обучение

Следующий шаг после уверенной работы с ветками — автоматические проверки, которые запускаются при каждом коммите. Тестировщику они нужны, чтобы автотесты шли без его участия, техническому писателю — чтобы площадка сама проверяла ссылки и собирала сайт документации. Эту тему разбирают на онлайн-курсе «GitLab CI/CD с нуля» от Merion Academy: 13 блоков от Git и ветвления до конвейеров, тестирования, анализа безопасности и релизов, лабораторные работы и итоговый проект. Курс рассчитан на тех, кто уже знаком с Git, поэтому начинать с него не стоит.

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

Если Git для вас — первый шаг к DevOps-практикам, о которых есть отдельная статья на сайте, сравнить школы поможет рейтинг онлайн-школ по DevOps и инфраструктуре. Это широкий рейтинг по направлению, где Git служит основой для остальных инструментов.