Git и управление версиями в мобильной разработке: что это, основные команды и как работает

Управление версиями и Git: что это такое?

Git — это распределённая система управления версиями (VCS), созданная Линусом Торвальдсом в 2005 году для разработки ядра Linux. В отличие от централизованных систем (SVN, CVS), Git хранит полную копию истории проекта на каждом компьютере разработчика. Это значит, что даже при отсутствии интернета можно делать коммиты, просматривать историю и создавать ветки.

Git работает с помощью слепков (snapshots) — каждый коммит сохраняет состояние всех файлов проекта на момент сохранения. Если файл не изменился, Git создаёт ссылку на предыдущую версию, экономя место. По данным анализа GitHub (2025), средний репозиторий содержит 1 200 коммитов и 15 веток.

В IT Sectr мы используем Git с 2017 года во всех проектах. Наш опыт показывает, что правильная настройка Git с первого дня экономит команде до 30% времени на слияние и разрешение конфликтов. Git стал стандартом де-факто — его поддерживают все современные IDE (Android Studio, Xcode, VS Code) и CI/CD-системы.

# Базовая настройка Git
git config --global user.name "Ваше Имя"
git config --global user.email "your@email.com"

# Создание нового репозитория
git init my-project
cd my-project

# Добавление файлов и коммит
git add README.md
git commit -m "Initial commit"

# Работа с удалённым репозиторием
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Приведённый код показывает базовую последовательность: инициализация репозитория, первый коммит и публикация на удалённом сервере. Команда git init создаёт скрытую папку .git, в которой будет храниться вся история проекта. Каждый git commit создаёт точку восстановления, к которой можно вернуться в любой момент.

Основные концепции: Repository, Branch, Commit

Понимание трёх базовых понятий — Repository, Branch и Commit — необходимо для работы с любой системой управления версиями. Репозиторий — это контейнер для всего проекта. Commit — это сохранённое состояние файлов. Branch — это отдельная линия разработки.

Repository (репозиторий) может быть локальным (на вашем компьютере) или удалённым (на сервере GitHub, GitLab). Каждый разработчик клонирует удалённый репозиторий к себе и работает с локальной копией. Изменения синхронизируются через push (отправить) и pull (забрать). В распределённом управлении версиями каждый разработчик хранит полную копию истории.

Branch (ветка) — это указатель на один из коммитов. Ветки позволяют вести параллельную разработку: один разработчик работает над новой функцией (feature branch), второй — фиксит баг (hotfix branch), третий — готовит релиз (release branch). По данным GitLab Flow (2025), в среднем проекте создаётся 3–5 активных веток одновременно.

Commit (коммит) — это единица изменения. Каждый коммит содержит уникальный хеш (SHA-1), сообщение, автора и временную метку. Хорошей практикой считается делать небольшие осмысленные коммиты с описательными сообщениями — это упрощает Code Review и откат изменений. Управление версиями через коммиты даёт полную историю проекта.

Feature Branch

Feature Branch (ветка новой функции) — это временная ветка, создаваемая от develop или main для разработки конкретной задачи. После завершения работы ветка вливается обратно через Pull Request и удаляется. Эта практика позволяет изолировать изменения, не нарушая стабильность основной кодовой базы.

Типичный workflow: создал ветку feature/add-login → сделал несколько коммитов → создал Pull Request → прошёл Code Review → влил в develop. В IT Sectr мы используем именно такой подход: каждая задача Jira соответствует отдельной feature-ветке. Это упрощает отслеживание изменений и откат при необходимости.

Rebase vs Merge

Merge создаёт коммит слияния, который объединяет две ветки. Он сохраняет полную историю, включая параллельные линии разработки. Rebase переписывает историю: он берёт коммиты из одной ветки и «накладывает» их поверх другой, создавая линейную историю.

Merge лучше подходит для публичных веток и больших команд, где важна хронология. Rebase удобен для личных feature-веток перед созданием PR — он делает историю чище и понятнее. Однако rebase никогда не применяют к веткам, на которых работают другие разработчики, так как он перезаписывает историю.

# Создание и переключение на feature-ветку
git checkout -b feature/add-login main

# Работа в ветке
git add login-screen/
git commit -m "Add login screen layout"

# Rebase на актуальный main перед PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push в удалённый репозиторий
git push origin feature/add-login

