Git и управление на версиите в мобилната разработка: какво е, основни команди и как работи

Управление на версии и Git: какво е?

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

Git работи с моментни снимки (snapshots) — всеки commit запазва състоянието на всички файлове на проекта в момента на запазване. Ако файл не се е променил, Git създава препратка към предишната версия, спестявайки място. Според анализ на GitHub (2025), средното хранилище съдържа 1200 комита и 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

# Добавяне на файлове и commit
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

Горният код показва основната последователност: инициализиране на хранилище, първи commit и публикуване на отдалечен сървър. Командата 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 е единица за промяна. Всеки commit съдържа уникален хеш (SHA-1), съобщение, автор и времеви печат. Добра практика е да правите малки смислени комити с описателни съобщения — това опростява Code Review и връщането на промени. Управлението на версии чрез комити ви дава пълната история на проекта.

Feature Branch

Feature Branch (клон за функция) е временен клон, създаден от develop или main за разработка на конкретна задача. След завършване на работата, клонът се слива обратно чрез Pull Request и се изтрива. Тази практика позволява изолиране на промените, без да се нарушава стабилността на основната кодова база.

Типичен работен процес: създаване на клон feature/add-login → извършване на няколко комита → създаване на Pull Request → преминаване през Code Review → сливане в develop. В IT Sectr използваме точно този подход: всяка задача от Jira отговаря на отделен feature клон. Това опростява проследяването на промени и връщането при необходимост.

Rebase срещу Merge

Merge създава merge commit, който обединява два клона. Той запазва пълната история, включително паралелните линии на разработка. 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

Този пример показва типичен работен процес: създаване на feature клон от main, няколко комита и rebase за получаване на чиста линейна история преди изпращане за преглед. Този подход минимизира конфликтите при сливане.

Git Flow срещу 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), 37% от екипите използват Git Flow. Този модел за управление на версии остава стандарт за проекти с фиксирани версии.

# Пример 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

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

Кодът илюстрира създаването на release клон, неговото стабилизиране и сливане в основните клонове. Флагът --no-ff гарантира създаването на merge commit, запазвайки информацията, че промените идват от release клона.

Pull Request и Code Review

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

Добрият PR трябва да бъде малък (до 300 реда код), фокусиран върху една задача и да съдържа описание на това, което е направено и защо. Според проучване на Google (2025), PR над 400 реда се преглеждат два пъти по-дълго, а вероятността за откриване на грешки намалява с 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. Безплатният план включва неограничени частни хранилища за екипи до 3 души. GitHub е популярен в open-source общността.

GitLab е пълна DevOps платформа с интегриран CI/CD, регистър на контейнери и управление на инфраструктура. За разлика от GitHub, GitLab може да бъде инсталиран на ваш собствен сървър (Self-Managed). Bitbucket на Atlassian е тясно интегриран с Jira и Confluence, което го прави избор за екипи, които вече използват екосистемата на Atlassian.