Rebase: bu nədir, Merge-dən nə ilə fərqlənir və iş prinsipi

Rebase nədir?

Rebase (bazanın dəyişdirilməsi) — cari budaqdan commitləri yeni istinad nöqtəsinə (bazaya) köçürən Git əməliyyatıdır. Merge commiti yaratmaq əvəzinə, rebase hər bir commiti mənbə budaqdan götürərək növbə ilə yeni baza üzərinə tətbiq edir. Nəticədə budaqlanmalar olmadan xətti commit ardıcıllığı əldə edilir.

Rebase adı „re-base" — bazanı dəyişmək mənasından gəlir. Əgər merge iki budağı bir nöqtədə birləşdirirsə, rebase sanki bütün budağınızı yeni bir yerə köçürür, işə hədəf budağın cari vəziyyətindən başladığınız illüziyasını yaradır. Bu, ideallaşdırılmış ardıcıl iş təəssüratı yaradır.

Atlassian, 2025 məlumatına görə, feature budaqları üçün rebase istifadə edən komandalar commit tarixçəsini təhlil etməyə yalnız merge istifadə edən komandalarla müqayisədə 30% daha az vaxt sərf edirlər. Xətti tarixçə git blame, bisect və git log --oneline vasitəsilə jurnalın baxışını sadələşdirir.

Merge-dən əsas fərq

Merge iki valideynli commit yaradaraq budaqları birləşdirir. Rebase tarixçəni yenidən yazır: yeni commitlər orijinal dəyişikliklərlə eyni olsa da, yeni hash-lərlə təzədən yaradılır. Bu o deməkdir ki, rebase commit-lərin SHA identifikatorlarını dəyişir ki, bu da ictimai budaqlar üçün kritikdir.

Rebase necə işləyir

Rebase mexanizmi dörd addımdan ibarətdir: Git cari və hədəf budağın ortaq əcdadını (merge base) müəyyən edir, sonra cari budağın hər bir commitini ardıcıl olaraq hədəf budaq üzərinə tətbiq edir. Əgər hansısa addımda konflikt yaranarsa — rebase dayanır və həllini gözləyir.

# Başlanğıc vəziyyəti: feature develop-dan 3 commit geridədir
git checkout feature/new-login
git rebase develop

# Git feature-dan 3 commit götürür ve onları develop üzərinə tətbiq edir
# Konflikt yoxdursa — rebase avtomatik tamamlanır
# Varsa — Git konfliktli commitdə dayanır

Rebase-dən sonra feature budağı develop-dan bütün commitləri və öz commitlərini ehtiva edir, bunlar develop-in davamı kimi görünür. Bu, merge commiti yaratmadan develop-ə fast-forward vasitəsilə birləşdirməyə imkan verir.

Addım-addım proses

Ətraflı nümunəyə baxaq: proqramçı develop-dan feature budağı yaratdı, iki commit etdi, bu müddətdə digər proqramçılar develop-a üç commit əlavə etdilər. Rebase feature-ın iki commitini yeni yerə köçürərək yeni SHA-larla surətlərini yaradır.

# 1. Feature budağı yaratmaq
git checkout -b feature/payment-refactor develop

# 2. Feature-da commitlər etmək
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Develop-ı yeniləmək (həmkarların işi)
git checkout develop
git pull

# 4. Feature-ı yeni develop üzərinə rebase etmək
git checkout feature/payment-refactor
git rebase develop

# 5. İndi feature fast-forward vasitəsilə birləşdirilə bilər
git checkout develop
git merge feature/payment-refactor

4-cü addımda konflikt yaranarsa, Git problemli commitdə dayanır. Proqramçı konflikti həll edir, git add edir və git rebase --continue icra edir. Commiti atlamaq lazımdırsa — git rebase --skip, bütün rebase-i ləğv etmək üçün — git rebase --abort.

Boş commitlərin avtomatik atlanması

--empty flagı boş commitlərdə rebase davranışını idarə edir — commit-in bütün dəyişikliklərinin artıq hədəf budaqda mövcud olduğu vəziyyətlər. Susmaya görə rebase dayanır və qərar tələb edir. --empty=drop flagı ilə Git belə commitləri dayanmadan avtomatik atlayır, bu da çox sayda commit ilə kütləvi bazanın dəyişdirilməsini sürətləndirir.

İnteraktiv Rebase

Interactive rebase (git rebase -i) — commit tarixçəsini redaktə etmək üçün güclü vasitədir. O, commit siyahısı və əsas əmrlərlə redaktor açır: pick (saxla), reword (mesajı dəyiş), edit (məzmunu dəyiş), squash (əvvəlki ilə birləşdir), fixup (mesaj olmadan birləşdir), drop (sil).

# Son 4 commit-in interaktiv rebase-i
git rebase -i HEAD~4

# Redaktorda rebase planı açılacaq:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Dəyişdiririk:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Nəticə: üç commit (giriş ekranı, validasiya, tərtibat) birinə sıxışdırıldı, şərhləri olan commit silindi. Bu, kod baxışına qaralama və düzəlişlər olmadan təmiz tarixçə təqdim etməyə imkan verir. Interactive rebase — Pull Request-dən əvvəl feature budağının hazırlanması üçün standart vasitədir.

