3.6 Git branĉantaj - Rebasing

Uzante Git, estas du ĉefaj manieroj integri ŝanĝoj de unu branĉo al alia: la merge kaj la rebase . En ĉi tiu sekcio vi lernos kio rebasing estas, kiel fari ĝin, tial ĝi estas bela mirinda ilo, kaj en kio kazoj vi ne volas uzi ĝin.

La Bazaj Rebase

Se vi reiros al pli frua ekzemplo de Bazaj kunfalado , vi povas vidi ke vi disiĝis vian laboron kaj faris interna du malsamaj branĉoj.

Figuro 3-27. Simpla diferenca historio

La plej facila maniero por integri la branĉoj, kiel ni jam kovrita, estas la merge komando. Ĝi realigas tridirekta kunfandas inter la du lastaj branĉo instantáneas ( C3 kaj C4 ) kaj la plej lastatempa komuna prapatro de la du ( C2 ), kreante nova instantánea (kaj faris).

Figuro 3-28. Miksante integri diverĝis laboro historio

Tamen, ekzistas alia vojo: vi povas preni la diakilo de la ŝanĝo kiu estis enkondukita en C4 kaj rekandidatiĝi ĝin sur C3 . En Git, tio nomiĝas rebasing. Kun la rebase komando, vi povas preni ĉiuj ŝanĝoj kiuj estis faritaj sur unu brancxo kaj revidigi ilin sur alia.
En ĉi tiu ekzemplo, oni kredus kuri la jenaj:

  $ Git kaso eksperimento
 $ Git rebase mastro
First, rewinding head to replay your work on top of it...
Applying: added staged command 

Funkcias irante al la komuna praulo de la du branĉoj (la unu vi estas sur kaj tiu kiun vi rebasing sur), alvenante la malsamoj enkondukita de ĉiu faras de la branĉo vi estas sur, ŝparante tiujn ŝanĝoj al intertempaj dosieroj , recomposición la aktuala branĉo al tion transdonu al la branĉo vi rebasing sur kaj fine aplikanta ĉiu ŝanĝo laŭvice.

Figuro 3-29. Rebasing la ŝanĝo enkondukita en C4 sur C3

Ĉe tiu punkto, vi povas reiri al la master branĉo kaj fari rapida antaŭen merge.

  $ Git kaso mastro
 $ Git merge eksperimento 

Kalkuli 3-30. Fast-plusendanta la mastro branĉo

Nun la instantánea almontras C4' estas ekzakte la sama kiel la unu kiu almontras C5 en la merge ekzemplo. Ne ekzistas diferenco en la produkto fino de la integriĝo, sed rebasing faras por pura historio. Se vi ekzamenos la ŝtipo de rebased branĉo, ĝi aspektas kiel lineara historio: ĝi similas ke ĉiuj laboroj okazis en serio, eĉ kiam ĝi origine okazis en paralela.
Ofte, vi faros tion certigi via interna apliki pure sur fora branĉo - eble en projekto al kiu vi provas kontribui sed vi ne subtenas. En tiu kazo, vi volas fari vian laboron en branĉo kaj tiam rebase via laboro sur origin/master kiam vi pretas sendi vian batitaj al la ĉefa projekto. Tiel, la administranto ne devas fari ajnan integriĝo laboro - simple rapida antaŭen aŭ pura apliki.
Notu ke la instantánea almontras la fina commit vi finos kun, ĉu ĝi estas la lasta de la rebased interna por rebase aŭ la fina merge fari post merge, estas la sama instantánea - estas nur la historio kiu estas malsama. Rebasing ripetoj ŝanĝoj de unu linion de laboro al alia en la ordo estis enkondukita, dum kunfandado prenas la finpunktoj kaj kunfandas ilin.

Pli Interesaj Rebases

Vi povas ankaŭ havi vian rebase ripetmatĉo sur io alia ol la rebase celo branĉo. Preni historion kiel Figuro 3-31 , ekzemple. Vi ramificado temo branĉo ( server ) aldoni iun servilo-flanko funcionalidad al via projekto kaj faris commit. Tiam, vi disbranĉiĝis ke fari la kliento-flanko ŝanĝoj ( client ) kaj faris kelkajn fojojn. Fine, vi reiris al via servilo branĉo kaj faris kelkajn pli interna.

Kalkuli 3-31. Historio kun temo branĉo de alia temo branĉo

Supozi vi decidas ke vi volas kunfandi viajn kliento-flanko ŝanĝojn en via ĉeftendenca por liberigo, sed vi volas teni ekstere sur la servilo-flanko ŝanĝoj ĝis ĝi estas provita plu. Vi povas preni la ŝanĝojn sur kliento kiuj ne estas en servilo ( C8 kaj C9 ) kaj revidigi ilin sur via master branĉo uzante la --onto eblo de git rebase :

  $ Git rebase --onto mastro servilo kliento 

Ĉi esence diras, "Legu la kliento branĉo, diveni la makulojn de la komuna praulo de la client kaj server branĉoj, kaj tiam ripeti ilin sur master ." Estas iom kompleksa, sed la rezulto estas sufiĉe malvarmaj.

Kalkuli 3-32. Rebasing temo branĉo de alia temo branĉo

Nun vi povas rapide plusendu via master branĉo (vidu Figuro 3-33 ):

  $ Git kaso mastro
 $ Git merge kliento 

Kalkuli 3-33. Fast-plusendanta via mastro branĉo inkludi la kliento branĉo ŝanĝoj

Diru vi decidas tiri en via servilo branĉo ankaŭ. Vi povas rebase la servilo branĉo sur la master branĉo sen devi kontroli ĝin unue por kuri git rebase [basebranch] [topicbranch] - kiu kontrolas la temon branĉo (en tiu kazo, server ) por vi kaj ripetoj ĝin sur la bazo branĉo ( master ):

  $ Git rebase mastro servilo 

Tiun Ripetoj via server laboro sur supro de via master laboro, kiel montrita en Figuro 3-34 .

Kalkuli 3-34. Rebasing via servilo branĉo sur supro de via sinjoro branĉo

Tiam, vi povas rapide plusendu la bazo branĉo ( master ):

  $ Git kaso mastro
 $ Git merge servilo 

Vi povas forigi la client kaj server branĉoj ĉar ĉiuj la laboro estas integrita kaj vi ne bezonas ilin plu, lasante via historio por ĉi tiu tuta procezo aspektas kiel Figuro 3-35 :

  $ Git branĉo -d kliento
 $ Git branĉo -d servilo 

Kalkuli 3-35. Fino commit historio

La Danĝeroj de Rebasing

Ahh, sed la feliĉo de rebasing ne estas sen malavantaĝoj, kiuj povas resumi en sola linio:
Ne rebase interna kiuj ekzistas ekster via deponejo.
Se vi sekvas ke gvidlinio, vi estos bone. Se ne, homoj malamos vin, kaj vi estos malestimis de amikoj kaj familio.
Kiam vi rebase stuff, vi forlasante ekzistanta interna kaj kreante novaj kiu estas similaj sed malsamaj. Se vi puŝas faras ie ​​kaj aliaj tiri ilin malsupren kaj bazo laboron sur ilin, kaj tiam vi reverki tiujn interna kun git rebase kaj puŝi ilin supren denove, via kunlaborantoj devos re-kunfandi ilian laboron kaj aĵoj ricevos senorda kiam vi provas tiri sian laboron reen en via.
Ni rigardu ekzemplon de kiel rebasing laboro ke vi faris publikan povas kaŭzi problemojn. Supozi vi kloni de centra servilo kaj tiam fari iun laboron ekstere tiel. Via commit historio aspektas jene:

Kalkuli 3-36. Kloni deponejo, kaj bazo iu laboro sur ĝi

Nun, iu alia faras pli laboro kiu inkludas merge kaj puŝas tiun laboron al la centra servilo. Vi prenu gxin kaj kunfandi la nova fora branĉo en via laboro, farante vian historion aspektas tiel:

Kalkuli 3-37. Venigu plej interna kaj kunfandi ilin en via laboro

Tuj poste, la persono kiu puŝis la kunfandita laboron decidas iri reen kaj rebase ilia laboro anstataŭe; ili faras git push --force anstataŭigi la historio sur la servilon. Vi tiam venigu de tiu servilo, alportanta malsupren la nova interna.

Kalkuli 3-38. Iu pelas rebased interna, forlasante interna vi bazita vian laboron

Nun vi estas ambaŭ en piklaĵo. Se vi faros git pull , vi kreos merge commit kiu inkluzivas ambaŭ linioj de la historio, kaj via deponejo aspektos tiel ĉi:

Figuro 3-39. Vi kunfandi en la sama laboro denove en novan merge commit

Se vi kuras git log kiam via historio similas tiun, vi vidos du interna kiuj havas la saman aŭtoron, daton, kaj mesaĝo, kiu estos konfuza. Plue, se vi puŝas tiun historion reen al la servilo, vi reenkonduki ĉiuj rebased interna al la centra servilo, kiu povas plui konfuzi homojn. Estas bela sekure supozi ke la aliaj desarrollador ne volas C4 kaj C6 esti en la historio; tial ili rebased en la unua loko.

Rebase Kiam Vi Rebase

