Çfarë është Git Rebase dhe si është i ndryshëm nga bashkimi?

Bashkimi dhe ribazimi përmbushin qëllime të ngjashme, por shkoni rreth tyre në mënyra të ndryshme. Të dyja ndihmojnë në menaxhimin e punës me degë dhe bashkëpunimin me shumë njerëz, por ato nuk janë të këmbyeshme dhe ribazimi mund të jetë i dëmshëm nëse nuk bëhet siç duhet.

Cila është marrëveshja me ribazimin?

Ribazimi është shumë i ndërlikuar, kështu që është e rëndësishme të kuptojmë se si funksionon git nën kapuç, nëse do ta kuptojmë atë.

Git ruan kodin tuaj si një seri modifikimesh. Ju mund ta mendoni këtë si një zinxhir, duke punuar mbrapsht. Çdo modifikim, ose kommit, i referohet ID-së së kryerjes së mëparshme dhe përfshin atë që ka ndryshuar nga kryerja e mëparshme. Ky zinxhir ruhet vetëm në kompjuterin tuaj; klienti juaj Git nuk flet me asnjë klient tjetër Git përveç nëse po kryen një marr ose shtytje (pull është në të vërtetë vetëm fetch + bashko me degën tënde lokale), dhe madje edhe atëherë, ai po flet vetëm me një depo të përbashkët në distancë.

Degët janë më të ndërlikuara. Git ruan vetëm një gjë kur kemi të bëjmë me degë: ID-në e kryerjes në fund të degës. Në këtë mënyrë, ju mund t'i mendoni ato si koka e luajtjes në një lojtar diskografike; ju e vendosni kokën e degës në një pozicion të caktuar dhe ajo rikthehet përmes zinxhirit, duke luajtur kodin tuaj dhe duke arritur në një version përfundimtar. Sa herë që kryeni, klienti juaj lokal i git do të lëvizë automatikisht kryesimin e luajtjes përpara në kryerjen e re.

Nëse dëshironi të bashkoni funksionin në master, do të ekzekutoni:

git checkout master
git merge feature

Kjo krijon një bashkim të ri, dhe nëse ka ndonjë konflikt, do t'ju duhet t'i zgjidhni ato manualisht. Komanda bashkimi i git lëviz kokën kryesore të luajtjes në komitetin e ri të bashkimit dhe fshin kokën e luajtjes së veçorive, pasi nuk është më e nevojshme.

Kjo metodë e bashkimit të kodit paraqet tre probleme:

• Mund të ketë ndryshime në degën kryesore që dega e veçorive do të donte të përfshinte, veçanërisht nëse funksioni kërkon pak kohë për t'u zhvilluar.
• Të jesh i detyruar të kalosh procesin e bashkimit sa herë që dëshiron të punosh me degë është e bezdisshme.
• Historia e kryerjes është e çrregullt, megjithëse ky është kryesisht një problem estetik.

Rebasing përpiqet t'i zgjidhë këto çështje, në shkallë të ndryshme suksesi. Ribazimi i ndryshimeve ku keni filluar degën tuaj. E gjithë dega ngrihet lart dhe transportohet në fund të degës kryesore aktuale, ku lidhet deri në fund. Dega kryesore është lënë e paprekur dhe është e lirë të vazhdojë të marrë zotime.

Megjithatë, kryerjet nuk janë lëvizur, pasi që detyrimet janë të pandryshueshme. Përkundrazi, ato kopjohen, gjë që rezulton në ID të reja të kryerjes. Kryerjet e mëparshme mbeten të bllokuara, duke u fshehur në skedarët tuaj Git, por nuk do të shihen më kurrë, pasi koka e luajtjes është zhvendosur diku tjetër.

Për të ekzekutuar këtë proces nga linja e komandës, duhet të ekzekutoni:

git checkout feature
git pull
git rebase master

Kjo hap degën, tërheq ndryshimet aktuale në master dhe më pas ribazon degën e veçorive në degën kryesore.

Në këtë pikë, kodi në degën e veçorive është tani më i përditësuar, që është veçoria e vetme reale e git rebase. Ribazimi nuk bashkon degët, pasi nuk krijon asnjë detyrim bashkimi ose nuk lëviz kryesuesin e lojës.

Nëse dëshironi të bashkoheni pas ribazimit, do të ekzekutoni:

git checkout master
git merge feature

