Фундамент

Финал Фундамента: всё вместе

Прочитано0%

Квизы0/6

Уровень 1 · Новичок

Зачем это нужно

Восемь глав трека выглядели как восемь отдельных предметов: английский отдельно, терминал отдельно, git отдельно, слепая печать вообще где-то сбоку. В реальной работе они никогда не встречаются по отдельности. Одна обычная задача — «почини вот это» — за сорок минут задействует все пять навыков подряд, и слабое место в любом из них съедает время у всех остальных.

Эта глава — не повторение пройденного и не список формул. Это один рабочий день, разобранный по шагам: тебе прилетела задача на английском, ты её прочитал, разобрал непонятное сообщение об ошибке, настроил доступ к репозиторию, нашёл нужный файл среди сотен, починил, закоммитил, отправил и оформил pull request. Ни одной новой команды здесь почти нет — новое только одно: как эти команды складываются в цепочку и где в этой цепочке обычно теряются минуты.

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

• Зачем это нужно
• Шаг 1. Тебе дали задачу текстом на английском
• Шаг 2. Незнакомая ошибка: источник, виновник, суть
• Шаг 3. Готовим машину: SSH-ключ и config
• Шаг 4. Терминал: клонировать, дойти, найти, проверить права
• Шаг 5. Git: ветка, атомарные коммиты, push, pull request
• Шаг 6. Всё то же самое — без мыши
• Чек-лист выпускника Фундамента
• Что дальше: три открытых направления
• На чемпионате: где эти минуты возвращаются
• Углубиться
• Куда дальше: проверенные ресурсы

Один рабочий день от issue до pull request: где в цепочке работает английский, где терминал, где git и где клавиатура. Ни один навык не используется в одиночку.

Шаг 1. Тебе дали задачу текстом на английском

Задача приходит не голосом и не в виде объяснения от преподавателя. Она приходит текстом — как issue в репозитории. Вот реальный формат: короткий заголовок, тело задачи, метки.

Title: Login button does nothing on slow connections

Steps to reproduce:
1. Throttle network to "Slow 3G" in DevTools
2. Open /login, fill in valid credentials
3. Click "Sign in" once

Expected: request is sent, spinner is shown until response arrives
Actual: nothing happens, no request in the Network tab

Notes: cannot reproduce on a fast connection. Probably a race
condition — the handler is attached after the first click.

Labels: bug, priority: high, good first issue

Первое, что нужно понять: это не текст «для чтения со словарём». У issue жёсткая структура, и её знание половину работы делает за тебя. Разберём по частям — ровно так же, как в главе про IT-английский мы разбирали сообщения об ошибках.

Часть issue	Что значит буквально	Что от тебя требуется
Title	Заголовок	Одна строка: что сломано. Читаешь первой, чтобы решить, твоя ли это задача вообще
Steps to reproduce	Шаги воспроизведения	Инструкция, как увидеть баг своими глазами. Пока не воспроизвёл — чинить нечего
Expected	Ожидалось	Как должно быть. Это и есть определение слова «починил»
Actual	Фактически	Как есть сейчас. Разница между Expected и Actual — вся задача целиком
Notes	Примечания	Догадки автора. Полезны, но это гипотеза, а не факт
Labels	Метки	bug — поломка, feature — новая возможность, good first issue — задача для новичка, priority: high — срочно

⚠️Важно

Самая частая ошибка новичка на этом шаге — начать чинить, не воспроизведя баг. Если ты не увидел поломку своими глазами, ты не сможешь доказать, что починил её: единственный признак успеха — что шаги из Steps to reproduce больше не приводят к Actual. Воспроизведение — это не бюрократия, а точка отсчёта.

Слова, которые в issue встречаются постоянно и которые надо знать без словаря: expected (ожидалось), actual (фактически), to reproduce (воспроизвести), steps (шаги), crash (аварийное завершение), hang/freeze (зависание), regression (то, что раньше работало, а теперь сломалось), workaround (временный обходной путь, не исправление), edge case (крайний случай), by design (так задумано, это не баг).

