Jeg synes det er vanskelig å forstå git, da jeg ikke kunne finne betydningen av ordene som ble brukt til handlingene. Jeg har sjekket ordboken for betydningen av «scene», og ingen av betydningene var relatert til kildekontrollbegreper.

Hva betyr «stage» i sammenheng med git?

Kommentarer

  • relatert: Hva er fordelen med git ‘ s to -scene-forpliktelsesprosess (iscenesettelse)?
  • Git har faktisk sitt eget ordforråd. Og siden hver instruksjon er formulert i det spesielle ordforrådet, er det vanskelig å komme i gang. Å » trinn » er å gjøre git add file.ext for en bestemt fil, eller git add . for å påvirke alle endrede og usporede filer. Filer som er lagt til på denne måten sies å være » iscenesatt » og de vil bli inkludert i neste » forplikt «. Forpliktelsen er et øyeblikksbilde av arbeidet ditt opprettet f.eks. med git commit -m "I wrote something".
  • Git er vanskelig å forstå fordi det ikke er noen konseptuell veiledning der ute. Alt går gjennom unødvendige detaljer.
  • Mente du å fjerne » terminologi » fra dette spørsmålet? Det virker som en helt gyldig kode for meg.
  • Av en eller annen grunn er den beste måten jeg kunne forstå viktigheten av iscenesettelse på fra dette svaret i Quora: qr .ae / TbSK2I

Svar

Til scene en fil er ganske enkelt å forberede det fint for en forpliktelse. Git, med indeksen, lar deg bare begå bestemte deler av endringene du har gjort siden siste forpliktelse. Si at du jobber med to funksjoner – den ene er ferdig, og en trenger fortsatt litt arbeid. Du vil gjerne forplikte deg og gå hjem (klokka 5 til slutt!), Men vil ikke begå delene av den andre funksjonen, som ikke er gjort ennå. Du iscenesetter delene du vet tilhører den første funksjon, og forplikt deg. Nå er forpliktelsen ditt ditt prosjekt med den første funksjonen gjort, mens den andre fremdeles pågår i arbeidskatalogen.

Kommentarer

  • God forklaring. Vær oppmerksom på at git, distribuert, åpenbart lar deg begå begge funksjonene, siden forpliktelser er lokale (først). Det kan likevel være lurt å sette dele endringene i en forpliktelse per funksjon, og igjen er oppsett nyttig.
  • Jeg don ‘ t forstå hvorfor du trenger iscenesettelse for dette. Jeg kan gjøre dette med HG eller til og med SVN ved å bare begå de aktuelle filene. Det føles som om denne funksjonen primært er designet for å hjelpe folk som insisterer på å jobbe med kommandolinjen der den ‘ s vanskeligere t o avkrysningsruter for hva du forplikter deg.
  • @jiggy git lar deg iscenesette del av en fil. Du kan også iscenesette en fil, gjøre ytterligere modifikasjoner og deretter begå staten den var i under iscenesettelsen. Du kan ‘ ikke gjøre det i subversion.
  • @jiggy I SVN er det noe mellom det tidspunktet du velger hvilke filer / deler av filer du vil begå og når du er ferdig med å skrive kommisjonsmeldingen, registreres hvilke filer / deler du valgte å begå. Det blir kanskje aldri nevnt eksplisitt, det kan implementeres i SVN-klienten i stedet for en faktisk del av depotet. Det kan bare være noen flagg i minnet, men det er SVN ‘ s scene. Jeg har ikke ‘ t sett på HG, men jeg mistenker at det gjør det samme. Forskjellen med git er at git erkjenner at det er en ting, registrerer den på disken og lar brukeren komme direkte til den.
  • Den andre pilen » scenefiler » i figuren kan være misvisende. » scene hunks » kan være mer nøyaktig?

Svar

Siden alle hittil har svart på den «formelle» måten, la meg gjøre dette med alternativer for å forbedre læring med kraften av metaforer.

iscenesettingsområdet er som:

  • en cache med filer du vil bruke
  • ikke en serie av rør, men faktisk en dumper, klar til å flytte arbeidet du laster den med, inn i depotet
  • et magisk sted hvor utvalgte filer blir omgjort til stein med trollmennet ditt og kan transporteres magisk til depot etter ditt innfall
  • den gule mursteinsveien for filene å gå lykkelig til depotet (eller falle av hvis du vil tilbakestille)
  • det fiktive stedet i havneporten hvor filer mottas et par sementsko og deretter kastes i depothavet
  • resepsjonen på biblioteket, legger du filene der for at bibliotekaren skal forberede seg på arkivering i biblioteket
  • en boks der du legger ting inn før du skyver den under sengen din, der sengen din er et arkiv med bokser du tidligere har dyttet inn
  • innlastingsfilen for filer før den går inn i depotlageret med kraftlaster
  • filteret til en elektrisk drypp kaffetrakter, hvis filene er som kaffepulveret, så er de engasjerte filene den bryggede kaffen
  • Scrooge McDuck s kontor ved siden av hvelvet, filene er som myntene før de går inn i hvelvet til den enorme pengebøtten hans
  • dyrebutikken, når du tar med et kjæledyr hjem, er du forpliktet

Det er magisk !

Kommentarer

  • Elsker analogiene ; veien å gå knopp ^ _ ^
  • Elsk den endelige analogien.
  • Dette svaret var » FORMELTIG » som trengs blant rommet for vanlige forsøk på å forklare metafysikken til git index = git staging. Helt ærlig vil jeg ‘ også vite hva Linus tenkte da han bestemte seg for at han ville ha et indeksområde. Jeg liker det, men jeg vil rett og slett forstå bedre hvorfor det ‘ er bra å ha det, og hvordan du bruker det mest effektivt.

Svar

Staging er et trinn før forpliktelsesprosessen i git. Det vil si at en forpliktelse i git utføres i to trinn: iscenesettelse og faktisk forpliktelse.

Så lenge et endringssett er i iscenesettingsområdet, lar git deg redigere det som du vil (erstatte trinnvise filer med andre versjoner av iscenesatte filer, fjern endringer fra iscenesettelse osv.).

Ødelagt metafortid:

Tenk på et scenario der du ringer flytterne for å få tingene dine fra den gamle leiligheten din til den nye leiligheten din. Før du gjør det, vil du gå gjennom tingene dine, bestemme hva du tar med deg og hva du kaster, pakke det i poser og la det være i hovedgangen. Flytterne kommer ganske enkelt, henter (allerede pakket) poser fra gangen og transporterer dem. I dette eksemplet iscenesetter alt til flytterne dine ting: du bestemmer hva som skal hvor, hvordan du skal pakke det og så videre (f.eks. Kan du bestemme at halvparten av tingene dine skal kastes før flytterne til og med kommer dit – at » s del av staging).

Fra et teknisk synspunkt støtter staging også transaksjonsforpliktelser ved å dele alle operasjoner i hva som kan mislykkes (staging) og hva som ikke kan mislykkes (commit):

Forpliktelsen i git implementeres transaksjonsmessig etter at iscenesettelsen er vellykket. Flere trinn i iscenesettelsen kan mislykkes (for eksempel må du forplikte deg, men harddisken din er 99,9999% full, og git har ikke plass til Dette vil mislykkes i iscenesettelsen (depotet ditt blir ikke ødelagt av en delvis forpliktelse) og iscenesettelsesprosessen påvirker ikke forpliktelseshistorikken din (det ødelegger ikke depotet ditt i tilfelle en feil).

Kommentarer

  • … og så lite stemmer så langt.

Svar

Å iscenesette en fil er å forberede den på en forpliktelse. Fordi git eksponerer denne handlingen for brukernes kontroll, lar den deg lage delvise forpliktelser, eller for å endre en fil, iscenesette den, endre den på nytt, og bare forplikte eller gå tilbake til den opprinnelige endringen.

Staging lar deg finere kontroll over nøyaktig hvordan du vil nærme deg versjonskontroll.

Svar

For å legge til de andre utmerkede svarene, her kommer navnet til «scene» fra:

Jeg sjekket ordboken for betydningen av scenen, og ingen av betydningene var relatert til kildekontrollbegreper.

På engelsk kan «to stage» bety

organisere og delta i (et offentlig arrangement): UDF-tilhengere arrangerte en demonstrasjon i Sofia

(fra http://oxforddictionaries.com/definition/stage )

Navnet «iscenesettelse» for git-funksjonen kommer av denne betydningen: Når du iscenesetter, forbereder du og organiserer en forpliktelse.Selvfølgelig er en forpliktelse ikke helt det samme som en forestilling, men det er en viktig hendelse i en VCS :-).

Kommentarer

  • Jeg ‘ d har trodd at det samsvarte nærmere bruken i iscenesettingsinnlegg
  • Ditto. Også » et punkt, en periode eller et trinn i en prosess eller utvikling. »
  • Også ‘ staging server ‘ er et ganske vanlig begrep som brukes til å beskrive en server som ‘ s mellom utvikling og produksjon.

Svar

«Scenen» er et teknisk nødvendig mellomtrinn i prosessen med å sjekke inn en fil, nemlig å samle inn endringene som skal legges til depotet. Gits forfattere valgte å gjøre dette trinnet synlig og vedvarende der andre VCS gjør det til en forbigående del av forpliktelsesprosessen. Så det er bare et alternativ som git gir deg fordi det kan, så hvorfor ikke?

Slik jeg ser det, er det viktigste git «scenen» gir deg at andre VCS ikke er at du kan bruke den til å kontrollere en fil. Det er effektivt et unavngitt, unkommentert lokalt forpliktelse som gir deg et mellomtrinn mellom gjøres med alt arbeidet ditt og forplikter det til depotet permanent og ikke har noe lagret i ditt lokale repo i det hele tatt.

La oss for eksempel si at du har en funksjon delvis ferdig. Den er i stabil tilstand, består alle testene og kan gå i produksjon, men du har mer arbeid å gjøre med den. Du kan iscenesette alle endringene dine og deretter fortsette å jobbe med funksjonen.

Senere har du muligheten til å bare forplikte det du iscenesatte (og skyve forpliktelsen til det eksterne depotet) eller å legge til nye endringer i iscenesettelsesområdet ditt og deretter forplikte det på en gang, eller å angre bare de nye endringene og tilbakestille arbeidskatalogen til den tilstanden den var i da du iscenesatte endringene.

Det er helt mulig for å praktisk talt hoppe over iscenesettingsområdet helt og bare bruke alternativet -a til git commit hvis du ikke finner oppstillingsområdet som et nyttig konsept. Mange hopper over iscenesettelse, og GUI-verktøy tillater vanligvis også dette.

Kommentarer

  • » annet VCS ikke ‘ t » – hva får deg til å tro det? Hyller hos Perforce ser ut til å gjøre det du beskriver, og til og med med noen få bjeller og fløyter
  • @gnat ja, selvfølgelig mange andre VCS gir deg noe som iscenesettelse. Med » annet VCS » mener jeg andre VCS som ikke ‘ t har noe som git ‘ s scene, siden det var det OP refererte til.
  • Jeg syntes dette svaret var utrolig bedre enn alle de ovennevnte, siden det ‘ er den eneste som avklarer hvorfor Staging i det hele tatt eksisterer (er teknisk nødvendig ), en forklaring på opprinnelsen ( Git ‘ s forfattere valgte å gjøre dette trinnet synlig og vedvarende ), og la til det jeg personlig synes er en god definisjon for det ( et mellomliggende, unavngitt, unkommentert lokalt forpliktelse ) . Jeg tror imidlertid det kan forbedres ved å sitere en kilde for uttalelsen om opprinnelsen til Staging, og utdype noe mer om hvorfor det ‘ s teknisk kreves . @OldPro
  • Ble git designet fra bunnen av, kunne dette nettopp ha vært en del av en generalisert » gren » konsept, lokalt og usett av andre i dette tilfellet. På samme måte kunne » stash » nettopp ha blitt implementert (og forstått!) Som en spesifikk forekomst av det generaliserte begrepet » gren. » Du kan da ha et hvilket som helst antall nivåer av » iscenesettelse » du foretrekker.

Svar

Med de fleste andre versjonskontrollsystemer er det to steder å lagre data: arbeidskopien din (mappene / filene du bruker for øyeblikket) og datalageret (hvor versjonskontrollen bestemmer hvordan du skal pakke og lagre endringene). I Git er det et tredje alternativ: iscenesettingsområdet (eller indeksen). Det er i utgangspunktet en lasteplass hvor du får bestemme hvilke endringer som skal sendes bort.

kilde: http://gitready.com/beginner/2009/01/18/the-staging-area.html

Kommentarer

  • dette ser ikke ut til ‘ å legge til noe vesentlig i forhold til tidligere 6 svar
  • Det nevner indeks. Og referanser til en veldig grundig artikkel. Oppstemning. BTW, noen svar ovenfor er bare vitser.

Svar

Min forståelse er at jeg utvikler påloggingsfunksjonen og krevde 5 trinn på rad for å fullføre. Så her iscenesettelse vil hjelpe deg med å jobbe på trinn som
gjort med trinn 1 trinn det.
gjort med trinn 2, nå trinn 1 og trinn 2 begge er riktig trinn det.
rot med trinn 3 nei problemkasse siste trinnet som er trinn 2 – på samme måte når du er ferdig med alle 5 trinnene som betyr at funksjonen er fullført, nå utfør forpliktelse.

Kommentarer

  • dette ser ikke ‘ ut til å legge til noe vesentlig over poeng som er gjort og forklart tidligere 9 svar
  • ja du har rett, jeg prøvde bare å gjøre forklaringen enkel og søt
  • Og hvordan jeg har lyst til å bruke dette konseptet praktisk talt, jeg prøvde å forklare det
  • vurdere å ta en titt på diskusjonen her: Er andre TL; DR-svar akseptable? (FWIW sammenlignet med tidligere svar denne ‘ ser ikke enkel eller søt ut for meg)
  • takk sir, jeg har et spørsmål å stille. Jeg har kommet over mange svar, og de fleste av dem er for kompliserte, ja de er korrekte, men vanskelige å fordøye på en gang. Jeg tror at hvis du ikke kan ‘ ikke forklare noe på en enkel måte, så har ikke lært det ordentlig eller vet ikke ‘ hvordan du bruker det. Så er det dårlig nå å si sammendrag eller enkel måte å svare på ??

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *