# Git: кнопка сохранения с памятью

Экспресс-курс о Git и контроле версий. 21 понятие — Version Control, Repository, Commit, Staging Area, HEAD, Branch, main, Merge, Merge Conflict, Remote и origin, Clone/Push/Pull/Fetch, Pull Request, Log, Revert и Reset, Rebase и другие — у каждого английское название, образ, схема и карточка с примером. В конце — карта связей и шпаргалка на одной странице. Главная мысль: почти весь страх вокруг Git — это незнакомые слова; выучи их, и он становится спокойной страховочной сетью.

- **Author:** Фёдор Чищин
- **Level:** intro
- **Reading time:** ~30 минут чтения
- **Published:** 2026-06-13
- **Source:** https://fedorthinks.com/ru/learn/git-express

---

## 1. Зачем контроль версий

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

### Карта: 21 понятие в шести группах

> Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Сначала **основы** — что такое контроль версий, Git и репозиторий. Дальше по главе на группу: **коммит** (как сохраняется снимок), **ветки** (параллельные линии работы), **слияние** и конфликты, **удалённые репозитории** и работа в команде, **история** и безопасная отмена. Последняя глава — **хорошие привычки**, карта связей и шпаргалка.

_Diagram: Шесть групп понятий — по ним идут главы 1–6. Глава 7 — привычки, что связывают всё вместе._

### Как читать каждое понятие

> Паспорт: одинаковые поля у всех, поэтому их легко сравнивать.

У каждого понятия дальше одно и то же: **английское название** (запомни его — это термин, по нему ищут в документации и в ошибках Git), образ из жизни, **схема** и **карточка**: _что это_, _как работает_, _пример_ (часто с командой), _подвох_ и _связи_ с другими понятиями. В конце — карта связей и шпаргалка.

### Version Control — контроль версий вместо папки _final_v2_FINAL

> Стол, заваленный `report.doc`, `report_v2.doc`, `report_final.doc`, `report_final_FINAL.doc` — никто не уверен, какой текущий, а хорошая версия со вторника потеряна навсегда.

Каждый прожил ручной способ хранить версии: скопируй файл, добавь суффикс, надейся. Он разваливается мгновенно — не сказать, какой новее, не вернуть версию, что затёр, а двое редактирующих значит, что один теряет работу. **Version control** (контроль версий) — это инструмент, построенный, чтобы это прекратить: один проект, вся история хранится безопасно, и каждую версию можно восстановить.

_Diagram: Слева — куча копий, и непонятно, какая главная. Справа — один файл и полная история: любую версию можно вернуть._

#### Version Control (контроль версий, VCS)

- **Проблема:** Копии с суффиксами: непонятно, какая новее, старое не вернуть, двое затирают друг друга.
- **Идея:** Один проект + полная история изменений, где любую версию можно восстановить.
- **Пример:** Вместо `report_final_FINAL.doc` — один `report.doc` и запись каждой его версии.
- **Подвох:** Работает, только если сохранять изменения в систему, а не мимо неё.
- **Связи:** **Git** — самая популярная система контроля версий. Историю она хранит в **Repository**.

### Git — лента снимков (snapshots)

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

**Git** — это система контроля версий, что использует почти каждый. Она записывает проект как серию **снимков** (snapshots) — каждый это полная картина всех файлов в момент, что ты выбрал сохранить. Итог — лента, по которой можно путешествовать: смотреть, что изменилось, когда и кем, и вернуться к любому прошлому состоянию. Это кнопка сохранения, что не забывает ни одного сохранения.

_Diagram: Каждое сохранение — полный снимок всех файлов. Выделены те, что изменились с прошлого раза._

#### Git (система контроля версий, снимки)

- **Что это:** Самая распространённая система контроля версий.
- **Как работает:** Хранит проект как ленту **снимков** (snapshots) всех файлов в выбранные моменты.
- **Пример:** Снимок 3 добавил `style.css`; через месяц можно вернуться ровно к снимку 2.
- **Подвох:** Пугает словами, а не сложностью: термины надо просто выучить.
- **Связи:** Каждый снимок — это **Commit**; лента живёт в **Repository**.

### Repository — проект плюс вся его история

> Книга, что несёт каждый черновик, которым была, вплетённый в конец, — ты держишь текущий текст и полную запись того, как он таким стал, вместе.

