Основы Git

Git — распределённая система контроля версий, которая сохраняет историю изменений проекта, помогает сравнивать версии файлов, создавать независимые ветки разработки и совместно работать над кодом.

Git отслеживает не отдельные действия в редакторе, а состояния файлов, сохранённые в виде коммитов.

Типичный цикл работы:

Изменение файлов
      ↓
git add
      ↓
Индекс (staging area)
      ↓
git commit
      ↓
История репозитория

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

git --version

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

git config --global user.name "Ivan Ivanov"
git config --global user.email "ivan@example.com"

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

git config --list

Содержание

• Зачем нужна система контроля версий
• Разница между Git, GitHub и GitLab
• Основные области Git
• Создание репозитория: `git init`
• Клонирование репозитория: `git clone`
• Проверка состояния: `git status`
• Добавление изменений: `git add`
• Создание коммита: `git commit`
• Просмотр изменений: `git diff`
• Просмотр истории: `git log`
• Базовый цикл работы
• Ветки
• Объединение веток: `git merge`
• Fast-forward merge
• Конфликты слияния
• Файл `.gitignore`
• Удалённые репозитории: `git remote`
• Отправка изменений: `git push`
• Получение информации: `git fetch`
• Получение и объединение: `git pull`
• Связь локальных и удалённых веток
• Создание репозитория на GitHub или GitLab
• README
• Pull Request и Merge Request
• Что сделано
• Как проверить
• Откат незакоммиченных изменений
• Откат через `git checkout --`
• Удаление файла из индекса
• Откат коммитов: `git reset`
• Безопасная отмена коммита: `git revert`
• Выбор команды для отката
• Типичный сценарий индивидуальной работы
• Типичный сценарий командной работы
• Полезные команды
• Общий пример

Зачем нужна система контроля версий

VCS (Version Control System) — система контроля версий. Она хранит историю изменений файлов и позволяет управлять разными версиями проекта.

Без VCS разработчики часто создают копии каталогов:

project
project-final
project-final-2
project-final-really
project-final-fixed

Система контроля версий решает эту проблему и позволяет:

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

Локальные и удалённые репозитории

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

Удалённый репозиторий находится на сервере, например GitHub или GitLab. Он используется для обмена изменениями и совместной работы.

Локальный репозиторий ←→ Удалённый репозиторий

Разница между Git, GitHub и GitLab

Git — программа и система контроля версий. Она работает локально и управляется командами из терминала.

GitHub — веб-сервис для хранения Git-репозиториев и совместной работы.

GitLab — другой веб-сервис для Git-репозиториев. Он предоставляет похожие возможности и может разворачиваться на собственном сервере.

Git можно использовать без GitHub и GitLab:

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

GitHub и GitLab используют Git, но добавляют веб-интерфейс и дополнительные возможности:

• просмотр файлов и истории;
• Pull Request или Merge Request;
• обсуждение изменений;
• управление задачами;
• проверку кода;
• автоматическую сборку и тестирование;
• управление участниками проекта.

Основные области Git

В базовой модели Git используются три области.

Рабочая директория

Рабочая директория (working tree) — файлы проекта, которые разработчик видит и редактирует.

Например:

project/
├── index.html
├── styles.css
└── script.js

Индекс

Индекс (staging area) — промежуточная область, в которой собираются изменения для следующего коммита.

Команда:

git add index.html

добавляет текущую версию index.html в индекс.

Репозиторий

Репозиторий хранит историю зафиксированных изменений.

Команда:

git commit -m "Добавлена главная страница"

создаёт коммит из изменений, находящихся в индексе.

Рабочая директория → Индекс → Репозиторий
       git add         git commit

Создание репозитория: git init

Команда git init создаёт новый локальный Git-репозиторий в существующей директории.

mkdir my-project
cd my-project
git init

Git создаст скрытую директорию .git:

my-project/
└── .git/

В .git хранятся:

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

Удаление .git удаляет историю Git, но не удаляет обычные файлы проекта.

Проверить состояние нового репозитория:

git status

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

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

Указать имя основной ветки при инициализации:

git init -b main

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

git branch -M main

Повторный вызов git init в существующем репозитории обычно не удаляет историю и не создаёт вложенный репозиторий. Git только повторно инициализирует текущий репозиторий.

Клонирование репозитория: git clone

Команда git clone загружает существующий удалённый репозиторий на компьютер.

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

Git:

