Как начать работать с Git: пошаговая инструкция для новичков с нуля

Чтобы начать, понадобятся: любой компьютер (Windows, macOS или Linux), интернет и терминал. Специальные знания не нужны.

После этой инструкции вы создадите репозиторий, сделаете первый коммит и отправите код на GitHub.

Зачем нужен Git и как он устроен

Git создал Линус Торвальдс (Linus Torvalds) в 2005 году. Лицензия — GPL-2.0. В отличие от более старых систем контроля версий (CVS, SVN), которые хранят список изменений между версиями файлов (дельты), Git сохраняет снимки (snapshot) всего состояния проекта при каждом коммите. Целостность данных обеспечивается через SHA-1 хэш — изменить историю незаметно невозможно.

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

Git и GitHub: в чём принципиальная разница

Git и GitHub — разные вещи, которые часто путают новички.

Git — программа, которая устанавливается на ваш компьютер и работает локально, без интернета. Именно она управляет историей версий.

GitHub — облачный сервис для хранения репозиториев, совместной работы и код-ревью. GitHub добавляет поверх Git функции: Pull Request (запрос на слияние ветки), Issues (задачи), Actions (автоматизация). Без установленного Git работать с GitHub по-настоящему не получится.

Аналогия: Git — это Microsoft Word, GitHub — это Google Docs. Первый — редактор на вашем устройстве, второй — облачное хранилище с доступом для команды.

GitLab — альтернатива GitHub с возможностью развернуть сервер на собственной инфраструктуре (self-hosted) и встроенным набором инструментов для непрерывной интеграции и доставки (CI/CD).

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

Чек-лист для старта:

• компьютер под управлением Windows, macOS или Linux;
• около 100 МБ свободного места на диске;
• интернет для скачивания Git и работы с GitHub;
• терминал: на macOS и Linux он встроен, на Windows рекомендуется Git Bash (устанавливается вместе с Git).

Для работы с кодом подойдёт любой текстовый редактор. Новичкам рекомендуется VSCode — в нём есть встроенная Git-интеграция с наглядным интерфейсом, что упрощает первые шаги. Умение работать с Git сначала через командную строку даёт более глубокое понимание инструмента, чем графический интерфейс.

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

Как установить Git на Windows, macOS и Linux

Установка занимает 5–10 минут. После неё введите в терминале git --version — если команда вернула версию (например, git version 2.44.0), всё готово.

Windows: официальный установщик Git for Windows

1. Перейдите на git-scm.com и скачайте установщик .exe.
2. Запустите его и на шаге «Adjusting your PATH environment» выберите «Git from the command line and also from 3rd-party software».
3. Остальные параметры — по умолчанию. Завершите установку.

Результат: в системе появится Git Bash, а команды git станут доступны в CMD и PowerShell.

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

macOS: через Xcode Command Line Tools или Homebrew

Способ 1 (быстрый): откройте терминал, введите git --version. Если Git не установлен, macOS сам предложит установить Xcode Command Line Tools — нажмите «Install».

Способ 2: если уже установлен менеджер пакетов Homebrew — запустите brew install git. Это даёт более свежую версию.

Linux: через встроенный пакетный менеджер

• Ubuntu / Debian: sudo apt install git
• Fedora / CentOS / RHEL: sudo dnf install git-all

После установки проверьте: git --version.

Настройка Git после установки

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

git config --global user.name "Имя Фамилия"

git config --global user.email "ваш@email.com"

Флаг --global применяет настройки ко всем репозиториям на компьютере. Без него настройки действуют только для текущего проекта. Есть три уровня конфигурации: --system (для всех пользователей ПК), --global (для текущего пользователя), --local (для одного репозитория). Последний имеет наивысший приоритет.

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

git config --global core.editor "code --wait"

Nano проще для новичков, Vim — редактор по умолчанию, требует отдельного изучения. Если вы случайно попали в Vim, выйти можно командой :q! (без сохранения).

