Rebase: nədir, necə işləyir və Git ilə iş

Git-də rebase nədir

Rebase — bu Git əmridir ki, cari budağı göstərilən bazaya yenidən yerləşdirir: cari budağın bütün commit-lərini götürür, onları müvəqqəti saxlayır, budaq göstəricisini hədəf commit-ə aparır və ardıcıl olaraq saxlanılmış commit-ləri onun üzərinə tətbiq edir. Nəticə — tarix elə görünür ki, sanki tərtibatçı birbaşa hədəf budağın son commit-indən işləyib.

Əsas sintaksis: git rebase main — feature budağında olarkən bu əmr bütün feature commit-lərini main-in təpəsinə köçürür. Git hər commit üçün ayrıca three-way merge strategiyasından istifadə edir. Əgər commit A hədəf budaqda artıq mövcuddursa (hash ilə müəyyən edilir), Git onu avtomatik olaraq keçir, bu da dəyişikliklərin təkrarlanmasının qarşısını alır.

Rebase həmçinin commit-lərin bir hissəsini köçürmək üçün onto rejimini dəstəkləyir: git rebase --onto target start end — bu forma bir budaqdan commit diapazonunu çıxarmağa və onları digərinin təpəsinə tətbiq etməyə imkan verir. Məsələn, git rebase --onto main feature~3 feature feature budağının son üç commit-ini main-in təpəsinə köçürəcək.

# Feature budağına keç
git checkout feature

# Feature-ı main-ə yenidən baza et
git rebase main

# Uğurlu rebase-dən sonra — tarix xəttidir
git log --oneline --graph

# Son 3 commit-i main-ə köçür
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: əsas fərqlər

Rebase və merge eyni tapşırığı həll edir — müxtəlif budaqlardan dəyişiklikləri birləşdirmək — lakin bunu prinsipial olaraq fərqli üsullarla edir. Merge iki valideyn ilə merge-commit yaradaraq tam birləşmə tarixini qoruyur. Rebase tarixi yenidən yazaraq onu xətti edir. Onların arasında seçim komandanın workflow-ündən və repozitoriya ilə iş qaydalarından asılıdır.

Əsas fərq — birləşmə faktının necə qeydə alınması. Merge qoruyur: “bu nöqtədə feature-ı main-ə birləşdirdik” — bu layihə tarixi üçün məlumatlandırıcıdır, lakin tez-tez birləşmələrdə jurnalı zibilləyir. Rebase göstərir: “feature commit-ləri main-in son vəziyyətindən ardıcıl olaraq edildi” — bu təmizdir, lakin işin paralel aparıldığı faktını gizlədir.

İkinci fərq — münaqişələrin işlənməsi. Merge-də münaqişələr bir dəfə həll edilir və həll merge-commit-də qeyd olunur. Rebase-də münaqişələr hər köçürülən commit üçün yarana bilər və hər biri ayrıca həll tələb edir. Bu daha zəhmətlidir, lakin son versiyaya hansı dəyişikliklərin daxil olacağını daha dəqiq idarə etməyə imkan verir.

İnteraktiv rebase: əmrlər və bayraqlar

İnteraktiv rebase (git rebase -i) — bu rejimdir ki, Git commit-lərin siyahısı və hər biri üçün mövcud hərəkətlərlə redaktoru açır. Tərtibatçı uzaq repozitoriyaya göndərməzdən əvvəl tarixi yenidən yaza bilər. Bu, feature budağında commit-lərin təmizliyini qorumaq üçün əsas vasitədir.

İnteraktiv rejimdə mövcud əmrlər: pick (commit-i olduğu kimi saxla), reword (commit mesajını dəyiş), edit (dəyişikliklər üçün dayan), squash (əvvəlki commit-lə birləşdir, hər iki mesajı saxla), fixup (mesajı ataraq birləşdir), drop (commit-i sil). Hər əmr açılan redaktorda commit hash-indən əvvəl göstərilir.

Squash və fixup — commit-ləri birləşdirmək üçün ən çox istifadə olunan əmrlər. Əgər tərtibatçı iş prosesində 5 kiçik düzəliş commit-i edibsə, squash onları mənalı mesajla bir məntiqi commit-də birləşdirir. Fixup səhvləri düzəltmək üçün faydalıdır: dəyişikliklər öz mesajını saxlamadan əvvəlki commit-ə daxil olur.

# Son 4 commit üçün redaktoru aç
git rebase -i HEAD~4

# Redaktor göstərəcək:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Saxladıqdan sonra — Git rebase-i yerinə yetirir
# və birləşdirilmiş commit mesajı üçün redaktoru açır

# Redaktoru açmadan auto-squash
git rebase -i HEAD~4 --autosquash

--autosquash bayrağı mesajları fixup! və ya squash! ilə başlayan commit-lər üçün avtomatik fixup/squash təyin edir. Bu, tərtibatçı əvvəlcədən commit-ləri sonrakı birləşmə üçün qeyd edərsə, işi sürətləndirir. --committer-date-is-author-date bayrağı yenidən bazalama zamanı commit-in orijinal tarixini qoruyur — tarixdə xronologiyanı saxlamaq üçün faydalıdır.

Rebase zamanı münaqişələrin həlli