1. создаст директорию project;
2. загрузит файлы;
3. загрузит историю коммитов;
4. настроит удалённый репозиторий с именем origin;
5. переключится на основную ветку.

После клонирования:

cd project
git status
git remote -v

Клонирование в директорию с другим именем:

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

Клонирование по SSH:

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

HTTPS обычно проще для первого знакомства. SSH удобен для регулярной работы после настройки ключей.

git init или git clone

Используйте git init, если проект уже находится на компьютере и для него нужно начать вести историю:

cd existing-project
git init

Используйте git clone, если репозиторий уже существует на GitHub, GitLab или другом сервере:

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

Не нужно выполнять git init внутри репозитория, полученного через git clone: он уже инициализирован.

Проверка состояния: git status

Команда git status показывает текущее состояние рабочей директории и индекса:

git status

Она сообщает:

• текущую ветку;
• наличие изменённых файлов;
• изменения, добавленные в индекс;
• неотслеживаемые файлы;
• наличие конфликтов;
• отличие локальной ветки от удалённой.

Короткий формат:

git status --short

Пример:

 M styles.css
A  script.js
?? notes.txt

Обозначения:

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

XY имя-файла

Первый символ относится к индексу, второй — к рабочей директории.

Добавление изменений: git add

Команда git add добавляет изменения в индекс для следующего коммита.

Добавить один файл:

git add index.html

Добавить несколько файлов:

git add index.html styles.css

Добавить все изменения из текущей директории:

git add .

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

git add -A

Добавить все изменения уже отслеживаемых файлов:

git add -u

После git add полезно проверить состояние:

git status

git add не создаёт коммит и не отправляет изменения на сервер. Команда только помещает выбранную версию файлов в индекс.

Если после git add снова изменить файл, Git будет видеть две версии изменений:

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

Посмотреть различия можно командами:

git diff
git diff --staged

Создание коммита: git commit

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

Создать коммит:

git commit -m "Добавлена форма регистрации"

В коммит попадут только изменения, добавленные через git add.

Пример базового цикла:

git status
git add index.html styles.css
git commit -m "Добавлена главная страница"

Хорошее сообщение коммита кратко описывает выполненное изменение:

git commit -m "Добавлена проверка электронной почты"
git commit -m "Исправлено отображение меню на мобильных устройствах"
git commit -m "Обновлена инструкция по запуску проекта"

Малоинформативные сообщения:

git commit -m "Изменения"
git commit -m "Исправления"
git commit -m "Готово"

Коммит всех отслеживаемых файлов

Команда:

git commit -am "Исправлена навигация"

автоматически добавляет в индекс изменения уже отслеживаемых файлов и создаёт коммит.

Новые неотслеживаемые файлы она не добавляет. Для них всё равно нужен git add.

Изменение последнего коммита

Добавить забытые изменения в последний локальный коммит:

git add forgotten-file.txt
git commit --amend --no-edit

Изменить сообщение последнего коммита:

git commit --amend -m "Новое сообщение"

--amend создаёт новый коммит вместо предыдущего, поэтому изменяется его идентификатор. Не рекомендуется изменять таким способом коммит, который уже отправлен другим разработчикам.

Просмотр изменений: git diff

Команда git diff показывает различия между версиями файлов.

Изменения, не добавленные в индекс

git diff

Команда сравнивает рабочую директорию с индексом.

Изменения, добавленные в индекс

git diff --staged

Альтернативная запись:

git diff --cached

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

Все изменения относительно последнего коммита

git diff HEAD

Изменения конкретного файла

git diff styles.css

Сравнение двух коммитов

git diff abc123 def456

Сравнение веток

git diff main feature/login

В выводе строки с - обозначают удалённый текст, а строки с + — добавленный:

-const title = "Old title";
+const title = "New title";

Перед коммитом полезно выполнить:

git diff
git diff --staged

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

Просмотр истории: git log

Команда git log показывает историю коммитов:

git log

Обычно для каждого коммита отображаются:

• идентификатор;
• автор;
• дата;
• сообщение.

Краткий формат:

git log --oneline

Пример:

4f28c1a Добавлена форма входа
72e91bf Создана главная страница
a15b302 Первый коммит

Показать граф веток:

git log --oneline --graph --decorate --all

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

git log -5

Показать историю конкретного файла:

git log -- index.html

Показать изменения внутри коммитов:

git log -p

Показать краткую статистику изменённых файлов:

git log --stat

Идентификатор коммита

