Git — стандарт де-факто в разработке и самая популярная распределенная система контроля версий (Version Control System, VCS). Навык работы с ней обязателен для программистов и крайне полезен техническим специалистам. В этом пошаговом руководстве разберем базу: от установки консоли до слияния веток и безопасного разрешения конфликтов.
- Что такое Git и GitHub
- Ключевые термины простыми словами
- Пошаговое руководство по Git
- Решение проблем: конфликты слияния
- Шпаргалка по основным командам Git
- Коротко о главном
Что такое Git и GitHub
Git — это бесплатная распределенная система контроля версий с открытым исходным кодом. Она фиксирует изменения кода в проектах любого размера и позволяет команде разработчиков параллельно трудиться над одним продуктом без риска затереть файлы друг друга.
GitHub — это коммерческий сервис и облачное хранилище для хостинга IT-проектов. Платформа предоставляет визуальный интерфейс для управления кодом, отслеживания багов и совместной работы. Использовать Git можно локально без GitHub, но работать с GitHub без установленного Git не получится.
Ключевые термины простыми словами
Работа с системой строится вокруг пяти базовых понятий. Без их понимания консольные команды превращаются в слепое копирование.
- Рабочая директория (Working Directory) — ваша текущая папка с файлами на компьютере. Это место для экспериментов и написания кода.
- Индекс (Staging Area) — промежуточная зона. Аналогия: корзина в интернет-магазине, где товар выбран, но заказ еще не оформлен. Сюда добавляют файлы командой git add.
- Репозиторий (Repository) — хранилище истории проекта в скрытой папке .git. Это архив, где лежат все сохраненные версии файлов.
- Коммит (Commit) — снимок состояния файлов из индекса. К любому коммиту можно откатиться в будущем.
- Ветка (Branch) — независимая линия разработки. Позволяет безопасно пилить новую фичу, не ломая основной продукт.
- HEAD — указатель на текущий активный коммит или ветку.
Такая трехуровневая архитектура (директория → индекс → репозиторий) дает гибкость: вы можете закоммитить только часть измененных файлов, оставив остальные в рабочей папке для доработки.
Пошаговое руководство по Git
Следуйте приведенной инструкции, чтобы настроить окружение и выполнить первые операции.
Шаг 1: Установка и создание учетной записи
Сначала необходимо установить консольную утилиту и зарегистрироваться в облаке. Скачайте дистрибутив с официального сайта под вашу операционную систему и пройдите стандартную установку. Если программа уже стоит, обновите ее до актуальной версии.
.jpg)
Далее создайте бесплатный аккаунт на GitHub:
- Откройте официальную страницу регистрации.
- Укажите email, придумайте надежный пароль и логин (username).
- Пройдите проверку на робота (капчу).
- Нажмите Create account.
- Введите проверочный код, который придет на указанную почту.
- Заполните небольшую анкету о себе или пропустите этот этап.
Шаг 2: Создание локального репозитория
Теперь подготовим папку на компьютере для отслеживания изменений.
Действие 1. Откройте терминал (Git Bash или командную строку) и перейдите в нужный каталог. Например, создадим папку на рабочем столе:
cd ~/Desktop
mkdir myproject
cd myproject/Действие 2. Инициализируйте репозиторий командой init:
git init
Шаг 3: Создание удаленного репозитория
Чтобы хранить код в облаке и работать в команде, создадим проект на GitHub.
- Авторизуйтесь на GitHub.
- Нажмите иконку плюса в правом верхнем углу и выберите New repository.
- Укажите название проекта, добавьте описание и выберите тип доступа (Public или Private).
- Нажмите Create repository.
Свяжем локальную папку с облаком и отправим данные на сервер:
git remote add origin https://github.com/[ваш логин]/[название репозитория.git]
git push -u origin main
Основная ветка сейчас по умолчанию называется main. В старых legacy-проектах она часто носит имя master. Проверить текущее название можно командой git branch.
%201.png)
%201.png)
%201.png)
%201.png)
%201.png)
Если вам нужно скачать уже существующий чужой проект с сервера на свой ПК, используйте команду клонирования:
git clone https://github.com/логин/репозиторий.gitШаг 4: Добавление файлов и настройка .gitignore
Система видит появление новых файлов в папке, но игнорирует их до прямой команды. Проверить статус рабочей директории можно так:
git status
Красным цветом подсветятся неотслеживаемые элементы (untracked). Чтобы добавить конкретный документ в индекс, введите:
git add [название файла]
Важное правило: перед первым коммитом обязательно создайте файл .gitignore в корне проекта. Он предотвращает случайную отправку служебного мусора и конфиденциальных данных (паролей, токенов) в публичный доступ. Пример содержимого .gitignore:
node_modules/
*.log
.env
.idea/
build/Шаг 5: Удаление файлов из индекса
Если вы случайно добавили в индекс лишний файл (например, файл с паролями .env), его нужно безопасно убрать оттуда до создания коммита. Физически на жестком диске он останется.
Для отмены индексации используйте современный синтаксис:
git restore --staged [путь к файлу]Если конфиденциальный файл уже попал в историю репозитория до настройки .gitignore, удалите его из отслеживания специальной командой, добавьте имя в .gitignore и сделайте новый коммит:
git rm --cached [имя файла]
Шаг 6: Коммит изменений
Когда нужные файлы собраны в индексе, фиксируем их состояние. Обязательно пишите осмысленные комментарии — это сэкономит часы дебаггинга вам и вашим коллегам.
git commit -m "Добавлена форма авторизации"Шаг 7: Отмена коммита (Revert vs Reset)
Выбор инструмента для отмены зависит от того, успели ли вы отправить код на удаленный сервер.
Сценарий 1: Коммит уже опубликован (push).
Используйте только git revert [хэш коммита]. Эта команда создает новый коммит, который зеркально отменяет предыдущие правки. История сохраняется, и у коллег не возникает конфликтов при синхронизации.
Сценарий 2: Коммит существует только локально.
Здесь применяется git reset. У команды есть три режима работы:
--soft HEAD~1— отменяет сам коммит, но оставляет файлы в индексе (удобно, если забыли добавить пару строк).--mixed HEAD~1(по умолчанию) — отменяет коммит и убирает файлы из индекса, оставляя их в рабочей директории.--hard HEAD~1— безвозвратно удаляет коммит и все изменения в файлах. Применять с максимальной осторожностью.
.jpg)
Шаг 8: Создание новой ветки
Ветки изолируют разработку. Создание копии проекта позволяет тестировать гипотезы без риска сломать production-версию (ветку main).
git branch [название новой ветки]
Шаг 9: Переключение между ветками
Для навигации по веткам используйте современную команду switch (вместо устаревающего синтаксиса checkout):
git switch [название ветки]Типичная ошибка новичков: переключение напрямую на хэш коммита (git checkout [хэш]). Это приводит к состоянию detached HEAD (отсоединенный указатель). Коммиты, созданные в этом режиме, не привязаны ни к одной ветке и будут удалены сборщиком мусора. Если вы случайно оказались в detached HEAD и написали код, сохраните его, создав новую ветку: git switch -c [имя ветки].
Шаг 10: Переименование веток
Частая задача — безопасное переименование старой ветки master в main в legacy-проектах без потери истории. Процесс состоит из трех этапов.
Сначала переименовываем локально:
git branch -m master main
Переименовать удаленную ветку напрямую нельзя. Нужно удалить старую и отправить новую:
git push origin --delete master
git push -u origin mainШаг 11: Удаление веток
После успешного слияния фичи с основной кодовой базой, рабочую ветку принято удалять для поддержания чистоты.
Удаление локально:
git branch -d [название ветки]Удаление на сервере GitHub:
git push origin --delete [название ветки]
Шаг 12: Установка upstream-ветки
Upstream-ветка — это удаленная ветка по умолчанию, с которой синхронизируется ваша локальная. Без этой настройки при попытке сделать push система выдаст ошибку, так как не понимает, куда именно отправлять данные.
Установить связь (флаг -u) нужно при первой отправке:
git push -u origin [имя ветки]После этого для синхронизации достаточно писать короткие git push и git pull. Важно: несуществующей команды git set upstream нет, это распространенное заблуждение.
.jpg)
Шаг 13: Отвязка удаленного репозитория
Если проект переехал с GitHub на GitLab или другой хостинг, старое подключение (origin) необходимо удалить.
git remote remove origin
Шаг 14: Объединение веток (Merge)
Команда merge интегрирует изменения из одной ветки в другую. Разберем алгоритм слияния фичи с веткой main.
- Переключитесь на целевую ветку:
git switch main. - Подтяните свежие изменения с сервера. Команда
git fetchтолько скачивает новые коммиты в скрытую область, аgit pullскачивает и сразу сливает их с вашей текущей веткой. Используем pull. - Выполните слияние:
git merge [название ветки с фичей].
Решение проблем: конфликты слияния
Конфликт (merge conflict) возникает, когда два разработчика изменили одну и ту же строку кода в разных ветках. Система останавливает процесс и просит ручного вмешательства. Это штатная ситуация.
В проблемном файле Git расставит точные текстовые маркеры:
<<<<<<< HEAD
ваш вариант кода
=======
вариант кода из другой ветки
>>>>>>> feature/loginАлгоритм безопасного разрешения:
- Откройте файл в редакторе кода.
- Проанализируйте оба блока и оставьте правильный вариант (или скомбинируйте их).
- Вручную удалите все служебные маркеры (
<<<<<<<,=======,>>>>>>>). - Добавьте исправленный файл в индекс:
git add [файл]. - Завершите процесс:
git commit -m "Разрешен конфликт".
Если вы запутались и хотите отменить слияние полностью, введите git merge --abort. Репозиторий вернется к исходному состоянию.
Шаг 15: Создание Pull Request
Pull Request (PR) — это запрос на проверку вашего кода перед вливанием в основную ветку на GitHub. Это основа процесса Code Review.
- Создайте файл, добавьте его в индекс и закоммитьте.
- Отправьте ветку на сервер:
git push origin [имя ветки]. - Зайдите в репозиторий на GitHub. Появится зеленая кнопка Compare & pull request. Нажмите ее.
- Опишите суть изменений и нажмите Create pull request.
.jpg)
Шаг 16: Синхронизация изменений
После того как PR одобрен и слит на GitHub, ваша локальная папка об этом не знает. Обязательно подтяните обновления:
git pull origin main
Шпаргалка по основным командам Git
Сохраните эту таблицу. Здесь собраны консольные команды, необходимые для ежедневной продуктивности.
| Команда | Что делает | Пример |
|---|---|---|
| git init | Инициализировать репозиторий | git init |
| git clone | Склонировать удаленный репозиторий | git clone https://github.com/user/repo.git |
| git status | Показать состояние файлов | git status |
| git add | Добавить в индекс | git add . |
| git commit | Создать коммит | git commit -m "сообщение" |
| git push | Отправить на сервер | git push origin main |
| git pull | Скачать и слить изменения | git pull |
| git switch | Переключить ветку | git switch feature-x |
| git merge | Слить ветку | git merge feature-x |
| git log | История коммитов | git log --oneline |
| git diff | Показать отличия | git diff HEAD |
| git rm --cached | Убрать из отслеживания | git rm --cached .env |
| git stash | Спрятать незакоммиченное | git stash |
Коротко о главном
- Git — распределенная система контроля версий, защищающая код от случайной потери и конфликтов при командной разработке.
- Архитектура состоит из трех уровней: рабочая директория (где пишем код), индекс (что готовим к сохранению) и репозиторий (архив истории).
- Основная ветка по современным стандартам называется main. Проверяйте название через git branch.
- Обязательно настраивайте файл .gitignore до первого коммита, чтобы пароли и логи не утекли в сеть.
- Для отмены опубликованных изменений используйте безопасный git revert. Команда git reset подходит только для локальных правок.
- При возникновении конфликтов слияния не паникуйте: откройте файл, выберите нужный код, удалите маркеры и закоммитьте результат.
.png)
.png)
Комментарии (5)
Оставить комментарий