Что такое pull request: словарь вайбкодинга простыми словами

Pull request (PR, «пул реквест») — просьба добавить сделанные изменения в основную версию проекта. Например, поиск для сайта уже сделали, но он пока есть только в отдельной версии проекта. Через PR работу показывают другим людям: они могут посмотреть её, попросить исправления и решить, добавлять ли её в проект. Пока PR открыт, посетители сайта обычно ничего нового не видят.

Представьте, что вы попросили ИИ добавить поиск в каталог цифровых сотрудников. Он отвечает: «Сделал ветку, коммит и pull request; CI прошёл, можно мержить и деплоить». Звучит так, будто всё готово. Но поиск может пока существовать только на компьютере, где шла работа. Эта статья поможет понять, что произошло и что ещё нужно сделать, чтобы поиск появился на сайте.

Путь изменения: вы написали промпт — просьбу к ИИ → ИИ изменил код → работу сохранили коммитом → предложили добавить её через pull request → всё проверили → изменения объединили → обновили сайт через деплой. Каждое слово по ссылке объясняется ниже.

Что такое pull request простыми словами

Pull request

Представьте общий документ, в котором хранится основной вариант сайта. Вы не переписываете его сразу, а готовите свой вариант в стороне. Затем говорите коллегам: «Посмотрите, пожалуйста, мою работу. Если всё хорошо, добавим её в основной вариант». В разработке такая просьба и место для обсуждения называются pull request, сокращённо PR. На странице PR видно, какие файлы поменялись, что ответили проверяющие и прошли ли автоматические проверки. На некоторых других платформах это называют merge request. Источник: GitHub Docs.

Пример. На сайте есть каталог без поиска. Разработчик делает отдельный вариант каталога с поиском. Этот отдельный вариант называется веткой. Затем он сохраняет работу коммитом, отправляет её на GitHub и открывает PR «Добавить поиск по каталогу». Другой человек смотрит, какие строки изменились, пробует поиск и замечает: на телефоне кнопка съехала. Разработчик исправляет кнопку. Когда всё проверено, поиск добавляют в основной вариант проекта.

Есть несколько разных действий, которые легко перепутать. Push отправляет сделанную работу на GitHub или другой сервер с кодом. Merge добавляет её в основной вариант проекта. Деплой обновляет работающий сайт. Иногда последнее происходит автоматически, иногда для него нужна отдельная команда. Поэтому после сообщения «PR закрыт» стоит открыть сайт и проверить, появился ли там поиск.

Что посмотреть в PR, даже если код написал ИИ: делает ли поиск то, о чём вы просили; какие страницы изменились вместе с ним; что проверяли; можно ли вернуть прежнюю версию, если возникнет проблема. На примере каталога: найдите одного сотрудника, введите слово без совпадений, откройте страницу на телефоне и обновите её.

А теперь отмотаем историю назад. Откуда взялась ветка с поиском? Что именно проверяли? И почему после фразы «всё готово» иногда выясняется, что на живом сайте ничего не изменилось?

Один поиск в каталоге и почти весь словарь разработки

Сцена первая: просьба, которую можно понять десятью способами

Вы открываете чат с ИИ и пишете: «Сделай поиск по цифровым сотрудникам. Чтобы было удобно». Начало хорошее, но тут есть вопросы. Искать только по имени или ещё по профессии? Что показывать, пока человек ничего не ввёл? Что делать, если никого не нашли? Должны ли старые фильтры продолжить работать? Как всё будет выглядеть на телефоне?

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

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

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

Последние предложения особенно полезны. Вы заранее перечислили, что будете проверять. Разработчики называют такие условия критериями приёмки. И вы напомнили сохранить прежний вид сайта. Бывает, что после правки одной страницы случайно меняется другая: например, поиск появился, а привычный фильтр исчез. Это регрессия — новая работа сломала старую.

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

Если вы пока выбираете сам инструмент для такой работы, начните с разбора о выборе AI-инструмента для компании. Там есть вопросы, которые помогут сравнить варианты на одной задаче.

Сцена вторая: вы нажали кнопку, и начался невидимый разговор программ

Посетитель вводит в поиске слово «аналитик». Поле поиска и карточки на экране — это фронтенд, то есть видимая часть сайта. Где взять подходящие карточки? Иногда все они уже загружены в браузер. Если же список хранится на сервере, сайт отправляет туда вопрос: «Есть сотрудники по слову „аналитик“?» Невидимая часть сайта, бэкенд, находит ответ в базе данных и отправляет его обратно. После этого посетитель видит карточки.

