Mobil inkişafda Git və versiya idarəetməsi: bu nədir, əsas əmrlər və necə işləyir

Versiya idarəetməsi və Git: bu nədir?

Git 2005-ci ildə Linus Torvalds tərəfindən Linux nüvəsinin inkişafı üçün yaradılmış paylanmış versiya idarəetmə sistemidir (VCS). Mərkəzləşdirilmiş sistemlərdən (SVN, CVS) fərqli olaraq, Git hər tərtibatçının kompüterində layihə tarixçəsinin tam surətini saxlayır. Bu o deməkdir ki, internet bağlantısı olmadan da commit edə, tarixçəyə baxa və budaqlar yarada bilərsiniz.

Git snapshot ilə işləyir — hər commit saxlanma anında bütün layihə fayllarının vəziyyətini saxlayır. Fayl dəyişməyibsə, Git əvvəlki versiyaya istinad yaradaraq yerə qənaət edir. GitHub analizinə (2025) görə, orta depoda 1.200 commit və 15 budaq var.

IT Sectr-də 2017-ci ildən bütün layihələrdə Git istifadə edirik. Təcrübəmiz göstərir ki, ilk gündən düzgün Git konfiqurasiyası komandaya birləşmə və münaqişələrin həllində 30% vaxt qazandırır. Git de-fakto standarta çevrilib — bütün müasir IDE (Android Studio, Xcode, VS Code) və CI/CD sistemləri tərəfindən dəstəklənir.

# Git əsas qurulumu
git config --global user.name "Adınız"
git config --global user.email "email@adresiniz.com"

# Yeni depo yaratmaq
git init my-project
cd my-project

# Fayl əlavə etmək və commit
git add README.md
git commit -m "Initial commit"

# Uzaq depo ilə işləmək
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Yuxarıdakı kod əsas ardıcıllığı göstərir: deponun başladılması, ilk commit və uzaq serverdə nəşr. git init əmri bütün layihə tarixçəsini saxlayacaq gizli .git qovluğu yaradır. Hər git commit istənilən vaxt qayıda biləcəyiniz bərpa nöqtəsi yaradır.

Əsas anlayışlar: Repository, Branch, Commit

Üç əsas anlayışı — Repository, Branch və Commit — başa düşmək hər hansı versiya idarəetmə sistemi ilə işləmək üçün vacibdir. Depo bütün layihə üçün konteynerdir. Commit faylların saxlanmış vəziyyətidir. Branch ayrı bir inkişaf xəttidir.

Repository (depo) lokal (kompüterinizdə) və ya uzaq (GitHub, GitLab serverində) ola bilər. Hər tərtibatçı uzaq deponu öz maşınına klonlayır və lokal surətlə işləyir. Dəyişikliklər push (göndərmək) və pull (çəkmək) vasitəsilə sinxronlaşdırılır. Paylanmış versiya idarəetməsində hər tərtibatçı tarixçənin tam surətini saxlayır.

Branch (budaq) commitlərdən birini göstərən göstəricidir. Budaqlar paralel inkişafa imkan verir: bir tərtibatçı yeni funksiya üzərində (feature branch), digəri səhv düzəlişi (hotfix branch), üçüncüsü buraxılış hazırlığı (release branch) üzərində işləyir. GitLab Flow-a (2025) görə, orta layihədə eyni vaxtda 3–5 aktiv budaq olur.

Commit dəyişiklik vahididir. Hər commit unikal hash (SHA-1), mesaj, müəllif və zaman damğası ehtiva edir. Yaxşı təcrübə təsviri mesajlarla kiçik mənalı commitlər etməkdir — bu Kod İncelemesini və dəyişikliklərin geri qaytarılmasını sadələşdirir. Commit vasitəsilə versiya idarəetməsi sizə layihənin tam tarixçəsini verir.

Feature Branch

