Практический курс по Git и Docker для инженеров

Git и Docker давно перестали быть инструментами только для backend-разработки или DevOps. В инженерной практике они нужны не меньше, чем компилятор, отладчик или нормальная система логирования. Когда работаешь с прошивками, кодом для Linux-устройств, Python-скриптами обработки данных, ML-моделями и разными стендами, очень быстро становится понятно: без внятного контроля версий и воспроизводимого окружения проект начинает расползаться. На одной машине всё собирается, на другой не хватает пакета, на третьей внезапно другая версия Python или системной библиотеки. А если в проекте несколько человек, хаос наступает ещё быстрее.

На практике Git решает задачу управления изменениями, а Docker — задачу повторяемой среды выполнения. Вместе они дают основу, без которой сложно строить стабильные пайплайны разработки, тестирования и доставки. Ниже — не абстрактное введение, а практический разбор того, как использовать эти инструменты в инженерных проектах: от простого локального репозитория до CI/CD-сценариев для embedded и edge AI.

Зачем инженеру Git и Docker в 2026 году

В инженерных задачах код почти никогда не существует сам по себе. Он связан с железом, внешними библиотеками, драйверами, версиями SDK, форматами данных, тестовыми стендами и окружением, в котором всё это запускается. Это может быть компьютерное зрение на камере, сбор телеметрии с датчиков, сервис на Python для предобработки данных или кросс-компиляция прошивки под ARM. Во всех этих сценариях важно не только написать рабочий код, но и сохранить его историю, воспроизвести сборку и передать проект другому человеку без многочасовых объяснений.

Git фиксирует изменения, позволяет безопасно экспериментировать, откатываться, сравнивать версии и работать в команде без постоянного риска что-то затереть. Docker, в свою очередь, упаковывает приложение вместе с зависимостями в контейнер и помогает получить одинаковое поведение на ноутбуке разработчика, на CI-сервере и на целевой Linux-машине. Формулировку про «даже ядро Linux» обычно используют упрощённо, но инженерно корректнее помнить: контейнеры используют ядро хоста, а изолируют пользовательское пространство и зависимости. Именно это и даёт воспроизводимость, которая особенно ценна в прикладных AI- и embedded-проектах.

Почему это критично:

• Версионный контроль спасает от потерь. Представьте: вы оптимизируете C++-код под ARM, сокращаете потребление памяти, меняете работу с буферами, а параллельно коллега правит тот же модуль драйвера. Без Git такие изменения легко потерять или слить в нечитаемую смесь. С Git история прозрачна, а откат к рабочему состоянию занимает минуты.
• Docker решает классическую проблему «у меня работает». Например, ML-модель на PyTorch требует CUDA 12.1, а на сервере стоит 11.8. Или локально у вас одна версия OpenCV, а на стенде — другая. Контейнер фиксирует окружение и устраняет этот класс ошибок заметно быстрее, чем ручная настройка системы.
• Для embedded и AI это особенно полезно. Git хранит код прошивок, конфигурации, скрипты подготовки данных, инфраструктурные файлы и даже описание сборки. Docker помогает собирать пайплайны CI/CD, запускать тесты в изолированной среде, кросс-компилировать под ARM и воспроизводить окружение для эмуляторов и инструментов анализа.

По моему опыту, инженеры, которые действительно освоили Git и Docker не «на уровне пары команд», а как рабочие инструменты, тратят заметно меньше времени на бессмысленный дебаг окружений. В исходном тезисе фигурирует оценка около 40% — и она вполне правдоподобна для команд, где раньше многое держалось на ручной настройке. Особенно это заметно в проектах, где рядом живут Python, C/C++, системные пакеты, скрипты сборки и модели машинного обучения.

Часть 1: Git для инженеров — от нуля до ветвления проектов

Git — это распределённая система контроля версий. В отличие от старых централизованных подходов, у каждого разработчика есть полноценная локальная история, и это очень удобно в инженерной практике: можно коммитить, ветвиться, сравнивать версии и работать офлайн, не завязываясь каждую минуту на удалённый сервер. Установить Git можно с git-scm.com для Windows, macOS и Linux. После установки имеет смысл сразу настроить профиль:

git config --global user.name "Ilya Vorontsov"
git config --global user.email "[email protected]"
git config --global core.editor "vim"

