История коммитов в Git — это своеобразный дневник разработки проекта. Каждый коммит — это запись о том, какие изменения были внесены и зачем. Но иногда мы совершаем ошибки: забываем добавить файл, пишем непонятное сообщение или делаем слишком много маленьких коммитов, которые засоряют историю. В этом уроке вы научитесь управлять историей коммитов: просматривать её, исправлять последние изменения и объединять коммиты для более чистой и понятной структуры.

Представьте, что вы ведёте личный дневник. Если вы сделали ошибку на странице, то вместо того чтобы вырвать её, вы можете поправить текст или объединить несколько заметок в одну. Git даёт вам такие же возможности, только для кода.

Что вы узнаете в рамках статьи

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

Ключевые термины

• Коммит (Commit) — зафиксированное состояние файлов в репозитории.
• История коммитов (Commit history) — последовательность всех изменений проекта.
• git log — команда для просмотра истории коммитов.
• Rebase — операция для переписывания или изменения истории.
• Squash — объединение нескольких коммитов в один.

Просмотр истории коммитов

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

Базовый просмотр

Самая простая команда:

git log

Она выводит список всех коммитов в обратном хронологическом порядке — от самого нового к старому. Для каждого коммита вы увидите:

• Хэш — уникальный идентификатор коммита. Git хранит его в виде длинной строки из цифр и букв. Это как «паспорт» изменения.
• Автор — кто сделал коммит (имя и email).
• Дата — когда именно он был зафиксирован.
• Сообщение — описание изменений, написанное разработчиком.

Пример:

commit e3b0c4d
Author: Ivan Petrov <ivan@example.com>
Date:   Tue Sep 24 14:52 2024

    Исправление бага с загрузкой изображений

👉 Здесь видно, что Иван Петров 24 сентября внёс исправление ошибки в загрузке картинок.

Укороченный вывод

В больших проектах коммитов может быть сотни и даже тысячи. Смотреть длинный вывод неудобно. Поэтому часто используют ключ --oneline:

git log --oneline

Вывод станет компактным:

e3b0c4d Исправление бага с загрузкой изображений
f4a5b3e Добавлен README.md
c4b9b7d Настройки CI/CD

Теперь каждый коммит занимает одну строку, а длинный хэш заменён на короткий (первые 7 символов).

Визуальное дерево

Если в проекте много веток, полезно добавить флаг --graph:

git log --oneline --graph

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

* e3b0c4d Исправление бага с загрузкой изображений
| * f4a5b3e Добавлен README.md
|/
* c4b9b7d Настройки CI/CD

Здесь видно, что была параллельная работа в другой ветке, которая позже объединилась с основной.

Фильтрация истории

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

• По автору:

  git log --author="Ivan"
  
  

• По времени:

  git log --since="2 weeks ago"
  git log --until="2024-09-01"
  
  

• С подробностями:

  git log -p
  
  

  Этот вариант показывает не только список коммитов, но и изменения в коде (diff).

Упрощение вывода

Когда проект развивается уже не первый месяц, история коммитов может насчитывать сотни или даже тысячи записей. Представьте себе длинный дневник, где каждая страница — это новый коммит. Читать его от начала до конца неудобно, особенно если нужно просто быстро найти, что изменялось недавно.

Поэтому Git предлагает специальные параметры для команды git log, чтобы сделать вывод компактнее и удобнее.

git log --oneline

Эта опция превращает каждый коммит в одну строку:

git log --oneline

Пример вывода:

e3b0c4d Исправление бага с загрузкой изображений
f4a5b3e Добавлен README.md
c4b9b7d Настройки CI/CD

• Длинный хэш заменяется коротким (обычно 7 символов).
• Показывается только сообщение коммита.

👉 Такой вид отлично подходит для быстрого обзора истории. Это как заголовки новостей вместо длинных статей: сразу видно суть.

git log --graph

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

Команда:

git log --graph

Добавляет к выводу простую визуализацию в виде «веточек» и «линий»:

* e3b0c4d Исправление бага
| * f4a5b3e Добавлен README.md
|/
* c4b9b7d Настройки CI/CD

• Звёздочки (\*) обозначают коммиты.
• Вертикальные и диагональные линии показывают, где ветки расходились и где снова соединились.

📖 Аналогия: это похоже на схему метро — можно увидеть, где линия разделилась на две, а потом снова сошлась в одну.