Такой обмен идёт по правилам, которые называют API. Это как договор между двумя частями сайта: куда послать вопрос и в каком виде придёт ответ. Конкретный адрес для одного действия называют эндпоинтом. Ответ может выглядеть как текст с чётко названными полями: «имя — Анна, профессия — менеджер». Часто для этого используют формат JSON. Необязательно разбираться во всех кавычках и скобках; важно, чтобы сайт и сервер одинаково понимали названия полей.

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

Ещё одно частое недоразумение — слово интеграция. Если в карточке написано «работает с CRM», это не значит, что вашу CRM уже подключили. Нужно настроить доступ и отправить пробную заявку: дошла ли она туда, куда нужно? Иногда для подключения нужен API-ключ — секретный набор символов, похожий по назначению на пароль. Его нельзя размещать в открытом коде сайта. Для хранения таких настроек используют, например, переменные окружения.

Сцена третья: изменения лежат у разработчика, но их ещё никто не видел

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

Перед сохранением полезно посмотреть diff — список того, какие строки добавили и удалили. Вы просили поиск, а в списке вдруг изменены цвета главной страницы? Спросите почему. Возможно, поиск использует общий элемент сайта. Возможно, ИИ поменял лишнее. Это как просмотреть исправления в документе перед тем, как принять их.

Затем работу сохраняют коммитом. Это похоже на сохранённую версию документа: к ней можно вернуться. У коммита есть короткая подпись, например «Добавить поиск по каталогу». Следующий шаг — push: отправить сохранённую работу с этого компьютера на GitHub или другой сервер с кодом. После push посетители сайта всё ещё могут видеть старую версию.

В переписке может встретиться слово remote. Оно означает адрес, куда Git отправляет сохранённую работу. Это может быть GitHub или собственный сервер. Если на сервере закончилось место, стоит выяснить, что его занимает. Папка с историей Git, весь проект и файлы Docker — разные вещи. Удаление маленькой папки Git может почти ничего не дать.

Сцена четвёртая: тот самый pull request

После push открывают PR. На его странице есть название, описание и кнопка «Merge». Но главное там — возможность спокойно посмотреть работу перед тем, как добавлять её в основной проект. Что обещали сделать? Какие файлы поменяли? Проверили ли поиск? Не сломалась ли форма заявки? Всё это лучше выяснить до публикации.

Проверяющий смотрит список изменений и может написать прямо рядом со строкой: «На телефоне кнопка перекрывает текст, исправь». Такая проверка человеком называется код-ревью. Автор исправляет проблему, и PR обновляется. Параллельно компьютер может сам запустить тесты. Эту автоматическую проверку часто называют CI. Зелёная отметка означает, что запущенные тесты прошли. Но она ничего не говорит о том, чего эти тесты не проверяли. Если среди них нет проверки телефона, съехавшую кнопку они не найдут.

Если будете принимать работу ИИ-помощника, пригодятся десять реальных сценариев для проверки. Тот же принцип работает и с поиском по каталогу: проверяйте обычный запрос, пустой результат и работу на телефоне.

Три сообщения означают три разных шага. «PR открыт» — работу предложили. «PR одобрен» — её посмотрели и согласились принять. «PR слит» — изменения добавили в основной вариант проекта. Последний шаг называют слиянием. Если два человека одновременно меняли одно и то же место, Git попросит выбрать, какую версию оставить. Это конфликт слияния. И даже после слияния работающий сайт может пока оставаться прежним.

Сцена пятая: сайт собран, но где он запущен?

После слияния новую версию сайта готовят к запуску. Это называется сборкой. В некоторых проектах её упаковывают в Docker-образ — готовый набор файлов и программ, нужных для запуска. Когда его запускают, получается контейнер. Если у сайта несколько частей, например сам сайт и база данных, Docker Compose помогает запустить их вместе.

Сайт для посетителей часто работает на VPS — арендованном компьютере, который постоянно подключён к интернету. Отправить на него новую версию и запустить её — значит сделать деплой. Работающий сайт разработчики называют продакшеном. Иногда у проекта есть ещё тестовая копия сайта. Там сначала пробуют изменения, а потом обновляют настоящий сайт.