**Repository** (репозиторий, или **репо**) — это папка твоего проекта, когда Git его отслеживает: текущие файлы _плюс_ вся скрытая история каждого когда-либо сделанного снимка (она лежит в скрытой папке `.git`). Клонируй репо — и получишь не только сегодняшний код, но всю историю. Это единица, в которой ты работаешь: репо — это «проект, что Git помнит», и всё остальное в курсе — это то, что ты делаешь внутри него.

_Diagram: Репозиторий = рабочие файлы, которые ты видишь, + скрытая папка .git со всеми снимками._

#### Repository (репозиторий, репо)

- **Что это:** Папка проекта под присмотром Git: файлы + вся история.
- **Как работает:** История хранится в скрытой папке `.git`; рабочие файлы — то, что ты видишь сейчас.
- **Пример:** `git init` превращает папку в репо; `git clone` копирует чужое репо целиком, с историей.
- **Подвох:** Удалишь `.git` — останутся только файлы, вся история пропадёт.
- **Связи:** Состоит из **Commits**; бывает **local** (у тебя) и **remote** (на сервере).

> **Вопрос рамки:** «Если я сделал изменение и пожалел о нём завтра, или двое из нас редактировали один файл сегодня — смог бы я восстановиться чисто? Контроль версий — это система, что делает ответ всегда „да“.»

> Контроль версий заменяет папку копий _final_FINAL одним проектом и полной, восстановимой историей. Git держит эту историю как ленту снимков.

## 2. Коммит

Самое важное слово в Git — коммит, один сохранённый снимок в ленте. Пойми, как делается коммит, — и поймёшь сердцебиение всей системы.

### Commit — один сохранённый снимок

> Фотография всего твоего проекта в выбранный миг, подшитая с запиской о том, чем был этот момент, — приколотая навсегда к ленте.

**Commit** (коммит) — это один снимок в истории проекта: записанное состояние файлов, с уникальным ID (хешем, вроде `e81f53`) и запиской. Каждый коммит указывает назад на предыдущий — своего **родителя** (parent), — образуя цепочку, что и есть твоя история. Ты коммитишь не постоянно, а в осмысленных точках — «добавил вход», «починил баг с датой», — чтобы лента читалась как последовательность намеренных шагов, каждый — место, куда можно вернуться.

_Diagram: Четыре коммита: у каждого ID и сообщение, и каждый ссылается на предыдущий. Эта цепочка и есть история._

#### Commit (коммит, снимок)

- **Что это:** Один сохранённый снимок проекта с ID, автором, временем и сообщением.
- **Как работает:** Каждый коммит ссылается на родителя; цепочка родителей = история.
- **Пример:** `git commit -m "fix date bug"` создаёт коммит `e81f53`.
- **Подвох:** Коммит сохраняет только то, что ты положил в **staging area**, а не все правки подряд.
- **Связи:** Собирается в **Staging Area**, подписывается **Commit Message**, на последний указывает **HEAD**.

### Staging Area — упакуй коробку до того, как запечатать

> Коробка для отправки на столе: ты кладёшь в неё ровно те предметы для этой посылки, оставляя другие в стороне, и лишь потом заклеиваешь и шлёшь.

Git не снимает всё, что ты изменил, автоматически. Сперва ты выбираешь, какие изменения пойдут в следующий коммит, **добавляя их в индекс** (`git add`) — в **staging area**, коробку, что ты пакуешь. Потом `git commit` запечатывает ровно эту коробку. Этот двушаг — добавь то, что вместе, потом закоммить — вот почему история Git может быть чистой: ты решаешь, что содержит каждый снимок, вместо того чтобы свалить все изменения разом.

_Diagram: Изменены три файла, но в коробку (staging area) попали только два про вход. Коммит запечатывает ровно их; notes.txt ждёт своего часа._

#### Staging Area (индекс, область подготовки)

- **Что это:** Промежуточная «коробка» между твоими правками и коммитом.
- **Как работает:** `git add` кладёт изменения в коробку, `git commit` запечатывает её в снимок.
- **Пример:** Правил `login.js`, `login.css` и `notes.txt` — добавил только первые два, закоммитил «add login».
- **Подвох:** Забыл `git add` — изменение не попадёт в коммит.
- **Связи:** Наполняется из рабочих файлов, опустошается в **Commit**. Основа **маленьких коммитов**.

### Commit Message — записка будущему

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

Каждый коммит несёт **commit message** (сообщение коммита), объясняющее, что изменилось и почему. Кажется рутиной, а позже — чистое золото: когда ты охотишься за изменением, что что-то сломало, или понимаешь, почему строка существует, сообщения — это история проекта. Хорошее сообщение («fix timezone bug in invoice export») превращает историю из стены загадочных ID в читаемый лог. Пиши их для того, кто прочтёт через полгода, — обычно для себя.