Проверить все текущие настройки: git config --list.

Базовый цикл работы с Git: пошаговая инструкция

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

Ключевая концепция: коммит — это локальное сохранение, ваши коллеги его не видят. Push — отправка изменений на сервер. Пропускать шаги нельзя: нельзя запустить push без коммита, нельзя сделать коммит без git add.

Три состояния, в которых существует любой файл в Git: изменён (modified) → подготовлен (staged) → зафиксирован (committed). Команды git add и git commit переводят файл из одного состояния в следующее.

Шаг 1 — Создайте или клонируйте репозиторий

Чтобы поставить папку проекта под контроль версий, перейдите в неё в терминале и выполните:

git init

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

Если проект уже существует на GitHub, используйте клонирование:

git clone https://github.com/user/repository.git

Важно: клонирование ≠ «скачать ZIP». ZIP-архив не содержит истории изменений и не связан с Git. Только через git clone вы получаете полноценную копию репозитория со всей историей.

Шаг 2 — Добавьте изменения в область ожидания

Создайте или отредактируйте файл в папке проекта. Затем добавьте его в область ожидания (staging area):

git add index.html # один файл

git add . # все изменения в текущей папке

Область ожидания — промежуточная зона между рабочим каталогом и коммитом. Аналогия: корзина в интернет-магазине — товар выбран, но заказ ещё не оформлен. Это позволяет выбрать, какие именно изменения войдут в коммит.

Перед git add проверьте состояние файлов:

git status

Команда покажет: untracked (новый файл, не отслеживается), modified (изменён), staged (добавлен в область ожидания).

Предупреждение: git add . захватит все файлы, включая .env с паролями и папку node_modules. Прежде чем использовать эту команду, создайте файл .gitignore и перечислите в нём файлы, которые не должны попасть в репозиторий.

Шаг 3 — Зафиксируйте коммит

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

git commit -m "добавил форму авторизации"

Каждый коммит получает уникальный SHA-1 хэш — по нему можно найти любое состояние проекта в истории.

Правила хорошего сообщения:

✅ Хорошо	❌ Плохо
«исправил ошибку авторизации»	«фикс»
«добавил валидацию формы регистрации»	«апдейт»
«обновил зависимости до версии 4.x»	«работа»

Через месяц невнятное сообщение не даст понять, что именно было сделано. Принцип: один коммит = одна завершённая задача, код в рабочем состоянии.

Просмотреть историю: git log (полный вывод) или git log --oneline (компактно).

Шаг 4 — Подключите удалённый репозиторий

Если репозиторий создан через git init (а не клонирован), нужно связать его с GitHub или GitLab:

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

origin — стандартное имя для основного удалённого репозитория. Проверить подключение: git remote -v.

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

Шаг 5 — Отправьте изменения и синхронизируйтесь с командой

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

git push -u origin main

Флаг -u устанавливает связь между локальной веткой main и удалённой (origin/main). После этого для последующих отправок достаточно просто git push.

Чтобы получить изменения от коллег, используйте git pull. По сути это две команды в одной: git fetch (загрузить изменения с сервера) + git merge (слить с локальной веткой). Рекомендуется запускать git pull каждое утро перед началом работы.

Обязательный порядок: git add → git commit → git push. Коллеги видят ваши изменения только после push.

Ветки в Git: создание, переключение и слияние

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

Основные команды:

git branch feature/login # создать ветку

git checkout feature/login # переключиться на ветку

git checkout -b feature/login # создать и сразу переключиться

Два типа слияния (merge):

Fast-forward — если ветка main не изменялась, пока вы работали в feature, Git просто передвигает указатель main вперёд. Никакого дополнительного коммита не создаётся — история остаётся линейной.

Merge commit — если обе ветки развивались параллельно (дивергентные ветки), Git создаёт новый коммит с двумя «родителями», фиксируя факт слияния в истории.

Слить ветку в main:

git checkout main

git merge feature/login

