Jag tycker det är svårt att förstå git eftersom jag inte kunde hitta betydelsen av orden som användes för handlingarna. Jag har kollat ordboken för innebörden av ”stage” och ingen av betydelserna var relaterade till källkontrollbegrepp.

Vad betyder ”stage” i samband med git?

Kommentarer

  • relaterade: Vad är fördelen med git ’ s två -stage commit process (staging)?
  • Git har verkligen en egen vokabulär. Och eftersom varje instruktion är formulerad i den speciella vokabulären är det svårt att komma igång. Att ” steg ” är att göra git add file.ext för en specifik fil, eller git add . för att påverka alla modifierade och ospårade filer. Filer som har lagts till på detta sätt sägs vara ” iscensatt ” och de kommer att ingå i nästa ” begå ”. Åtagandet är en ögonblicksbild av ditt arbete som skapats t.ex. med git commit -m "I wrote something".
  • Git är svårt att förstå eftersom det inte finns någon konceptuell handledning där ute. Allt går igenom onödiga detaljer.
  • Menade du att ta bort taggen ” ” från den här frågan? Det verkar vara en helt giltig tagg för mig.
  • Av någon anledning är det bästa sättet jag kunde förstå vikten av iscensättning från detta svar i Quora: qr .ae / TbSK2I

Svar

Till scenen en fil är helt enkelt att förbereda det fint för ett åtagande. Git, med sitt index låter dig bara begå vissa delar av de ändringar du har gjort sedan senaste förpliktelsen. Anta att du arbetar med två funktioner – en är klar och en behöver fortfarande göra lite arbete. Du skulle vilja göra ett åtagande och åka hem (5 o ”klocka, äntligen!) Men skulle inte vilja begå delarna av den andra funktionen, vilket inte är klart ännu. Du iscensätter de delar du vet tillhör den första funktion och engagera. Nu är ditt engagemang ditt projekt med den första funktionen klar, medan den andra fortfarande pågår i din arbetskatalog.

Kommentarer

  • Bra förklaring. Observera att git, som distribueras, uppenbarligen låter dig begå båda funktionerna, eftersom åtaganden är lokala (till en början). Ändå kanske du vill dela upp modifieringarna i ett engagemang per funktion, och återigen är iscenesättningen till nytta.
  • Jag don ’ t förstår varför du behöver iscensätta för detta. Jag kan göra detta med HG eller till och med SVN genom att bara begå relevanta filer. Det känns som att den här funktionen främst är utformad för att hjälpa människor som insisterar på att arbeta med kommandoraden där den ’ är hårdare t o kryssrutor för vad du gör.
  • @jiggy git låter dig scenera del av en fil. Du kan också iscensätta en fil, göra ytterligare ändringar och sedan begå det tillstånd den var i vid iscenesättningen. Du kan ’ inte göra det i subversion.
  • @jiggy I SVN finns det något mellan den tid du väljer vilka filer / delar av filer du vill begå och när du är färdig med att skriva ditt engagemangsmeddelande registreras vilka filer / delar du valt att begå. Det kan aldrig nämnas uttryckligen, det kan implementeras i SVN-klienten snarare än en faktisk del av förvaret, det kan bara vara några flaggor i minnet, men det är SVN ’ s skede. Jag har inte ’ inte tittat på HG, men jag misstänker att det gör samma sak. Skillnaden med git är att git erkänner att det är en sak, spelar in det på hårddisken och låter användaren komma till det direkt.
  • Den andra pilen ” scenfiler ” i figuren kan vara vilseledande. ” stage hunks ” kanske är mer exakt?

Svar

Eftersom alla hittills har svarat på det ”formella” sättet, låt mig göra detta med alternativ för att förbättra lärandet med metaforernas kraft.

iscensättningsområdet är som:

  • en cache med filer som du vill begå
  • inte en serie av rör men faktiskt en dumper, redo att flytta arbetet du laddar den med in i förvaret
  • en magisk plats där utvalda filer kommer att förvandlas till sten med din trollkarl och magiskt kan transporteras till förråd vid ditt infall
  • den gula tegelvägen för filerna att gå lyckligt till förvaret (eller falla av om du vill återställa)
  • den fiktiva platsen vid hamnen där filer tas emot ett par cementskor och sedan kastas i förvarshavet
  • mottagningsdisken på biblioteket, du lägger filerna där för att bibliotekaren ska förbereda sig för arkivering i biblioteket
  • en låda där du lägger in saker innan du skjuter in dem under din säng, där din säng är ett arkiv med lådor som du tidigare har sköt in i
  • laddningsfilen för filer innan den går in i förvarets lager med kraftlastare
  • filtret på en elektrisk droppkaffebryggare, om filerna är som kaffepulvret, så är de engagerade filerna det bryggda kaffet
  • Scrooge McDucks kontor bredvid valvet, filerna är som mynten innan de går in i valvet på hans massiva penningkorg
  • djuraffären, när du väl har tagit ett husdjur är du engagerad