Каждый коммит имеет уникальный хеш:

4f28c1ae3dc5b3d80d637a7c3f25049ac781ab12

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

git show 4f28c1a

Показать содержимое и информацию о коммите:

git show 4f28c1a

HEAD

HEAD — указатель на текущий коммит и обычно на текущую ветку.

HEAD → main → последний коммит

Предыдущий коммит:

HEAD~1

Два коммита назад:

HEAD~2

Пример:

git show HEAD~1

Базовый цикл работы

Типичная последовательность действий:

git status
git diff
git add .
git diff --staged
git commit -m "Добавлена страница профиля"
git log --oneline

Полный смысл команд:

git status         → проверить состояние
git diff           → посмотреть неподготовленные изменения
git add            → подготовить изменения
git diff --staged  → проверить будущий коммит
git commit         → сохранить коммит
git log            → посмотреть историю

Один коммит желательно посвящать одной логически завершённой задаче.

Например, исправление ошибки и полная переработка дизайна обычно должны находиться в разных коммитах.

Ветки

Ветка — независимая линия разработки. Ветки позволяют работать над новой функцией или исправлением, не изменяя основную версию проекта до завершения работы.

Основная ветка обычно называется main.

A — B — C  main
         \
          D — E  feature/login

Ветка является указателем на определённый коммит. Создание ветки не копирует весь проект.

Просмотр веток: git branch

Показать локальные ветки:

git branch

Текущая ветка отмечается символом *:

* main
  feature/login

Показать локальные и удалённые ветки:

git branch --all

Показать дополнительную информацию:

git branch -v

Создание ветки

Создать ветку без переключения:

git branch feature/login

Создать ветку и сразу переключиться:

git switch -c feature/login

Старый вариант:

git checkout -b feature/login

В имени ветки удобно указывать назначение:

feature/login
feature/profile-page
fix/header-layout
docs/readme

Переключение веток: git switch

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

git switch feature/login

Вернуться в основную ветку:

git switch main

Переключение через git checkout

До появления git switch для переключения использовалась команда:

git checkout feature/login

Создать ветку и переключиться:

git checkout -b feature/login

Для работы с ветками предпочтительнее git switch, потому что она имеет более узкое и понятное назначение.

Удаление ветки

Удалить объединённую локальную ветку:

git branch -d feature/login

Принудительно удалить ветку, даже если изменения не объединены:

git branch -D feature/login

-D может привести к потере коммитов, если они недоступны из других веток.

Объединение веток: git merge

Команда git merge добавляет изменения указанной ветки в текущую ветку.

Допустим, работа выполнялась в feature/login:

git switch feature/login

После завершения создаётся коммит:

git add .
git commit -m "Добавлена форма входа"

Для объединения нужно перейти в ветку, которая должна получить изменения:

git switch main
git merge feature/login

Важно запомнить правило:

Сначала перейти в принимающую ветку,
затем выполнить git merge с именем подключаемой ветки.

После успешного объединения рабочую ветку можно удалить:

git branch -d feature/login

Fast-forward merge

Fast-forward — простое объединение, при котором основная ветка не изменялась после создания рабочей ветки.

До объединения:

A — B  main
     \
      C — D  feature/login

Команда:

git switch main
git merge feature/login

После объединения:

A — B — C — D  main, feature/login

Git просто перемещает указатель main на последний коммит рабочей ветки. Отдельный merge-коммит не создаётся.

Пример сообщения Git:

Fast-forward

Если после создания рабочей ветки в main появились новые коммиты, fast-forward может быть невозможен:

A — B — C  main
     \
      D — E  feature/login

В таком случае Git обычно создаёт отдельный merge-коммит или просит разрешить конфликты.

Принудительно создать merge-коммит даже при возможности fast-forward:

git merge --no-ff feature/login

Разрешить только fast-forward и отменить команду в остальных случаях:

git merge --ff-only feature/login

Конфликты слияния

Конфликт возникает, когда разные ветки несовместимо изменили один и тот же участок файла.

Git отмечает конфликтующий участок:

<<<<<<< HEAD
Текст из текущей ветки
=======
Текст из подключаемой ветки
>>>>>>> feature/login

Для разрешения конфликта нужно:

1. открыть конфликтующий файл;
2. выбрать правильный вариант или объединить изменения вручную;
3. удалить маркеры <<<<<<<, ======= и >>>>>>>;
4. добавить исправленный файл в индекс;
5. завершить слияние коммитом.