_Diagram: Слева — лог, из которого ничего не понять. Справа — лог, что читается как рассказ о проекте._

#### Commit Message (сообщение коммита)

- **Что это:** Короткая записка к коммиту: что изменилось и зачем.
- **Как работает:** Пишется при `git commit -m "…"`; потом видна в **log** у каждого снимка.
- **Пример:** Плохо: «fix», «wip». Хорошо: «fix timezone bug in invoice export».
- **Подвох:** Экономия пяти секунд сейчас = часы раскопок через полгода.
- **Связи:** Подписывает **Commit**; делает **Log** читаемым.

### HEAD — твой маркер «ты здесь»

> Точка «ты здесь» на карте ленты — она отмечает, на каком снимке ты сейчас стоишь.

**HEAD** — это указатель Git на то, где ты сейчас в истории, — обычно на последний коммит текущей ветки. Когда ты делаешь новый коммит, он добавляется сразу после HEAD, и HEAD двигается вперёд к нему. Ты редко трогаешь HEAD напрямую, но слово появляется повсюду, и знать, что это просто «моя текущая позиция в ленте», демистифицирует бо́льшую часть того, что прочтёшь.

_Diagram: HEAD указывает на ветку main, а main — на последний коммит. Следующий коммит встанет после него, и HEAD сдвинется вперёд._

#### HEAD (указатель «ты здесь»)

- **Что это:** Указатель на коммит (обычно через ветку), где ты сейчас стоишь.
- **Как работает:** Новый коммит встаёт после HEAD, и HEAD переезжает на него.
- **Пример:** `HEAD → main → c4`: ты на ветке main, на коммите c4. Сделал коммит — теперь на новом.
- **Подвох:** Слово пугает в сообщениях Git, хотя означает всего лишь «текущая позиция».
- **Связи:** Двигается с каждым **Commit**; при **Switch** переезжает на другую ветку.

> **Вопрос коммита:** «Захватывает ли этот коммит одно связное изменение, с сообщением, что сказало бы незнакомцу — или будущему мне — что он сделал и почему?»

> Коммит — это один сохранённый снимок. Ты добавляешь в индекс ровно те изменения, что вместе, потом запечатываешь их сообщением — а HEAD отмечает, где ты стоишь.

## 3. Ветки

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

### Branch — параллельная линия работы

> Ксерокопировать рукопись, чтобы черкать смелую переработку на своей копии, пока оригинал остаётся чистым и другие продолжают над ним работать.

**Branch** (ветка) — это независимая линия разработки: твоя копия ленты, где ты можешь делать коммиты, не затрагивая ничью чужую работу. Ты заводишь ветку, чтобы построить фичу или попробовать идею, свободно коммитишь на ней, а главная версия остаётся нетронутой, пока ты не готов. Ветвление — это как команда работает над десятью вещами разом в одном репо без хаоса: каждый на своей линии.

_Diagram: От main отходит ветка feature/login. Её коммиты f1–f3 живут отдельно, и main их не видит._

#### Branch (ветка)

- **Что это:** Независимая линия коммитов внутри одного репо.
- **Как работает:** Ветка — это просто подвижная метка на последнем коммите линии; новые коммиты двигают её вперёд.
- **Пример:** `git switch -c feature/login` — создать ветку под форму входа и перейти на неё.
- **Подвох:** Ветка, что живёт слишком долго, уходит от main и больно сливается.
- **Связи:** Отходит от **main**, возвращается через **Merge** или **Rebase**, обсуждается в **Pull Request**.

### main — доверенная линия

> Официальное, поставленное на полку издание книги, которому все доверяют, — черновики случаются в другом месте, и лишь законченная, одобренная работа вплетается в него.

По соглашению главная ветка зовётся **main** (в старых репо ещё встретишь **master**). Она держит стабильную, рабочую версию проекта — ту, что ты бы выпустил. Новая работа случается на других ветках и присоединяется к main, лишь когда готова и отревьюена. Относиться к main как к доверенной линии, никогда как к черновику, — простая дисциплина за большинством здоровых командных процессов.

_Diagram: main идёт прямой линией. Ветки feature/search и fix/date отходят от неё и возвращаются слиянием (M), только когда готовы._

#### main (главная ветка, раньше master)

