Git: что это и как работает

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

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

Git входит в Roadmap Unity и Unreal Engine-разработчиков и в программу обучения любого программиста.

Главное – понять четыре сущности:

• Рабочая папка – файлы, которые вы сейчас редактируете.

• Индекс, или staging area – изменения, выбранные для следующего коммита.

• Локальный репозиторий – история проекта на вашем компьютере.

• Удаленный репозиторий – копия проекта на GitHub, GitLab или другом сервере.

Простой рабочий процесс выглядит так:

изменили файл → git add → git commit → git push

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

Репозиторий – проект вместе с его историей изменений.

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

git init

В каталоге появится скрытая папка .git. В ней находятся данные о коммитах, ветках, настройках и других объектах репозитория.

Если проект уже существует на сервере, обычно используют:

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

Клонирование создает локальную копию проекта вместе с его историей.

Коммит – зафиксированное состояние выбранных изменений.

Допустим, разработчик исправил форму авторизации. Сначала стоит посмотреть состояние проекта:

git status

Затем добавить нужный файл:

git add src/login.js

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

git diff --staged

И сохранить их:

git commit -m "Исправлена проверка формы входа"

После этого изменение становится частью истории. Посмотреть ее можно так:

git log --oneline

Хороший коммит должен описывать одно понятное изменение. «Исправлена авторизация» информативнее, чем «правки» или «работа за вторник». git log позволяет затем просматривать сохраненную последовательность коммитов.

Ветка позволяет менять проект независимо от основной версии.

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

git switch -c feature-registration

Теперь изменения можно спокойно тестировать, не затрагивая main.

Когда функция готова:

git switch main

затем:

git merge feature-registration

Git объединит истории двух веток. Такой подход позволяет параллельно разрабатывать функции, исправления и эксперименты.

Git это система контроля версий. Git это не GitHub.

Git может работать локально даже без GitHub. GitHub – сервис, где размещают удаленные репозитории и организуют совместную работу: pull request, review, обсуждение изменений и управление проектами.

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

После установки проверьте версию: 

git --version

Перед первым коммитом задайте имя и email:

git config --global user.name "Ivan Ivanov"

git config --global user.email "[email protected]"

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

git config --list

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

Допустим, есть проект robot-project.

Переходим в него:

cd robot-project

Включаем контроль версий:

git init

Перед добавлением файлов создаем .gitignore. Например:

.env
 build/
 *.log

Теперь проверяем состояние:

git status

Добавляем файлы:

git add .

Создаем первый коммит:

git commit -m "Первый коммит"

На этом этапе проект уже находится под контролем версий, но только локально.

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

git remote add origin https://github.com/user/robot-project.git

Посмотреть подключенные удаленные репозитории:

git remote -v

Отправить основную ветку:

git push -u origin main

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

git push

Получается полный цикл:

изменили → проверили → добавили → закоммитили → отправили

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

Когда коллега уже отправил новые коммиты на сервер, их нужно получить.

Самый короткий вариант:

git pull

Команда получает изменения удаленной ветки и интегрирует их в текущую.

Есть более контролируемый вариант:

git fetch

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

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

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

Возникает merge conflict.

В файле можно увидеть:

<<<<<<< HEAD
 текущий вариант
 =======
 вариант другой ветки
 >>>>>>> feature

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

Затем:

git add filename

и создается коммит, завершающий слияние.

Если merge был запущен случайно, его можно отменить:

git merge --abort

Конфликт – не поломка репозитория. Это ситуация, когда автоматическое объединение невозможно и требуется решение человека.

Не все содержимое проекта должно попадать в историю.

Обычно не сохраняют:

• пароли и API-ключи;
• .env;
• временные файлы;
• кеши;
• результаты сборки;
• локальные настройки среды разработки.

Для этого существует .gitignore.

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

Поэтому перед первым git add . полезно посмотреть, какие файлы находятся в проекте.

Здесь важно понимать, на каком этапе находится файл.

Вы изменили файл, но еще не добавили его в индекс:

git restore filename

Добавили файл через git add, но не хотите включать его в следующий коммит:

git restore --staged filename

Нужно изменить последний локальный коммит:

git commit --amend

git restore умеет восстанавливать рабочие файлы и убирать изменения из staging area.

С командами вроде reset --hard и принудительным push --force новичку стоит быть осторожнее: они могут переписывать историю или удалять локальные изменения.

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

• git status – что сейчас происходит с файлами;
• git diff – что именно изменилось;
• git add – что попадет в следующий коммит;
• git commit – сохранить изменение;
• git log --oneline – посмотреть историю;
• git switch – переключить ветку;
• git merge – объединить ветки;
• git pull – получить изменения;
• git push – отправить свои коммиты;
• git clone – получить существующий проект.

Не нужно заучивать сотни параметров. Гораздо важнее понимать простой маршрут:

рабочие файлы → индекс → коммит → удаленный репозиторий.

Допустим, робототехнику нужно исправить ошибку датчика.

Он получает актуальную версию:

git switch main
git pull

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

git switch -c fix-sensor-timeout

Исправляет код и проверяет изменения:

git status
git diff

После проверки:

git add src/sensor.c
git commit -m "Исправлен таймаут датчика"
git push -u origin fix-sensor-timeout

После этого на GitHub можно открыть pull request, проверить код и объединить ветку с main. Такой branch-based workflow используется GitHub как базовая модель совместной разработки.

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