Экспресс-курс · No. 17

Git записывает каждую версию твоего проекта и позволяет целой команде менять одни файлы, не затирая друг друга. Почти весь страх вокруг него идёт от незнакомых слов — commit, branch, rebase, — а не от реальной сложности. Выучи горстку терминов, и Git из источника ужаса превратится в самую спокойную страховочную сеть, что у тебя будет.

21 понятие · схема у каждого · шпаргалка в конце

§ 01

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

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

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

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

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

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

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

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

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

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

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

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

ConceptVersion Control· контроль версий, VCS

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

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

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

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

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

ToolGit· система контроля версий, снимки

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

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

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

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

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

ConceptRepository· репозиторий, репо

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

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

§ 02

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

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

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

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

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

ConceptCommit· коммит, снимок

Что это: Один сохранённый снимок проекта с 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 может быть чистой: ты решаешь, что содержит каждый снимок, вместо того чтобы свалить все изменения разом.

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

ConceptStaging 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 в читаемый лог. Пиши их для того, кто прочтёт через полгода, — обычно для себя.

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

PracticeCommit Message· сообщение коммита

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

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

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

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

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

TermHEAD· указатель «ты здесь»

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

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

§ 03

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

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

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

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

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

ConceptBranch· ветка

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

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

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

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

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

Termmain· главная ветка, раньше master

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

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

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

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

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

ToolSwitch / Checkout· переключение ветки

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

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

§ 04

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

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

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

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

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

ConceptMerge· слияние

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

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

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

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

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

TermMerge Conflict· конфликт слияния

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

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

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

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

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

PracticeConflict Resolution· разрешение конфликта

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

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

§ 05

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

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

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

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

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

ConceptLocal / 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 скачивает новое, не сливая пока, чтобы ты сперва посмотрел. Освой эти четыре — и сможешь сотрудничать: это вся лексика того, как держаться в синхроне.

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

ToolClone / 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.

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

PracticePull 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 это где команда ревьюит до слияния.

§ 06

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

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

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

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

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

ToolLog· история коммитов, git log

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

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

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

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

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

ToolRevert 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, чтобы объединить общую.

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

ToolRebase· перебазирование

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

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

§ 07

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

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

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

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

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

PracticeSmall 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.

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

PracticeFeature 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.

Главные связи между понятиями курса: от правки до 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 / Remoteorigin: Твоя полная копия и общая копия на сервере.
Clone / Push / Pull / Fetchсинхронизация: Первая копия · отправить своё · забрать и слить · только скачать.
Pull RequestPR, ревью: Предложение слить ветку в main после ревью.

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

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

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

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