- **Что это:** Главная ветка с рабочей версией, которую можно выпускать.
- **Как работает:** Прямо в неё не пишут; работа приходит из других веток через слияние после ревью.
- **Пример:** Ветки `feature/search` и `fix/date` вливаются в main, когда готовы.
- **Подвох:** Коммитить прямо в main — значит рисковать сломать то, чем пользуются все.
- **Связи:** Принимает работу через **Merge** и **Pull Request**; от неё отходят все **Branches**.

### Switch (checkout) — переключение веток меняет твои файлы

> Сменить, какой черновик открыт на столе, — тот же стол, но теперь показывает совершенно другую версию работы, мгновенно.

Когда ты **переключаешься** (`git switch`, раньше `git checkout`) на ветку, Git меняет файлы в твоей папке, чтобы они совпали со снимком той ветки. Перейди на ветку фичи — и твои правки появляются; переключись обратно на main — и они исчезают из виду (безопасно сохранённые, не потерянные). Ветки в Git дёшевы и мгновенны, поэтому создавать по одной на фичу или починку — норма: не тяжеловесный акт, а будничный ход.

_Diagram: Та же папка: на main в ней два файла, после git switch feature/login — изменённый app.js и новый login.js._

#### Switch / Checkout (переключение ветки)

- **Что это:** Команда, что переносит тебя на другую ветку.
- **Как работает:** Git переписывает файлы в папке под снимок выбранной ветки и переносит туда **HEAD**.
- **Пример:** `git switch feature/login` — появился `login.js`; `git switch main` — он скрылся, но цел.
- **Подвох:** Незакоммиченные правки могут помешать переключению — сначала закоммить их.
- **Связи:** Двигает **HEAD** между **Branches**.

> **Вопрос ветки:** «Делаю ли я эту работу на своей ветке, держа main чистым, — чтобы незаконченная или сломанная идея никогда не тронула доверенную версию?»

> Ветка — это параллельная линия работы, где ты свободно коммитишь, никого не беспокоя. main — доверенная версия; новая работа живёт на своей ветке, пока не готова.

## 4. Слияние и конфликты

Работа, что разошлась по веткам, рано или поздно должна сойтись обратно. Слияние — это как Git воссоединяет линии, а конфликт — тот единственный момент, когда ему нужно, чтобы решил ты.

### Merge — слияние сводит две ветки вместе

> Вложить правки из своего отдельного черновика обратно в официальную рукопись, чтобы книга теперь содержала и оригинал, и твою новую главу.

**Merge** (слияние) объединяет коммиты одной ветки в другую — обычно вкладывая законченную ветку фичи обратно в main. Git смотрит, что изменилось с каждой стороны, и сплетает их в одну ленту, что содержит оба набора работы, — часто через **merge commit**, коммит с двумя родителями. Бо́льшую часть времени это автоматически и без усилий: две ветки тронули разные файлы или разные части, и Git просто сшивает их.

_Diagram: Ветка feature (f1, f2) возвращается в main. Коммит слияния M соединяет обе линии — у него два родителя._

#### Merge (слияние)

- **Что это:** Объединение работы одной ветки с другой.
- **Как работает:** Git сравнивает изменения обеих сторон и создаёт **merge commit** с двумя родителями.
- **Пример:** `git switch main` → `git merge feature/login` — форма входа теперь в main.
- **Подвох:** Если обе стороны тронули одну строку — получится **конфликт**, и решать будешь ты.
- **Связи:** Альтернатива — **Rebase**. Может привести к **Merge Conflict**. В командах идёт через **Pull Request**.

### Merge Conflict — две правки одной строки

> Два редактора, что оба переписали ровно одно предложение по-разному, — ни одна машина не знает, что ты имел в виду, так что она останавливается и спрашивает тебя.

**Merge conflict** (конфликт слияния) случается, когда обе ветки изменили _одну часть одного файла_ несовместимо. Git не может угадать, какая версия верна, так что он ставит паузу, помечает место и показывает обе версии бок о бок. Это не ошибка и не катастрофа — это Git верно отказывается тихо выбросить чью-то работу. Конфликты пугают в первый раз ровно потому, что ставки (не потерять работу) ясны.

_Diagram: В main строка 3 стала «Hello, team!», в feature — «Hi, world!». Git не знает, что верно, и останавливается._

#### Merge Conflict (конфликт слияния)

- **Что это:** Две ветки по-разному изменили одно и то же место в файле.
- **Как работает:** Git останавливает слияние и помечает спорные строки в файле.
- **Пример:** Строка 3 в `greeting.txt`: «Hello, team!» против «Hi, world!».
- **Подвох:** Это не поломка — это Git отказывается молча выкинуть чью-то работу.
- **Связи:** Возникает при **Merge** или **Rebase**; лечится через **Conflict Resolution**; реже бывает при **коротких ветках**.

