Финальный проект: провести изменение через весь цикл

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

Вы прошли локальные снимки, ветки, обмен, отмену и поиск поломки. Теперь соберите маленький проект и проведите изменение так, чтобы другой человек мог понять его без вашей памяти. Обязательная практика целиком локальна: bare-репозиторий и два клона изображают автора и проверяющего. Настоящий GitHub PR остаётся дополнительным опытом, не условием завершения.

Проект — текстовый договор сервиса фоновых заданий. settings.txt содержит queue и workers, README объясняет эти значения и остановку, а внешний shell-скрипт проверяет согласованность файлов. Задача Git здесь — сохранять согласованные версии и передавать их между рабочими местами. Он не проверяет реальный сервер и не доказывает пригодность конфигурации под нагрузкой.

Подготовьте исходное состояние

lab=$(mktemp -d "${TMPDIR:-/tmp}/git-14.XXXXXX")
git init --bare -b main "$lab/shared.git"
git init -b main "$lab/author"
cd "$lab/author"
git config user.name "Учебный автор"
git config user.email "author@example.invalid"
git config commit.gpgsign false
printf 'queue=16\nworkers=2\n' > settings.txt
printf 'Queue capacity: 16\nWorkers: 2\nShutdown drains accepted jobs\n' > README.txt
printf '*.log\n/build/\n.env\n' > .gitignore
git add settings.txt README.txt .gitignore
git commit -m "Describe initial service contract"
git remote add origin "$lab/shared.git"
git push -u origin main
git clone "$lab/shared.git" "$lab/reviewer"
cat > "$lab/check-project.sh" <<'SH'
#!/bin/sh
set -eu
queue=$(sed -n 's/^queue=//p' settings.txt)
workers=$(sed -n 's/^workers=//p' settings.txt)
test -n "$queue"
test -n "$workers"
grep -qx "Queue capacity: $queue" README.txt
grep -qx "Workers: $workers" README.txt
grep -qx 'Shutdown drains accepted jobs' README.txt
SH
sh "$lab/check-project.sh"

Проверка должна завершиться с кодом ноль. Скрипт расположен в общей временной папке, а не в истории author: можно проверять разные снимки одним и тем же критерием. Он сравнивает выбранные строки, но не запрещает любые лишние сведения и не оценивает разумность лимитов. Если хотите более строгий договор, явно добавьте проверки, а не приписывайте их текущему скрипту.

Проведите предложение через ревью

Создайте свою ветку изменения queue с шестнадцати на двадцать четыре. Обновите settings и README согласованно, разделите подготовку от локальных заметок. Опубликуйте ветку в shared, напишите записку с причиной изменения и командой проверки. В reviewer настройте локального автора, получите предложение через fetch и прочитайте diff относительно общей базы.

Намеренно оставьте в первой версии одно несоответствие, чтобы проверяющий составил конкретный комментарий. Исправьте его новым коммитом и повторите проверку после получения обновления. Только затем объедините ветку в main и отправьте результат. Сохраните записку вне tracked-проекта, чтобы оценка не смешивалась с требованиями сервиса.

Переживите независимое изменение

До интеграции пусть reviewer создаст в main собственную правку workers, а author — свою формулировку той же строки. Опубликуйте одну сторону. На другой получите ожидаемый отказ push и затем сделайте fetch. Покажите расходящийся graph; ff-only не должен скрыть наличие двух линий.

Объедините через merge, разрешите конфликт по заданному договору: итоговое workers равно трём, README сообщает то же. Не выбирайте сторону только по имени ours или theirs. Прогоните check-project, создайте завершённое слияние и опубликуйте. Другой клон должен получить обе согласованные правки обычным обменом без принудительного переписывания.

Исправьте опубликованную ошибку и найдите регрессию

После готового main создайте отдельный простой коммит, который ошибочно меняет queue только в settings. Опубликуйте его. Проверка должна упасть: это демонстрация настоящей связи теста и требования. Отмените эту запись через revert, опубликуйте исправление и подтвердите, что обе записи остались в общей истории.

В отдельной локальной ветке создайте ещё несколько нейтральных коммитов и одну такую же регрессию. Не исправляйте её до вершины диапазона. С помощью bisect и внешнего check-project найдите первую плохую запись, сравните с контрольным хешем и выйдите из поиска. Здесь нет необходимости публиковать заведомо сломанную учебную ветку.

Проверка другим человеком

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

Если проходите один, закройте терминал и повторите после перерыва. Сравните воспроизведённые отношения коммитов и содержимое, а не буквальное совпадение новых хешей. Объясните одно ограничение проверки и одну причину выбранной интеграции. Финальный отчёт нужен для передачи знания: другой человек должен понять, какой факт вы доказали и где ему ещё потребуется собственный сценарий.

Самостоятельная лаборатория

На проект выделите 2–4 подхода по 45–60 минут. Сценарии выше задают требования, но команды интеграции вы выбираете сами по пройденным урокам. Сохраните отчёт: исходная база, предложение, замечание, исправление, конфликт, принятое решение, revert и результат bisect. Для каждого шага покажите небольшой вывод, который доказывает именно заявленное свойство.

Критерии готовности

Готовый результат имеет одинаковый main в двух клонах и bare. Settings и README согласованы, рабочие деревья чисты, локальные журналы и фиктивный config не отслеживаются. История сохраняет опубликованную ошибку и её отмену. Найденная регрессия подтверждается тестом и diff. Ни настоящих секретов, ни force push в выполнении нет.

Разбор и новое условие

Слияние доказывает объединение линий, а проверка — конкретную согласованность строк. Revert доказывает видимое исправление общей истории. Bisect указывает границу выбранного сбоя. Эти доказательства дополняют друг друга: красивый graph без проверки текста не завершает проект.

Теперь новое условие без готового решения: автору нужно перенести только исправление инструкции в поддерживаемую ветку старой версии, не включая новый размер очереди. Сформулируйте критерии, выберите действие, проверьте зависимости коммита и покажите, что лимит старой версии сохранён. Объясните, почему перенос одной правки не равен слиянию всей ветки.

Первичные источники для защиты решения: merge, revert, bisect, cherry-pick. Вы закончили курс, когда можете воспроизвести проект и объяснить изменение ссылок и содержимого, а не когда только прочитали все страницы.