Feature Branch (funksiya budağı) müəyyən bir tapşırığın inkişafı üçün develop və ya main-dən yaradılan müvəqqəti budaqdır. İş tamamlandıqdan sonra budaq Pull Request vasitəsilə geri birləşdirilir və silinir. Bu təcrübə əsas kod bazasının sabitliyini pozmadan dəyişiklikləri təcrid etməyə imkan verir.

Tipik iş axını: feature/add-login budağı yarat → bir neçə commit et → Pull Request yarat → Kod İncelemesindən keç → develop-a birləşdir. IT Sectr-də məhz bu yanaşmanı istifadə edirik: hər Jira tapşırığı ayrı bir funksiya budağına uyğun gəlir. Bu, dəyişiklik izləməni və lazım olduqda geri qaytarmağı asanlaşdırır.

Rebase vs Merge

Merge iki budağı birləşdirən birləşmə commiti yaradır. Paralel inkişaf xətləri daxil olmaqla tam tarixçəni qoruyur. Rebase tarixçəni yenidən yazır: bir budaqdan commitləri götürür və onları digər budağın üzərinə "yenidən tətbiq edərək" xətti tarixçə yaradır.

Merge xronologiyanın vacib olduğu ictimai budaqlar və böyük komandalar üçün daha uyğundur. Rebase PR yaratmadan əvvəl şəxsi funksiya budaqları üçün əlverişlidir — tarixçəni daha təmiz və anlaşılan edir. Bununla belə, rebase tarixçəni yenidən yazdığı üçün digər tərtibatçıların üzərində işlədiyi budaqlara heç vaxt tətbiq edilməməlidir.

# Funksiya budağı yaratmaq və keçid etmək
git checkout -b feature/add-login main

# Budaqda işləmək
git add login-screen/
git commit -m "Add login screen layout"

# PR əvvəl ən son main-ə Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Uzaq depoya Push
git push origin feature/add-login

Bu nümunə tipik iş axınını göstərir: main-dən funksiya budağı yaratmaq, bir neçə commit və icmal üçün göndərməzdən əvvəl təmiz xətti tarixçə əldə etmək üçün rebase. Bu yanaşma birləşmə münaqişələrini minimuma endirir.

Git Flow vs Trunk-Based Development

Git Flow və Trunk-Based Development komandanın Git ilə işi necə təşkil etdiyini müəyyən edən iki əsas versiya idarəetmə strategiyasıdır. Seçim komanda ölçüsündən, buraxılış tezliyindən və sabitlik tələblərindən asılıdır.

Git Flow çoxlu daimi budaqları olan sərt modeldir: main (buraxılış kodu), develop (cari inkişaf), feature/* (yeni funksiyalar), release/* (buraxılış hazırlığı) və hotfix/* (təcili düzəlişlər). Bu model aydın buraxılış dövrləri olan layihələr üçün yaxşıdır (məsələn, 1.0, 2.0 versiyaları olan mobil tətbiqlər).

Trunk-Based Development bütün tərtibatçıların gündə bir neçə dəfə dəyişiklikləri birləşdirdiyi tək əsas budaq (trunk/main) yanaşmasıdır. Tamamlanmamış funksiyaları gizlətmək üçün funksiya bayraqları istifadə olunur. Bu yanaşma çatdırılma sürətinin vacib olduğu veb inkişaf və startaplarda populyardır.

Git Flow

Git Flow, 2010-cu ildə Vincent Driessen tərəfindən təklif edilmiş, ən populyar modellərdən biri olaraq qalır. Onun əsas üstünlüyü kodun həyat dövrü mərhələlərinə görə sərt şəkildə ayrılmasıdır. main budağı yalnız buraxılış kodunu ehtiva edir, develop cari inkişafı ehtiva edir və funksiya budaqları yeni funksiyaları bir-birindən təcrid edir.

Hotfix budaqları təcili düzəlişlər üçün main-dən yaradılır və birləşdirildikdən sonra həm main-ə, həm də develop-a geri birləşdirilir. Release budaqları komanda buraxılışa hazır olduqda develop-dan yaradılır. Onlara yalnız səhv düzəlişləri və metadata (versiya, qurma) əlavə edilir. Buraxılışdan sonra release budağı main və develop-a birləşdirilir. JetBrains sorğusuna (2024) görə, komandaların 37%-i Git Flow istifadə edir. Bu versiya idarəetmə modeli sabit buraxılışları olan layihələr üçün standart olaraq qalır.

# Git Flow nümunəsi: buraxılış üzərində işə başlamaq
git checkout -b release/1.2.0 develop

# release budağında səhv düzəlişi
git commit -m "Fix login button crash"

# Buraxılışı tamamlamaq — main və develop-a birləşdirmək
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 budağını silmək
git branch -d release/1.2.0

Kod release budağının yaradılmasını, sabitləşdirilməsini və əsas budaqlara birləşdirilməsini göstərir. --no-ff bayrağı birləşmə commitini təmin edir, dəyişikliklərin release budağından gəldiyi məlumatını qoruyur.

Pull Request və Kod İncelemesi

Pull Request (PR) tərtibatçının öz budağından əsas budağa dəyişiklik təklif etdiyi mexanizmdir. PR komanda işində versiya idarəetməsinin əsas elementidir — bu sadəcə kod birləşdirmə üsulu deyil, müzakirə, icmal və keyfiyyət yoxlaması prosesidir. GitLab-da oxşar mexanizm Merge Request (MR) adlanır, lakin mahiyyət eynidir: komandaya dəyişikliklər barədə məlumat vermək və təsdiq almaq.

Yaxşı PR kiçik (300 sətir kodadək), tək tapşırığa yönəldilmiş və nə edildiyi və niyə edildiyinin təsvirini ehtiva etməlidir. Google araşdırmasına (2025) görə, 400 sətirdən çox PR-lərin icmalı iki dəfə uzun çəkir və səhv aşkaretmə ehtimalı 30% azalır. Kod İncelemesi (Code Review) birləşdirmədən əvvəl kodun başqa tərtibatçı tərəfindən yoxlanılmasıdır.

IT Sectr-də hər PR üçün məcburi Kod İncelemesi tətbiq edirik. Bu təkcə kod keyfiyyətini yaxşılaşdırmır, həm də komanda daxilində bilik yayılmasına kömək edir. Kod İncelemesi yoxlayır: kod memarlıq prinsiplərinə uyğundurmu, səhv varmı, kifayət qədər test varmı, dəyişənlər düzgün adlandırılıbmı. Bütün şərhlər birləşdirməyə qədər PR-də müzakirə olunur.

Platformalar: GitHub, GitLab, Bitbucket

Git protokoldur, lakin əməkdaşlıq üçün veb interfeys, giriş idarəetməsi, CI/CD və icmal alətləri təmin edən versiya idarəetmə platforması lazımdır. Bazarda üç platforma üstünlük təşkil edir: GitHub, GitLab və Bitbucket.

GitHub 56 milyondan çox tərtibatçı ilə ən böyük platformadır. Microsoft-a məxsusdur, Actions (CI/CD), Pages (hosting), Discussions və Copilot təklif edir. Pulsuz plan 3 nəfərə qədər komandalar üçün limitsiz özəl depoları əhatə edir. GitHub açıq mənbə cəmiyyətində populyardır.

GitLab inteqrasiya olunmuş CI/CD, konteyner reyestri və infrastruktur idarəetməsi ilə tam DevOps platformasıdır. GitHub-dan fərqli olaraq, GitLab öz serverinizdə quraşdırıla bilər (Self-Managed). Atlassian-ın Bitbucket-ı Jira və Confluence ilə sıx inteqrasiya olunub, bu da onu artıq Atlassian ekosistemindən istifadə edən komandalar üçün seçim edir.