Это базовая настройка, но лучше сделать её сразу. В реальных командах имя и e-mail потом используются в истории, ревью, автоматизации и аналитике изменений. Если работаете с несколькими аккаунтами, например личным GitHub и корпоративным GitLab, лучше заранее разобраться с локальными конфигами репозиториев и SSH-ключами, чтобы потом не чинить авторство задним числом.

Базовые команды: локальный репозиторий

1. Инициализация:

   git init

   Команда создаёт директорию .git/ — внутреннее хранилище истории и метаданных репозитория. С этого момента папка проекта начинает жить как управляемый Git-код.

2. Добавление файлов:

   Создайте, например, main.c с кодом для микроконтроллера.

   git add main.c
   git commit -m "Добавлен базовый код main.c"

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

3. Проверка статуса:

   git status

   Эта команда показывает, какие файлы изменены, какие уже добавлены в индекс, а какие Git пока не отслеживает. На практике это одна из самых часто используемых команд, особенно перед коммитом, переключением ветки или отправкой кода на сервер.

Практика: создайте репозиторий, добавьте 3 файла — например, C-код, README и config — и сделайте 2 коммита. После этого проверьте историю через git log. Лучше, если коммиты будут осмысленными: не один общий «initial», а, скажем, отдельный коммит под структуру проекта и отдельный под рабочую логику. Это хорошая привычка, которая потом сильно упрощает поиск ошибок.

Ветвление и merge: работа в команде

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

git checkout -b feature/sensors
git add .
git commit -m "Добавлена поддержка I2C-датчиков"
git checkout main
git merge feature/sensors

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

Конфликты? Git отметит их прямо в файлах, после чего конфликтные места нужно отредактировать вручную, затем выполнить git add и завершить процесс через git commit. Это нормальная часть командной работы. Главное — не пытаться «забить» конфликт без понимания, что именно вы сливаете. В embedded-проектах особенно опасны конфликты в конфигурациях сборки, pin mapping, CMake-файлах, коде инициализации периферии и таблицах параметров — они могут не ломать сборку сразу, но выстрелить уже на железе.

Таблица ветвенной стратегии для инженеров:

Такая схема проста, но работает. Не обязательно вводить сложный Git Flow на маленьком проекте. В большинстве инженерных команд достаточно понятных имён веток, дисциплины в коммитах и нормального ревью перед слиянием.

Удаленный репозиторий: GitHub/GitLab

1. Создайте репозиторий на GitHub.
2. Свяжите локальный проект с удалённым:

git remote add origin https://github.com/username/repo.git
git branch -M main
git push -u origin main

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

Дальше стандартный сценарий такой: делаете git push, создаёте PR в браузере и отдаёте изменения на ревью. Для embedded- и AI-проектов это особенно полезно, потому что на ревью часто всплывают не только стилевые замечания, но и вполне реальные инженерные проблемы: небезопасная работа с памятью, лишняя аллокация, неудачная структура модуля, тяжёлые зависимости, неоптимальный формат модели или потенциальные ошибки в API-интеграции.

Про-tip для embedded: добавьте .gitignore. Туда обычно стоит включить build/, .elf, временные бинарники, артефакты IDE, логи и тяжёлые файлы вроде models/large.pt. Для крупных моделей и весов используйте LFS, иначе репозиторий быстро станет тяжёлым и неудобным. Это частая ошибка у новичков в AI: случайно закоммитить гигабайты артефактов обучения, после чего с репозиторием становится неприятно работать всем.

Практика: залейте локальный репозиторий на GitHub, создайте ветку docker-test и слейте её через PR. Даже если проект совсем маленький, полезно пройти этот сценарий руками хотя бы один раз — именно так формируется рабочая привычка.

Часть 2: Docker — контейнеризация для AI и embedded

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

Особенно хорошо Docker показывает себя там, где проект быстро обрастает зависимостями. Типичный пример — Python-сервис для обработки данных с датчиков, рядом с которым живут NumPy, OpenCV, PyTorch, системные библиотеки, утилиты для сериализации и скрипты тестирования. На локальной машине всё это можно один раз настроить, но без контейнеризации повторяемость будет слабой. А когда проект уедет в CI или к коллеге, начнутся расхождения.

Dockerfile: ваш рецепт

Создайте Dockerfile для Python ML-проекта:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "main.py"]

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

Сборка и запуск:

docker build -t ml-app .
docker run --rm ml-app

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