Rebase zamanı münaqişələr Git hədəf budaqdakı dəyişikliklərlə ziddiyyət səbəbindən köçürülən commit-i avtomatik tətbiq edə bilmədikdə yaranır. Merge-dən fərqli olaraq, münaqişə bir dəfə həll edilir, rebase-də isə hər commit münaqişəyə səbəb ola bilər və onu ən köhnədən ən yenisinə qədər ardıcıl həll etmək lazımdır.

Münaqişə yarandıqda, Git rebase-i dayandırır və hansı commit-in problem yaratdığını bildirir. Tərtibatçı münaqişə edən faylı açır (Git münaqişə sahələrini <<<<<<<, =======, >>>>>>> işarələri ilə qeyd edir), onu redaktə edir, indeksə əlavə edir (git add) və git rebase --continue əmri ilə rebase-i davam etdirir. Həll tapılmazsa — git rebase --abort rebase-i tamamilə ləğv edir.

Məsləhət: çoxsaylı münaqişələrdə ziddiyyətləri həll etmək üçün vizual redaktoru açan git mergetool-dan istifadə etmək daha səmərəlidir. Həmçinin problemli commit-i keçmək olar (git rebase --skip), lakin bu, onun dəyişikliklərini son tarixdən siləcək ki, bu da nadir hallarda düzgün həll olur.

# Münaqişə ilə rebase-ə başla
git rebase main
# Auto-merging file.txt
# MÜNAQİŞƏ (məzmun): file.txt-də birləşmə münaqişəsi

# Statusu yoxla
git status
# hər ikisi dəyişdirilib: file.txt

# Münaqişəli hissələri düzəlt → git add → davam et
git add file.txt
git rebase --continue

# Şübhə varsa — ləğv et
git rebase --abort

Rebase nə vaxt edilməməlidir

Rebase-in qızıl qaydası: uzaq repozitoriyaya artıq göndərilmiş və digər tərtibatçılar üçün əlçatan olan commit-ləri heç vaxt yenidən bazalamayın. Rebase commit hash-lərini yenidən yazdığından, həmkarlarınız sinxronizasiya cəhdində münaqişələrlə qarşılaşacaq — onların lokal tarixi yenidən yazılmış uzaq tarixlə uyğunsuz olacaq.

Rebase-in qəti şəkildə qadağan olduğu vəziyyət: kimsə artıq sizin commit-ləriniz əsasında budaq yaradıbsa (məsələn, həmkarınız sizin feature-ınızdan feature edibsə), tarixin dəyişdirilməsi onun işini pozacaq. Belə hallarda merge istifadə edilməlidir. Həmçinin rebase-i son tarixdən dərhal əvvəl etmək tövsiyə edilmir — münaqişələrin həllində səhv gözləniləndən çox vaxt apara bilər və buraxılışı bloklaya bilər.

İstisna: budaq yalnız bir tərtibatçı tərəfindən istifadə olunursa (şəxsi feature budağı, dərc edilməmiş və ya draft rejimində dərc edilmiş), push-dan əvvəl rebase standart təcrübədir. Dərc etdikdən və kollektiv işə başladıqdan sonra — yalnız merge. GitHub və GitLab varsayılan olaraq squash merge-i kompromis kimi təklif edir: commit-ləri birinə birləşdirir, lakin hədəf budağın tarixini yenidən yazmır.

• İctimai budaqlar (main, develop, release) — rebase tamamilə qadağandır.
• Yad commit-lər — budaq başqa tərtibatçının commit-lərini ehtiva edirsə, rebase yolverilməzdir.
• Buraxılışdan əvvəl — münaqişə riski daha yüksəkdir: merge son tarixdən bir gün əvvəl daha təhlükəsizdir.
• Teqli budaqlar — teq ilə commit-i köçürmək semantik versiyalama konvensiyalarını pozur.
• CI/CD hash-lərə bağlıdırsa — bəzi yerləşdirmə sistemləri build-ləri commit hash-i ilə identifikasiya edir; rebase izləməni pozacaq.

Rebase ilə praktiki workflow

Müasir komandalarda ən çox rebase yönümlü workflow GitHub Flow ilə birlikdə istifadə olunur. Proses belə görünür: tərtibatçı main-dən feature budağı yaradır, orada işləyir, vaxtaşırı git rebase main vasitəsilə sinxronlaşır və pull request yaratmazdan əvvəl tarixi təmizləmək üçün interaktiv rebase edir.

PR yaratdıqdan sonra (main-dən yeni dəyişiklikləri çəkmək lazım olduqda) adi git pull əvəzinə git pull --rebase main istifadə olunur. Bu, lazımsız merge-commit yaratmadan dəyişiklikləri çəkməyə imkan verir. --rebase bayrağı ilə git pull git fetch + git rebase-ə ekvivalentdir — Git əvvəlcə yeni commit-ləri yükləyir, sonra lokal dəyişiklikləri onların üzərinə yenidən bazalayır.

Git pull üçün rebase-i standart davranış kimi təyin etməyə imkan verir: git config --global pull.rebase true. Bu konfiqurasiyadan sonra git pull həmişə merge əvəzinə rebase edir. Adi pull lazım olduqda — git pull --no-rebase istifadə olunur. Bir çox komandalar həmçinin autostash-ı aktivləşdirir: git config --global rebase.autoStash true — bu, rebase-dən əvvəl təsdiqlənməmiş dəyişiklikləri avtomatik gizlədir və sonra bərpa edir.