Посетитель набирает в браузере имя сайта — домен. Система DNS подсказывает браузеру, на каком сервере искать этот сайт. HTTPS защищает данные, которые передаются между браузером и сервером. Поэтому после сообщения «сайт запущен» стоит открыть привычный адрес и убедиться, что он работает у посетителя, а не только на компьютере разработчика.

После деплоя разработчик может сказать: «Сервер ответил 200». Это значит, что открылась какая-то проверенная страница. Хорошо, но попробуйте и сам поиск. Если адреса страницы нет, сервер часто отвечает 404; если у него произошла ошибка — 500. Быстро пройти главные действия на настоящем сайте — это smoke test. Если что-то сломалось, прежнюю версию возвращают через откат. Чтобы понять причину сбоя, смотрят логи — журнал работы сайта. Ещё бывает health check: автоматическая проверка, что сайт вообще отвечает.

Сцена шестая: когда ИИ работает на самом сайте

До этого ИИ помогал нам делать сайт. Но ИИ может ещё и работать на сайте: отвечать клиентам, готовить карточки, разбирать заявки. Здесь встречаются два слова. Модель — «мозг», который получает вопрос и составляет ответ. Агент — программа, которой дали такой «мозг», инструкции и право пользоваться определёнными инструментами. Например, открыть нужный файл или подготовить черновик карточки. Так различие объясняют и официальные документы OpenAI.

Допустим, вы говорите помощнику внутри панели управления сайтом: «Добавь город». Ему надо собрать сведения, написать текст и предложить картинки. Чтобы сделать это на самом деле, ему нужны права на нужные действия: читать данные, сохранять черновик, показывать его вам. Нужно решить и кто нажмёт кнопку «Опубликовать». Если у помощника нет доступа к панели, он может только рассказать, как добавить город. Если дать ему слишком много прав без проверки, ошибка попадёт прямо на сайт. Инструменты и API определяют, что ему разрешено делать.

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

Пользоваться ИИ в чате и подключить его к своему сайту — разные задачи. Если вы хотите подключить к сайту облачную модель OpenAI, вам понадобятся доступ к API, секретный ключ и контроль расходов. Другие способы подключения устроены иначе. В документации OpenAI отдельно описано, как следить за расходами при работе через API. Одна только подписка на чат не подключает модель к вашему сайту: использование API оплачивается отдельно. Если хочется понять, что именно поручить такому помощнику, посмотрите как выбрать первый процесс для ИИ и когда бизнесу нужен ИИ-агент.

Сцена седьмая: страница существует, но найдёт ли её поиск?

Поиск в каталоге выпущен. Теперь вы публикуете статью «Что такое pull request». У неё есть адрес — URL. Нужен понятный заголовок на самой странице, а также название и короткое описание, которые поисковик может показать в результатах. Эти поля называют title и meta description. Ссылки на связанные материалы помогут читателю продолжить разбираться.

Чтобы статья появилась в поиске, поисковик должен её найти, прочитать и добавить в свой список страниц — индекс. Sitemap помогает сообщить ему адрес статьи. Canonical подсказывает, какой адрес считать главным, если у статьи их несколько. Метка noindex означает, что страницу не хотят показывать в поиске. Но даже опубликованная и открывающаяся статья не обязательно сразу попадёт в результаты, тем более на первое место.

Здесь важно понять, что человек хотел узнать, когда ввёл запрос. Это называют поисковым намерением. На вопрос «что такое pull request» сначала нужен короткий ответ, потом пример. На вопрос «как создать pull request» нужна инструкция по шагам. Если повторить нужные слова двадцать раз и так и не ответить на вопрос, статья читателю не поможет. Google Search Central советует писать прежде всего для людей.

Вся история укладывается в несколько простых вопросов. Что вы попросили? Что уже сделано? Где сейчас находится результат? Кто его проверил? Видят ли его посетители? Когда вам отвечают техническими словами, возвращайтесь к этим вопросам. Тогда будет понятнее, на каком шаге находится работа.

Быстрый указатель терминов

Ниже можно читать последовательно или искать отдельное слово через поиск по странице. Каждый термин связан с соседними понятиями; возвращайтесь к истории выше, если определение кажется слишком сухим.