Что делать при конфликте слияния

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

В файле появятся маркеры:

<<<<<<< HEAD

наша версия кода

=======

версия из ветки feature

>>>>>>> feature/login

Алгоритм разрешения:

1. Открыть файл с маркерами.
2. Выбрать нужную версию (или объединить обе).
3. Удалить все маркеры (<<<<<<<, =======, >>>>>>>).
4. git add <файл> → git commit.

Если что-то пошло не так и нужно отменить слияние полностью: git merge --abort — это вернёт репозиторий к состоянию до команды git merge.

Шпаргалка основных команд Git

Эти команды покрывают около 90% ежедневной работы с Git.

Команда	Описание	Пример
git init	Создать репозиторий	git init
git clone	Клонировать репозиторий	git clone <url>
git status	Состояние рабочего каталога	git status
git add	Добавить в область ожидания	git add .
git commit	Зафиксировать коммит	git commit -m "сообщение"
git push	Отправить на сервер	git push origin main
git pull	Получить изменения с сервера	git pull
git branch	Список / создать ветку	git branch feature
git checkout	Переключить ветку	git checkout main
git merge	Слить ветку	git merge feature
git log	История коммитов	git log --oneline
git diff	Показать изменения	git diff HEAD
git stash	Временно убрать изменения	git stash
git reset	Откатить коммит (локально)	git reset --soft HEAD~1
git revert	Отменить коммит безопасно	git revert HEAD
git config	Настройка параметров	git config --global user.name
git remote	Управление удалёнными репозиториями	git remote -v
git rm	Удалить файл из отслеживания	git rm --cached .env

Типичные ошибки начинающих и способы их исправить

Ошибка 1: коммит без push. Изменения сохранены локально, но коллеги их не видят. Решение: всегда завершать цикл командой git push.

Ошибка 2: git add . без .gitignore. В репозиторий попадают файл .env с паролями, папка node_modules (сотни мегабайт), системные файлы. Решение: создавать .gitignore до первого git add.

Ошибка 3: нечитаемые сообщения коммитов. «фикс», «апдейт», «работа» — через месяц по таким сообщениям невозможно восстановить контекст. Решение: описывать, что именно сделано, в форме «глагол + объект».

Ошибка 4: git reset на опубликованных коммитах. Если коммит уже ушёл на сервер и другие разработчики его получили, git reset перепишет историю и создаст конфликты у всей команды. Безопасная альтернатива — git revert, который создаёт новый коммит, отменяющий изменения.

Ошибка 5: .gitignore добавлен после первого push. Файлы уже в репозитории и продолжают отслеживаться. Решение: git rm --cached <file> → добавить в .gitignore → новый коммит.

Режимы git reset — только для локальных изменений, не прошедших push:

Режим	Что происходит с изменениями	Когда использовать
--soft HEAD~1	Изменения переходят в область ожидания (staged)	Нужно переделать коммит
--mixed HEAD~1	Изменения остаются в рабочем каталоге (modified)	Нужно пересмотреть, что коммитить
--hard HEAD~1	Изменения удаляются безвозвратно	Нужно полностью отменить последний коммит

Следующие шаги после освоения основ

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

Git → GitHub → командное ветвление → CI/CD

На GitHub вам пригодятся Pull Request (запрос на слияние ветки) — стандартный способ предложить изменения в командном проекте. Перед тем как ветка сливается в main, коллеги проверяют код в режиме ревью и оставляют комментарии. После освоения Pull Request имеет смысл познакомиться с системами непрерывной интеграции и доставки (CI/CD) — они позволяют автоматически запускать тесты и деплой при каждом push.

Если вы хотите углубить знания в разработке и системном анализе, в рамках федерального проекта «Активные меры содействия занятости» доступны программы по направлениям «Специалист по информационным системам: от организации до сопровождения ИТ-проектов» и «Системный аналитик: с нуля до проектирования систем». Обучение проходит онлайн, без отрыва от работы. Подробнее — в каталоге доступных программ.