Для embedded-сценариев, например C++-сборки под ARM, можно использовать такой подход:

FROM arm32v7/gcc:latest

WORKDIR /src
COPY . .
RUN g++ -O2 -o app main.cpp

CMD ["./app"]

Это полезно, когда нужно собрать или протестировать код в среде, близкой к целевой архитектуре. Да, реальное embedded-железо контейнер не заменяет: периферия, тайминги, драйверы и аппаратные особенности всё равно проверяются на стенде. Но как средство стандартизации сборки, кросс-компиляции и прогона части тестов Docker работает очень хорошо. Особенно если проект должен одинаково собираться у всех участников команды.

Docker Compose: мультиконтейнеры

Когда проект состоит не из одного процесса, а из нескольких сервисов, удобнее использовать Docker Compose. Например, у вас есть ML-сервер, база данных и, возможно, отдельный сервис для API или брокер сообщений. В таком случае docker-compose.yml описывает всю связку как единый стек.

version: '3.9'
services:
  ml:
    build: .
    ports:
      - "8000:8000"
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example

Запуск — командой docker-compose up. В современных версиях Docker часто используется и вариант docker compose up без дефиса, но сам смысл тот же: поднять несколько взаимосвязанных контейнеров одной командой. Для локальной разработки это очень удобно. Не нужно отдельно ставить БД, вручную поднимать сервисы и вспоминать правильные параметры запуска.

В инженерных проектах Compose особенно полезен для локальной сборки пайплайнов обработки данных. Например, один контейнер принимает данные с API, второй делает предобработку, третий — инференс модели, четвёртый складывает результаты в БД. Даже если потом всё это будет жить в другой инфраструктуре, локально отладить такую схему через Compose гораздо проще и быстрее.

Таблица популярных образов для инженеров:

С образами стоит работать осознанно. Базовый образ — это часть архитектурного решения: от него зависят размер, скорость сборки, совместимость библиотек и удобство поддержки. Например, на Raspberry Pi не всякий образ подойдёт без доработки, а в GPU-сценариях критична совместимость между версией CUDA, драйверами хоста и библиотеками внутри контейнера.

Практика: соберите Docker для простого C-проекта, например LED-симулятора, и запустите его на ARM-эмуляции через docker run --platform linux/arm64. Это хороший учебный сценарий: он показывает, как выглядит переносимая сборка и где начинаются реальные архитектурные ограничения.

Интеграция Git + Docker: CI/CD пайплайн

Настоящая польза раскрывается, когда Git и Docker начинают работать вместе. Типовой сценарий в реальном проекте простой: вы пушите изменения в репозиторий, а система CI автоматически собирает Docker-образ, гоняет тесты и проверяет, не развалили ли вы проект. Это уже не просто удобство, а основа стабильной разработки.

Один из самых доступных вариантов — GitHub Actions. Для этого в репозитории создаётся файл .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [ "main" ]

jobs:
  docker-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t my-app .

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

Для embedded-проектов стоит добавить шаг с docker run --platform linux/arm64 для кросс-компиляции или проверки сборки под целевую архитектуру. Это не заменяет аппаратные тесты на реальном устройстве, но отлично ловит часть проблем заранее. Например, можно быстро обнаружить, что проект тянет неподходящую библиотеку, использует несовместимую системную зависимость или просто не собирается в нужном контейнере.

В AI-сценариях CI/CD полезен не меньше. Там, кроме сборки кода, часто нужно проверять, что модель корректно подхватывается, API стартует, зависимости не конфликтуют, а базовый smoke-test инференса проходит. Даже небольшой автоматический тест на одном-двух примерах уже спасает от неприятных ситуаций, когда контейнер формально собрался, а приложение падает при первом же вызове.

Практика: настройте Actions для своего репозитория так, чтобы Docker-образ собирался при пуше в main. Если хотите приблизиться к реальной инженерной практике, добавьте ещё простой тест внутри контейнера — это уже будет зачаток рабочего CI-пайплайна.

Распространенные ошибки и как их фиксить

Ошибки в Git и Docker почти всегда одни и те же. Хорошая новость в том, что они достаточно типовые, и после пары реальных проектов начинают распознаваться автоматически.

