Антон — Head of Engineering в Mindbox. В прошлом работал в разных ролях и компаниях: Intel, Dodo, Райффайзенбанк, своя компания. Был разработчиком, техлидом, скрам-мастером, сейчас отвечает за инженерное направление.
Света — тренер по инженерным практикам. Работает с командами и помогает улучшать бизнес-метрики через инженерные подходы. Тоже прошла путь разработчик → тимлид → скрам-мастер.
Цель митапа очень простая: познакомить людей, которые не пишут код, с ключевыми инженерными практиками, чтобы стало легче работать вместе с разработчиками. Сегодня фокус — Git и базовые понятия, которые звучат почти в каждой продуктовой команде: branch, pull request, merge, merge hell, CI/CD.
Важно: программировать не нужно. Мы не будем писать ни строчки кода — всё объясняем на обычном тексте и на простых примерах.
Зачем «неразработчикам» понимать Git
Git мы выбрали не случайно. Он помогает закрыть разрыв между разработкой и остальными ролями: продактами, аналитиками, скрам-мастерами, менеджерами, DevOps, QA.
Когда человек из «неразработческого мира» понимает, что такое ветка, почему нужен pull request и зачем вообще это всё, резко снижается количество ситуаций из серии:
- «почему так долго?»;
- «почему нельзя просто быстро поправить?»;
- «почему мы не можем менять прямо в main?»;
- «почему релиз откладывается из-за какого-то merge?».
Мы не ставим цель сделать из участников программистов. Мы хотим, чтобы вы:
- понимали, как разработчики реально работают с изменениями;
- могли говорить с командой на одном языке;
- лучше понимали, где возникают риски и почему инженерные практики — это не «техническая прихоть».
С чего начинаем: код — это обычный документ
Перед тем как говорить про Git, разберём базовую идею.
Каждый из нас работает с документами: Google Docs, Word, Notepad и так далее. Обычно мы делаем одни и те же действия: создаём документ, редактируем, сохраняем, иногда удаляем.
Главный секрет вечера: код — это такой же документ. Это обычный текстовый файл. Даже проще, чем Word-документ: в коде почти нет «красивого оформления», только текст, отступы и структура.
Разработчик делает с кодом то же самое, что вы делаете с документами. Разница в том, что обычно таких файлов много, и изменения нужно сохранять согласованно сразу в нескольких местах.
Почему одного «облака» недостаточно
Кажется, что проблема хранения документов давно решена: облако надёжнее ноутбука, документы не пропадают из-за поломки диска или пролитого кофе.
Но у облака есть другая боль: если хранить «как попало», особенно когда с файлами работают несколько человек, легко получить хаос:
- непонятно, где последняя версия;
- кто-то случайно удалил или перенёс файл;
- в папках появляется «файловая помойка»;
- начинается пересылка документов по почте и версиями “final_final_v3”.
В этом месте полезно вспомнить, почему многим нравится Google Docs: там есть история версий — можно откатиться назад и восстановить документ. В Confluence и других системах иногда есть даже более удобная вещь: можно фиксировать смысл изменений комментарием.
Хочешь развиваться системнее?
Выбери, что ближе тебе — и получи 🎁 подборку материалов от Neogenda.
Разработчикам нужно всё то же самое — только на уровне кода и командной работы. Для этого и существует система контроля версий.
Что такое Git и GitHub простыми словами
Git — это система контроля версий. Её можно установить на компьютер и использовать локально.
GitHub — онлайн-сервис и хранилище репозиториев, которое поддерживает Git. Это как большая библиотека кода. Аналоги: GitLab, Bitbucket.
Важно не путать: Git — инструмент, GitHub — сервис вокруг него.
Репозиторий: «папка проекта» с историей
Репозиторий (repo) — это по сути набор файлов и папок, которые относятся к одному проекту.
Он может быть:
- удалённым (на GitHub или GitLab);
- локальным (на вашем компьютере).
Типичный разработчик работает так: он берёт удалённый репозиторий, скачивает себе локальную копию, работает, а затем отправляет изменения обратно в удалённое хранилище.
Это похоже на ситуацию, когда файл лежит в облаке, но вы сохраняете его офлайн и редактируете на компьютере, а потом загружаете обновлённую версию назад.
Fork: «скопировать чужую библиотеку себе»
Fork — это когда вы берёте чужой публичный репозиторий на GitHub и создаёте свою копию у себя.
Хороший пример — Avito Tech Playbook. Это открытый репозиторий с описаниями ролей, инженерных практик, принципов разработки, библиотекой полезных материалов. Любая компания может:
- взять его за основу;
- сделать fork;
- адаптировать под свои роли и контекст.
Главный принцип: вы меняете свою копию — оригинал не трогаете. Авторы исходного репозитория вообще могут не знать, что вы что-то изменили.
Fork происходит в облаке, на уровне GitHub. Это не то же самое, что «склонировать репозиторий на компьютер».
Ветка: несколько «изданий» одного и того же текста
Ветки (branches) нужны, чтобы параллельно вести разные версии изменений и не мешать друг другу.
Аналогия простая: вы написали книгу — это «основная версия». Потом делаете второе издание, где меняете главы и добавляете материал. При этом читатель нашёл опечатку в первом издании, и вам нужно её исправить, не ломая работу над вторым.
В разработке это происходит постоянно. Поэтому есть:
- основная ветка (main/master) — «рабочая версия»;
- дополнительные ветки — «черновики», эксперименты, фичи.
Commit: сохранить согласованное состояние сразу нескольких файлов
Commit — это когда вы фиксируете изменения как логически целое.
Представим статью: текст + картинка + график. Вы решили переписать статью с «серых котиков» на «рыжих». Сначала поменяли текст, потом — картинку, потом — график. Пока всё не согласовано, публиковать нельзя.
Коммит — это момент, когда вы говорите: «вот теперь это цельная версия». Разработчику важно фиксировать такие состояния постоянно — иначе легко потерять, где что работало.
Checkout: переключиться между ветками
Checkout — это переключение того, на какую ветку вы сейчас смотрите и в какой ветке работаете.
На одном экране нельзя работать сразу в двух ветках. Вы всегда находитесь в какой-то одной, а checkout позволяет быстро переключиться.
Pull request: безопасный способ внести изменения
Pull request (PR) — это запрос: «посмотрите мои изменения и примите их, если ок».
Почти идеальная бытовая аналогия — режим правок в Google Docs, когда вы не переписываете документ напрямую, а предлагаете изменения, и владелец документа решает:
- принять;
- отклонить;
- попросить доработать.
В GitHub pull request работает так же:
- вы делаете изменения в своей ветке;
- создаёте PR в основную ветку;
- другие участники делают review;
- если всё ок — изменения мерджатся (попадают в основную ветку).
Вопрос «почему pull, а не push?» обычно возникает всегда. Смысл в том, что инициатор «предлагает», а принимающая сторона «подтягивает» изменения в свою основную ветку. Терминология историческая, но логика такая.
«Можно ли настроить мердж так, чтобы требовалось несколько одобрений?»
Да, такая настройка бывает. Владелец репозитория (или администраторы проекта) может включить правило, что изменения попадут в основную ветку только если их одобрят:
- 1 человек;
- 2–3 человека;
- конкретные роли (например, архитекторы или тимлиды);
- или вообще любой из команды.
По смыслу это похоже на права в Google Docs: кому-то можно «редактировать», а кому-то только «комментировать». Здесь аналогично — можно разрешить изменения только через pull request и обязать несколько людей поставить “Approve”.
Короткое уточнение: что такое commit
Участники попросили ещё раз объяснить commit, потому что слово часто путает.
Commit — это «сохранение», но не одного файла, а согласованного набора изменений.
Пример с котиками остаётся ключевым:
- у вас есть 3 отдельные сущности: текст, картинка, график (то есть 3 файла);
- пока вы переписали текст, но не поменяли картинку и график — состояние «недоделанное»;
- commit — это “коробочка”, в которую вы складываете изменения тогда, когда они логически согласованы.
В командной работе вопрос «ты закоммитил?» часто означает:
- «ты сохранил изменения так, чтобы их можно было забрать»
- в реальной жизни часто подразумевают не только commit, но и push (то есть отправку в удалённый репозиторий), потому что обычно эти шаги идут подряд
Вопросы про конфликты и «merge hell»
Уточнили важную вещь: можно ли делать всё “за раз” и что происходит, если кто-то уже поменял то же самое.
- конфликты возникают, когда несколько человек меняют одну и ту же строчку в одном и том же файле;
- «merge hell» — это как раз история про то, как синхронизировать изменения и решать конфликты;
- тему конфликтов не стали разбирать глубоко в рамках метапа, потому что она требует отдельного занятия и практики.
Дополнительная аналогия, которую использовали: если один и тот же файл открыт на компьютере и телефоне, и вы отредактировали одну и ту же строчку в двух местах, системе нужно решить, какую правку считать истинной. Git как раз про то, чтобы управлять такими ситуациями в команде.
«Почему в Avito playbook нет scrum-мастеров и agile coaching?»
Ответ был в том, что у Avito иначе нарезаны роли: часть функций процесса и развития команд закрывается через инженерных менеджеров (people management + системный дизайн + процессная часть). То есть роль есть, но она упакована по-другому.
«GitHub/GitLab бесплатные — на чём они зарабатывают?»
Логика как у Google Docs / Gmail:
- бесплатный уровень обычно покрывает публичные репозитории и базовые сценарии.
деньги приносят корпоративные тарифы и подписки, где:
- приватность;
- расширенные настройки безопасности;
- управление доступами;
- аналитика, интеграции, автоматизация;
- компании, которым нельзя хранить код публично, поднимают корпоративные решения в своём контуре.