### Conflict Resolution — разрешить конфликт значит просто выбрать

> Прочитать оба переписанных предложения, потом написать финальную версию, что ты реально хочешь, — оставив одно, другое или смесь, — и идти дальше.

Ты **разрешаешь** (resolve) конфликт, отредактировав помеченный файл до версии, что хочешь, — оставь своё, оставь чужое или объедини, — убрав метки `<<<<<<<`, `=======`, `>>>>>>>`, и закоммитив результат. Вот вся тайна: конфликт — это Git, вручающий тебе решение, что может принять только человек, а разрешение — это принятие того решения. Конфликты становятся меньше и реже, когда ветки короткоживущие и ты сливаешь часто, так что две стороны никогда не уходят далеко друг от друга.

_Diagram: Слева — файл с метками конфликта: между ними обе версии. Справа — то, что выбрал человек. Потом git add и git commit._

#### Conflict Resolution (разрешение конфликта)

- **Что это:** Ручной выбор итоговой версии спорного места.
- **Как работает:** Правишь файл, убираешь метки `<<<<<<<` / `=======` / `>>>>>>>`, потом `git add` и `git commit`.
- **Пример:** Из «Hello, team!» и «Hi, world!» получилось «Hi, team!».
- **Подвох:** Чтобы выбрать верно, надо понимать обе версии — спроси автора, если не уверен.
- **Связи:** Завершает **Merge** после **Merge Conflict**.

> **Вопрос слияния:** «Когда эти ветки воссоединятся, тронули ли они одни строки — и если Git попросит меня разрешить конфликт, понимаю ли я обе версии достаточно, чтобы выбрать верно?»

> Слияние сплетает две ветки в одну ленту. Конфликт — это просто две правки одной строки: Git отказывается гадать и просит тебя выбрать.

## 5. Удалённые и команда

Пока что всё живёт на твоей машине. Работа с другими — или резервная копия твоей работы — означает соединить твой локальный репо с общим в облаке.

### Local и Remote — две копии, origin — общая

> Твоя личная рабочая копия рукописи дома и общая мастер-копия в офисе, с которой вся команда держится в синхроне.

Git **распределённый** (distributed): у тебя есть полная копия репо на машине (**local**, локальная), и обычно есть общая копия на сервере (**remote**, удалённая) — на сервисе вроде GitHub или GitLab. Ты делаешь всю работу локально — быстро, даже офлайн — и синхронизируешься с удалённым, чтобы поделиться ею и подтянуть чужую работу. Удалённый по умолчанию по соглашению зовётся **origin**. Две копии, нарочно держимые в шаге.

_Diagram: У каждого в команде полная копия репо. Общая копия origin на GitHub или GitLab держит всех в синхроне._

#### Local / Remote (локальный и удалённый репозиторий, origin)

- **Что это:** Local — твоя полная копия репо; remote — общая копия на сервере. Главный remote зовут **origin**.
- **Как работает:** Работаешь локально (даже офлайн), потом синхронизируешься с remote.
- **Пример:** Репо на GitHub — это origin; у тебя и у коллег по копии на ноутбуках.
- **Подвох:** Работа, что не запушена, живёт только на твоём ноутбуке — и пропадёт вместе с ним.
- **Связи:** Копии синхронизируют **Clone / Push / Pull / Fetch**; на remote живут **Pull Requests**.

### Clone, Push, Pull, Fetch — четыре хода синхронизации

> Ксерокопировать офисный мастер, чтобы унести домой (clone), отправить свои готовые страницы (push) и забрать новые страницы всех остальных (pull).

Четыре слова двигают работу между локальным и удалённым. **Clone** делает твою первую локальную копию удалённого репо. **Push** шлёт твои коммиты наверх на удалённый, чтобы другие их увидели. **Pull** приносит чужие новые коммиты вниз в твою копию и сливает их. **Fetch** скачивает новое, не сливая пока, чтобы ты сперва посмотрел. Освой эти четыре — и сможешь сотрудничать: это вся лексика того, как держаться в синхроне.

_Diagram: Clone — первая копия. Push — отправить своё наверх. Pull — забрать чужое и слить. Fetch — только скачать, не сливая._

#### Clone / Push / Pull / Fetch (четыре команды синхронизации)

