Repozitoriyanın yaradılması, rebase və məxfi məlumatlar

Bu məqalədə Git-in əsas iş dövrünü mənimsədikdən sonra qarşılaşacağınız üç mövzu bir araya gətirilib: repozitoriyanı necə yaratmaq (git init ilə və IDE-dən), rebase-in merge-dən nə ilə fərqləndiyi və təsadüfən tarixçəyə düşmüş məxfi məlumatı necə düzgün silmək. Bu mövzular Claude Code ilə işləyərkən də lazım olacaq: o, bu əməliyyatları əmrlərlə yerinə yetirir və onların arxasında nələrin dayandığını başa düşməyiniz vacibdir.

Nümunələr və interfeys görüntüləri JetBrains IDE-yə aiddir; əməliyyatların adları və yeri sizin versiyanızda fərqli ola bilər. Məşqlər üçün ayrıca təlim repozitoriyasından istifadə edin. İş layihəsində budaqlar, dəyişikliklərin qeydə alınması və göndərilməsi ilə bağlı onun qaydalarına əməl edin.

Repozitoriyanın yaradılması: git init və IDE

Layihə artıq GitHub-dadırsa, onu klonlaya bilərsiniz. Başqa bir vəziyyətdə isə kod olan yerli qovluğunuz var. git init həmin qovluqda Git-in xidməti məlumatlarını yaradır, amma ilk commit-i yaratmır. Aşağıdakı nümunədə README.md və .gitignore fayllarının artıq yaradılıb yoxlanıldığı, digər lazımi faylların isə ayrıca əlavə edildiyi nəzərdə tutulur.

git init
git status
# README və ignore qaydalarını yoxladıqdan sonra
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

IDE-də yerli repozitoriya yaratmaq üçün Git repozitoriyasının yaradılması və ya versiyaya nəzarətin aktivləşdirilməsi seçimindən istifadə edin. Share Project on GitHub ayrıca ssenaridir: bu seçim uzaq repozitoriya da yaradır və dəyişiklikləri göndərməyi təklif edir. Göndərməzdən əvvəl seçilmiş faylları, tarixçəni və görünürlük parametrini yoxlayın.

Public və ya private

Repozitoriya yaradarkən onun görünürlüyünü seçirsiniz:

• public - repozitoriya internetdə hamıya görünür və kodu istənilən şəxs görə bilər. Portfolio və open source üçün uyğundur;
• private - yalnız sizin və dəvət etdiyiniz şəxslərin girişi var. Göstərilməsi uyğun olmayan iş və təlim kodu üçün bu, standart seçimdir.

Görünürlük dəyişməz deyil: onu sonradan GitHub-dakı repozitoriya tənzimləmələrində dəyişə bilərsiniz.

rebase və merge arasındakı fərq

Həm merge, həm də rebase eyni məsələni həll edir: bir budaqdakı işi digərinə daşıyır. Amma bunu fərqli üsullarla edirlər və layihə tarixçəsinin necə görünəcəyi də bundan asılıdır.

merge tarixçələri birləşdirir. Budaqlar ayrılıbsa, adətən iki valideyni olan merge commit yaranır. Cari budaq digərinin əcdadıdırsa, Git yeni commit yaratmadan fast-forward edə bilər. Aşağıdakı diaqramda məhz ayrılmış budaqlar göstərilir.

merge hər iki xətti saxlayır və merge commit əlavə edir. Tarixçədə ayrıca feature budağının olduğu aydın görünür.

rebase commit-lərinizi elə daşıyır ki, sanki işə hədəf budağın ən son commit-indən başlamısınız. Tarixçə düz xətt kimi ardıcıl olur. Amma bunun bir bədəli var: rebase commit-lərinizi yenidən yazır: köhnələrin yerinə fərqli hash-ləri olan yeniləri yaranır.

Rebase-dən sonra C və D commit-ləri sanki E-nin üzərində yaradılmış kimi görünür: tarixçə xəttidir, amma bunlar artıq hash-ləri fərqli olan yeni commit-lərdir (C2, D2).

Hansını seçməli:

• merge - həqiqi tarixçəni saxlamaq vacibdirsə və budaq ortaq istifadə olunursa. Standart halda daha təhlükəsiz seçimdir;
• rebase - pull request açmazdan əvvəl şəxsi budağınızı səliqəyə salmaq üçün: xətti tarixçəni oxumaq daha asandır.

Məxfi məlumatların repozitoriyadan silinməsi

Faylı yeni commit-də silmək məxfi məlumatı əvvəlki commit-lərdən silmir. Parol və ya token başqalarına əlçatan olubsa, əvvəlcə onu verən xidmətdə etibarsızlaşdırın və ya yenisi ilə əvəz edin. Tarixçəni təmizləmək artıq yaradılmış nüsxələri yox etmir.

Tarixçəni təmizləmək üçün GitHub git-filter-repo ilə prosedur təsvir edir. Konkret əmrlər faylın tam silinməsindən, yoxsa məxfi sətrin əvəz edilməsindən, onun harada rast gəlindiyindən və tarixçənin hara ötürüldüyündən asılıdır. Təzə nüsxə yaratmaq, nəticəni yoxlamaq, uzaq istinadları yeniləmək və həmkarların görəcəyi işlər də daxil olmaqla, həssas məlumatların silinməsi ilə bağlı rəsmi təlimata əməl edin.

Yerli nüsxəni təmizləmək serveri dəyişmir. Yenidən yazılmış tarixçəni force push etmək ayrıca razılaşdırılmalı addımdır: burada bütün budaqlar üçün ümumi bir əmr icra etmək lazım deyil. Başqalarının klon və fork-larındakı nüsxələr sizin nəzarətinizdə deyil; əlçatan GitHub linkləri və keşlərlə bağlı Support-a müraciət şərtləri həmin təlimatda göstərilib.

Yenidən baş vermə ehtimalını azaltmaq üçün:

• məxfi dəyərləri koddan kənarda, məsələn, mühit dəyişənlərində saxlayın;
• .env kimi yerli faylları Git izləməyə başlamazdan əvvəl .gitignore-a əlavə edin;
• commit-dən əvvəl seçilmiş faylları və git diff --cached nəticəsini yoxlayın;
• repozitoriya üçün secret scanning və push protection əlçatandırsa, əlavə yoxlama kimi aktivləşdirin: onlar mümkün olan bütün məxfi məlumatları aşkarlamır.

Claude Code ilə birlikdə necə işləyir

Claude Code repozitoriya ilə işləyəndə bu üç mövzu da gündəmə gəlir. Bunlara diqqət edin:

• repozitoriyanı başlada (git init) və ilk commit-i hazırlaya bilər; GitHub-da yaradarkən public və ya private seçimini özünüz edirsiniz;
• layihənin qaydalarına əsasən birləşdirmə üsulu təklif edir; başlamazdan əvvəl merge və rebase-in nəticələrini yoxlayın;
• commit-ə düşən faylları görür, amma məxfi məlumatın ora sızmamasına görə son məsuliyyət yenə sizin üzərinizdədir.

Əvvəlki məqalə: Git-də dəyişikliklərin ləğvi və bərpası