Që do të dukej kështu, me kokën e luajtjes së masterit që zëvendëson kokën e luajtjes së veçorive:

Pra, ribazimi nuk përfundon në zgjidhjen e problemit të trajtimit të bashkimeve, pasi do t'ju duhet gjithsesi të bashkoheni në fund për të përditësuar degën kryesore. Sidoqoftë, komanda aktuale bashkimi në fund duhet të funksionojë pa probleme, pasi procesi i ribazimit kërkon që ju të bashkoni në ndryshime, të cilat ende mund të shkaktojnë konflikte. Dhe nëse dëshironi të vazhdoni të punoni në degën tuaj, ju ende duhet të bashkoni në ndryshime.

Mos i ribazoni degët e përbashkëta

Mbani mend se si ribazimi i kopjeve angazhohet dhe lë një kokë të bllokuar? Kjo është në të vërtetë një çështje kryesore nëse jeni duke punuar me kod të përbashkët. Le të themi se keni krijuar degën e veçorive dhe e shtyni atë në depon tuaj në mënyrë që bashkëpunëtorët tuaj ta testojnë atë. Kjo është krejtësisht në rregull, por nëse njëri prej tyre donte të degëzohej nga dega juaj, kur ju përfundimisht ribazoni, përfundoni me këtë:

Dega tipare2 e kolegut tuaj tani po i referohet një zinxhiri të vjetër angazhimesh. Klienti juaj Git nuk ka asnjë mënyrë për ta ditur këtë, pasi dega e funksionit 2 ruhet në kompjuterin e kolegut tuaj. Ata gjithashtu nuk kanë asnjë mënyrë për të ditur se keni ribazuar derisa të shtyni ndryshimet tuaja.

Kur ribazove, ai nuk kopjoi degën e tipareve2 kur kopjoi të gjitha kryerjet. Edhe nëse do të mundej, nuk do të ndikonte në repon lokale Git të kolegut tuaj, duke e bërë gjithçka jashtë sinkronizimit. Zgjidhja këtu do të ishte ribazimi i veçorisë 2 në veçori në vendin ku do të ishte, por kjo është e çrregullt, edhe sipas standardeve të Git, dhe ky është vetëm një shembull shumë i thjeshtë.

Në fund të fundit, mos ribazoni nëse nuk jeni duke punuar në nivel lokal.

Kur është më mirë ribazimi sesa bashkimi?

Nëse dega juaj do të marrë pak kohë për t'u zhvilluar, ribazimi zgjidh çështjen e sindromës së degës, ku kodi juaj është shumë i vjetëruar me masterin që punon dhe ju duhet ta përditësoni atë për të vazhduar punën. Duke folur në përgjithësi, duhet të përpiqeni ta shmangni këtë problem sa më shumë që të jetë e mundur, por ribazimi mund ta rregullojë atë kur të lindë.

Nëse thjesht po bëni ndryshime të vogla, në rritje, ditore, duhet të punoni në një degë kryesore lokale dhe të përdorni Kërkesat për tërheqje kur të jeni gati të shtyni ndryshimet tuaja. Këto përdorin modelin e degëve aktuale, të krijuara posaçërisht për të ruajtur kodin tuaj përpara se të miratohet për një bashkim.

Por, nëse jeni duke punuar në një hark kohor javor dhe do të përfundoni duke bërë kërkesa të shumta tërheqjeje dhe bashkim disa herë, mund të punoni në kodin tuaj për pak më gjatë, të ribazoni në nivel lokal për përditësime dhe të kryeni një kërkesë tërheqjeje në fund për të ulur sasinë e testimit dhe bisedës me mbikëqyrësit. Ribazimi është kryesisht një gjë lokale, kështu që ju mund ta bëni atë në degët tuaja të skenimit pa pritur miratimin.

Nëse askush tjetër nuk varet nga dega juaj, ju mund të ribazoni përpara se një degë të bashkohet për ta bërë historinë e kryerjes të pastër dhe njëdimensionale. Megjithëse, dikush mund të argumentojë se bashkimi tradicional, megjithëse sigurisht më i shëmtuar, është më i lehtë për t'u ndjekur dhe korrigjuar, pasi kryerjet e bashkimit janë krejtësisht jo-shkatërruese. Sido që të jetë, ribazimi duhet të bëhet menjëherë përpara se ndryshimet tuaja të bashkohen, ose mund të hasni në problemin e përditësimit të Masterit përpara se ndryshimet tuaja të miratohen.