Отдельно — фразы, которыми тебе отвечают в комментариях: cannot reproduce («у меня не воспроизводится», значит нужны детали окружения), needs more info («не хватает информации»), duplicate of #42 («это то же самое, что задача 42»), wontfix («чинить не будем»), LGTM — looks good to me, «по мне так нормально», стандартное одобрение при code review.

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

✨Интересный факт

Метка good first issue — не формальность, а соглашение всего open source: так помечают задачи, которые сознательно оставили новичкам. Если хочешь первый вклад в чужой проект, ищи по этой метке — она специально придумана, чтобы тебе было с чего начать.

Шаг 2. Незнакомая ошибка: источник, виновник, суть

Ты воспроизвёл баг, полез в проект — и на первом же запуске получил вот это:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

Ни одного из этих слов ты, возможно, раньше не встречал в такой комбинации. Это нормально и это не повод искать перевод целиком. Сообщения об ошибках почти всегда собраны по одной схеме, и её мы разбирали в главе про IT-английский:

источник : виновник : суть

Разложим:

• Источник — fatal. Это git, и это его уровень тревоги: fatal — работа прервана, ничего не сделано. Не путать с warning (предупреждение, работа продолжилась) и error (ошибка конкретной операции).
• Виновник — could not read Username for 'https://github.com'. Git не смог получить имя пользователя для адреса GitHub. Уже видно главное: он вообще спрашивал логин, то есть пошёл по HTTPS, а не по SSH.
• Суть — terminal prompts disabled. Запросы в терминал отключены, поэтому спросить тебя git не мог и сдался.

Три части — три разных факта, и починка следует из второй, а не из третьей. Отключённые запросы — это следствие; настоящая причина в том, что репозиторий подключён по HTTPS, хотя должен быть по SSH. Это и есть переход к следующему шагу.

Любое сообщение об ошибке распадается на три части: кто ругается, на чём споткнулся и что именно пошло не так. Чинить надо среднюю часть, а не последнюю.

Потренируемся на ещё трёх сообщениях, которые ты гарантированно увидишь в первый месяц работы.

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Источник — SSH-клиент, затем git. Виновник — Permission denied (publickey): сервер отказал в доступе, и в скобках сказано, по какому именно способу аутентификации — по публичному ключу. Суть — Could not read from remote repository: как следствие, git не смог прочитать удалённый репозиторий. Вывод: ключ либо не создан, либо не добавлен в аккаунт GitHub, либо не подхвачен агентом.

bash: ./deploy.sh: Permission denied

Источник — bash, сама оболочка. Виновник — ./deploy.sh. Суть — Permission denied: нет права на выполнение. Слова те же самые, что и в прошлом примере, а причина совершенно другая — там сетевой доступ, здесь права файла. Именно поэтому переводить целиком бесполезно: смысл задаёт источник.

error: failed to push some refs to 'github.com:pgk-champs/team-report.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Источник — git, уровень error. Виновник — failed to push some refs, не удалось отправить часть ссылок (веток). Суть — в строках hint: на сервере есть коммиты, которых нет у тебя. Git здесь даже подсказывает решение — сначала git pull, потом git push. Строки hint читают реже всего, а они самые полезные во всём выводе.

💡Совет

Гуглить сообщение об ошибке нужно правильно: копируй только постоянную часть, без своих путей, имён файлов и айдишников. Permission denied (publickey) найдётся мгновенно, а Permission denied (publickey) /Users/ivan/projects/my-super-app — не найдётся никогда, потому что такой строки нет больше ни у кого в мире.

Отвечено вопросов: 0 из 5

В issue есть блоки Expected и Actual. Что даёт их сочетание?

Почему нельзя начинать чинить баг, не воспроизведя его?

fatal: could not read Username for https://github.com: terminal prompts disabled. Где здесь настоящая причина?

Одно и то же Permission denied пришло от bash для ./deploy.sh и от ssh для git@github.com. Это одна проблема?

Что полезнее всего в выводе git при отклонённом push?

Отвечено верно: 0 из 5

Шаг 3. Готовим машину: SSH-ключ и config

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

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

ls -la ~/.ssh

total 20
drwx------  2 ivan ivan 4096 Sep  1 10:12 .
drwxr-xr-x 18 ivan ivan 4096 Sep  1 10:10 ..
-rw-------  1 ivan ivan  411 Sep  1 10:12 id_ed25519
-rw-r--r--  1 ivan ivan   98 Sep  1 10:12 id_ed25519.pub

Два файла — это одна пара: id_ed25519 — приватный ключ, id_ed25519.pub — публичный. Обрати внимание на права в левой колонке: у приватного -rw-------, то есть читать может только владелец. Это не рекомендация — SSH откажется работать с приватным ключом, доступным кому-то ещё.

Если папка пуста, ключ создаётся одной командой:

ssh-keygen -t ed25519 -C "ivanov@example.com"

Нажми на часть выражения

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

cat ~/.ssh/id_ed25519.pub

Теперь ~/.ssh/config — файл, про который знают далеко не все и который экономит время каждый день. В нём описываются подключения по короткому имени:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Строка IdentitiesOnly yes — самая полезная. Без неё SSH-агент предлагает серверу все ключи подряд, и если их несколько, GitHub может отклонить попытку раньше, чем очередь дойдёт до нужного. С ней используется ровно тот ключ, который указан.

Проверка — команда, которую стоит выучить наизусть:

ssh -T git@github.com

Hi ivanov! You've successfully authenticated, but GitHub does not
provide shell access.

Читаем по частям: «Привет, ivanov» — сервер узнал тебя по ключу, аутентификация прошла. «GitHub не предоставляет доступ к оболочке» — это не ошибка, а обычное поведение: на GitHub нельзя зайти в консоль, ключ нужен только для git. Флаг -T как раз и означает «не запрашивать терминал».

Путь ключа: ssh-keygen создаёт пару, публичная половина уезжает в аккаунт GitHub, приватная остаётся на диске — и дальше clone и push проходят без единого пароля.

⚠️Важно

Приватный ключ не покидает твою машину никогда: ни в чат, ни в репозиторий, ни на флешку «чтобы работало и на втором ноутбуке». На второй машине генерируется отдельный ключ и добавляется в аккаунт вторым — GitHub разрешает сколько угодно ключей. Если приватный ключ всё-таки где-то засветился, единственное правильное действие — удалить его из аккаунта и сделать новый.

Отвечено вопросов: 0 из 5

Какой из двух файлов пары загружается в настройки аккаунта GitHub?

Что означает ответ «Hi ivanov! You have successfully authenticated, but GitHub does not provide shell access»?

Зачем в ~/.ssh/config нужна строка IdentitiesOnly yes?

ls -la ~/.ssh показывает у приватного ключа права -rw-r--r--. Что будет?

Нужен доступ с двух компьютеров. Как правильно?

Отвечено верно: 0 из 5

Шаг 4. Терминал: клонировать, дойти, найти, проверить права

Доступ есть — забираем код. Адрес берётся на странице репозитория, вкладка SSH, а не HTTPS.

git clone git@github.com:pgk-champs/team-report.git
cd team-report

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

Сначала осмотрись. Что вообще за проект и что в корне:

ls -la

Потом ищи по содержимому. Из issue известно название кнопки — «Sign in». Ищем эту строку по всему проекту:

grep -rn "Sign in" src/

src/pages/Login.jsx:42:      <button id="signin-btn">Sign in</button>
src/i18n/en.json:17:  "auth.signin": "Sign in",

Разбор флагов: -r — recursive, рекурсивно по подпапкам; -n — number, показывать номера строк. Формат вывода один и тот же везде: файл:строка:содержимое. Две находки — и уже понятно, что верстка кнопки в src/pages/Login.jsx, строка 42.

Ищи по именам файлов, когда знаешь не текст, а название:

find . -name "*.test.js" -not -path "./node_modules/*"

-name — шаблон имени, -not -path — исключить путь. Без исключения node_modules вывод утонет в тысячах чужих файлов — это первое, чему учит find на практике.

Проверь права, когда что-то не запускается. В issue упоминался скрипт проверки:

ls -l scripts/check.sh

-rw-r--r-- 1 ivan ivan 812 Sep  2 14:03 scripts/check.sh

Первый символ - — обычный файл (d был бы каталогом). Дальше три тройки: владелец rw-, группа r--, остальные r--. Ни в одной нет x — файл нельзя выполнить, отсюда и bash: ./scripts/check.sh: Permission denied. Лечится одной командой:

chmod +x scripts/check.sh

✨Интересный факт

Права в git тоже хранятся — но только один бит, «исполняемый или нет». Поэтому chmod +x для файла в репозитории — это изменение, которое надо закоммитить: иначе у коллеги скрипт снова не запустится. В git status это выглядит как изменение файла, хотя содержимое не поменялось ни на байт.

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

pwd

Отвечено вопросов: 0 из 5

Нужно найти, в каком файле проекта встречается текст «Sign in». Какая команда?

Что означает вывод grep вида src/pages/Login.jsx:42: перед строкой?

Почему в find почти всегда добавляют -not -path "./node_modules/*" или аналог?

ls -l показывает -rw-r--r-- у скрипта, и он не запускается. В чём дело?

Ты сделал chmod +x на файл в репозитории. Нужно ли что-то коммитить?

Отвечено верно: 0 из 5

Шаг 5. Git: ветка, атомарные коммиты, push, pull request

Файл найден, причина понятна, чинить — минут пять. Но коммитить прямо в main нельзя: в командной работе main — это то, что работает всегда. Всё остальное живёт в ветках.

git switch -c fix/login-button-race

Имя ветки — не творчество, а соглашение. Рабочий шаблон: <тип>/<что-делаем>, где тип — fix, feat, docs, refactor. Ветка fix/login-button-race понятна любому в команде без единого вопроса; ветка новая или test2 — никому, включая тебя через неделю.

Дальше — самое недооценённое умение всей главы: атомарный коммит. Один коммит = одно законченное изменение, которое можно описать одной строкой без слова «и».

Плохо:

исправления

Тоже плохо (два изменения в одном):

починил кнопку логина и заодно поправил отступы в футере

Хорошо — два отдельных коммита:

fix: вешать обработчик клика до первого рендера формы входа
style: выровнять отступы в футере

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

Проверяем, что попадёт в коммит, и добавляем осознанно:

git status
git add src/pages/Login.jsx
git commit -m "fix: вешать обработчик клика до первого рендера формы входа"

💡Совет

Не привыкай к git add . вслепую. Эта команда добавляет всё подряд, включая случайно созданные файлы, отладочный мусор и — рано или поздно — файл с паролем. Явное перечисление файлов занимает на пять секунд дольше и снимает целый класс проблем.

Отправляем ветку на сервер:

git push -u origin fix/login-button-race

remote: Create a pull request for 'fix/login-button-race' on GitHub by visiting:
remote:      https://github.com/pgk-champs/team-report/pull/new/fix/login-button-race
branch 'fix/login-button-race' set up to track 'origin/fix/login-button-race'.

Флаг -u связывает локальную ветку с одноимённой веткой на сервере — после него достаточно писать просто git push. Сервер тут же в ответ печатает готовую ссылку на создание pull request: это не реклама, а самый быстрый путь к следующему шагу.

Pull request — предложение влить твою ветку в main. В нём важно ровно три вещи:

1. Заголовок — что сделано, одной строкой.
2. Ссылка на задачу. Строка Closes #128 в описании закроет issue номер 128 автоматически, когда PR вольют.
3. Как проверить — те же шаги, что были в Steps to reproduce, только теперь они должны давать Expected.

Пример описания целиком:

Closes #128

Обработчик клика вешался в useEffect после первого рендера,
поэтому на медленной сети первый клик уходил в пустоту.
Перенёс привязку в разметку — обработчик существует с первого кадра.

Как проверить:
1. DevTools → Network → Slow 3G
2. /login, ввести валидные данные, один клик по «Sign in»
3. В Network появляется запрос, показывается спиннер

Заметь, что описание — это ответ на issue тем же языком и той же структурой, что был в задаче. Круг замкнулся: английский на входе, английский в ссылке на задачу, понятный русский там, где команда говорит по-русски.

