Что такое коммит (commit) в системе контроля версий Git?

Давай разжую тебе эту тему про коммиты, как будто я объясняю своему коту, который только что перезаписал историю ветки main своими лапами. Сидит, блядь, довольный, а в репе — пиздец.

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

Из чего эта фотка состоит, ёпта?

1. Уникальный ID (SHA-1 хеш). Это типа a1b2c3d.... Это как отпечаток пальца коммита. Генерируется из всего, что внутри: файлов, автора, даты, сообщения. Попробуй изменить хоть запятую в описании — хеш поменяется, и это будет уже другой коммит. Хуй с горы, магия криптографии, короче.
2. Снимок файлов (tree). Не дельта, не «что изменилось», а вся структура папок и файлов целиком на тот момент. Git хранит это умно, но для тебя это выглядит как полный слепок.
3. Ссылка на родителя. Коммит знает, от какого коммита он произошёл. Так и строится цепочка — история. Если родителей два, это слияние (merge), если ни одного — первый коммит, начало всех начал.
4. Метаданные. Кто автор, кто закоммитил (это может быть разный человек, если ты делаешь cherry-pick), дата и, внимание, сообщение коммита. Вот на этом пункте большинство и обосрывается.

Как это обычно происходит, на живом примере:

# 1. Ты что-то накодил, надеясь, что сработает.
# 2. Ты смотришь на это и думаешь: "Ну, вроде ничего не сломал". Добавляешь файлы в staging (индекс).
git add script.py config.yaml

# 3. Ты создаёшь коммит. И вот тут начинается пиздец.
git commit -m "fix"
# Или, что ещё хуже: "asdasd", "update", "123", "ёбта, работает же".

А теперь слушай сюда, манда с ушами, почему так делать — пиздопроебибна:

• Атомарность, блядь! Один коммит — одна логическая фича или фикс. Не надо впихивать в один коммит «пофиксил баг, добавил новую кнопку и поудалял старые логи». Это же читать потом невозможно! git log превращается в помойку. Делай маленькие, осмысленные коммиты. Это как упаковывать вещи в коробки: «Посуда», «Книги», а не «Всё, что валялось в прихожей и на балконе».
• Сообщения, ёпта! Сообщение коммита — это не для тебя, а для того бедолаги (включая тебя же через полгода), который будет это читать. Что ты сделал и зачем? Используй хуевые таски в трекере или соглашения вроде Conventional Commits (feat:, fix:, docs:). git commit -m "feat(auth): добавить OAuth2 через Google" — вот это я понимаю. Сразу видно, что и где искать.
• Управление этой самой историей:
  • git commit --amend — твоя палочка-выручалочка, когда ты только что закоммитил и тут же вспомнил, что забыл добавить файл или опечатался в сообщении. Но! Не делай этого с коммитами, которые уже ушли на удалённый репозиторий, если не хочешь, чтобы тебе коллеги впендюрили вилкой в глаз.
  • git revert <хэш> — культурный способ сказать «ой, нахуй». Он создаёт новый коммит, который отменяет изменения старого. История остаётся целой, все довольны.
  • git reset — это уже тяжёлая артиллерия. Он двигает указатель ветки. Можешь похерить историю так, что не соберёшь. Используй с умом, а лучше — когда ты один в репозитории и тебя никто не видит.

Вот и вся магия. Коммиты — это кирпичики, из которых строится вся история твоего проекта. Можно сложить ровную, красивую стену, по которой потом приятно гулять взглядом (git log --oneline --graph --all), а можно набросать кучу говна, в которой через месяц сам ни хуя не разберёшься. Выбор за тобой, чувак.