Ett av de vanliga felmeddelanden som du sannolikt kommer att stöta på Git är varningen om att “ du befinner dig i ‘ fristående HEAD ’ tillstånd. ” Du kanske har snubblat in i detta av misstag, men oroa dig inte — det är ett normalt problem och kan enkelt åtgärdas när du förstår vad det betyder.
Vad är GIT HEAD?
“ HEAD ” är helt enkelt ett alias för din nuvarande arbetsåtagande, ungefär som din nuvarande katalog på en kommandorad. Oavsett vilket tillstånd ditt Git -arkiv är i, pekar HEAD alltid på något, och nya åtaganden kommer att läggas till framför HEAD.
Vanligtvis hänvisar HEAD inte direkt till ett enda åtagande. Det pekar istället på en gren och indirekt refererar till det senaste åtagandet i den grenen. När du “ checkar ut ” en ny gren, växlar Git över huvudet till den grenen. Detta gör att du kan göra nya åtaganden som kommer att läggas till i slutet av den grenen.
Men du kan också kolla in enskilda åtaganden. Vad händer om du ville undersöka förvaret vid en viss tidpunkt? Det är en av de stora fördelarna med Git, men det är ett litet problem med hur Git strukturerar saker. Eftersom nya åtaganden inte kommer att uppdatera en filial, kommer alla åtaganden du gör efter att ha flyttat HEAD bort att lossna från alla grenreferenser, och därför kommer “ fristående HEAD. ”
Detta kan faktiskt vara ganska användbart. Säg att du flyttade tillbaka huvudet några åtaganden och sedan gjorde några experimentella uppdateringar. Du gör i princip en ny filial, som kan slås samman till master senare.
Annons
Du måste officiellt integrera den i Git -repo om du bestämmer dig för att behålla ändringarna, men som ett verktyg för att göra ändringar i tiden, är det inte så läskigt att ha ett fristående HEAD som det låter.
Om du kom hit av en olycka
Det är väldigt lätt att hamna här av misstag och bli förvirrad över felmeddelandet som Git klagar över trots att han inte gjort något fel. Lyckligtvis är det otroligt enkelt att åtgärda:
Om du precis checkat ut en förpliktelse och inte har rört förvaret annars (inga nya åtaganden gjordes) kan du helt enkelt flytta HEAD tillbaka dit den hör hemma med git checkout:
git checkout master
Det här är i princip som att köra cd på Linux, förutom att Git fortfarande kopplar cachade commits och ändringar med det gamla HEAD, så du vill inte checka ut om du har åtaganden eller ändringar som skulle lämnas kvar.
Om du hade några ändringar och bara vill slänga dem kan du svårt att återställa till master:
git reset –hard origin/master git clean -d –force
Om du vill spara dina åtaganden, men du måste officiellt slå tillbaka dem till Gits tidslinje.
Om du vill spara dina ändringar
Det första du vill göra om du vill behålla de ändringar du gjorde i ett fristående HEAD -tillstånd är att skapa en ny gren. Detta beror på att Gits sopsamlare kommer att städa upp fristående åtaganden automatiskt, så att du aldrig vill tappa reda på dem.
git filial fristående gren Annonsering
Då kan du kan checka ut den här grenen för att flytta HEAD så att den inte längre är fristående och istället pekade på den här officiella nya grenen:
git checkout fristående-gren
När ändringarna har registrerats har du ett av två alternativ. Den här nya grenen är i grunden en vanlig funktionsgren, så du kan antingen kombinera eller git rebase.
Sammanfogning är enkelt; checkout master och slå ihop den fristående grenen:
git checkout master git merge det-branch
Detta fungerar bra om du integreras i en filial som behöver godkännande, vilket är fallet med pull-begäranden och kod recensioner. Du kan behöva gå igenom ditt teams godkännandeprocess istället för att köra dessa kommandon själv.
Om du har åtkomst, som om du går samman till en funktionsgren som du arbetar med, är en bättre metod att cherryplocka de fristående åtagandena. Körsbärsplockning kopierar i princip ett åtagande och klistrar in det på en annan gren. Det används vanligtvis för att dra ut specifika åtaganden från en funktionsgren innan det hela är klart, men i det här fallet kan körsbärsplockning förena den fristående grenen utan en sammanslagning.
Annons –
I det här exemplet är åtagandet uppe fristående. I stället för att slå ihop det, plockas det körsbärsplockat och flyttas till funktionsgrenen. Detta flyttar HEAD- och funktionsgrenen till att peka på det senaste åtagandet utan sammanslagning. Därefter kan den ursprungliga fristående åtagandet kasseras.
Först måste du göra den fristående grenen och sedan checka ut funktionsgrenen för att flytta huvudet dit:
git -grenen lossnar -gren filutcheckningsfunktionen
Kör sedan Git -loggen för att få en lista med åtaganden:
git -log –pretty = format: ” %h %s” –graph
Sedan kan du cherryplocka en åtagande med sitt ID:
git cherry -pick 1da76d3
Sedan, när du har bekräftat att de körsbärsplockade åtagandena tillämpas korrekt, kan du ta bort den fristående grenen, eftersom åtagandena kopierades och den inte längre används.
git-gren -D fristående-gren
Rebasing istället för att slå samman
Du kan också göra en rebase. Rebaser skiljer sig från sammanslagningar genom att de skriver om filialens historia, lyfter upp de fristående åtagandena och flyttar dem till grenens framsida.
Problemet med detta är dock att du fortfarande har två grenar kvar, och du kommer fortfarande att behöva slå samman funktion och fristående gren tillsammans, lämnar dig med en sammanslagning åtar sig åt båda hållen. Men det lämnar förvaret med en mer linjär Git -historia, vilket är att föredra framför att köra git -sammanslagning om du har behörighet att göra det.