Du har en projektmapp med filer till en webbplats, men Git visar ingen versionshistorik. Kör git init i projektets rotmapp för att skapa ett lokalt Git-arkiv, men kommandot börjar inte spåra filerna automatiskt.
Git-arkivet börjar tomt tills du lägger till och committar filer
- Initiera: kör
git init -b maini projektets rotmapp. - Spåra filer: välj innehåll med
git addoch spara en första version medgit commit. - Välj rätt kommando: använd
git clonenär arkivet redan finns på en server. - Kontrollera platsen:
git statusvisar om du är i rätt arkiv och vad Git ser.
Initiera i projektets rotmapp, inte i en mapp bredvid
Stå i mappen där webbplatsens filer och projektinställningar hör hemma. Kör du kommandot en nivå för högt kan Git börja behandla flera projekt som ett enda arkiv, vilket gör statuslistan svår att tolka.
cd sökväg/till/projektet
git init -b main
git statusFlaggan -b main anger namnet på den första grenen, så du slipper förlita dig på vilken standardinställning som gäller på datorn. Enligt Git-dokumentationen för git init skapar kommandot arkivets interna struktur; det lägger inte till projektfilerna i historiken.
Kontrollera platsen innan du går vidare. Om terminalen visar oväntat många filer eller projekt, kör pwd för att se aktuell mapp och git status för att kontrollera vilket arkiv Git använder.
Den första versionen kräver både staging och commit
Ett nytt arkiv är tomt på historik även när projektmappen redan innehåller en färdig webbplats. Första gången behöver du välja vilka filer som ska ingå, granska urvalet och sedan skapa en commit, alltså en sparad ögonblicksbild.git status
git add .
git status
git commit -m "Första versionen"git add . lägger till filer från den aktuella mappen och dess undermappar i staging-området, där du förbereder nästa commit. Jag tycker att en extra git status före commit är en enkel försäkring: den kan avslöja att en uppladdningsmapp, en loggfil eller en lokal konfigurationsfil råkat följa med.
Om projektet innehåller filer som inte ska versionshanteras, skapa först en .gitignore-fil och ange mönster för dem, till exempel byggfiler eller lokala miljöinställningar. Kontrollera sedan status igen; ignorering påverkar inte filer som redan har lagts till i Git.
Välj git clone när projektets arkiv redan finns
Skillnaden märks tydligast när du ska börja arbeta med ett befintligt projekt. git init skapar ett nytt lokalt arkiv, medan git clone hämtar ett arkiv som redan finns, inklusive dess historik.
| Situation | Vad det betyder | Gör så här |
|---|---|---|
| Projektet finns bara på din dator | Det finns ingen fjärrhistorik att hämta. | Kör git init i projektmappen. |
| Arkivet finns redan på GitHub eller en annan server | En ny lokal kopia behöver den befintliga historiken. | Kör git clone med arkivets adress. |
| Fjärrarkivet är tomt och du har en lokal projektmapp | Det finns ingen befintlig historik att bevara på servern. | Initiera lokalt, skapa en commit och koppla sedan in fjärrarkivet. |
GitHubs guide till git init beskriver samma praktiska uppdelning: börja lokalt med git init när projektet ännu saknar ett arkiv, och välj git clone när ett arkiv redan finns. Att använda båda utan att tänka på ordningen kan skapa två separata historiker som senare måste fogas ihop.
Ett README på servern kan skapa en oväntad konflikt
Du har committat webbplatsen lokalt och skapat ett tomt fjärrarkiv. Då kan du koppla ihop dem så här:
git remote add origin fjärrarkivets-adress
git push -u origin mainProblemet uppstår om fjärrarkivet inte längre är tomt, till exempel för att en README-fil skapades där från början. Då har den lokala och fjärranslutna historiken olika startpunkter, och en vanlig push kan nekas. GitHub beskriver flödet för befintlig lokal kod i dokumentationen om att lägga till lokalt lagrad kod.
Om fjärrarkivet redan har filer, klona det först och flytta sedan in projektfilerna i den klonade mappen. Om du redan har committat lokalt, kontrollera fjärrarkivets innehåll och historik innan du försöker slå ihop dem; undvik att tvinga igenom en push som skriver över andras arbete.
Git status pekar ut var initieringen gick snett
När Git verkar se fel filer är orsaken ofta att terminalen står i fel mapp eller att ett annat arkiv finns högre upp i mappstrukturen. Börja med statusmeddelandet och jämför det med projektets faktiska plats.
| Situation | Trolig orsak | Nästa steg |
|---|---|---|
git status visar filer från flera projekt |
Arkivet kan ha initierats i en överordnad mapp. | Kontrollera sökvägen med pwd och leta efter en oavsiktlig .git-mapp. |
| Filerna listas som untracked | Arkivet finns, men filerna har inte lagts till i staging. | Granska git status, välj filer med git add och committa dem. |
| Git säger att det inte finns något att committa | Inga nya ändringar har lagts till, eller så ligger filerna utanför arkivet. | Kontrollera aktuell mapp och kör git status --short. |
Ta inte bort en .git-mapp förrän du har bekräftat vilket arkiv den tillhör. Den innehåller projektets Git-historik, och om den raderas försvinner den lokala historiken även om webbplatsens vanliga filer ligger kvar.
Låt den första commiten bli en tydlig startpunkt
När rätt filer ligger i rätt arkiv blir den första commiten en ren bas för fortsatt arbete. Kontrollera status, uteslut privata inställningar och välj main som startgren om det passar projektets arbetsflöde.
Om fjärrarkivet redan innehåller historik, klona det i stället för att skapa ett parallellt arkiv med git init. Då slipper du börja med att reda ut varför två versioner av samma projekt inte går att skicka ihop.