Отвечено вопросов: 0 из 5

Что такое атомарный коммит?

Зачем работать в отдельной ветке, а не коммитить в main?

Что делает флаг -u в git push -u origin my-branch?

Что даёт строка Closes #128 в описании pull request?

Почему git add . считается плохой привычкой?

Отвечено верно: 0 из 5

Шаг 6. Всё то же самое — без мыши

Пересчитай, сколько раз в предыдущих шагах ты трогал мышь. Правильный ответ: один — когда открывал pull request в браузере. Всё остальное делается с клавиатуры, и это не поза, а арифметика.

Ctrl + R — поиск по истории команд. Самая недооценённая клавиша в терминале. Нажимаешь, начинаешь печатать любой кусок команды — оболочка находит последнюю подходящую из истории:

(reverse-i-search)`push': git push -u origin fix/login-button-race

Повторное нажатие Ctrl + R листает более старые совпадения, Enter выполняет, → — вставляет команду в строку для правки. Длинная команда, которую ты набирал час назад, достаётся за три нажатия вместо тридцати.

Ctrl + A и Ctrl + E — в начало и в конец строки. Ты набрал длинную команду и понял, что забыл sudo в начале. Не надо давить стрелку влево сорок раз: Ctrl + A — курсор в начало, дописал, Ctrl + E — обратно в конец.

Ctrl + C — прервать текущую команду. Программа зависла, git log открылся на весь экран, скрипт печатает бесконечный лог — Ctrl + C возвращает управление. Важное уточнение, на котором спотыкаются все: в терминале Linux и macOS Ctrl + C — это не копирование. Копирование — Ctrl + Shift + C, вставка — Ctrl + Shift + V.

Остальной прожиточный минимум:

Сочетание	Что делает	Когда экономит время
Tab	Дополнить имя файла или команды	Каждая вторая команда: длинные пути не набирают руками
Ctrl + U	Стереть строку до курсора	Опечатался в начале длинной команды — проще стереть всё и набрать заново
Ctrl + W	Стереть слово перед курсором	Ошибся в последнем аргументе
Ctrl + L	Очистить экран	Вывод захламлён, нужен чистый лист
Ctrl + D	Конец ввода / выход из оболочки	Быстрее, чем печатать exit
↑ / ↓	Предыдущая и следующая команда	Повторить только что выполненное

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

Теперь про печать. Слепая печать — не отдельное умение «печатать быстро», а множитель ко всем остальным навыкам. Посчитаем на нашем же дне. Ты набрал за него примерно: команды в терминале, сообщения коммитов, описание pull request, пару комментариев в задаче — суммарно порядка полутора тысяч знаков. На скорости 120 знаков в минуту это около 13 минут чистого набора, на скорости 300 — около 5. Разница за один день — восемь минут, за учебный год — десятки часов.

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

⚠️Важно

Проверить себя честно можно за минуту: набери вслепую строку git switch -c fix/login-button-race и не подглядывай на клавиатуру, когда доходишь до дефиса и слеша. Именно спецсимволы — а не буквы — обычно проваливаются у тех, кто «в целом умеет печатать». В коде их больше, чем в обычном тексте, поэтому тренировать нужно именно их.

Отвечено вопросов: 0 из 5

Что делает Ctrl + R в терминале?

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

Скрипт печатает бесконечный лог и не отдаёт управление. Что нажать?

Ты выделил текст в терминале Linux и нажал Ctrl + C, чтобы скопировать. Что произойдёт?

Почему слепую печать называют множителем, а не отдельным навыком?

Отвечено верно: 0 из 5

Чек-лист выпускника Фундамента

Честный список: то, что ты должен уметь без подсказок, без поиска в интернете и без этой страницы перед глазами. Не «слышал» и не «когда-то делал» — а сесть и сделать прямо сейчас.

Английский

• Прочитать issue на английском и назвать по нему: что сломано, как воспроизвести, как выглядит результат «починил».
• Разобрать незнакомое сообщение об ошибке на источник, виновника и суть, не переводя его целиком.
• Отличить warning от error и от fatal и понимать, что после каждого из них произошло с работой программы.
• Правильно составить поисковый запрос по ошибке: постоянная часть без своих путей и имён.

Терминал и система

• Сориентироваться в незнакомой папке: pwd, ls -la, cd без осмотра через файловый менеджер.
• Найти файл по содержимому через grep -rn и по имени через find, исключив папки зависимостей.
• Прочитать строку прав из ls -l и понять, почему файл не запускается; починить через chmod +x.
• Понимать разницу между относительным и абсолютным путём и между ~, . и ...

SSH

• Проверить, есть ли уже ключ, и создать новый через ssh-keygen -t ed25519.
• Объяснить, какой файл пары публичный, какой приватный, и что из них уходит на GitHub.
• Проверить подключение через ssh -T git@github.com и понять ответ.
• Не отдавать приватный ключ никому и никогда, включая себя на второй машине.

Git

• Клонировать репозиторий по SSH, создать ветку с осмысленным именем.
• Сделать атомарный коммит с сообщением, которое объясняет что и зачем, а не «правки».
• Отправить ветку через git push -u, открыть pull request со ссылкой на задачу и шагами проверки.
• Прочитать отказ push-а, понять из hint, что на сервере есть чужие коммиты, и забрать их перед повторной отправкой.

Клавиатура

• Печатать вслепую, включая спецсимволы: -, _, /, ., кавычки, скобки.
• Пользоваться Tab, Ctrl + R, Ctrl + A, Ctrl + E, Ctrl + C не задумываясь.
• Выполнить весь путь от клонирования до push, ни разу не взяв мышь.

💡Совет

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

Что дальше: три открытых направления

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

Мобильная разработка — Android, Kotlin, интерфейсы, работа с данными на устройстве. Самый прямой путь к компетенции «Мобильная разработка» на чемпионате. Всё, что ты изучил, здесь работает с первого дня: проект живёт в git, зависимости ставятся из терминала, сообщения об ошибках сборки читаются ровно по той же схеме источник—виновник—суть, только источником становится Gradle.

Блокчейн и смарт-контракты — как устроены распределённые реестры, откуда берётся неизменяемость истории и как пишутся контракты. Тут особенно приятно, что за спиной есть git: понятие «цепочка, где каждый блок ссылается на предыдущий по хешу» после git log перестаёт быть абстракцией — это ровно та же идея, только у git она про твои коммиты.

Отдельные темы — то, что не складывается в линейный трек, но нужно всем: анатомия взрослого репозитория, code review, CI, оформление проекта. Ближайшая глава, которую логично прочитать сразу после Фундамента, — про то, что должно лежать в корне репозитория и почему.

✨Интересный факт

Навыки Фундамента не устаревают вместе с технологиями. Языки и фреймворки меняются каждые несколько лет, а git, SSH, терминал и умение читать английскую документацию работают одинаково и в мобильной разработке, и в бэкенде, и в системном администрировании. Это редкий случай, когда вложенное время не обесценивается.

На чемпионате: где эти минуты возвращаются

На площадке ситуация другая, чем в учебной обстановке: время жёстко ограничено, задание выдаётся текстом, интернет обычно урезан или закрыт, а спросить нельзя. Здесь Фундамент перестаёт быть теорией и превращается в разницу между «успел» и «не успел».

Первые пятнадцать минут. Пока одни читают задание со словарём, ты уже понял структуру: что требуется, как это будут проверять, что считается выполненным. Задания чемпионата написаны тем же языком, что и issue, — с разделами «требуется», «критерии оценки», «ожидаемый результат».

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

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

Сдача работы. Не отправленный на сервер код на чемпионате не существует. Ветка, коммит, push — это буквально акт сдачи, и делать его надо не в последнюю минуту, а регулярно по ходу: каждый законченный кусок сразу уезжает на сервер. Тогда даже упавший ноутбук за пять минут до конца стоит тебе минут, а не всего модуля.

История коммитов как доказательство. Эксперт видит не только результат, но и то, как ты к нему шёл. Ровная история из осмысленных атомарных коммитов читается как отчёт о работе; один коммит «final» в конце — как принесённый откуда-то готовый результат.

Скорость набора. На модуле, где надо написать много кода за ограниченное время, разница между 120 и 300 знаками в минуту — это не «чуть быстрее», а целая задача, на которую у одного участника время осталось, а у другого нет.

Углубиться

Углубиться

Шаблоны issue в репозитории. Структура, которую мы разбирали в первом шаге, не берётся из воздуха: её задаёт файл шаблона в папке .github/ISSUE_TEMPLATE. Когда человек нажимает «New issue», ему подставляется форма с готовыми разделами. Это же объясняет, почему issue в разных проектах выглядят по-разному.

SSH-агент и пароль на ключ. Ключ можно защитить парольной фразой — тогда приватный файл бесполезен без неё, даже если утечёт. Чтобы не вводить её каждый раз, ключ один раз добавляется в агент (ssh-add), который держит его расшифрованным до конца сессии. Плата за безопасность — одна команда при старте дня.

Несколько аккаунтов на одной машине. Личный GitHub и учебный — частая ситуация. Решается через ~/.ssh/config с разными Host-псевдонимами: например, Host github-study со своим IdentityFile. Дальше адрес репозитория пишется как git@github-study:pgk-champs/repo.git, и нужный ключ подставляется автоматически.

Conventional Commits. Формат сообщений вида fix:, feat:, docs:, который мы использовали в примерах, — не наша выдумка, а распространённое соглашение с формальной спецификацией. Его плюс в том, что по таким сообщениям машина может сама собрать список изменений для релиза.

Draft pull request. PR можно открыть как черновик — работа ещё не закончена, но код уже виден команде и по нему уже гоняются автоматические проверки. Полезно, когда задача большая и хочется поймать замечания раньше, чем всё будет дописано.

Переназначение клавиш readline. Сочетания Ctrl + A, Ctrl + E, Ctrl + R — не свойство bash, а свойство библиотеки readline, которую используют десятки программ: тот же python в интерактивном режиме, psql, многие клиенты баз данных. Выучил один раз — работает везде.

Дальше по теме:

• Conventional Commits — спецификация на русском — точный формат сообщений коммитов и список типов
• Bash Reference Manual: Readline Interaction — полный набор сочетаний правки командной строки

Сводная проверка по всей главе: 12 вопросов, 5:00 на всё, без подсказок по ходу. Вопросы показываются по одному, ответ изменить нельзя. Если время выйдет — экзамен завершится с тем, что успел ответить. Пересдавать можно сколько угодно раз.

Куда дальше: проверенные ресурсы

• GitHub Docs: генерация SSH-ключа и добавление в агент — пошагово для Linux, macOS и Windows.

• GitHub Docs: проверка SSH-подключения — что именно должен ответить ssh -T git@github.com.

• GitHub Docs: ошибка Permission denied (publickey) — разбор самой частой ошибки доступа по шагам.

• ssh_config — официальная man-страница OpenSSH — полный список директив ~/.ssh/config, включая IdentityFile и IdentitiesOnly.

• git-clone — официальная документация — все формы адреса репозитория и опции клонирования.

• git-push — официальная документация — что делает -u, как ведёт себя отклонённый push и чем опасен --force.

• git-grep — официальная документация — поиск по содержимому внутри репозитория, с учётом отслеживаемых файлов.

• GitHub Docs: об issue — как устроены задачи, метки и связь issue с pull request.

• GitHub Docs: о pull request — жизненный цикл PR от создания до слияния.

• Bash Reference Manual: команды работы с историей — первоисточник про Ctrl + R и поиск по истории.

• Bash Reference Manual: Readline Interaction — полный набор сочетаний правки командной строки.

• coreutils: chmod — символьная и числовая запись прав, официальное описание.

• man find — все ключи поиска файлов по имени, типу, времени и правам.

• Conventional Commits (на русском) — соглашение о формате сообщений коммитов.

• Клавогонки — тренировка слепой печати, в том числе на режимах со спецсимволами.

• Видео и материалы сообщества — ниже — ролики по теме и ссылки от студентов и преподавателей смотри в самом низу страницы.