• Разговор с ИИ: вайбкодинг, промпт, контекст, критерии приёмки, модель, агент, токен, RAG, инструмент, галлюцинация.
• Устройство приложения: код, фронтенд, бэкенд, API, эндпоинт, JSON, API-ключ, вебхук, база данных, миграция, резервная копия.
• Работа с версиями: Git, репозиторий, терминал, CLI, ветка, worktree, remote, diff, коммит, push, pull request, ревью, merge, конфликт слияния.
• Проверка и выпуск: тест, лог, регрессия, CI, сборка, переменные окружения, Docker-образ, контейнер, Docker Compose, деплой, продакшен, стейджинг, VPS, домен, DNS, HTTPS, health check, smoke test, откат, MVP.
• Поиск и публикация: SEO, URL, поисковое намерение, title и description, canonical, sitemap, noindex, индексация.

Как разговаривать с ИИ о задаче

Vibe coding

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

Prompt

Промпт — ваша просьба к ИИ. «Сделай сайт красивее» — тоже промпт, но каждый поймёт его по-своему. Лучше написать: «Добавь поиск, не меняй вид карточек, покажи сообщение, если ничего не найдено, и проверь телефон». Чем яснее просьба, тем легче проверить ответ. См. контекст и критерии приёмки.

Context

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

Acceptance criteria

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

AI model

ИИ-модель — часть системы, которая принимает ваш вопрос и составляет ответ: текст, код или изображение. Можно представить её как «мозг» помощника. Она не видит ваши файлы и сайт сама по себе: ей должны их показать или дать подходящий инструмент.

AI agent

ИИ-агент — помощник, который может не только написать ответ, но и сделать несколько шагов: открыть файл, внести правку, запустить проверку и показать результат. Что именно ему разрешено, зависит от настроек. Если права не дали, он может лишь подсказать, что сделать человеку. См. инструмент и API.

Token

Токен — маленький кусочек текста, которым ИИ считает написанное и прочитанное. Один токен не обязательно равен одному слову. В документах об оплате API указывают стоимость токенов: чем больше текста отправили и получили, тем выше может быть счёт. Источник: OpenAI Docs.

RAG

RAG — способ отвечать по вашим документам. Сначала программа находит нужную инструкцию, например правила возврата, затем даёт ИИ прочитать её и составить ответ клиенту. Если инструкция старая или программа нашла не тот документ, ответ может быть неверным. Источник: OpenAI Docs.

Tool

Инструмент — действие, которое разрешено ИИ-помощнику. Например, открыть файл, зайти на страницу или запустить проверку сайта. Если помощник пишет «я проверил», полезно попросить показать, что именно он открыл и какой результат получил.

Hallucination

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

Из чего состоит приложение

Code

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

Frontend

Фронтенд — то, что человек видит на сайте и чем пользуется: страницы, кнопки, карточки, формы. Поле поиска в каталоге — фронтенд. Иногда ему нужно спросить у бэкенда, какие карточки показать.

Backend

Бэкенд — невидимая для посетителя часть сайта. Она может принять запрос «найди аналитика», посмотреть список сотрудников и вернуть ответ. Там же часто решается, кому можно видеть заявки и куда их сохранять.

API

API — способ, которым одна программа просит другую что-то сделать. Представьте окно выдачи заказов: вы называете нужный заказ по правилам, а вам передают результат. Сайт может через API попросить список сотрудников, а ваш сервис — ответ от ИИ. Для подключения к API обычно нужны настройки и отдельный доступ. Источник: MDN. См. эндпоинт и API-ключ.

Endpoint

Эндпоинт — адрес для одного конкретного действия через API. Один адрес может выдавать список сотрудников, другой — принимать заявку. Посетитель сайта такие адреса обычно не видит: ими пользуются программы. Эти примеры учебные и не описывают реальные адреса «ЦифроШтата».

JSON

JSON — способ записать данные так, чтобы программы их понимали. Например: «имя: Анна; профессия: менеджер по продажам». В настоящем JSON будут кавычки и скобки, но смысл тот же: у каждого значения есть понятная подпись.

API key

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

Webhook

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

Database

База данных — место, где сайт хранит сведения: карточки сотрудников, заявки и другие записи. Если код — это инструкция, то база — заполненная картотека. При изменении этой картотеки особенно важна резервная копия.

Migration

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

Backup

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

Как Git хранит изменения

Git

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

Repository

Репозиторий, или «репо», — папка проекта вместе с историей изменений, которую ведёт Git. Такая папка может быть на компьютере разработчика, а её копия — на GitHub. Они не всегда одинаковы: после работы на своём компьютере изменения ещё нужно отправить.