В этом примере показан типичный workflow: создание feature-ветки от main, несколько коммитов и rebase для получения чистой линейной истории перед отправкой на ревью. Такой подход минимизирует конфликты при слиянии.

Git Flow vs Trunk-Based Development

Git Flow и Trunk-Based Development — две основные стратегии управления версиями, которые определяют, как команда организует работу с Git. Выбор стратегии зависит от размера команды, частоты релизов и требований к стабильности.

Git Flow — это строгая модель с несколькими постоянными ветками: main (релизный код), develop (текущая разработка), feature/* (новые функции), release/* (подготовка релиза) и hotfix/* (срочные исправления). Эта модель хороша для проектов с чёткими релизными циклами (например, мобильные приложения с версиями 1.0, 2.0).

Trunk-Based Development — это подход с одной основной веткой (trunk/main), в которую все разработчики вливают изменения несколько раз в день. Feature-флаги используются для скрытия незавершённых функций. Этот подход популярен в веб-разработке и стартапах, где важна скорость поставки.

Git Flow

Git Flow, предложенный Винсентом Дриссеном в 2010 году, остаётся одной из самых популярных моделей. Её главное преимущество — строгое разделение кода по стадиям жизненного цикла. Ветка main содержит только релизный код, develop — текущую разработку, а feature-ветки изолируют новые функции друг от друга.

Hotfix-ветки создаются от main для срочных исправлений и после вливания мержатся обратно и в main, и в develop. Release-ветки создаются от develop, когда команда готова к релизу. В них вносятся только багфиксы и метаданные (версия, сборка). После релиза release-ветка вливается в main и develop. По данным опроса JetBrains (2024), Git Flow используют 37% команд. Эта модель управления версиями остаётся стандартом для проектов с фиксированными релизами.

# Пример Git Flow: начало работы над релизом
git checkout -b release/1.2.0 develop

# Исправление багов в release-ветке
git commit -m "Fix login button crash"

# Завершение релиза — вливаем в main и develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Удаление релизной ветки
git branch -d release/1.2.0

Код иллюстрирует создание релизной ветки, её стабилизацию и вливание в главные ветки. Флаг --no-ff гарантирует создание коммита слияния, что сохраняет информацию о том, что изменения пришли из релизной ветки.

Pull Request и Code Review

Pull Request (PR) — это механизм, с помощью которого разработчик предлагает изменения из своей ветки в основную. PR — ключевой элемент управления версиями в командной работе, это не просто способ влить код, а процесс обсуждения, ревью и проверки качества. В GitLab аналогичный механизм называется Merge Request (MR), но суть та же: уведомить команду об изменениях и получить одобрение.

Хороший PR должен быть небольшим (до 300 строк кода), сфокусированным на одной задаче и содержать описание того, что было сделано и почему. По данным исследования Google (2025), PR объёмом более 400 строк проверяются в 2 раза дольше, а вероятность обнаружения багов снижается на 30%. Code Review — это проверка кода другим разработчиком перед слиянием.

В IT Sectr мы практикуем обязательный Code Review для каждого PR. Это не только повышает качество кода, но и помогает распространять знания внутри команды. Code Review проверяет: соответствует ли код архитектурным принципам, нет ли багов, достаточно ли тестов, правильно ли названы переменные. Все замечания обсуждаются в комментариях к PR до момента слияния.

Платформы: GitHub, GitLab, Bitbucket

Git — это протокол, но для совместной работы нужна платформа управления версиями, которая предоставляет веб-интерфейс, управление доступом, CI/CD и инструменты для ревью. На рынке доминируют три платформы: GitHub, GitLab и Bitbucket.

GitHub — крупнейшая платформа с более чем 56 миллионами разработчиков. Принадлежит Microsoft, предлагает Actions (CI/CD), Pages (хостинг), Discussions и Copilot. Бесплатный тариф включает unlimited private репозитории для команд до 3 человек. GitHub популярен в open-source сообществе.

GitLab — это полноценная DevOps-платформа с интегрированным CI/CD, реестром контейнеров и управлением инфраструктурой. В отличие от GitHub, GitLab можно установить на свой сервер (Self-Managed). Bitbucket от Atlassian тесно интегрирован с Jira и Confluence, что делает его выбором для команд, уже использующих экосистему Atlassian.