Se vi ja trovas vin mem en situacio kiel tiu, Git havas iuj pli magion kiu povus helpi vin. Se iu en via teamo forto puŝas ŝanĝojn kiuj anstatauxigas laboro ke vi bazis laboro sur via defio estas elkompreni kio estas via kaj kio ili jam reskribita.
Ĝi rezultas ke krom la commit SHA-1 checksum, Git ankaŭ kalkulas checksum kiu estas bazita nur sur la diakilo enkondukita kun la commit. Tio nomiĝas "diakilo-identigilo".
Se vi tiri malsupren laboro kiu estis reskribita kaj rebase sur supro de la nova interna de via partnero, Git povas ofte sukcese diveni kio estas unike via kaj apliki ilin reen sur la nova branĉo.
Ekzemple, en la antaŭa scenaro, se anstataŭ faranta merge kiam ni estas en Figuro 3-38 ni kuras git rebase teamone/master , Git volo:

• Determini kion laboro estas unika al nia branĉo (C2, C3, C4, C6, C7)
• Determini kiuj ne kunfalas interna (C2, C3, C4)
• Determini kiu ne estis reskribita en la cela branĉo (ĵus C2 kaj C3, kiam C4 estas la sama diakilo kiel C4 ')
• Apliki tiujn interna al la supro de teamone/master

Do anstataŭ la rezulton ni vidas en Figuro 3-39 , ni finus kun io pli da kiel Figuro 3-40 .

Kalkuli 3-40. Rebase aldone forto-puŝis rebase laboro.

Tiu nur funkcias se C4 kaj C4 'ke via partnero faras preskaŭ ekzakte la sama diakilo. Alie la rebase ne povos diri ke ĝi estas duplikato kaj aldonos alian C4-kiel diakilo (kiu verŝajne malsukcesos apliki pure, ekde la ŝanĝoj jam estus almenaŭ iom tie).
Vi povas ankaŭ simpligi tion kurante git pull --rebase anstataŭ normala git pull . Aŭ vi povus fari ĝin manualmente kun git fetch sekvita per git rebase teamone/master en tiu kazo.
Se vi uzas git pull kaj volas fari --rebase la defaŭlta, vi povas agordi la pull.rebase config valoro kun iu kiel git config --global pull.rebase true .
Se vi traktas rebasing kiel maniero purigi kaj labori kun interna antaux vi puŝi ilin, kaj se vi nur rebase interna kiuj neniam estis disponebla publike, tiam vi estos bone. Se vi rebase interna kiuj jam puŝis publike, kaj homoj povas esti bazita laboron sur tiuj interna, tiam vi povas esti en por iu frustrante mizero, Kaj malestimo de via samteamanoj.
Se vi aŭ partnero ne trovas ĝin necesa en iu momento, certigu ĉiuj scias kuri git pull --rebase provi fari la doloro post okazas iomete pli simpla.

Rebase vs. Kunfandi

Nun ke vi vidis rebasing kaj kunfando en ago, vi eble scivolas kiu unu estas bona. Antaŭ ol ni povas respondi tion, ni retropaŝi iom kaj paroli pri kio historio rimedoj.
Unu vidpunkton sur ĉi estas ke via deponejo de fari historio estas rekordo de kio vere okazis. Ĝi estas historia dokumento, valoraj en sia propra rajto, kaj oni ne difektis. De tiu angulo, ŝanĝante la commit historio estas preskaŭ blasfema; Vi mensogas pri kio vere okazis. Do kio se ekzistis senorda serio de merge faras? Tiel estas kiel ĝi okazis, kaj la deponejo devus konservi ke por la posteularo.
La kontraŭa vidpunkto estas ke la commit historio estas la historio de kiel via projekto estis farita. Vi ne publikigas la unuan malneton de libro, kaj la manlibro por kiel subteni vian programaron meritas zorgema redaktado. Tio estas militistaro kiu uzas ilojn kiel rebase kaj filtrilo-branĉo al rakonti la historion en la maniero kiu estas plej bone por estontaj legantoj.
Nun, al la demando de ĉu kunfalado aŭ rebasing estas bona: espereble vi vidos ke ĝi ne estas tiu simpla. Git estas potenca ilo, kaj permesas vin fari multon por kaj per via historio, sed ĉiu teamo kaj ĉiu projekto estas malsama. Nun ke vi scias kiel ambaŭ de tiuj aferoj funkcias, ĝi estas supren al vi por decidi kio estas bona por via aparta situacio.
Ĝenerale la vojo akiri la plej bonan de ambaŭ mondoj estas rebase lokaj ŝanĝoj vi faris sed ne dividis ankoraux antaux vi puŝi ilin por purigi vian historion, sed neniam rebase ion vi puŝis ie.

prev | sekva