3.1 Git branĉantaj - Branĉoj Unuvorte

Preskaŭ ĉiu VCS havas iun formon de branĉantaj subteno. Disbranĉadon signifas vin diverĝas de la ĉefa linio de disvolviĝo kaj daŭre faros laboron sen rompado kun tiu ĉeftendenca. En multaj VCS iloj, ĉi tiu estas iom peniga procezo, ofte postulanta vin krei novan kopion de via fontkodo dosierujo, kiu povas preni longan tempon por grandaj projektoj.
Iuj homoj aludas al Git la disbranĉadon modelo kiel lia "murdisto karakterizaĵo," kaj certe aroj Git dise en la VCS komunumo. Kial tiom speciala? La vojo Git branĉoj estas nekredeble malpeza, farante branĉantaj operacioj preskaŭ instantáneo, kaj ŝaltanta-reen inter branĉoj ĝenerale tiom rapide. Malkiel multaj aliaj VCSs, Git instigas fluoj de laboro ke branĉo kaj kunfandi ofte, eĉ plurfoje en tago. Komprenon kaj majstranta tiu karakterizaĵo donas potencan kaj sola ilo kaj povas tute ŝanĝi la maniero kiun vi disvolvi.

Branĉoj Unuvorte

Por vere kompreni la manieron Git does branĉantaj, ni bezonas preni retropaŝon kaj ekzameni kiel Git stokas liajn datumojn.
Kiel vi eble memoras de ekuzi , Git ne stokas datumojn kiel serio de changesets aŭ diferencoj, sed anstataŭe kiel serion de instantáneas.
Kiam vi faras fari, Git vendejoj oni faras objekto kiu enhavas puntero al la instantánea de la enhavo vi enscenigita. Tiu celo ankaŭ enhavas la aŭtora nomo kaj retpoŝto, la mesaĝo kiu vi tajpas, kaj punteros al la commit aŭ faras ke rekte venis antaux tiu faras (lia patro aŭ gepatroj): nul gepatroj por la komenca farante per unu gepatro por normala fari, kaj multnombraj gepatroj por fari ke rezultoj de merge de du aŭ pli branĉojn.
Bildigi tion, ni supozu ke vi havas dosierujo enhavanta tri dosierojn, kaj vi enscenigi ilin ĉiujn kaj fari. Enscenigante la dosierojn checksums ĉiu (la SHA-1 hash ni menciis en ekuzi ), tendencas ke versio de la dosiero en la Git-deponejo (Git raportas ilin kiel blobs), kaj aldonas ke checksum al la surscenigo areo:

 $ Git aldonu README test.rb LICENCO $ git commit -m 'The initial commit of my project' 

Kiam vi kreas la commit de kuranta git commit , Git checksums ĉiu subdosierujo (en tiu kazo, nur la radiko projekto dosierujo) kaj tendencas tiuj arbo objektoj en la Git-deponejo. Git tiam kreas commit objekto kiu havas la metadatenoj kaj montrilo al la radika projekto arbo do ĝi povas re-krei tiun instantánea kiam devita.
Vian Git-deponejo nun enhavas kvin objektojn: unu blob pri la enhavo de ĉiu de viaj tri dosierojn, unu arbon kiu listigas la enhavon de la dosierujo kaj specifas kiun dosiero nomoj estas stokitaj kiel kiu blobs, kaj oni faras kun la puntero al tiu radika arbo kaj ĉiuj faras pridatumon.

Figuro 3-1. A commit kaj lia arbo

Se vi faras iujn ŝanĝojn kaj fari denove la proksima commit tendencas puntero al la commit kiu venis tuj antaŭ ĝi.

Figuro 3-2. Kompromitas kaj iliaj gepatroj

Branĉo en Git estas simple malpeza meblo puntero al unu el tiuj interna. La defaŭlta branĉo nomon en Git estas master . Kiel vi komenci farante interna, vi ricevis master branĉo kiu notas al la lasta commit vi faris. Ĉiufoje vi faras, ĝi moviĝas antaŭen aŭtomate.

noto

La "mastro" branĉo en Git ne speciala branĉo. Estas ĝuste kiel ajna alia branĉo. La sola kialo preskaŭ ĉiu deponejo havas estas ke la git init komando kreas defaŭlte kaj plej homoj ne ĝenas ŝanĝi ĝin.

Figuro 3-3. Branĉo kaj lia commit historio

Kreante Nova Branĉo

Kio okazas se vi kreas novan branĉon? Nu, farante tiel kreas novan montrilon por vi movi ĉirkaŭe. Imagu ke vi kreas novan filion nomita testado. Vi faras tion per la git branch komando:

  $ Git branĉo testado 

Ĉi kreas novan sagon al la sama commit vi aktuale plu.

Figuro 3-4. Du branĉoj montrante en la sama serio de interna

Kiel Git scias kion branĉo vi aktuale sur? Ĝi tenas specialan puntero nomis HEAD . Notu ke ĉi tiu estas multe malsama ol la koncepto de HEAD en aliaj VCSs vi povas uzi por, ekzemple Subversion aŭ CVS. En Git, ĉi estas puntero al la loka branĉo vi aktuale plu. En tiu kazo, vi ankoraŭ sur master . La git branch komandon nur kreis novan branĉon - ne ŝanĝi al tiu branĉo.

Figuro 3-5. KAPO indikus branĉo

Vi povas facile vidi tion kurante simpla git log komando kiu montras vin kie la branĉo punteros notas. Opcio estas nomita --decorate .

  $ Git log --oneline --decorate
f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to the central interface
34ac2 Fixed bug #1328 - stack overflow under certain conditions
98ca9 The initial commit of my project 

Vi povas vidi la "majstro" kaj "testado" branĉoj kiuj estas ĝuste tie apud la f30ab fari.

ŝaltanta Branĉoj

Alti al ekzistanta branĉo, vi kuras la git checkout komando. Ni ŝanĝos al la nova testing branĉo:

  $ Git kaso testado 

Ĉi movas HEAD atentigi al la testing branĉo.

Figuro 3-6. KAPO punktoj al la aktuala branĉo

Kio estas la signifo de tio? Nu, ni faru alian fari:

  $ Vim test.rb
 $ Git commit -a -m 'made a change' 

Figuro 3-7. La KAPO branĉo movas antaŭen kiam faras estas farita

Tio estas interesa, ĉar nun via testing branĉo movis antaŭen, sed via master branĉo ankoraŭ montras al la commit vi estis kiam vi kuris git checkout alti branĉoj. Ni ŝanĝi reen al la master branĉo:

  $ Git kaso mastro 

Figuro 3-8. KAPO movas kiam checkout

Ke komando faris du aferojn. Ĝi kopiis la KAPO montrilon al punkto al la master branĉo, kaj ĝi revenis la dosierojn en via labordosierujon reen al la instantánea ke master punktoj. Ĉi tio ankaŭ signifas la ŝanĝoj kiujn vi faras el tiu punkto antaŭen estos diverĝas de malnova versio de la projekto. Ĝi esence rebobina la laboro vi faris en via testing branĉo do vi povas iri en malsama direkto.

noto

Ŝaltanta branĉoj ŝanĝas dosierojn en via laboranta dosierujo

Estas grave noti, ke kiam vi ŝanĝos branĉoj en Git, dosierojn en via labordosierujon ŝanĝos. Se vi ŝanĝos al malnova branĉo, via labordosierujon estos reverted rigardi kiel ĝi faris la lastan fojon vi faris en tiu branĉo. Se Git ne povas fari ĝin pure, ĝi ne permesas vin ŝanĝi tute.

Ni faru kelkajn ŝanĝojn kaj fari denove:

  $ Vim test.rb
 $ Git commit -a -m 'made other changes' 

Nun via projekto historio diverĝis (vidu Figuro 3-9 ). Vi kreis kaj interŝanĝita al branĉo, faris iun laboron sur ĝi kaj poste interŝanĝita reen al via ĉefa branĉo kaj faris alian laboron. Ambaŭ de tiuj ŝanĝoj estas izolita en apartajn branĉojn: vi povas ŝanĝi tien kaj reen inter la branĉoj kaj kunfandi ilin kune kiam vi estas preta. Kaj vi faris cxion, kio kun simpla branch , checkout , kaj commit ordonojn.

Figuro 3-9. Diferenca historio

Vi povas ankaŭ vidi ĉi facile kun la git log komando. Se vi kuras git log --oneline --decorate --graph --all ĝi presos la historio de via interna, montrante kie via branĉo punteros estas kaj kiom via historio diverĝis.

  $ Git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project 

Ĉar branĉo en Git estas en realeco simplan dosieron kiu enhavas la 40 karaktero SHA-1 checksum de la commit notas al, branĉoj estas malkaraj por krei kaj detrui. Kreante novan branĉon kiel rapida kaj simpla kiel skribanta 41 bajtoj al dosiero (40 karakteroj kaj lino).
Tio estas en akra kontrasto al la maniero plej malnovaj VCS iloj branĉo, kiu engaĝas kopiante ĉiuj projekto dosierojn en sekundo dosierujo. Tio povas preni plurajn sekundojn aŭ eĉ minutojn, depende de la grandeco de la projekto, dum kiu en Git la procezo estas ĉiam instantánea. Ankaŭ, ĉar ni gravuras la gepatroj kiam ni faras, trovanta konvenan merge bazo por fandado estas aŭtomate farita por ni kaj estas ĝenerale tre facile fari. Tiuj trajtoj helpos kuraĝigi desarrolladores krei kaj uzi branĉoj ofte.
Vidu kial vi devus tion fari.

prev | sekva