Vanliga frågor och svar om Git

Kontrollera först att du har en origin konfigurerad lagringsplats. Om du klonade lagringsplatsen med git clonehar du redan en. När du checkar ut en gren som inte finns lokalt avgör Git om det finns en fjärrgren med samma namn. I så fall skapar Git en lokal gren som refererar till fjärrgrenen. Använd git pull för att ladda ned commits och uppdatera grenhistoriken lokalt.

Kör git branch utan argument för att visa de lokala grenarna och markera den du checkade ut. I Visual Studio visar statusfältet den aktuella grenen när du arbetar med ett projekt som lagras på en lokal Git-lagringsplats.

Gör separata kommittar för logiskt åtskilda ändringar. Tänk på commits som poster i en loggbok. När du gör en ändring som är värd att notera, registrera den i en commit. Ett populärt tillvägagångssätt är att tillåta frekventa lokala commits men slå ihop dem genom rebasing innan du gör en push. Den här metoden ger flexibilitet samtidigt som commithistoriken effektiviseras.

I stora projekt med många incheckningar och deltagare kan grenhistoriken main återspegla utveckling av ämnesgrenar mer än övergripande projektframsteg. Du kan komprimera incheckningar på grenar genom att krossa incheckningar och ombasera. Squashing commits förenklar grenhistoriken och skapar en renare huvudgren när du har sammanfogat.

git blame Använd kommandot för att ta reda på vem som gjorde en viss ändring i en fil. Från din lokala lagringsplats, kör du git blame med parametern -L för att ange de rader som du är intresserad av. Blame skapar formaterad utdata som visar commit:en som senast uppdaterade varje rad och vem som gjorde ändringen.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame söker i commithistoriken. Du kan också granska en fils historik i webbportalen för att avgöra vem som gjorde en ändring och när. Öppna Code Explorer för din lagringsplats och gren och välj sedan den fil som du vill undersöka. Azure Repos visar en fullständig kommithistorik för filen på den aktuella grenen.

Att checka ut en annan gren i Git påverkar tillståndet för filer i filsystemet. Git använder commit-historiken för att säkerställa att arbetskatalogen överensstämmer med den valda grenen. Om du försöker byta gren medan du har okommitterade ändringar kommer de att skrivas över vid utcheckningen. För att förhindra oavsiktlig dataförlust blockerar Git utcheckningen. Du kan välja mellan följande alternativ:

• Avbryt ändringarna och återgå till den senaste incheckningen. Se Ångra ändringar i Git för instruktioner om hur man återställer till den senaste incheckningen.
• Genomför ändringarna. Se Spara ditt arbete i Git med commits.
• Stash ditt aktuella arbete för att lägga undan ändringarna till senare och återställa arbetsytan till den senaste commit.

Det här problemet uppstår på grund av sammanslagningskonflikter i stora binära filer. Den aktuella filstorleksgränsen är 100 MB. För att kringgå det här problemet, sammanfoga målet med källan lokalt, lös konflikter och pusha ändringarna.

Använd Git LFS (Large File Storage) för stora binära filer för att undvika konflikter och hantera den totala lagringsplatsens storlek, vilket påverkar klonings- och push-tider.

För att spara ändringar utan att committa dem, använder du Git stash. Det här kommandot sparar de aktuella mellanlagrade och icke-mellanlagrade ändringarna i din gren och återställer grenen till tillståndet vid senaste commit. Du kan sedan växla till en annan gren, slutföra ditt arbete och senare köra stash apply för att återställa ändringarna.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

När du kör git stash applygäller de senast undangömda ändringarna för din aktuella gren. Om någon fil är i konflikt, återställer stash de icke-konflikterande filerna och skapar konfliktmarkörer i de återstående filerna. Lös eventuella konflikter manuellt.

När du inte längre behöver gömman tar du bort den med git stash drop. Det här kommandot tar bort den senaste gömman.

Du kan ha flera stashar, men du måste uttryckligen tillämpa och ta bort varje enskild. Mer information finns i Git Stash-dokumentationen.

Som standard använder Git en kommandoradsredigerare när den frågar efter incheckningsmeddelanden, utför ombaseringar och hanterar andra uppgifter som kräver indata. Konfigurera standardredigeraren med git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Git för Windows gör det enkelt att ange Anteckningar som redigeringsprogram:

> git config core.editor notepad

Det här kommandot konfigurerar Windows Notepad för att hantera Git-textredigering. Du kan också ange en önskad kolumnbredd för incheckningsmeddelanden:

> git config format.commitMessageColumns 72 

Den här inställningen omsluter incheckningsmeddelandetexten med önskad kolumnbredd på 72 tecken.

Git inkluderar ett användarnamn och en e-postadress i varje commit, och Azure Repos använder denna information när det visar commits och pull-förfrågningar. Om du vill uppdatera namnet och e-postmeddelandet på kommandoraden git config använder du kommandot:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

Alternativet --global anger e-post och namn som ingår i incheckningar för alla Git-lagringsplatser i det här systemet. Om du vill ändra inställningarna för en enskild lagringsplats går du till katalogen för lagringsplatsen och kör föregående kommandon utan --global flaggan.

Du kan också ändra namn- och e-postinställningarna från Visual Studio. På Git-menyn väljer du Inställningar. I dialogrutan Alternativ väljer du Globala Git-inställningar ellerInställningar>för Git-lagringsplatsAllmänt.

Aktivera utförlig spårning för att få detaljerad felinformation. Ange följande miljövariabler innan du kör Git-kommandot:

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

Spårningsutdata hjälper dig att avgöra om felet gäller nätverksanslutning, proxykonfiguration, SSL-certifikat eller autentisering. Mer information om Git-miljövariabler finns i Git Internals – Miljövariabler.

Om du är bakom en proxyserver och Git inte har konfigurerats för att använda den, misslyckas kloningsåtgärder och push-åtgärder med 407, 502 eller "det går inte att komma åt".

Kör git config --list för att kontrollera om en proxy redan har konfigurerats. Om inte anger du proxyn globalt:

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Så här konfigurerar du endast en proxy för en specifik URL:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Mer information finns i Dokumentation om Git-konfiguration.

Om lösenordet har ändrats eller cachelagrade autentiseringsuppgifter är inaktuella misslyckas Git-kloningar eller push-åtgärder med autentiseringsfel. Återställ Git Credential Manager (GCM) för att lösa problemet:

> git config --global --unset credential.helper
> git config --global credential.helper manager

Du kan också ta bort cachelagrade autentiseringsuppgifter direkt i Windows Credential Manager:

1. ÖppnaAutentiseringshanteraren för> på >.
2. Välj Windows-autentiseringsuppgifter.
3. Hitta och ta bort poster för git:https://dev.azure.com/<orgname>.

Du kan också använda kommandoraden:

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

På macOS kör du git credential reject för att rensa lagrade autentiseringsuppgifter:

echo url=https://dev.azure.com/<orgname> | git credential reject

När du har rensat autentiseringsuppgifterna, försök att klona eller utföra push-åtgärden igen. Git uppmanar dig att autentisera igen.

När du klonar eller push-överför till en Azure DevOps Server-instans som använder ett självsignerat eller internt CA-certifikat misslyckas Git med:

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

Alternativ 1: Använd Windows SChannel (rekommenderas i Windows)

Konfigurera Git för att använda Windows-certifikatarkivet i stället för det paketerade OpenSSL CA-paketet. Om Windows litar på serverns certifikat eller certifikatutfärdare krävs inga ytterligare steg:

> git config --global http.sslBackend schannel

Mer information om hur du konfigurerar SSL-serverdelen i Visual Studio finns i Git-inställningar – Kryptografisk nätverksprovider.

Alternativ 2: Peka Git på ditt CA-certifikat

Exportera ditt rotcertifikat eller mellanliggande CA-certifikat som en Base-64-kodad .crt fil och berätta sedan för Git var du hittar det:

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

Du kan också lägga till certifikatet i Gits befintliga CA-paket (vanligtvis på C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) i stället för att åsidosätta hela paketet.

Information om pipelineagentscenarier med självsignerade certifikat finns i Köra en lokalt installerad agent bakom en proxy eller med självsignerade certifikat.

Relaterat innehåll

• Dokumentation om Azure Repos Git
• Klona en befintlig Git-lagringsplats
• Spara ditt arbete med commits
• Använd Git-grenar