- **Clone:** `git clone <url>` — первая полная локальная копия удалённого репо.
- **Push:** `git push` — отправить свои коммиты на remote.
- **Pull:** `git pull` — скачать чужие коммиты и сразу слить их к себе (fetch + merge).
- **Fetch:** `git fetch` — скачать новое, но пока не сливать: сначала посмотреть.
- **Подвох:** Push без pull часто отклоняется: сначала забери чужие изменения, потом отправляй своё.
- **Связи:** Двигают **Commits** между **Local** и **Remote**; pull внутри делает **Merge**.

### Pull Request — как команды ревьюят работу

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

На платформах вроде GitHub ты обычно не сливаешь прямо в main. Ты пушишь свою ветку и открываешь **pull request** (PR; в GitLab — merge request) — предложение слить твою работу, где сокомандники **ревьюят** её, оставляют комментарии и одобряют, прежде чем она присоединится к main. Это контрольная точка, где вторая пара глаз ловит проблемы, а команда соглашается, что изменение готово. PR — это где реально случается бо́льшая часть командного Git.

_Diagram: Ветку пушат, открывают PR, коллеги ревьюят. Попросили правки — чинишь и пушишь снова. Одобрили — слияние в main._

#### Pull Request (PR, merge request)

- **Что это:** Предложение слить ветку в main, с обсуждением и ревью.
- **Как работает:** Push ветки → открыть PR → комментарии и правки → одобрение → merge.
- **Пример:** PR «add login form»: коллега просит переименовать функцию, ты пушишь правку, PR одобрен.
- **Подвох:** Огромный PR никто толком не прочитает — держи их маленькими.
- **Связи:** Живёт на **Remote**, состоит из **Branch**, заканчивается **Merge** в **main**.

> **Вопрос удалённого:** «Подтянул ли я последнее перед началом, и запушена ли и предложена ли моя готовая работа — чтобы команда её видела и ничто не жило только на моём ноутбуке?»

> Локальный — твоя копия; удалённый (origin) — общая. Clone, push, pull и fetch держат их в шаге — а pull request это где команда ревьюит до слияния.

## 6. Отмена и история

Глубочайшее утешение Git в том, что почти ничто никогда по-настоящему не теряется. Знать, как читать историю и шагать назад безопасно, — вот что превращает Git из пугающего в успокаивающий.

### Log — история проекта

> Пролистывать датированную, подписанную стопку каждого черновика — видя ровно, что изменилось на каждом шаге и кто это сделал.

**Log** (лог, `git log`) — это список коммитов, история твоего проекта по порядку, каждый со своим сообщением, автором и временем. Он отвечает на «что случилось и когда?» и это отправная точка для понимания любой кодовой базы или охоты за любым багом. Когда что-то ломается, лог даёт найти точный коммит, что это ввёл, потому что каждое изменение записано. История, что можно прочесть, — это история, что можно отлаживать.

_Diagram: git log: коммиты от новых к старым, с автором, датой и сообщением. Баг с датами — ищи коммит, что менял разбор дат._

#### Log (история коммитов, git log)

- **Что это:** Список всех коммитов: ID, автор, время, сообщение.
- **Как работает:** `git log` показывает историю от новых коммитов к старым.
- **Пример:** Даты сломались 11 июня — в логе видно коммит `e81f53` «change date parsing».
- **Подвох:** Лог полезен ровно настолько, насколько хороши сообщения коммитов.
- **Связи:** Читает цепочку **Commits**; ценность даёт **Commit Message**.

### Revert vs Reset — две отмены: честная и переписывающая

> Два способа отменить ошибку: добавить ясно помеченную поправку в запись (revert) или тихо вырвать последнюю страницу, будто её и не было (reset).

Git даёт безопасные пути назад. **Revert** создаёт новый коммит, что отменяет предыдущий, — ошибка остаётся в истории, с её отменой, записанной сверху, что честно и безопасно для общей работы. **Reset** двигает тебя назад к раннему коммиту, переписывая недавнюю историю, будто тех коммитов не было, — мощно, но опасно на работе, что у других уже есть. Правило большого пальца: revert в публичном, reset только на приватной, локальной работе.

_Diagram: Сверху revert: ошибка C остаётся, а новый коммит её отменяет. Снизу reset: HEAD откатывается на B, и C исчезает из истории._

#### Revert vs Reset (отмена коммитом / откат истории)

- **Revert:** `git revert C` — новый коммит, отменяющий C. История цела.
- **Reset:** `git reset B` — перенести ветку назад на B, будто C не было.
- **Пример:** Сломал прод коммитом в main — revert. Накосячил локально, не пушил — reset.
- **Подвох:** Reset того, что коллеги уже забрали, рассинхронит всю команду.
- **Связи:** Работают с **Commits** и **HEAD**; reset, как и **Rebase**, переписывает историю.