Комбинация параметров

Чаще всего используют сразу оба параметра:

git log --oneline --graph

Результат — компактная и наглядная история: короткие сообщения + дерево веток.

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

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

• сообщение получилось неточным или с опечаткой,
• забыли добавить один важный файл,
• случайно закоммитили что-то лишнее.

Создавать новый коммит ради этого — не самое удачное решение, ведь история станет захламлённой. Для таких случаев Git предоставляет команду git commit --amend.

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

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

git commit --amend -m "Исправлен баг с авторизацией"

Теперь в истории останется только один коммит, но с обновлённым текстом. 📌 Это как исправить запись в дневнике — зачеркнуть старое предложение и написать поверх более понятное.

Добавление забытых файлов

Частая ситуация: вы сделали коммит, но не добавили в индекс (git add) один из файлов. Не беда — просто добавьте его и снова используйте --amend:

git add important_file.py
git commit --amend -m "Добавлены недостающие файлы и исправлено сообщение"

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

Важное ограничение

Использовать --amend можно только для локальных коммитов, которые ещё не были отправлены на общий репозиторий (git push).

Почему?

• Если переписать историю и потом «вытолкнуть» её на сервер, коллеги получат конфликт версий: у них есть один коммит, а у вас — уже другой с тем же хэшем.
• Это может запутать всю команду.

📌 Золотое правило: амендим коммиты только пока они «живут» локально.

Объединение коммитов (Squash)

В процессе разработки часто получается слишком «шумная» история. Например:

Добавлен файл стилей
Исправлена опечатка
Мелкая правка кода

Каждый из этих коммитов сам по себе ничего не говорит о прогрессе задачи. А вот если объединить их в один коммит вроде "Добавлен и доработан модуль авторизации", история проекта станет гораздо понятнее.

📌 Squash — это процесс объединения нескольких мелких коммитов в один более крупный и содержательный.

Зачем нужен squash

1. Чистая история проекта. История становится более линейной и читаемой.
2. Удобство для команды. Другим разработчикам проще понять смысл изменений, не перелистывая десятки мелких записей.
3. Документирование логики. Вместо «заплаток» появляется цельный коммит, который отражает завершённую задачу.

Аналогия: представьте, что пишете черновик статьи. Сначала вы делаете заметки, исправляете ошибки, переносите абзацы. Но в финале хочется оставить один «чистовик», а не 10 исправленных черновиков подряд. Именно это делает squash.

Как объединить коммиты

Для этого используется интерактивный rebase.

git rebase -i HEAD~3

• HEAD~3 означает: взять последние 3 коммита.
• Git откроет редактор с их списком.

Пример списка:

pick e3b0c4d Добавлен файл стилей
pick f4a5b3e Исправлена опечатка
pick c4b9b7d Мелкая правка кода

Чтобы объединить коммиты, оставляем первый как pick, а остальные заменяем на squash (или просто s):

pick e3b0c4d Добавлен файл стилей
squash f4a5b3e Исправлена опечатка
squash c4b9b7d Мелкая правка кода

Далее Git попросит объединить сообщения коммитов: вы можете оставить все или переписать их в одно понятное.

Пример результата

После squash в истории будет:

e3b0c4d Добавлен и доработан модуль авторизации

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

Важные моменты

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

Наиболее частые ошибки

• Неправильное использование -amend.
  Новички иногда думают, что amend создаёт новый коммит, но на самом деле он перезаписывает последний. В результате можно потерять данные.
• Rebase в общем репозитории.
  Переписывание истории на ветке, которая уже отправлена коллегам, приводит к конфликтам.
• Слишком много мелких коммитов.
  История становится нечитаемой. Лучше объединять их.

Наиболее частые вопросы

1. Можно ли отменить rebase, если что-то пошло не так?
   Да, с помощью git reflog можно найти старое состояние и вернуться к нему через git reset.
2. Как найти, кто внёс ошибку в проект?
   Используйте git log -p и просмотрите изменения построчно.
3. Когда лучше объединять коммиты?
   Обычно перед отправкой изменений в командный репозиторий, чтобы оставить историю чистой.

Итоги

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

• использовать git log для просмотра и анализа,
• изменять последний коммит через -amend,
• объединять коммиты для чистоты истории.

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