Terminal

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

CLI

CLI — управление программой с помощью текстовых команд в терминале. Например, команда git status показывает, какие файлы изменились. Это та же работа с программой, только вместо меню и кнопок используются слова-команды.

Branch

Ветка — отдельный вариант проекта, в котором можно спокойно работать, не меняя основной. Например, в основной ветке сайт пока без поиска, а в ветке add-catalog-search поиск уже есть. Когда всё проверят, изменения из этой ветки добавят в основную.

Worktree

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

Remote

Remote — адрес другого компьютера или сервиса, куда Git может отправить проект. Часто этот адрес ведёт на GitHub. Имя origin, которое вы увидите в командах, — просто короткая подпись для такого адреса. Перед push полезно узнать, куда именно отправится работа.

Diff

Diff — список исправлений: что добавили, что убрали, что переписали. Он похож на режим «Исправления» в текстовом документе. Если вы просили поправить кнопку, а в diff поменялось полсайта, спросите почему. Его смотрят при проверке работы и в PR.

Commit

Коммит — точка сохранения в истории проекта. У неё есть подпись, например «Добавить поиск по каталогу». По этой подписи потом легче найти работу и при необходимости вернуться назад. Коммит сохраняет выбранные изменения там, где он сделан; после него работа ещё не обязательно отправлена на GitHub или показана посетителям. Источник: Git.

Push

Push, или «пуш», — отправка сохранённой работы со своего компьютера на GitHub или другой сервер с кодом. После этого её смогут посмотреть коллеги. Сайт для посетителей от одного push обычно не меняется.

Code review

Код-ревью — когда другой человек внимательно смотрит сделанные изменения до их добавления в основной проект. Он может заметить ошибку, лишнюю правку или непонятное место. Даже не читая код, вы можете спросить: «Что изменилось? Что проверили? Какие страницы могли пострадать?» Источник: GitHub Docs.

Merge

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

Merge conflict

Конфликт слияния — ситуация, когда два человека по-разному изменили одно и то же место, а Git не знает, какой вариант оставить. Человек смотрит оба и выбирает итоговый. Это рабочая задача, похожая на объединение двух разных правок одного абзаца.

Как проверить и выпустить результат

Test

Тест — проверка, что программа делает то, что должна. Например, после слова «аналитик» показывает аналитика, а не пустую страницу. Тест может запускаться сам или его может провести человек. Фраза «тесты прошли» полезна, если вы знаете, что именно ими проверяли.

Log

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

Regression

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

CI

CI — автоматическая проверка после изменения кода. Компьютер сам запускает то, что ему заранее поручили: например, собрать сайт и проверить поиск. Если всё прошло, рядом с PR появится зелёная отметка. Она означает только то, что прошли эти проверки; удобство сайта на телефоне они могли вообще не смотреть. Источник: GitHub Docs.

Build

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

Environment variables

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

Docker image

Docker-образ — готовый набор для запуска программы: её файлы и нужные программы для запуска. Представьте упакованный комплект, который можно перенести на сервер и там запустить. Для новой версии сайта обычно собирают новый образ. Источник: Docker Docs.

Container

Контейнер — программа, которую запустили из Docker-образа. Образ — это готовый комплект, контейнер — уже работающий сайт. База с заявками обычно хранится отдельно, чтобы данные не пропали при замене контейнера.

Docker Compose

Docker Compose — способ запустить несколько нужных программ вместе. Например, сам сайт и его базу данных. В одном файле заранее записывают, что запускать и как эти части связаны. Источник: Docker Docs.

Deploy

Деплой — обновление работающего сайта. Новые файлы отправляют на сервер и запускают там. После этого нужно открыть сайт по обычному адресу и проверить важные действия. Сохранить работу коммитом и отправить её на GitHub через push — ещё не значит сделать деплой.

Production

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

Staging

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

VPS

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

Domain

Домен — привычное имя сайта, например example.ru. Его вводят в браузере вместо длинного числового адреса сервера. При переносе сайта на другой сервер настройки домена иногда нужно поменять. Источник: MDN.

DNS

DNS — своего рода телефонная книга интернета. Вы набираете домен example.ru, а DNS подсказывает браузеру, на каком сервере находится сайт. Если там записан старый адрес сервера, сайт может быть уже готов, но посетитель попадёт не туда. Источник: MDN.

HTTPS

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

Health check

Health check — короткий автоматический вопрос сайту: «Ты работаешь?» Иногда он проверяет только то, что сайт отвечает. Иногда — ещё и связь с базой данных. Даже хороший ответ не заменяет попытку открыть страницу и воспользоваться поиском как обычный посетитель.

Smoke test

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

Rollback

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

MVP

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

Как поисковик увидит статью

SEO

SEO — работа над тем, чтобы люди могли найти вашу страницу через поиск. Поисковику нужно суметь открыть её и понять, о чём она. А человеку — быстро получить ответ на свой вопрос. Понятный заголовок, хороший текст и полезные ссылки помогают; многократное повторение нужных слов не обещает первое место. Источник: Google Search Central.

URL

URL — полный адрес страницы, например https://example.ru/blog/pull-request. Домен здесь — example.ru, а остальная часть указывает на конкретную статью. Хорошо, когда адрес понятен и остаётся прежним после небольших правок текста.

Search intent

Поисковое намерение, или интент, — то, что человек на самом деле хочет узнать. На вопрос «что такое pull request» нужен понятный ответ и пример. На вопрос «как создать pull request» нужна инструкция по шагам. Это близкие, но разные просьбы.

Title and meta description

Title — название страницы, которое вы видите на вкладке браузера; поисковик тоже может показать его в результатах. Meta description — короткое описание этой страницы. Оба текста должны честно говорить, что человек найдёт внутри. Поисковик иногда показывает собственный вариант названия или описания, взятый из статьи. Источники: Google о заголовках, Google об описаниях.

Canonical

Canonical — подсказка поисковику, какой адрес страницы считать главным. Она нужна, если одна и та же статья открывается по нескольким адресам. Например, по адресу с дополнительными параметрами и без них. Вы указываете основной вариант, хотя окончательный выбор делает поисковик. Источник: Google Search Central.

Sitemap

Sitemap — файл со списком страниц сайта, который помогает поисковику их найти. Можно представить его как оглавление, переданное поисковому роботу. Само наличие статьи в этом файле ещё не гарантирует, что она появится в поиске. Источник: Google Search Central.

Noindex

Noindex — просьба к поисковику не показывать страницу в результатах. Она подходит для страниц, которые людям не нужно находить через поиск. Если на странице есть личные данные, одной такой просьбы недостаточно: доступ к странице нужно закрыть. Источник: Google Search Central.

Indexing

Индексация — поисковик нашёл страницу и добавил её в свой список известных страниц. Публикация на сайте и индексация происходят в разное время. Даже после индексации статья может показываться далеко не на первой странице результатов.

Как читать рабочую фразу целиком

Вернёмся к сообщению: «Сделал ветку, коммит и pull request; CI прошёл, можно мержить и деплоить». Теперь его можно перевести так: «Я сделал поиск в отдельной версии проекта, сохранил работу и показал её для проверки. Компьютер запустил назначенные проверки, они прошли. Теперь можно добавить поиск в основную версию, а затем обновить сайт для посетителей».

Вам не нужно запоминать все команды. Главное — понимать, где сейчас результат: только у того, кто делал работу, уже на GitHub или уже на сайте для посетителей.

«Готово локально».

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

«Закоммитил и запушил».

Работу сохранили и отправили на GitHub или другой сервер с кодом. Спросите, открыл ли исполнитель PR и какие файлы поменялись. На самом сайте для посетителей пока может быть старая версия.

«Все проверки зелёные, можно мержить».

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

«Деплой успешен, сайт отвечает 200».

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

«Статья в sitemap, теперь ждём трафик».

Поисковику сообщили адрес статьи. Теперь нужно проверить, добавил ли он её в свой список и показывал ли кому-нибудь. Для этого смотрят данные в Яндекс Вебмастере или Google Search Console. Само добавление адреса в sitemap не означает, что появились читатели.

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

Если вы хотите, чтобы ИИ помогал уже в самой компании, начните с простой задачи. Например: «Получать новые заявки, готовить черновик ответа, а менеджер проверит его и отправит». Затем можно посмотреть роли в каталоге ЦифроШтата и сравнить их с вашей задачей. На странице «Как это работает» показан путь от выбора роли до обсуждения подключения. Перед запуском проверьте, можно ли подключить именно ваши программы и кто будет отвечать за ошибки. Если задача связана с обращениями клиентов, начните с разбора о потерянных заявках и страницы решения для обработки заявок.