← КурсСамостоятельный просмотрПульт

Пара 11 / ноябрь

Git: история, объекты и управление версиями

Создать репозиторий, проверить diff и записать осмысленный атомарный commit.

Контекст

Разрыв с BitKeeper ускорил создание свободного распределённого VCS.

Создать репозиторий, проверить diff и записать осмысленный атомарный commit.

Commit — снимок и объяснение

История связывает состояние проекта с намерением изменения.

01Код
02Diff
03Commit / SHA
04Повтор запуска

Аналогия: подписанные страницы лабораторного журнала вместо папки final_final.

Три области Git

Рабочая папка, index и история — разные состояния.

01Working tree
02git add → index
03git commit → история

Аналогия: стол с черновиками, конверт на отправку и зарегистрированное письмо.

Что хранить в репозитории

Храним исходники и рецепты восстановления среды.

01Исходники / рецепты
02Игнор: среда / секреты
03Внешнее хранилище: большие артефакты

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

Git возник из требований разработки Linux

Разрыв с BitKeeper ускорил создание свободного распределённого VCS.

Почему в 2005 году появился Git1991–2002Патчи и архивы Linux2002 · BitKeeperРаспределённый VCS2005 · разрывНет бесплатного доступа2005 · GitТорвальдс и сообществоТребования Linux-разработкиБыстрые операции, локальная история, нелинейные ветви, проверка содержимого, большие проектыЭто конфликт сообщества с владельцем проприетарного инструмента, а не «Linux-команда поделилась на Git и Linux».

Git решает задачу учёта и обмена изменениями, а не резервного копирования секретов или доставки сервиса сам по себе.

Commit — узел графа снимков

Branch — имя указателя; файлы и trees хранятся как объекты.

Git хранит граф снимков: commit ссылается на tree и родителейrefs/heads/mainУказатель на commitCommit Ctree + parent + metadataTreeИмена → blobs / treesparentCommit BПредыдущий снимокBlobСодержимое файлаGit — не GitHub. У коммита merge может быть несколько родителей; одинаковое содержимое переиспользуется.

git cat-file -p HEAD показывает commit; git ls-tree HEAD — snapshot tree; git diff --staged — содержимое следующего снимка.

Наблюдение механизмов

git log --oneline --graph --all
git cat-file -p HEAD
git ls-tree HEAD
git diff
git diff --staged
Полный разбор команд в конспекте →

Команды и наблюдения

Ubuntu / Bash, lab

cd ~/devops-course/lab
git init -b main
git config user.name "Student"
git config user.email "student@example.invalid"
git status
git add app.py models/model.json Dockerfile compose.yaml README.md .gitignore
git diff --staged --stat
git commit -m "feat: add reproducible StudyPulse service"
git log --oneline -3

Разбор результата

main содержит первый commit; .venv и .env отсутствуют среди отслеживаемых файлов.

Имя и email настраиваются локально для учебного репозитория; не меняем глобальные настройки ноутбука.

На macOS

Git-команды переносимы. Первый запуск git может предложить установку Apple Command Line Tools; выполните её заранее. Сохраняйте .gitignore и проверку секретов.

git --version
git status
git diff
git diff --staged
git log --oneline -3

История исправления README

  1. Создайте репозиторий в своей копии lab и проверьте .gitignore.
  2. Измените README: добавьте диагностику неверного порта.
  3. Просмотрите diff, подготовьте только README и выполните docs: commit.
  4. Измените файл после add в отдельном опыте; покажите различие diff и diff --staged.

Что должно получиться

Два осмысленных commit и пример staged/unstaged различия.

git ls-files не содержит .venv, .env или личных данных; изменения README понятны.

Ошибка для диагностики

Студент считает git add сохранением всей последующей работы.

Симптом→Гипотеза→Проверка

Основные выводы

  1. Содержимое index, а не автоматически все текущие правки.
  2. Нет, Git — система контроля версий, GitHub — платформа вокруг репозиториев.

После пары

Оформить историю Linux-чекпоинта и передать SHA проверяемого состояния.

Конспект, команды и разбор →

История Git: две линии изменения

mainA→B→D→M
featureA↳C→merge в M

Пара 12 / ноябрь

Git в команде: ветки, review и конфликты

Объединить два изменения и разрешить конфликт по смыслу, сохранив историю.

Контекст

Ветка не создаёт отдельную полную копию проекта.

Объединить два изменения и разрешить конфликт по смыслу, сохранив историю.

Ветка — указатель на историю

Ветка не создаёт отдельную полную копию проекта.

01main: A → B
02feature: B → C
03review
04merge: D

Аналогия: отдельная линия эксперимента с точкой возврата в журнале.

Конфликт — вопрос смысла

Git не может автоматически решить противоречие в одной области.

01Изменение A
02Изменение B
03Конфликт
04Общий осмысленный результат

Аналогия: два редактора меняют одну фразу; программа не знает намерения авторов.

Возврат изменений

revert создаёт обратное изменение в истории.

01Плохой commit
02git revert
03Новый commit
04Проверка поведения

Аналогия: бухгалтерская корректировка добавляется новой записью, а не стиранием старой.

Команды и наблюдения

Ubuntu / Bash, lab

git switch -c docs/health
printf "Health endpoint: /healthz
" > route-note.txt
git add route-note.txt
git commit -m "docs: describe health endpoint"
git switch main
printf "Health endpoint: /readyz
" > route-note.txt
git add route-note.txt
git commit -m "docs: record alternate endpoint"
git merge docs/health
# Resolve route-note.txt using the actual API contract
git status

Разбор результата

add/add conflict в route-note.txt; правильное решение сохраняет реально существующий /healthz.

Этот конфликт создаётся в отдельном учебном файле, не ломая README и код сервиса.

На macOS

Ветки, конфликты и revert устроены одинаково. На APFS без различения регистра переименование только регистра имени требует осторожности; тестируйте checkout на Linux, если проект туда доставляется.

git switch -c docs/health
git status
git merge docs/health
git log --graph --oneline --all

Парное review

  1. Создайте конфликт по демонстрации в собственной копии.
  2. Сосед объясняет, какой endpoint действительно существует, используя app.py и curl.
  3. Исправьте файл, git add route-note.txt и git commit завершат merge.
  4. Сделайте отдельный неправильный docs: commit и отмените его через revert; проверьте log.

Что должно получиться

Разрешённый merge, revert и краткая запись review.

В файле нет маркеров; актуальный endpoint подтверждён; история сохранена.

Ошибка для диагностики

Выбрана красивая, но несуществующая версия URL.

Симптом→Гипотеза→Проверка

Основные выводы

  1. Нет, он требует решения неоднозначного объединения.
  2. Он сохраняет след исходного изменения и его отмены.

После пары

Составить чеклист review: назначение, тест, конфигурация, секреты и обратимость.

Конспект, команды и разбор →