Часто задаваемые вопросы

В чём разница между Git и GitHub?

Git — это программа, установленная на вашем компьютере. Она управляет историей версий и работает полностью офлайн. GitHub — облачный сервис для хранения репозиториев и командной работы. GitHub добавляет поверх Git Pull Request, Issues, Actions. Без установленного Git работать с GitHub через командную строку не получится. GitLab — альтернатива с возможностью self-hosted развёртывания.

Как посмотреть историю коммитов в Git?

git log — выводит полную историю: хэш коммита, автор, дата, сообщение. git log --oneline — компактный вид, одна строка на коммит. Чтобы посмотреть содержимое конкретного коммита: git show <хэш>. SHA-1 хэш позволяет однозначно идентифицировать каждый снимок состояния проекта и вернуться к нему в любой момент.

В чём разница между git reset и git revert?

git reset переписывает историю: удаляет коммиты из лога. Использовать только для изменений, которые ещё не отправлены на сервер. Если коммит уже получили другие разработчики, git reset создаст конфликты. git revert создаёт новый коммит, который отменяет изменения предыдущего — история не переписывается, что безопасно для опубликованных веток.

Что такое staging area (индекс) в Git?

Staging area — промежуточная зона между рабочим каталогом и коммитом. Аналогия: корзина в интернет-магазине — товар выбран, но заказ ещё не оформлен. git add добавляет файлы в эту зону, git reset HEAD <file> — убирает обратно в рабочий каталог. Staging area даёт гибкость: можно закоммитить только часть изменённых файлов, не все сразу.

Как удалить файл из отслеживания Git, не удаляя его с диска?

Используйте git rm --cached <file>. Команда убирает файл из отслеживания (он пропадает из индекса), но физически остаётся на диске. После этого добавьте его имя в .gitignore и сделайте новый коммит. Это особенно полезно, если вы случайно закоммитили .env или другие конфигурационные файлы с паролями.

Как отменить последний коммит в Git?

До push: git reset --soft HEAD~1 — изменения вернутся в область ожидания; git reset --mixed HEAD~1 — в рабочий каталог; git reset --hard HEAD~1 — изменения удалятся безвозвратно. После push используйте только git revert HEAD — эта команда создаст отменяющий коммит без переписывания истории и не сломает работу коллег.

Что такое ветка в Git и зачем она нужна?

Ветка — подвижный указатель на коммит в истории. Она изолирует работу над отдельной задачей: пока вы разрабатываете новую функцию, основная ветка main остаётся стабильной. Когда работа завершена, ветки объединяют через git merge. Правило для командной разработки: одна задача — одна ветка. Это упрощает ревью кода и отслеживание изменений.

Как сохранить незафиксированные изменения и переключить ветку?

Используйте git stash — команда временно убирает все незафиксированные изменения из рабочего каталога и сохраняет их отдельно. После этого можно переключиться на нужную ветку: git checkout main. Когда вернётесь к задаче — git stash pop восстановит изменения. Это стандартный сценарий: «пришла срочная задача, нужно переключиться, не потеряв текущую работу».

Что такое HEAD в Git?

HEAD — указатель на активную ветку (или коммит). Обновляется автоматически при каждом git checkout. Если переключиться напрямую на конкретный хэш коммита (а не на ветку), HEAD «отсоединяется» (detached HEAD state) — в этом режиме создавать коммиты опасно, они не принадлежат ни одной ветке. Чтобы выйти из detached HEAD: git checkout main.

Что такое Pull Request и зачем он нужен?

Pull Request — запрос на слияние вашей ветки в основную (main). Это функция GitHub и GitLab, не самого Git. Перед слиянием коллеги изучают изменения, оставляют комментарии и подтверждают (апрувят) правки. Pull Request — стандартный инструмент командной разработки: он предотвращает попадание сырого кода в продакшн. Следующий логичный шаг после того, как освоены git push и базовое ветвление.