git add conflicted-file.txt
git commit

Посмотреть конфликтующие файлы:

git status

Отменить незавершённое слияние:

git merge --abort

Файл .gitignore

Файл .gitignore содержит правила для файлов и директорий, которые Git не должен отслеживать.

Пример структуры проекта:

project/
├── .gitignore
├── index.html
├── node_modules/
└── .env

Содержимое .gitignore:

node_modules/
.env
dist/
*.log

Основные шаблоны

Игнорировать конкретный файл:

config.local.js

Игнорировать директорию:

node_modules/

Игнорировать все файлы с расширением .log:

*.log

Игнорировать все .tmp-файлы во всех директориях:

**/*.tmp

Игнорировать директорию только в корне репозитория:

/build/

Не игнорировать конкретный файл:

*.log
!important.log

Комментарий:

# Зависимости проекта
node_modules/

Пустые строки не влияют на правила.

Типичный .gitignore для frontend-проекта

# Зависимости
node_modules/

# Результат сборки
dist/
build/

# Переменные окружения
.env
.env.local
.env.*.local

# Логи
*.log
npm-debug.log*
yarn-debug.log*

# Настройки редакторов
.vscode/
.idea/

# Системные файлы
.DS_Store
Thumbs.db

Не следует добавлять в репозиторий:

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

Уже отслеживаемые файлы

.gitignore не перестаёт отслеживать файл, который ранее был добавлен в Git.

Если .env уже отслеживается:

git rm --cached .env
git commit -m "Файл .env исключён из репозитория"

Для директории:

git rm -r --cached node_modules
git commit -m "Директория node_modules исключена из репозитория"

Флаг --cached удаляет объект из индекса Git, но сохраняет его в рабочей директории.

Проверить, почему файл игнорируется:

git check-ignore -v .env

Удалённые репозитории: git remote

Удалённый репозиторий (remote) — ссылка на репозиторий, расположенный на сервере.

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

git remote

Показать их адреса:

git remote -v

Пример:

origin  https://github.com/user/project.git (fetch)
origin  https://github.com/user/project.git (push)

origin — стандартное имя основного удалённого репозитория. Это соглашение, а не обязательное слово.

Добавление удалённого репозитория

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

Проверка:

git remote -v

Изменение адреса

git remote set-url origin https://github.com/user/new-project.git

Удаление подключения

git remote remove origin

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

Информация об удалённом репозитории

git remote show origin

Отправка изменений: git push

Команда git push отправляет локальные коммиты в удалённый репозиторий.

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

git push -u origin main

Здесь:

• origin — имя удалённого репозитория;
• main — имя отправляемой ветки;
• -u — связывает локальную ветку с удалённой.

После установки связи обычно достаточно:

git push

Отправить рабочую ветку:

git push -u origin feature/login

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

git push origin --delete feature/login

git push отправляет только созданные коммиты. Изменения, которые находятся только в рабочей директории или индексе, не отправляются.

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

Получение информации: git fetch

Команда git fetch загружает информацию о новых коммитах и ветках из удалённого репозитория, но не изменяет текущие файлы:

git fetch

Для конкретного удалённого репозитория:

git fetch origin

После загрузки можно посмотреть историю:

git log --oneline --graph --decorate --all

Удалённая ветка обычно отображается как:

origin/main

Сравнить локальную и удалённую ветки:

git diff main..origin/main

Объединить полученные изменения вручную:

git merge origin/main

git fetch удобен, когда сначала нужно посмотреть изменения и только затем решить, объединять ли их с локальной веткой.

Получение и объединение: git pull

Команда git pull получает изменения с сервера и объединяет их с текущей веткой:

git pull

В базовом варианте она приблизительно соответствует последовательности:

git fetch
git merge

Явное указание репозитория и ветки:

git pull origin main

Перед git pull желательно:

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

git status
git pull

Если локальная и удалённая ветки содержат несовместимые изменения, может возникнуть конфликт.

Разница между fetch и pull

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

git fetch origin
git log --oneline main..origin/main
git merge origin/main

Быстрый вариант:

git pull

Связь локальных и удалённых веток

После команды:

git push -u origin main

локальная ветка main начинает отслеживать origin/main.

Проверить связь:

git branch -vv

Пример:

* main 4f28c1a [origin/main] Добавлена главная страница

Основные обозначения в git status:

Your branch is up to date with 'origin/main'.

Локальная ветка синхронизирована с удалённой.

Your branch is ahead of 'origin/main' by 2 commits.

Есть два локальных коммита, которые ещё не отправлены. Обычно нужен:

git push

Your branch is behind 'origin/main' by 2 commits.

На сервере есть два новых коммита. Обычно нужен:

git pull

Your branch and 'origin/main' have diverged.

Локально и на сервере появились разные коммиты. Их необходимо объединить с помощью merge или rebase в соответствии с правилами проекта.

Создание репозитория на GitHub или GitLab

Общий порядок действий в веб-интерфейсе:

1. войти в учётную запись;
2. выбрать создание нового проекта или репозитория;
3. указать имя;
4. при необходимости добавить описание;
5. выбрать видимость;
6. решить, нужно ли автоматически создавать README;
7. создать репозиторий.

Основные варианты видимости:

Подключение существующего локального проекта

Если удалённый репозиторий создан пустым:

cd my-project
git init
git add .
git commit -m "Первый коммит"
git branch -M main
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Для GitLab последовательность та же, меняется адрес:

git remote add origin https://gitlab.com/user/my-project.git
git push -u origin main

Если на сервере уже создан README, .gitignore или лицензия, удалённый репозиторий содержит собственный коммит. В таком случае проще сначала клонировать его:

git clone https://github.com/user/my-project.git
cd my-project

Затем добавить файлы проекта, создать коммит и выполнить git push.

README

README.md — основной файл с описанием проекта. GitHub и GitLab обычно показывают его содержимое на главной странице репозитория.

Минимальный пример:

# Название проекта

Краткое описание проекта.

## Установка

```bash
npm install
\```

## Запуск

```bash
npm run dev
\```

## Использование

Описание основных возможностей проекта.

Обычно README содержит:

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

Добавить README в существующий проект:

git add README.md
git commit -m "Добавлено описание проекта"
git push

Pull Request и Merge Request

Pull Request (PR) — запрос на добавление изменений из одной ветки в другую. Такое название используется на GitHub.

На GitLab аналогичный механизм называется Merge Request (MR).

Типичный процесс:

main
  ↓
создание feature-ветки
  ↓
изменения и коммиты
  ↓
push ветки
  ↓
Pull Request / Merge Request
  ↓
проверка
  ↓
merge в main

Создание рабочей ветки

git switch main
git pull
git switch -c feature/login

Внести изменения и создать коммит:

git add .
git commit -m "Добавлена форма входа"

Отправить ветку:

git push -u origin feature/login

Создание простого Pull Request на GitHub

В веб-интерфейсе GitHub нужно:

1. открыть репозиторий;
2. перейти к созданию Pull Request;
3. выбрать базовую ветку main;
4. выбрать ветку с изменениями, например feature/login;
5. проверить список коммитов и изменённых файлов;
6. указать заголовок и описание;
7. создать Pull Request;
8. после проверки выполнить merge.

Направление объединения:

base: main ← compare: feature/login

Пример заголовка:

Добавлена форма входа

Пример описания:

## Что сделано

Добавлена форма входа с полями электронной почты и пароля.

## Как проверить

1. Открыть страницу входа.
2. Заполнить поля.
3. Нажать кнопку «Войти».

Создание Merge Request на GitLab

Последовательность почти такая же:

1. отправить рабочую ветку;
2. открыть проект в GitLab;
3. создать Merge Request;
4. выбрать feature/login как source branch;
5. выбрать main как target branch;
6. заполнить заголовок и описание;
7. отправить Merge Request на проверку;
8. после одобрения выполнить merge.

После объединения локальную ветку можно удалить:

git switch main
git pull
git branch -d feature/login

Если ветка осталась на сервере:

git push origin --delete feature/login

Откат незакоммиченных изменений

Способ отката зависит от того, где находятся изменения:

Рабочая директория → Индекс → Коммит → Удалённый репозиторий

Перед откатом всегда полезно проверить:

git status
git diff
git diff --staged

Откат через git checkout --

Старая команда для отмены изменений файла в рабочей директории:

git checkout -- index.html

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

Команда восстанавливает файл из индекса. Если файл не добавлялся через git add, его содержимое обычно вернётся к состоянию последнего коммита.

Явно восстановить файл из HEAD:

git checkout HEAD -- index.html

Отменить все незакоммиченные изменения в текущей директории:

git checkout -- .

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

Современный и более понятный вариант:

git restore index.html

Восстановить все файлы:

git restore .

Удаление файла из индекса

Если изменения были добавлены через git add, но их не нужно включать в следующий коммит:

git reset HEAD index.html

В современных версиях Git можно использовать:

git restore --staged index.html

Команда удаляет изменения из индекса, но сохраняет их в рабочей директории.

До команды:
изменения находятся в индексе

После команды:
изменения остаются в файле,
но не попадут в следующий коммит

Для всех файлов:

git reset HEAD .

Или:

git restore --staged .

Откат коммитов: git reset

Команда git reset перемещает текущую ветку на другой коммит. В зависимости от режима она также может изменить индекс и рабочую директорию.

git reset --soft

Отменяет коммит, но сохраняет изменения в индексе:

git reset --soft HEAD~1

После команды изменения готовы к новому коммиту:

git status
git commit -m "Исправленное сообщение"

Подходит, если нужно пересобрать последний локальный коммит.

git reset или git reset --mixed

Режим по умолчанию:

git reset HEAD~1

То же самое:

git reset --mixed HEAD~1

Команда:

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

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

git add .
git commit -m "Новый коммит"

git reset --hard

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

git reset --hard HEAD~1

Команда изменяет:

• текущую ветку;
• индекс;
• рабочую директорию.

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

Вернуться к конкретному коммиту:

git reset --hard 4f28c1a

--hard следует использовать только после проверки истории и состояния:

git status
git log --oneline

Сравнение режимов reset

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

Безопасная отмена коммита: git revert

Команда git revert создаёт новый коммит, который отменяет изменения указанного коммита:

git revert 4f28c1a

Отменить последний коммит:

git revert HEAD

История до revert:

A — B — C

После отмены коммита C:

A — B — C — D

Коммит D содержит обратные изменения для C. Сам коммит C остаётся в истории.

git revert рекомендуется использовать для коммитов, которые уже опубликованы:

git revert HEAD
git push

reset и revert

Правило:

Локальный неопубликованный коммит → reset
Опубликованный общий коммит → revert

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

Выбор команды для отката

Отменить изменения файла, которые ещё не добавлены в индекс:

git restore file.txt

Старый вариант:

git checkout -- file.txt

Убрать файл из индекса, сохранив изменения:

git restore --staged file.txt

Старый вариант:

git reset HEAD file.txt

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

git reset --soft HEAD~1

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

git reset HEAD~1

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

git reset --hard HEAD~1

Безопасно отменить опубликованный коммит:

git revert HEAD
git push

Типичный сценарий индивидуальной работы

Создание проекта:

mkdir my-project
cd my-project
git init -b main

Создание файлов и первого коммита:

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

Подключение GitHub или GitLab:

git remote add origin https://github.com/user/my-project.git
git push -u origin main

Работа над новой функцией:

git switch -c feature/profile

Сохранение изменений:

git status
git diff
git add .
git diff --staged
git commit -m "Добавлена страница профиля"

Отправка ветки:

git push -u origin feature/profile

После объединения Pull Request:

git switch main
git pull
git branch -d feature/profile

Типичный сценарий командной работы

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

git switch main
git pull

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

git switch -c feature/search

Внести изменения и создать коммиты:

git add .
git commit -m "Добавлен интерфейс поиска"

Отправить ветку:

git push -u origin feature/search

Создать Pull Request или Merge Request.

После объединения обновить локальную основную ветку:

git switch main
git pull

Удалить завершённую локальную ветку:

git branch -d feature/search

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

Общий пример

Создание локального проекта:

mkdir git-example
cd git-example
git init -b main

Создание README.md:

# Git Example

Учебный проект для изучения Git.

Первый коммит:

git status
git add README.md
git commit -m "Добавлен README"

Создание рабочей ветки:

git switch -c feature/home-page

Добавление файлов:

git-example/
├── README.md
├── index.html
└── styles.css

Сохранение изменений:

git status
git diff
git add index.html styles.css
git diff --staged
git commit -m "Добавлена главная страница"

Объединение с помощью fast-forward:

git switch main
git merge feature/home-page
git branch -d feature/home-page

Подключение удалённого репозитория:

git remote add origin https://github.com/user/git-example.git
git push -u origin main

Следующая задача:

git switch -c feature/navigation

После изменений:

git add .
git commit -m "Добавлена навигация"
git push -u origin feature/navigation

Затем изменения можно добавить в main через Pull Request или Merge Request.