• Git: используйте git stash перед переключением веток, если у вас есть незакоммиченные изменения. Это банальная команда, но она регулярно спасает от случайной путаницы. Для более чистой истории полезен git rebase, особенно если хочется убрать лишние merge-коммиты и выровнять ветку перед PR. Но применять rebase нужно аккуратно, особенно с уже опубликованной историей.
• Docker: для данных используйте volumes, например -v /host/data:/container/data. Это особенно важно, если контейнер пишет результаты обработки, логи, кэши или промежуточные артефакты. Иначе после удаления контейнера данные просто исчезнут.
• Сборка образов: применяйте multi-stage builds, если хотите уменьшить размер итогового образа. Это хороший инженерный приём: компилятор, dev-зависимости и промежуточные артефакты остаются в стадии сборки, а в runtime-образ попадает только то, что нужно для запуска.
• Размер и мусор: команда docker image prune помогает чистить неиспользуемые образы. Если активно экспериментировать, особенно с ML-зависимостями, диск забивается очень быстро.

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

Чек-лист запуска проекта:

• [ ] git clone
• [ ] docker-compose up
• [ ] Тесты: docker exec -it container pytest

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

FAQ

Зачем Docker инженеру embedded, если нет облака?

Потому что Docker нужен не только для облака. Он позволяет локально воспроизводить окружения, кросс-компилировать под ARM на x86-машине, стандартизировать toolchain и запускать часть тестов в изолированной среде. Для embedded это очень практично: можно собирать код в одинаковом контейнере у всей команды, не споря о версиях компилятора и библиотек. Плюс удобно тестировать вспомогательные компоненты — например, обработку изображений, API-обвязку или подготовку данных — без переустановки системы. В реальных кейсах это особенно выручает, когда нужно быстро поднять OpenCV-окружение на Raspberry Pi-подобный стек без ручной возни с зависимостями.

Git vs SVN — что выбрать в 2026?

Git. Он фактически стал стандартом индустрии: распределённая модель, быстрые ветки, удобная локальная история, интеграция с GitHub/GitLab, CI/CD и современной инженерной экосистемой. SVN сегодня выглядит устаревшим выбором для командной разработки. В узкоспециальных legacy-средах он ещё встречается, но если вы строите новый процесс, рациональных причин выбирать его вместо Git почти не осталось.

Сколько времени на освоение?

Базу можно освоить за 2–3 часа практики: создать репозиторий, сделать несколько коммитов, поработать с ветками, собрать и запустить контейнер. Но чтобы уверенно использовать полный пайплайн в реальном проекте, обычно нужна примерно неделя с практикой на живой задаче. И это нормальный срок: инструменты несложные по идее, но настоящие навыки появляются именно на проекте, где есть ветки, конфликты, сборка, зависимости и автоматизация.

Мои проекты на edge AI ломаются в Docker?

Нет, если правильно учитывать архитектуру и использовать multi-arch builds. Для edge AI это ключевой момент: локально вы можете работать на x86, а целевое устройство будет ARM64. Поэтому нужен корректный сценарий сборки, например через docker buildx build --platform linux/arm64. Плюс стоит внимательно смотреть на системные зависимости, версии Python-пакетов и нативные библиотеки вроде OpenCV, ONNX Runtime или PyTorch. Большинство проблем здесь не в самом Docker, а в несовпадении архитектур и окружений.

Где дальше: Kubernetes?

После Docker — да, можно двигаться туда, если вам нужна оркестрация на кластерах, масштабирование, управление несколькими сервисами в production и более сложная инфраструктура. Но для solo-инженера, учебных стендов, локальной разработки и большого числа прикладных проектов Docker Compose обычно более чем достаточен. Не стоит усложнять стек раньше времени. Сначала лучше научиться хорошо упаковывать приложение, воспроизводить сборку и автоматизировать базовый CI.

Этот курс — хорошая стартовая точка для собственных пайплайнов. Возьмите реальный проект, например обработку данных с датчиков, небольшой сервис компьютерного зрения или ML-модель для edge-устройства, и примените связку Git + Docker на практике. Разница становится заметна очень быстро: меньше ручной рутины, меньше проблем с окружением, больше предсказуемости в сборке и командной работе. А дальше уже можно спокойно наращивать уровень — добавлять тесты, CI, публикацию образов и более аккуратную архитектуру проекта.

Далее в AI-Triad логично двигаться в сторону Python для ML и C++ для микроконтроллеров — именно там эти инструменты начинают приносить максимальную пользу в реальной инженерной разработке.