Rebase vs Merge: müqayisə

Rebase və Merge eyni tapşırığı — dəyişikliklərin inteqrasiyasını — həll edir, lakin prinsipial olaraq fərqli üsullarla. Onlar arasında seçim git log-da hansı tarixçəni görmək istədiyinizdən və budağınızla kimin işlədiyindən asılıdır.

Praktik qayda: ortaq budaqlara (develop, main) inteqrasiya üçün merge, şəxsi feature budaqlarını aktual vəziyyətə gətirmək üçün rebase istifadə edin. Bir çox komandalar birləşdirir: feature-ı develop-a rebase, sonra develop-a --no-ff merge.

git bisect-ə təsir

Git bisect — reqressiyaya səbəb olan commiti tapmaq üçün vasitədir. Merge istifadə edərkən git bisect hər iki valideyni nəzərə alaraq birləşmə commitlərindən düzgün keçir. Rebase-də bisect daha sürətli işləyir, çünki tarixçə xəttidir və budaqlanma tələb etmir. Lakin rebase commitlər komandaya məlum olduqdan sonra edilibsə, orijinal SHA itirilir və bisect problemli commiti tapa bilməz.

Rebase nə vaxt tətbiq edilməlidir

Rebase üç ssenaridə optimaldır: feature budağının Pull Request-ə hazırlanması, şəxsi budağın main/develop-ın cari vəziyyətinə yenilənməsi və birləşmədən əvvəl tarixçənin təmizlənməsi. Hər bir halda rebase komanda işi üçün risk olmadan tarixçənin oxunaqlılığını yaxşılaşdırır.

Pull Request qarşısında iş commitlərini (WIP, rəydən sonra düzəlişlər) mənalı məntiqi vahidlərə birləşdirmək üçün interactive rebase icra etmək tövsiyə olunur. Bu kod nəzərdən keçirməsini asanlaşdırır: rəyçi 15 xırda commit deyil, anlaşılan mesajlarla 3-5 strukturlaşdırılmış dəyişiklik görür.

Feature budağının yenilənməsi üçün rebase merge-dən üstündür, çünki o, lazımsız birləşmə commitləri yaratmır. Feature budağında vaxtaşırı git rebase develop etsəniz, son birləşmədən sonra 10 birləşmə commiti kaskadı olmayacaq — yalnız develop üzərində təmiz funksiya commitləri.

Tarixçənin təmizlənməsi birləşmədən əvvəl interactive rebase vasitəsilə kiçik düzəlişləri (səhv hərflər, formatlaşdırma) gizlətməyə və commitləri funksionallığa görə qruplaşdırmağa imkan verir. Git mesajları Conventional Commits (fix:, feat:, refactor:, docs:) razılaşmasına uyğun olmalıdır ki, bu da avtomatik changelog yaradır.

Rebase riskləri və qaydaları

Rebase — səhv tətbiq edildikdə təhlükəli əməliyyatdır. Əsas risk — dərc edilmiş tarixçənin yenidən yazılması. Əgər proqramçı başqalarının artıq push etdiyi və istifadə etdiyi budağı rebase edərsə, onların yerli surətləri sinxronizasiyanı itirər və məlumat itkisi riski ilə force-pull etməli olarlar.

• Qızıl qayda: ortaq repozitoridə artıq mövcud olan commitləri heç vaxt rebase etməyin. Bu, komandanın digər üzvlərinin çıxışı olan istənilən budaqlara aiddir
• Force push: yerli feature budağının rebase-indən sonra --force-with-lease flagı ilə push tələb olunur, bu --force-dan təhlükəsizdir, çünki serverdə budağı kiminsə yenilədiyini yoxlayır
• Kontekstin itirilməsi: rebase feature budağının nə vaxt və hansı budaqdan yaradıldığı barədə məlumatı məhv edir. Budağın yaradılma tarixlərini qorumaq vacibdirsə — merge istifadə edin
• Konfliktlər: rebase zamanı konfliktlər hər bir commit üçün ayrıca həll edilməlidir, bu da çox sayda commit olduqda yorucu ola bilər

Riskleri minimuma endirmək üçün qaydaya əməl edin: rebase yalnız dərc edilməmiş şəxsi budaqlar üçün. Budaq artıq ortaq repozitoridədirsə — --no-ff ilə merge istifadə edin. Dərc edilmiş budağın rebase-i zəruridirsə — komandanı xəbərdar edin və force push-u əvvəlcədən razılaşdırın.

Təhlükəli rebase-dən avtomatik qorunma server-side hooks vasitəsilə həyata keçirilir: Git server tərəfində pre-receive hook push-un dərc edilmiş commitləri yenidən yazıb-yazmadığını yoxlaya bilər. GitHub və GitLab qorunan budaqlar üçün daxili qoruma təmin edir — administrator tərəfindən qoruma ləğv edilməyibsə, force push bloklanır.