### Rebase — переигрывает твою работу; уважай золотое правило

> Вместо того чтобы пристегнуть свой боковой черновик к рукописи видимым швом (merge), ты заново чисто переписываешь свои правки поверх последней версии, будто стартовал с неё (rebase).

**Rebase** — это альтернатива merge: вместо соединения двух линий коммитом слияния он переигрывает твои коммиты поверх другой ветки, делая опрятную, прямолинейную историю. Он хорош для прибирания собственной ветки до того, как поделиться. Но он _переписывает_ коммиты (создаёт их новые копии), так что **золотое правило**: никогда не делай rebase истории, что другие уже подтянули. Перепиши общую историю — и рассинхронишь всех. Rebase своей приватной работы; merge, чтобы объединить общую.

_Diagram: До: X и Y отходят от B. После git rebase main: их копии X′ и Y′ стоят после C — одна прямая линия, без коммита слияния._

#### Rebase (перебазирование)

- **Что это:** Переиграть свои коммиты поверх другой ветки.
- **Как работает:** Git берёт твои коммиты и заново создаёт их копии на новом основании.
- **Пример:** На `feature` выполнить `git rebase main` — твои X, Y встают после свежего C из main.
- **Подвох:** **Золотое правило**: никогда не делай rebase истории, что другие уже подтянули.
- **Связи:** Альтернатива **Merge**; может вызвать **Merge Conflict**; переписывает историю, как **Reset**.

> **Вопрос истории:** «Если это пойдёт не так, смогу ли я прочесть лог, чтобы найти где, — и отменяю ли я безопасным инструментом (revert для общей работы), никогда не переписывая историю, что у других уже есть?»

> Лог — это читаемая история; revert и reset — твои пути назад. Rebase делает опрятную историю — но никогда не переписывай историю, что другие уже подтянули.

## 7. Применять хорошо

Команд в Git много, но хорошая практика — это короткий список привычек. Следуй им, и Git остаётся спокойной страховочной сетью, а не редкой аварией.

### Small Commits — маленькие, сфокусированные коммиты

> Фотоальбом, где каждый снимок ловит один ясный момент с подписью, — куда полезнее одного смазанного кадра всего разом.

Коммить **мало и часто** (small, atomic commits), чтобы каждый коммит был одним связным изменением с сообщением, что его объясняет. Крошечные, хорошо подписанные коммиты делают историю читаемой, баги — легко прослеживаемыми, а отмены — хирургическими: можно откатить одно точное изменение, не теряя остального. Гигантский коммит, сваливающий неделю смешанной работы, — наоборот: невозможно отревьюить, распутать или частично отменить. Дисциплина стоит секунд и окупается на всю жизнь проекта.

_Diagram: Один огромный коммит за неделю против четырёх маленьких: каждый про одно дело, и любой можно отменить отдельно._

#### Small Commits (маленькие атомарные коммиты)

- **Проблема:** Гигантский коммит нельзя отревьюить, распутать или отменить по частям.
- **Идея:** Один коммит = одно связное изменение + ясное сообщение.
- **Пример:** Вместо «week of work» — «add login form», «style login page», «fix date bug».
- **Цена:** Пара секунд на `git add` нужных файлов и на сообщение.
- **Связи:** Держится на **Staging Area** и **Commit Message**; делает **Revert** и **Log** полезными.

### Feature Branch Workflow — ветка на фичу, сливаемая часто

> Каждая новая глава черновится на своей копии и вкладывается обратно, пока ещё мала, — чтобы ни один черновик не ушёл от книги так далеко, что воссоединить его станет битвой.

Делай каждый кусок работы на **своей ветке** (feature branch), держи её короткоживущей и сливай обратно часто. Долгоживущие ветки уходят далеко от main и превращают слияние в болезненную кучу конфликтов; маленькие ветки, сливаемые часто, остаются лёгкими. Сочетай это с **pull перед push** — сперва внеси чужие изменения, — чтобы интегрироваться непрерывно, а не сталкиваться в конце. Этот ритм — сердце гладкого командного Git.

_Diagram: Сверху — короткие ветки, что быстро возвращаются: конфликты крошечные. Снизу — одна долгая ветка, что ушла далеко: в конце большая куча конфликтов._

#### Feature Branch Workflow (ветка на фичу)

- **Проблема:** Все пишут в main — ломают друг друга; одна долгая ветка — гора конфликтов в конце.
- **Идея:** Одна задача — одна короткая ветка, слитая через PR за дни, а не недели.
- **Пример:** `fix/date`: pull, ветка, два коммита, push, PR, ревью, merge — всё за день.
- **Цена:** Нужно резать работу на маленькие куски и часто подтягивать main.
- **Связи:** Собирает вместе **Branch**, **Pull**, **Push**, **Pull Request** и **Merge**.

### Понятия связаны между собой

> Конвейер: от правки в файле до доверенной версии — одна дорога с понятными остановками.

Вся дорога выглядит так. Правки в **рабочих файлах** через `git add` попадают в **staging area**, через `git commit` — в **коммит**, что читается в **логе**. Коммиты складываются в **ветки**; ветки возвращаются через **merge** или **rebase**, иногда с **конфликтом**. В команде ветку **пушат** на **remote**, открывают **pull request** и после ревью сливают в **main**. Если что-то пошло не так — **revert** или **reset**.

_Diagram: Главные связи между понятиями курса: от правки до main и обратно._

#### Твои будничные привычки Git

- **Подтяни последнее** (pull) перед началом, чтобы строить на текущей работе.
- Работай на **ветке**, никогда прямо на хрупком main.
- Делай **маленькие коммиты** с **ясными сообщениями** по ходу.
- **Сливай часто**, пока ветки ещё короткие, чтобы держать конфликты крошечными.
- **Пушь** свою работу и открывай **pull request** на ревью.
- Отменяй через **revert** на общей работе; никогда не делай **rebase** истории, что у других есть.

#### Признаки, что ты используешь Git хорошо

- Твоя **история читается** как ясный рассказ из маленьких, подписанных шагов.
- Новая работа живёт на **ветках**; **main** всегда работает.
- Ты делаешь **pull перед push** и сливаешь, пока ветки ещё малы.
- Ты тянешься к **revert** на общей работе и никогда не переписываешь общую **историю**.
- Git ощущается **страховочной сетью** — ты свободно экспериментируешь, зная, что всегда вернёшься.

> Хороший Git — это несколько привычек: сперва pull, ветка под работу, маленькие коммиты с ясными сообщениями, частые слияния и ревью до слияния. Команд много; дисциплина коротка.

## Шпаргалка: все 21 понятие

### Основы

- **Version Control** (контроль версий): Один проект + полная история, любую версию можно вернуть.
- **Git** (лента снимков): Самая популярная система контроля версий; хранит проект как снимки.
- **Repository** (репозиторий, репо): Папка проекта + скрытая история в `.git`.

### Коммит

- **Commit** (коммит): Один сохранённый снимок с ID и ссылкой на родителя.
- **Staging Area** (индекс): Коробка перед коммитом: `git add` кладёт, `git commit` запечатывает.
- **Commit Message** (сообщение коммита): Записка будущему: что изменилось и зачем.
- **HEAD** («ты здесь»): Указатель на текущий коммит; едет вперёд с каждым коммитом.

### Ветки

- **Branch** (ветка): Параллельная линия коммитов, не трогающая чужую работу.
- **main** (главная ветка (master)): Доверенная, всегда рабочая версия.
- **Switch / Checkout** (переключение): Перейти на ветку: файлы в папке меняются под её снимок.

### Слияние и конфликты

- **Merge** (слияние): Свести ветки вместе; часто через коммит с двумя родителями.
- **Merge Conflict** (конфликт): Две ветки по-разному правили одну строку; Git просит решить.
- **Conflict Resolution** (разрешение): Выбрать итоговую версию, убрать метки, закоммитить.

### Удалённые и команда

- **Local / Remote** (origin): Твоя полная копия и общая копия на сервере.
- **Clone / Push / Pull / Fetch** (синхронизация): Первая копия · отправить своё · забрать и слить · только скачать.
- **Pull Request** (PR, ревью): Предложение слить ветку в main после ревью.

### Отмена и история

- **Log** (история): Список коммитов: кто, когда, что и зачем.
- **Revert vs Reset** (отмена): Revert — новый коммит-отмена (для общего). Reset — переписать (только своё).
- **Rebase** (перебазирование): Переиграть коммиты поверх другой ветки. Не трогай общую историю.

### Хорошие привычки

- **Small Commits** (маленькие коммиты): Одно изменение — один коммит с ясным сообщением.
- **Feature Branch Workflow** (ветка на фичу): Короткая ветка на задачу, сливается часто через PR.

Конец экспресс-курса · 7 глав · 21 понятие

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