Det är magisk !

Kommentarer

  • Älskar analogierna ; väg att gå knopp ^ _ ^
  • Älskar den slutliga analogin.
  • Detta svar var ” FÖRVÄNLIGT ” behövs bland rymden för vanliga försök att förklara metafysiken för git index = git staging. Uppriktigt sagt vill jag ’ också veta vad Linus tänkte när han bestämde sig för att han ville ha ett indexområde. Jag gillar det, men jag vill helt enkelt bättre förstå varför det ’ är bra att ha det och hur man använder det mest effektivt.

Svar

Staging är ett steg före kommit-processen i git. Det vill säga att en commit i git utförs i två steg: staging och faktisk commit.

Så länge som en ändringsuppsättning finns i stagingområdet, kan du med git redigera den som du vill (ersätt iscensatta filer med andra versioner av iscensatta filer, tar bort ändringar från iscensättning etc.).

Trasig metafortid:

Tänk på ett scenario där du ringer flyttarna för att få dina saker från din gamla lägenhet till din nya lägenhet. Innan du gör det kommer du att gå igenom dina saker, bestämma vad du tar med dig och vad du slänger, packa det i väskor och lämna det i huvudhallen. Flyttarna kommer helt enkelt, hämtar de (redan packade) väskorna från hallen och transporterar dem. I det här exemplet iscenesätter allt tills flyttarna får dina saker: du bestämmer vad som går vart, hur man packar det och så vidare (t.ex. kan du bestämma att hälften av dina saker ska kastas innan flyttarna ens kommer dit – att ” s del av staging).

Ur teknisk synvinkel stöder staging också transaktionsförpliktelser genom att dela upp alla operationer i vad som kan misslyckas (staging) och vad som inte kan misslyckas (commit):

Åtagandet i git implementeras transaktionellt efter att iscenesättningen är framgångsrik. Flera steg i iscenesättningen kan misslyckas (till exempel måste du begå, men din hårddisk är 99,9999% full och git har inget utrymme att utför ett engagemang). Det här misslyckas med att iscensätta (ditt förråd kommer inte att skadas av en delvis förpliktelse) och iscensättningen påverkar inte din engagemangshistorik (det skadar inte ditt förvar i händelse av ett fel).

Kommentarer

  • … och så lite röster hittills.

Svar

Att iscensätta en fil är att förbereda den för ett åtagande. Eftersom git exponerar denna åtgärd för användarkontrollen kan du skapa partiella åtaganden eller ändra en fil, iscensätta den, ändra den igen och bara begå eller återgå till den ursprungliga modifieringen.

Staging tillåter dig finare kontroll över exakt hur du vill närma dig versionskontroll.

Svar

För att lägga till andra utmärkta svar, här kommer namnet på ”stage” från:

Jag kollade ordboken för betydelsen av scenen och ingen av betydelserna var relaterade till källkontrollbegrepp.

På engelska kan ”to stage” betyda

organisera och delta i (ett offentligt evenemang): UDF-supportrar arrangerade en demonstration i Sofia

(från http://oxforddictionaries.com/definition/stage )

Namnet ”iscensättning” för git-funktionen härrör från denna betydelse: När du iscensätter förbereder du och organiserar ett åtagande.Naturligtvis är ett engagemang inte helt detsamma som en prestation, men det är en viktig händelse i en VCS :-).

Kommentarer

  • Jag ’ Jag har trott att det stämmer bättre överens med användningen i iscensättning
  • Ditto. ” en punkt, period eller ett steg i en process eller utveckling. ”
  • Även ’ staging server ’ är en ganska vanlig term som används för att beskriva en server som ’ s mellan utveckling och produktion.

Svar

”Scenen” är ett tekniskt nödvändigt mellansteg i processen att kontrollera fil, nämligen att samla in ändringarna som ska läggas till förvaret. Gits författare valde att göra detta steg synligt och ihållande där andra VCS gör det till en övergående del av åtagandeprocessen. Så det är bara ett alternativ som git ger dig eftersom det kan så varför inte?

Så som jag ser det, det viktigaste git ”stage” ger dig att andra VCS inte är att du kan använda den för att kontrollera en fil. Det är effektivt ett namnlöst, okommenterat lokalt engagemang som ger dig ett mellanliggande steg mellan göras med allt ditt arbete och förpliktar det permanent till förvaret och har inget sparat i ditt lokala repo alls.

Till exempel, låt oss säga att du har en funktion delvis avslutad. Den är i ett stabilt tillstånd, klarar alla tester och kan gå i produktion, men du har mer arbete att göra på den. Du kan göra alla dina ändringar och sedan fortsätta arbeta med funktionen.

Senare har du möjlighet att bara begå det du iscensatte (och trycka på det åtagandet till fjärrförvaret) eller lägga till din nya ändringar i ditt iscensättningsområde och sedan begå det på en gång, eller att ångra bara dina nya ändringar och återställa din arbetskatalog till det tillstånd den var i när du iscensatte dina ändringar.

Det är helt möjligt för att praktiskt taget hoppa över iscenesättningsområdet helt och bara använda alternativet -a för att git commit om du inte tycker att iscenesättningsområdet är ett användbart koncept. Många människor hoppar över iscensättning och GUI-verktyg tillåter vanligtvis också detta.

Kommentarer

  • ” andra VCS don ’ t ” – vad får dig att tro så? Hyllor vid Perforce verkar göra vad du beskriver, och till och med med några ytterligare klockor och visselpipor
  • @gnat ja, förstås många andra VCS ger dig något som iscenesättning. Med ” annan VCS ” menar jag andra VCS som inte ’ t har något som git ’ s scen, eftersom det var det som OP hänvisade till.
  • Jag tyckte att det här svaret var oerhört bättre än allt ovan, eftersom det ’ är den enda som klargör varför Staging överhuvudtaget existerar (eftersom tekniskt krävs ), en förklaring till dess ursprung ( Git ’ s författare valde att göra detta steg synligt och ihållande ) och lade till det jag personligen tycker är en bra definition för det ( en mellanliggande, namnlös, okommenterad lokal förpliktelse ) . Jag tror dock att det skulle kunna förbättras genom att citera en källa för uttalandet om Stagingens ursprung och utarbeta lite mer om varför det ’ s tekniskt krävs . @OldPro
  • Git designades från grunden, det kunde bara ha varit en del av en generaliserad ” gren ” koncept, lokalt och osedda av andra i detta fall. På samma sätt kunde ” stash ” bara ha implementerats (och förstått!) Som en specifik instans av det generaliserade begreppet ” gren. ” Du kan då ha valfritt antal nivåer av ” som iscensätter ” du föredrar.

Svar

Med de flesta andra versionskontrollsystem finns det två platser att lagra data: din arbetskopia (mapparna / filerna som du använder för närvarande) och datalagret (där versionskontrollen bestämmer hur dina ändringar ska packas och lagras). I Git finns det ett tredje alternativ: iscenesättningsområdet (eller indexet). Det är i grunden en lastdocka där du får bestämma vilka ändringar som skickas bort.

källa: http://gitready.com/beginner/2009/01/18/the-staging-area.html

Kommentarer

  • detta verkar inte ’ lägga till något väsentligt jämfört med tidigare 6 svar
  • Det nämner index. Och hänvisningar till en mycket grundlig artikel. Rösta. BTW, några svar ovan är bara skämt.

Svar

Min förståelse är att jag antar att jag utvecklar inloggningsfunktionen och krävde fem steg i följd för att slutföra. Så här hjälper staging dig till att arbeta på steg som
gjort med steg 1 steg det.
gjort med steg 2, nu steg 1 och steg 2 båda är korrekta steg det.
störa med steg 3 nej problemkassa senaste iscensatta steget som är steg 2 – på samma sätt när du gjort med alla 5 stegen, vilket innebär att funktionen är klar, gör nu kommit.

Kommentarer

  • detta verkar ’ inte lägga till något väsentligt över punkter som har gjorts och förklarats tidigare 9 svar
  • ja du har rätt, jag försökte bara göra förklaringen enkel och söt
  • Och hur jag känner att använda detta koncept praktiskt försökte jag förklara det
  • överväga att ta en titt på diskussionen här: Är andra TL; DR-svar acceptabla? (FWIW jämfört med tidigare svar här ’ ser inte enkel eller söt ut för mig)
  • tack sir, jag har en fråga att ställa. Jag har stött på många svar och de flesta av dem är för komplexa ja de är korrekta men svåra att smälta på en gång, jag tror att om du ’ inte kan förklara något på ett enkelt sätt så kan du har inte lärt sig det ordentligt eller vet inte ’ hur man använder det. Så är det dåligt att sätta sammanfattning eller enkelt sätt att svara ??

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *