From cb12bfc0d435a4764b234c292d120fd0e2981eb9 Mon Sep 17 00:00:00 2001 From: Josef Andersson Date: Sun, 29 Mar 2026 09:11:56 +0200 Subject: [PATCH] =?UTF-8?q?chore:=20lessen=20unneeded=20den=20h=C3=A4r/det?= =?UTF-8?q?=20h=C3=A4r/detta?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Josef Andersson --- B-embedding-git-in-your-applications.asc | 2 +- C-git-commands.asc | 10 ++--- .../sections/about-version-control.asc | 2 +- .../01-introduction/sections/command-line.asc | 2 +- book/01-introduction/sections/help.asc | 2 +- .../sections/getting-a-repository.asc | 2 +- .../sections/recording-changes.asc | 4 +- book/02-git-basics/sections/remotes.asc | 4 +- book/02-git-basics/sections/tagging.asc | 4 +- .../sections/basic-branching-and-merging.asc | 6 +-- book/03-git-branching/sections/rebasing.asc | 10 ++--- .../sections/remote-branches.asc | 4 +- book/03-git-branching/sections/workflows.asc | 2 +- book/04-git-server/sections/protocols.asc | 2 +- .../sections/setting-up-server.asc | 6 +-- .../sections/contributing.asc | 6 +-- .../sections/maintaining.asc | 2 +- .../sections/1-setting-up-account.asc | 2 +- book/06-github/sections/2-contributing.asc | 38 +++++++++---------- book/06-github/sections/3-maintaining.asc | 8 ++-- book/06-github/sections/5-scripting.asc | 6 +-- .../sections/advanced-merging.asc | 18 ++++----- book/07-git-tools/sections/bundling.asc | 4 +- book/07-git-tools/sections/credentials.asc | 2 +- book/07-git-tools/sections/debugging.asc | 2 +- .../sections/interactive-staging.asc | 2 +- book/07-git-tools/sections/replace.asc | 2 +- book/07-git-tools/sections/reset.asc | 16 ++++---- .../sections/revision-selection.asc | 4 +- .../sections/rewriting-history.asc | 8 ++-- .../sections/stashing-cleaning.asc | 2 +- book/07-git-tools/sections/submodules.asc | 12 +++--- .../sections/attributes.asc | 12 +++--- book/08-customizing-git/sections/config.asc | 12 +++--- book/08-customizing-git/sections/hooks.asc | 6 +-- book/08-customizing-git/sections/policy.asc | 4 +- .../sections/client-hg.asc | 6 +-- .../sections/client-p4.asc | 24 ++++++------ .../sections/client-svn.asc | 8 ++-- .../sections/import-custom.asc | 2 +- .../sections/import-hg.asc | 4 +- .../10-git-internals/sections/maintenance.asc | 2 +- book/10-git-internals/sections/objects.asc | 2 +- .../sections/plumbing-porcelain.asc | 6 +-- book/10-git-internals/sections/refs.asc | 2 +- .../sections/transfer-protocols.asc | 2 +- .../sections/guis.asc | 10 ++--- .../sections/jetbrainsides.asc | 2 +- .../sections/zsh.asc | 2 +- .../B-embedding-git/sections/command-line.asc | 2 +- book/B-embedding-git/sections/go-git.asc | 2 +- book/B-embedding-git/sections/jgit.asc | 8 ++-- book/B-embedding-git/sections/libgit2.asc | 2 +- ch03-git-branching.asc | 2 +- ch05-distributed-git.asc | 2 +- ch06-github.asc | 2 +- ch08-customizing-git.asc | 2 +- ch10-git-internals.asc | 2 +- 58 files changed, 163 insertions(+), 163 deletions(-) diff --git a/B-embedding-git-in-your-applications.asc b/B-embedding-git-in-your-applications.asc index b0e4d313..5ff29c35 100644 --- a/B-embedding-git-in-your-applications.asc +++ b/B-embedding-git-in-your-applications.asc @@ -3,7 +3,7 @@ == Bädda in Git i dina applikationer Om din applikation är för utvecklare är chansen stor att den skulle kunna dra nytta av integration med versionshantering. -Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan potentiellt dra nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier. +Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan eventuellt dra nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier. Om du behöver integrera Git med din applikation har du i praktiken två alternativ: starta ett skal och anropa kommandoradsprogrammet `git`, eller bädda in ett Git‑bibliotek i din applikation. Här går vi igenom kommandoradsintegration och flera av de mest populära inbäddningsbara Git‑biblioteken. diff --git a/C-git-commands.asc b/C-git-commands.asc index 41e5d975..a7c266ec 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -39,7 +39,7 @@ I <> använde vi det för att sätta upp en I <> visade vi hur man sätter upp smudge‑ och clean‑filter för innehåll som går in och ut ur Git. -Slutligen är i princip hela <> dedikerat åt kommandot. +Slutligen är i princip hela <> ägnat åt kommandot. [[ch_core_editor]] ==== git config core.editor‑kommandon @@ -101,7 +101,7 @@ Vi nämner kort hur du kan ändra standardgrennamnet från "`master`" i <>. -Slutligen går vi igenom några detaljer om vad det faktiskt gör bakom kulisserna i <>. +Slutligen går vi igenom några detaljer om vad det egentligen gör bakom kulisserna i <>. ==== git clone @@ -183,7 +183,7 @@ I <> går vi igenom i mycket större Vi tittade på hur man signerar incheckningar kryptografiskt med flaggan `-S` i <>. -Slutligen tittar vi på vad kommandot `git commit` gör i bakgrunden och hur det faktiskt är implementerat i <>. +Slutligen tittar vi på vad kommandot `git commit` gör i bakgrunden och hur det egentligen är implementerat i <>. ==== git reset @@ -229,7 +229,7 @@ Det finns bara en handfull kommandon som implementerar det mesta av grening och Kommandot `git branch` är i praktiken ett verktyg för grenhantering. Det kan lista de grenar du har, skapa en ny gren, ta bort grenar och byta namn på grenar. -Merparten av <> är dedikerat till kommandot `branch` och det används genom hela kapitlet. +Merparten av <> är ägnat åt kommandot `branch` och det används genom hela kapitlet. Vi introducerar det först i <> och går igenom de flesta andra funktionerna (lista och ta bort) i <>. I <> använder vi alternativet `git branch -u` för att sätta upp en spårningsgren. @@ -291,7 +291,7 @@ I <> går vi igenom detta ganska ingående. I <> och <> går vi igenom formatet `branchA...branchB` och syntaxen `--left-right` för att se vad som finns i den ena grenen eller den andra men inte i båda. I <> tittar vi också på hur man använder alternativet `--merge` för att hjälpa till med felsökning av sammanslagningskonflikter samt hur man använder `--cc` för att titta på sammanslagningsincheckningskonflikter i historiken. -I <> använder vi alternativet `-g` för att visa Git‑refloggen genom det här verktyget i stället för att traversera grenar. +I <> använder vi alternativet `-g` för att visa Git‑refloggen genom verktyget i stället för att traversera grenar. I <> tittar vi på att använda alternativen `-S` och `-L` för att göra ganska avancerade sökningar efter något som hände historiskt i koden, såsom att se historiken för en funktion. diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 8f501664..2417191d 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -40,7 +40,7 @@ Den här modellen ger många fördelar, särskilt jämfört med lokala VCS:er. Till exempel vet alla till viss del vad alla andra i projektet gör. Administratörer har detaljerad kontroll över vem som kan göra vad, och det är betydligt enklare att administrera ett centraliserat system än att hantera lokala databaser på varje klient. -Men den här modellen har också några allvarliga nackdelar. +Men modellen har också några allvarliga nackdelar. Den mest uppenbara är den enda felpunkt som den centraliserade servern utgör. Om den servern går ner i en timme kan ingen under den tiden samarbeta eller spara versionshanterade ändringar i det de jobbar med. Om hårddisken där den centrala databasen ligger blir korrupt och man inte har riktiga säkerhetskopior förlorar man allt – hela projektets historik, förutom de enstaka versioner som råkar finnas på folks lokala maskiner. diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index dc268455..0068c1df 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -2,7 +2,7 @@ Det finns många olika sätt att använda Git. Det finns de ursprungliga kommandoradsverktygen och det finns många grafiska användargränssnitt med varierande möjligheter. -För den här boken kommer vi att använda Git i kommandoraden. +I boken använder vi Git i kommandoraden. För det första är kommandoraden det enda stället där du kan köra _alla_ Git-kommandon – de flesta grafiska gränssnitt implementerar bara en delmängd av Gits funktionalitet för enkelhetens skull. Om du kan köra kommandoradsversionen kan du troligen också räkna ut hur du använder den grafiska versionen, medan det omvända inte nödvändigtvis är lika lätt. Dessutom är valet av grafisk klient en smakfråga, men _alla_ användare har kommandoradsverktygen installerade och tillgängliga. diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index fd512666..a679584e 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -18,7 +18,7 @@ $ git help config ---- Dessa kommandon är smidiga eftersom du kan använda dem överallt, även utan uppkoppling. -Om manualsidorna och den här boken inte räcker och du behöver personlig hjälp kan du prova kanalerna `#git`, `#github` eller `#gitlab` på Libera Chat IRC-servern, som finns på https://libera.chat/[^]. +Om manualsidorna och boken inte räcker och du behöver personlig hjälp kan du prova kanalerna `#git`, `#github` eller `#gitlab` på Libera Chat IRC-servern, som finns på https://libera.chat/[^]. På dessa kanaler samlas regelbundet hundratals personer som är kunniga i Git och ofta villiga att hjälpa till.(((IRC))) Dessutom, om du inte behöver hela manualsidan utan bara en snabb påminnelse om vilka flaggor som finns för ett Git-kommando, kan du be om den kortare hjälpen med `-h`-flaggan, till exempel: diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index a88a5b69..bd33f872 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -37,7 +37,7 @@ $ git init ---- Det här skapar en ny underkatalog som heter `.git` och innehåller alla nödvändiga filer – ett skelett för ditt Git‑kodförråd. -I det här läget är inget i projektet spårat. +I nuläget är inget i projektet spårat. Se <> för mer information om exakt vilka filer som finns i `.git`-katalogen du nyss skapade.(((git commands, init))) Om du vill börja versionshantera befintliga filer (till skillnad från en tom katalog) bör du börja spåra dem och göra en första incheckning. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 91b3b398..83fca627 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -341,7 +341,7 @@ index 0000000..03902a1 +My Project ---- -Viktigt att notera är att `git diff` i sig inte visar alla ändringar sedan senaste incheckningen – bara ändringar som ännu inte kommer ingå i nästa incheckning. +Viktigt att tänka på är att `git diff` i sig inte visar alla ändringar sedan senaste incheckningen – bara ändringar som ännu inte kommer ingå i nästa incheckning. Om du har köat alla ändringar att ingå i nästa incheckning ger `git diff` ingen utskrift. Ytterligare ett exempel: om du köar `CONTRIBUTING.md` och sedan ändrar den igen kan du använda `git diff` för att se både de köade och oköade ändringarna. @@ -559,7 +559,7 @@ Det betyder att du kan göra saker som: $ git rm log/\*.log ---- -Notera omvänt snedstreck (`\`) framför `*`. +Observera omvänt snedstreck (`\`) framför `*`. Det behövs eftersom Git gör sin egen filnamnsexpansion utöver skalets expansion. Kommandot tar bort alla filer med filändelsen `.log` i katalogen `log/`. Eller så kan du göra något i stil med: diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 698df6a2..824214bd 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -6,7 +6,7 @@ Fjärrkodförråd är versioner av ditt projekt som finns någonstans på nätet Du kan ha flera, och var och en är i regel antingen skrivskyddad eller läs/skriv för dig. Att samarbeta innebär att hantera dessa fjärrkodförråd och att skicka och uppdatera data till och från dem när du behöver dela arbete. Att hantera fjärrkodförråd innefattar att lägga till nya, ta bort sådana som inte längre är giltiga, hantera fjärrgrenar och markera dem som spårade eller inte, och mycket mer. -I det här avsnittet går vi igenom några av dessa färdigheter. +I avsnittet går vi igenom några av dessa färdigheter. [NOTE] .Fjärrkodförråd kan ligga på din lokala maskin @@ -67,7 +67,7 @@ origin git@github.com:mojombo/grit.git (push) Det betyder att vi kan uppdatera bidrag från alla dessa ganska enkelt. Vi kan också ha rättigheter att skicka till en eller flera av dem, men det ser vi inte här. -Notera att fjärrkodförråden använder olika protokoll; vi går igenom detta mer i <>. +Observera att fjärrkodförråden använder olika protokoll; vi går igenom detta mer i <>. ==== Lägga till fjärrkodförråd diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 54cad41d..f9263272 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -4,7 +4,7 @@ (((tags))) Precis som de flesta VCS:er kan Git tagga särskilda punkter i ett kodförråds historik. Vanligtvis används detta för att markera utgåvor (`v1.0`, `v2.0` och så vidare). -I det här avsnittet lär du dig hur du listar befintliga taggar, hur du skapar och tar bort dem, samt vilka typer av taggar som finns. +I avsnittet lär du dig hur du listar befintliga taggar, hur du skapar och tar bort dem, samt vilka typer av taggar som finns. ==== Lista taggar @@ -233,7 +233,7 @@ $ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add) ---- -Notera att detta inte tar bort taggen från några fjärrkodförråd. +Observera att detta inte tar bort taggen från några fjärrkodförråd. Det finns två vanliga sätt att ta bort taggar från fjärrkodförråd. Det första är `git push :refs/tags/`: diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index e97863f6..2da8c050 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -7,7 +7,7 @@ Du kommer att följa dessa steg: . Skapa en gren för en ny användarberättelse du jobbar på. . Gör arbete i den grenen. -I det här läget får du ett samtal om att ett annat problem är mer kritiskt och att det behövs en snabbkorrigering. +I det läget får du ett samtal om att ett annat problem är mer kritiskt och att det behövs en snabbkorrigering. Då gör du följande: . Byt till produktionsgrenen. @@ -60,7 +60,7 @@ Nu får du samtalet om att det finns ett problem med webbplatsen som måste fixa Med Git behöver du inte distribuera din fix tillsammans med `iss53`-ändringarna, och du behöver inte lägga tid på att ångra dem innan du kan jobba mot produktion. Allt du behöver göra är att byta tillbaka till `master`. -Notera dock att om arbetskatalogen eller köytan innehåller icke checkade in ändringar som krockar med grenen du vill växla till, kommer Git att hindra bytet. +Observera dock att om arbetskatalogen eller köytan innehåller icke checkade in ändringar som krockar med grenen du vill växla till, kommer Git att hindra bytet. Det är bäst att ha en ren arbetskatalog när du byter gren. Det finns sätt att komma runt detta (gömma ändringar eller göra en tilläggsincheckning), vilket vi går igenom senare i <>. För tillfället antar vi att du har checkat in allt och kan byta tillbaka till `master`: @@ -138,7 +138,7 @@ $ git commit -a -m 'Finish the new footer [issue 53]' .Arbetet fortsätter på `iss53` image::images/basic-branching-6.png[Arbetet fortsätter på `iss53`] -Det är värt att notera att arbetet du gjorde i `hotfix`-grenen inte finns i `iss53`. +Värt att veta är att arbetet du gjorde i `hotfix`-grenen inte finns i `iss53`. Om du behöver få in ändringarna kan du sammanfoga `master` in i `iss53` med `git merge master`, eller vänta tills du senare sammanfogar `iss53` till `master`. [[_basic_merging]] diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 276afc34..5c74e8b1 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -3,7 +3,7 @@ (((rebasing))) I Git finns två huvudsätt att integrera ändringar från en gren in i en annan: `merge` och `rebase`. -I det här avsnittet lär du dig vad ombasering är, hur man gör det, varför det är ett imponerande verktyg och när du inte ska använda det. +I avsnittet lär du dig vad ombasering är, hur man gör det, varför det är ett imponerande verktyg och när du inte ska använda det. ==== Grundläggande ombasering @@ -23,7 +23,7 @@ Men det finns ett annat sätt: du kan ta ändringspatchen som introducerades i ` I Git kallas detta _rebase(ombasera)_. Med `rebase` kan du ta alla ändringar som checkats in på en gren och spela upp dem på en annan.(((git commands, rebase))) -I det här exemplet växlar du till `experiment` och flyttar den till `master` så här: +I exemplet växlar du till `experiment` och flyttar den till `master` så här: [source,console] ---- @@ -57,7 +57,7 @@ Ofta gör du detta för att säkerställa att dina incheckningar går att applic Då gör du arbetet i en gren och flyttar det till `origin/master` när du är redo att skicka in dina ändringspatchar. På så vis behöver förvaltaren bara snabbspola eller applicera ändringarna rent. -Notera att ögonblicksbilden som den sista incheckningen pekar på – oavsett om det är den sista flyttade incheckningen eller den sista sammanslagningsincheckningen – är densamma. +Observera att ögonblicksbilden som den sista incheckningen pekar på – oavsett om det är den sista flyttade incheckningen eller den sista sammanslagningsincheckningen – är densamma. Det är bara historiken som skiljer sig. Ombasering spelar upp ändringar i samma ordning som de introducerades, medan sammanslagning tar ändpunkterna och fogar samman dem. @@ -174,7 +174,7 @@ Om du kör `git pull` skapar du en sammanslagningsincheckning som innehåller b .Du sammanfogar samma arbete igen i en ny sammanslagningsincheckning image::images/perils-of-rebasing-4.png[Du sammanfogar samma arbete igen i en ny sammanslagningsincheckning] -Om du kör `git log` i det här läget ser du två incheckningar med samma författare, datum och meddelande, vilket är förvirrande. +Om du kör `git log` i det läget ser du två incheckningar med samma författare, datum och meddelande, vilket är förvirrande. Om du skickar upp den här historiken till servern återinför du dessutom de omskrivna incheckningarna, vilket kan förvirra andra. Det är rimligt att anta att den andra utvecklaren inte vill ha `C4` och `C6` i historiken; det var därför de flyttade om den från början. @@ -222,7 +222,7 @@ Om du eller en kollega behöver göra det, se till att alla vet att de ska köra Nu när du har sett ombasering och sammanslagning i praktiken undrar du kanske vilket som är bäst. Innan vi kan svara behöver vi ta ett steg tillbaka och prata om vad historik betyder. -Ett perspektiv är att ditt kodförråds incheckningshistorik är *en redogörelse för vad som faktiskt hände*. +Ett perspektiv är att ditt kodförråds incheckningshistorik är *en redogörelse för vad som verkligen hände*. Det är ett historiskt dokument, värdefullt i sig, och ska inte manipuleras. Ur det perspektivet är ändring av historiken nästan hädelse; du _ljuger_ om vad som skedde. Vad gör det om det finns en stökig serie sammanslagningsincheckningar? diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 70222e5f..a4e07d4d 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -111,7 +111,7 @@ From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ---- -Det är viktigt att notera att när du uppdaterar nya fjärrspårade grenar får du inte automatiskt en lokal, redigerbar kopia av dem. +Tänk på att när du uppdaterar nya fjärrspårade grenar får du inte automatiskt en lokal, redigerbar kopia av dem. I det här fallet har du alltså ingen ny lokal `serverfix`-gren – bara en `origin/serverfix`-pekare som du inte kan ändra. För att sammanfoga arbetet med din nuvarande gren kan du köra `git merge origin/serverfix`. @@ -199,7 +199,7 @@ Vi ser också att `master` spårar `origin/master` och är uppdaterad. `serverfix` spårar `server-fix-good` på `teamone` och ligger före med tre och efter med en, vilket betyder att det finns en incheckning på servern som vi inte har sammanfogat ännu och tre lokala incheckningar som inte är skickade. Slutligen ser vi att `testing` inte spårar någon fjärrgren. -Det är viktigt att notera att dessa siffror bara gäller sedan senaste gången du uppdaterade från varje server. +Tänk på att dessa siffror bara gäller sedan senaste gången du uppdaterade från varje server. Kommandot kontaktar inte servrarna utan visar vad som finns i din lokala mellanlagring. Vill du ha helt uppdaterade siffror behöver du uppdatera från alla fjärrkodförråd precis innan du kör det, till exempel så här: diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index e858e863..79212ee7 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,7 +1,7 @@ === Arbetsflöden med grenar Nu när du har grunderna i grenarbete och sammanslagning, vad kan eller bör du göra med dem? -I det här avsnittet går vi igenom några vanliga arbetsflöden som de lättviktiga grenarna möjliggör, så att du kan avgöra om du vill använda dem i din egen utvecklingscykel. +I avsnittet går vi igenom några vanliga arbetsflöden som de lättviktiga grenarna möjliggör, så att du kan avgöra om du vill använda dem i din egen utvecklingscykel. ==== Långlivade grenar diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index f77fa06d..0c31467e 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -182,7 +182,7 @@ Om du vill ha anonym läsåtkomst och samtidigt använda SSH för uppsändning m (((protocols, git))) Till sist har vi Git-protokollet. -Det är en särskild demon som följer med Git; den lyssnar på en dedikerad port (9418) och tillhandahåller en tjänst liknande SSH, men helt utan autentisering eller kryptering. +Det är en särskild demon som följer med Git; den lyssnar på en egen port (9418) och tillhandahåller en tjänst liknande SSH, men helt utan autentisering eller kryptering. För att ett kodförråd ska kunna erbjudas via Git-protokollet måste du skapa en `git-daemon-export-ok`-fil – annars serveras det inte – men förutom det finns det ingen säkerhet. Antingen är kodförrådet tillgängligt för alla att klona eller inte alls. Det innebär att man normalt inte skickar upp via detta protokoll. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 747325b9..a59bcb28 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -2,7 +2,7 @@ === Konfigurera servern Låt oss gå igenom hur du sätter upp SSH‑åtkomst på serversidan. -I det här exemplet använder du metoden `authorized_keys` för att autentisera användare. +I exemplet använder du metoden `authorized_keys` för att autentisera användare. Vi antar också att du kör en vanlig Linuxdistribution, till exempel Ubuntu. [NOTE] @@ -57,7 +57,7 @@ Initialized empty Git repository in /srv/git/project.git/ ---- Därefter kan John, Josie eller Jessica skicka den första versionen av projektet genom att lägga till kodförrådet som fjärrkodförråd och skicka en gren. -Notera att någon måste logga in på maskinen och skapa ett bart kodförråd varje gång du vill lägga till ett projekt. +Observera att någon måste logga in på maskinen och skapa ett bart kodförråd varje gång du vill lägga till ett projekt. Låt oss använda `gitserver` som värdnamn på servern där du har skapat `git`-användaren och kodförrådet. Om du kör detta internt och har DNS som pekar `gitserver` till servern kan du i praktiken använda kommandona rakt av (förutsatt att `myproject` redan finns lokalt): @@ -118,7 +118,7 @@ hint: ~/git-shell-commands should exist and have read and execute access. Connection to gitserver closed. ---- -I det här läget kan användare fortfarande använda SSH‑portvidarebefordran för att nå värdar som gitservern når. +I nuläget kan användare fortfarande använda SSH‑portvidarebefordran för att nå värdar som gitservern når. Om du vill förhindra det kan du redigera `authorized_keys` och lägga till följande alternativ före varje nyckel du vill begränsa: [source,console] diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 3e8a2343..e4beba2a 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -102,7 +102,7 @@ Git‑projektet har välformaterade incheckningsmeddelanden – kör `git log -- [NOTE] .Gör som vi säger och inte som vi gör ==== -För att vara helt ärliga har många av exemplen i den här boken inte särskilt välformaterade incheckningsmeddelanden; vi använder ofta `-m` efter `git commit`. +För att vara helt ärliga har många av exemplen i boken inte särskilt välformaterade incheckningsmeddelanden; vi använder ofta `-m` efter `git commit`. Som sagt, gör som vi säger, inte som vi gör. ==== @@ -323,7 +323,7 @@ $ git commit -am 'Add limit to log function' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -I det här läget behöver hon dela arbetet med John, så hon skickar sin `featureA`-gren till servern. +I nuläget behöver hon dela arbetet med John, så hon skickar sin `featureA`-gren till servern. Jessica har inte behörighet att sammanfoga i huvudgrenen, så hon måste skicka till en separat gren för att kunna samarbeta: [source,console] @@ -479,7 +479,7 @@ Du kanske vill använda `rebase -i` för att komprimera ditt arbete till en enda ==== När arbetet är klart och du vill dela det går du till grundkodförrådets projektsida och klickar på knappen "Avgrena" för att skapa en avgrening som du har full behörighet till. -Därefter lägger du till den nya kodförrådets URL som ett nytt fjärrkodförråd; i det här exemplet kallar vi den `min-avgrening`: +Därefter lägger du till den nya kodförrådets URL som ett nytt fjärrkodförråd; i exemplet kallar vi den `min-avgrening`: [source,console] ---- diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 182bc0b8..657cce05 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -224,7 +224,7 @@ Merge made by the 'recursive' strategy. (((branches, diffing))) Nu har du en ämnesgren som innehåller ett bidrag. Du behöver bestämma vad du vill göra med den. -I det här avsnittet går vi igenom några kommandon som hjälper dig att granska exakt vad som kommer att tillämpas om du sammanfogar grenen med din huvudgren. +I avsnittet går vi igenom några kommandon som hjälper dig att granska exakt vad som kommer att tillämpas om du sammanfogar grenen med din huvudgren. Det är ofta användbart att få en överblick över alla incheckningar i grenen som inte finns i huvudgrenen. Du kan utesluta incheckningar i huvudgrenen genom att lägga till `--not` före grennamnet. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index ce316a41..7a29708c 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -15,7 +15,7 @@ Gör det direkt; det är ganska viktigt (som vi kommer se senare). ==== GitHub tillhandahåller nästan all funktionalitet i gratis konton, med undantag för några mer avancerade funktioner. -GitHubs betaltjänster innehåller avancerade verktyg och funktioner samt högre gränser för gratistjänster, men vi går inte igenom dem i den här boken. +GitHubs betaltjänster innehåller avancerade verktyg och funktioner samt högre gränser för gratistjänster, men vi går inte igenom dem i boken. Vill du läsa mer om tillgängliga abonnemang och deras jämförelse, besök https://github.com/pricing[^]. ==== diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index c481042e..cb94b24e 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -175,7 +175,7 @@ Lyckligtvis är det mycket rakt på sak. Där man via e-post kan behöva rulla om sin serie och skicka in den till e-postlistan igen, räcker det på GitHub att checka in i ämnesgrenen igen och skicka, vilket automatiskt uppdaterar ändringsförfrågan. I <<_pr_final>> kan du också se att den gamla kodkommentaren har fällts ihop i den uppdaterade ändringsförfrågan, eftersom den gjordes på en rad som sedan ändrats. -Att lägga till incheckningar i en befintlig ändringsförfrågan triggar ingen avisering, så när Tony har skickat upp sina rättelser väljer han att lämna en kommentar för att meddela projektägaren att han gjort den begärda ändringen. +Att lägga till incheckningar i en befintlig ändringsförfrågan utlöser ingen avisering, så när Tony har skickat upp sina rättelser väljer han att lämna en kommentar för att meddela projektägaren att han gjort den begärda ändringen. [[_pr_final]] .Ändringsförfrågan, slutligt läge @@ -198,7 +198,7 @@ Det här är det grundläggande arbetsflödet som de flesta GitHub-projekt anvä [NOTE] .Inte bara avgreningar ==== -Det är viktigt att notera att du också kan öppna en ändringsförfrågan mellan två grenar i samma kodförråd. +Tänk på att du också kan öppna en ändringsförfrågan mellan två grenar i samma kodförråd. Om du arbetar på en funktion med någon och ni båda har skrivrättigheter till projektet kan du skicka en ämnesgren till kodförrådet och öppna en ändringsförfrågan mot `master`-grenen i samma projekt för att starta kodgranskning och diskussion. Ingen avgrening behövs. ==== @@ -315,11 +315,11 @@ Vi kan fylla i beskrivningen som i <<_pr_references>>. .Korsreferenser i en ändringsförfrågan image::images/mentions-01-syntax.png[Korsreferenser i en ändringsförfrågan] -När vi skickar in ändringsförfrågan ser vi allt renderat som i <<_pr_references_render>>. +När vi skickar in ändringsförfrågan ser vi hur allt visas som i <<_pr_references_render>>. [[_pr_references_render]] -.Korsreferenser renderade i en ändringsförfrågan -image::images/mentions-02-render.png[Korsreferenser renderade i en ändringsförfrågan] +.Korsreferenser återgivna i en ändringsförfrågan +image::images/mentions-02-render.png[Korsreferenser återgivna i en ändringsförfrågan] Lägg märke till att hela GitHub-adressen vi la in kortades till precis den information som behövs. @@ -339,13 +339,13 @@ Du måste ange hela SHA-1 på 40 tecken, men om GitHub ser det i en kommentar l Att länka till andra ärenden är bara början på intressanta saker du kan göra i nästan varje textruta på GitHub. I beskrivningar av ärenden och ändringsförfrågningar, kommentarer, kodkommentarer med mera kan du använda det som kallas "GitHub-anpassad Markdown". -Markdown är som att skriva i vanlig text, men renderas rikt. +Markdown är som att skriva i vanlig text, men visas med rik formatering. -Se <<_example_markdown>> för ett exempel på hur kommentarer eller text kan skrivas och sedan renderas med Markdown. +Se <<_example_markdown>> för ett exempel på hur kommentarer eller text kan skrivas och sedan visas med Markdown. [[_example_markdown]] -.Ett exempel på GitHub-anpassad Markdown, både skriven och renderad -image::images/markdown-01-example.png[alt="Ett exempel på GitHub-anpassad Markdown, både skriven och renderad"] +.Ett exempel på GitHub-anpassad Markdown, både skriven och återgiven +image::images/markdown-01-example.png[alt="Ett exempel på GitHub-anpassad Markdown, både skriven och återgiven"] GitHubs variant av Markdown lägger till fler saker du kan göra utöver den grundläggande Markdown-syntaxen. Allt detta är mycket användbart när du skapar bra ändringsförfråge- eller ärendekommentarer eller beskrivningar. @@ -365,11 +365,11 @@ Du kan skapa en uppgiftslista så här: - [ ] Document the code ---- -Om vi tar med detta i beskrivningen av vår ändringsförfrågan eller vårt ärende ser det renderat ut som i <<_eg_task_lists>>. +Om vi tar med detta i beskrivningen av vår ändringsförfrågan eller vårt ärende ser det ut som i <<_eg_task_lists>>. [[_eg_task_lists]] -.Uppgiftslistor renderade i en Markdown-kommentar -image::images/markdown-02-tasks.png[Uppgiftslistor renderade i en Markdown-kommentar] +.Uppgiftslistor återgivna i en Markdown-kommentar +image::images/markdown-02-tasks.png[Uppgiftslistor återgivna i en Markdown-kommentar] Detta används ofta i ändringsförfrågningar för att ange vad du vill få gjort i grenen innan ändringsförfrågan är redo att sammanfogas. Det riktigt smidiga är att du kan klicka i kryssrutorna för att uppdatera kommentaren -- du behöver inte redigera Markdownen direkt för att bocka av uppgifter. @@ -404,11 +404,11 @@ for(int i=0 ; i < 5 ; i++) ---- Om du lägger till ett språknamn som vi gjorde med "java" kommer GitHub också att försöka syntaxmarkera snutten. -I fallet ovan skulle den renderas ungefär som i <<_md_code>>. +I fallet ovan skulle den visas ungefär som i <<_md_code>>. [[_md_code]] -.Renderat exempel på inhägnad kod -image::images/markdown-04-fenced-code.png[Renderat exempel på inhägnad kod] +.Visat exempel på inhägnad kod +image::images/markdown-04-fenced-code.png[Visat exempel på inhägnad kod] ===== Citat @@ -426,11 +426,11 @@ Citaten ser ut ungefär så här: How big are these slings and in particular, these arrows? ---- -När kommentaren renderas ser den ut som i <<_md_quote>>. +När kommentaren visas ser den ut som i <<_md_quote>>. [[_md_quote]] -.Renderat exempel på citat -image::images/markdown-05-quote.png[Renderat exempel på citat] +.Visat exempel på citat +image::images/markdown-05-quote.png[Visat exempel på citat] ===== Emoji @@ -457,7 +457,7 @@ I :eyes: that :bug: and I :cold_sweat:. :clap::tada::panda_face: ---- -När det renderas ser det ut ungefär som i <<_md_emoji>>. +När det visas ser det ut ungefär som i <<_md_emoji>>. [[_md_emoji]] .Mycket emoji i kommentarer diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 5421e4a5..33357d5d 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -314,7 +314,7 @@ Om det till exempel var ett ärende skulle fältet `` ha varit "issues" i s Fälten `List-Post` och `List-Unsubscribe` innebär att om du har en e-postklient som förstår dem kan du enkelt posta till listan eller "avprenumerera" från tråden. Det är i praktiken samma sak som att klicka på "tyst"-knappen i webbversionen av aviseringen eller "Avprenumerera" på ärende- eller ändringsförfrågesidan. -Det är också värt att notera att om du har både e-post- och webbaviseringar aktiverade och du läser e-postversionen av aviseringen kommer webbversionen att markeras som läst också, om du tillåter bilder i din e-postklient. +Värt att veta är också att om du har både e-post- och webbaviseringar aktiverade och du läser e-postversionen av aviseringen kommer webbversionen att markeras som läst också, om du tillåter bilder i din e-postklient. ==== Särskilda filer @@ -324,9 +324,9 @@ Det finns ett par särskilda filer som GitHub lägger märke till om de finns i Den första är `README`-filen, som kan vara i nästan vilket format som helst som GitHub känner igen som brödtext. Till exempel kan den vara `README`, `README.md`, `README.asciidoc` och så vidare. -Om GitHub ser en `README`-fil i källkoden renderar den den på projektets startsida. +Om GitHub ser en `README`-fil i källkoden visar den den på projektets startsida. -Många team använder den här filen för att samla all relevant projektinformation för någon som kan vara ny i kodförrådet eller projektet. +Många team använder filen för att samla all relevant projektinformation för någon som kan vara ny i kodförrådet eller projektet. Det inkluderar vanligtvis saker som: * Vad projektet är till för @@ -335,7 +335,7 @@ Det inkluderar vanligtvis saker som: * Vilken licens projektet ges ut under * Hur man bidrar till det -Eftersom GitHub renderar den här filen kan du bädda in bilder eller länkar i den för att göra det lättare att förstå. +Eftersom GitHub visar filen kan du bädda in bilder eller länkar i den för att göra det lättare att förstå. ==== CONTRIBUTING diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 7771cc17..7d7c1d4f 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -3,7 +3,7 @@ Nu har vi gått igenom alla viktiga funktioner och arbetsflöden i GitHub, men varje större grupp eller projekt vill ofta göra anpassningar eller integrera externa tjänster. Lyckligtvis är GitHub ganska enkelt att anpassa på många sätt. -I det här avsnittet går vi igenom hur du använder GitHubs krok-system och dess API för att få GitHub att fungera som du vill. +I avsnittet går vi igenom hur du använder GitHubs krok-system och dess API för att få GitHub att fungera som du vill. ==== Tjänster och krokar @@ -117,7 +117,7 @@ Vad händer om du behöver automatisera något som att lägga till medarbetare e Det är här GitHub-API:t kommer till nytta. GitHub har massor av API-ändpunkter för att göra nästan allt du kan göra på webbplatsen på ett automatiserat sätt. -I det här avsnittet lär vi oss hur vi autentiserar och ansluter till API:t, hur vi kommenterar ett ärende och hur vi ändrar status för en ändringsförfrågan via API:t. +I avsnittet lär vi oss hur vi autentiserar och ansluter till API:t, hur vi kommenterar ett ärende och hur vi ändrar status för en ändringsförfrågan via API:t. ==== Grundläggande användning @@ -142,7 +142,7 @@ $ curl https://api.github.com/users/schacon ---- Det finns massor av API-ändpunkter som den här för att hämta information om organisationer, projekt, ärenden och incheckningar -- i princip allt du kan se offentligt på GitHub. -Du kan till och med använda API:t för att rendera godtycklig Markdown eller hitta en `.gitignore`-mall. +Du kan till och med använda API:t för att återge godtycklig Markdown eller hitta en `.gitignore`-mall. [source,javascript] ---- diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index e1f5f676..dd4a094d 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -9,7 +9,7 @@ Till skillnad från vissa andra versionshanteringssystem försöker Git inte var Gits filosofi är att vara smart när en sammanslagningslösning är entydig, men om det finns en konflikt försöker den inte vara smart om att lösa den automatiskt. Därför kan du, om du väntar för länge med att sammanfoga två grenar som snabbt glider isär, stöta på vissa problem. -I det här avsnittet går vi igenom vad några av dessa problem kan vara och vilka verktyg Git ger dig för att hantera mer knepiga situationer. +I avsnittet går vi igenom vad några av dessa problem kan vara och vilka verktyg Git ger dig för att hantera mer knepiga situationer. Vi tar också upp några olika, icke‑standardiserade typer av sammanslagningar du kan göra, samt hur du tar dig ur sammanslagningar du redan gjort. ==== Sammanslagningskonflikter @@ -167,7 +167,7 @@ Först hamnar vi i sammanslagningskonflikt‑läge. Sedan vill vi ta kopior av vår version av filen, deras version (från grenen vi sammanfogar in) och den gemensamma versionen (från där båda sidor grenades). Sedan vill vi fixa antingen deras sida eller vår sida och försöka sammanfoga igen för just den filen. -Att få de tre filversionerna är faktiskt ganska enkelt. +Att få de tre filversionerna är ganska enkelt. Git lagrar alla dessa versioner i indexet under "steg" som vart och ett har ett nummer kopplat till sig. Steg 1 är den gemensamma anfadern, steg 2 är din version och steg 3 är från `MERGE_HEAD`, versionen du sammanfogar in ("`theirs`"/"deras"). @@ -220,10 +220,10 @@ index 36c06c8,e85207e..0000000 ---- Vid det här laget har vi snyggt sammanfogat filen. -Faktum är att det här fungerar bättre än alternativet `ignore-space-change` eftersom det faktiskt åtgärdar blankteckensändringarna före sammanslagning i stället för att bara ignorera dem. -I sammanslagningen med `ignore-space-change` hamnade vi faktiskt med några rader med DOS‑radslut, vilket gav en blandning. +Faktum är att det här fungerar bättre än alternativet `ignore-space-change` eftersom det verkligen åtgärdar blankteckensändringarna före sammanslagning i stället för att bara ignorera dem. +I sammanslagningen med `ignore-space-change` hamnade vi med några rader med DOS‑radslut, vilket gav en blandning. -Om du vill få en uppfattning innan du slutför den här incheckningen om vad som faktiskt ändrades mellan den ena sidan och den andra kan du be `git diff` jämföra det som ligger i din arbetskatalog och som du är på väg att checka in som resultat av sammanslagningen med något av dessa steg. +Om du vill få en uppfattning innan du slutför den här incheckningen om vad som egentligen ändrades mellan den ena sidan och den andra kan du be `git diff` jämföra det som ligger i din arbetskatalog och som du är på väg att checka in som resultat av sammanslagningen med något av dessa steg. Låt oss gå igenom dem allihop. För att jämföra ditt resultat med det du hade i din gren före sammanslagningen, med andra ord, för att se vad sammanslagningen introducerade, kan du köra `git diff --ours`: @@ -247,7 +247,7 @@ index 36c06c8..44d0a25 100755 hello() ---- -Här ser vi alltså att det som hände i vår gren, det vi faktiskt inför i filen med denna sammanslagning, är att en enda rad ändras. +Här ser vi alltså att det som hände i vår gren, det vi egentligen inför i filen med denna sammanslagning, är att en enda rad ändras. Om vi vill se hur resultatet av sammanslagningen skiljer sig från deras sida kan du köra `git diff --theirs`. I detta och följande exempel måste vi använda `-b` för att ta bort blanktecken eftersom vi jämför med det som ligger i Git, inte vår städade `hello.theirs.rb`‑fil. @@ -307,7 +307,7 @@ Removing hello.theirs.rb Kanske är vi inte nöjda med lösningen av någon anledning, eller så fungerade inte manuell redigering av ena eller båda sidor så bra och vi behöver mer kontext. Låt oss ändra exemplet lite. -I det här exemplet har vi två långlivade grenar som båda har några incheckningar i sig men skapar en legitim innehållskonflikt vid sammanslagning. +I exemplet har vi två långlivade grenar som båda har några incheckningar i sig men skapar en legitim innehållskonflikt vid sammanslagning. [source,console] ---- @@ -465,7 +465,7 @@ index 0399cd5,59727f0..0000000 Formatet kallas "Kombinerad diff" och ger dig två kolumner med data bredvid varje rad. Den första kolumnen visar om raden är annorlunda (tillagd eller borttagen) mellan "`ours`"‑grenen och filen i din arbetskatalog och den andra kolumnen gör samma sak mellan "`theirs`"‑grenen och din arbetskatalogskopia. -I det här exemplet kan du se att `<<<<<<<` och `>>>>>>>`‑raderna finns i arbetskopian men inte fanns på någon av sidorna i sammanslagningen. +I exemplet kan du se att `<<<<<<<` och `>>>>>>>`‑raderna finns i arbetskopian men inte fanns på någon av sidorna i sammanslagningen. Det är logiskt eftersom sammanslagningsverktyget satte in dem för kontext, men vi förväntas ta bort dem. Om vi löser konflikten och kör `git diff` igen ser vi samma sak, men det är lite mer användbart. @@ -607,7 +607,7 @@ $ git merge topic .Historik efter att sammanfoga om en återställd sammanslagning image::images/undomerge-revert3.png[Historik efter att sammanfoga om en återställd sammanslagning] -I det här exemplet tar `M` och `^M` ut varandra. +I exemplet tar `M` och `^M` ut varandra. `^^M` sammanfogar i praktiken ändringarna från `C3` och `C4`, och `C8` sammanfogar ändringarna från `C7`, så nu är `topic` helt sammanfogad. ==== Andra typer av sammanslagningar diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 2a01fdd2..74764934 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -1,7 +1,7 @@ [[_bundling]] === Bunta -Även om vi har gått igenom de vanliga sätten att överföra Git‑data över nätverk (HTTP, SSH, osv.) finns det faktiskt ytterligare ett sätt som inte används så ofta men kan vara riktigt användbart. +Även om vi har gått igenom de vanliga sätten att överföra Git‑data över nätverk (HTTP, SSH, osv.) finns det ytterligare ett sätt som inte används så ofta men kan vara riktigt användbart. Git kan "bunta" sin data till en enda fil. Det kan vara användbart i olika scenarier. @@ -112,7 +112,7 @@ Nu har vi en fil `commits.bundle` i vår katalog. Om vi tar den och skickar den till vår partner kan hon importera den i det ursprungliga kodförrådet, även om mer arbete har gjorts där under tiden. När hon får bunten kan hon inspektera den för att se vad den innehåller innan hon importerar den i sitt kodförråd. -Det första kommandot är `git bundle verify`, som säkerställer att filen faktiskt är en giltig Git‑bunt och att du har alla nödvändiga anfäder för att återskapa den korrekt. +Det första kommandot är `git bundle verify`, som säkerställer att filen verkligen är en giltig Git‑bunt och att du har alla nödvändiga anfäder för att återskapa den korrekt. [source,console] ---- diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 0f057345..551f6103 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -91,7 +91,7 @@ password=s3cre7 <4> Git‑credential tar sedan över och skriver till stdout med den information den hittade. <5> Om inloggningsuppgifter inte hittas frågar Git användaren efter användarnamn och lösenord och ger dem tillbaka till den som anropade på stdout (här sitter de på samma konsol). -Inloggningssystemet anropar faktiskt ett program som är separat från Git; vilket och hur beror på konfigurationsvärdet `credential.helper`. +Inloggningssystemet anropar i själva verket ett program som är separat från Git; vilket och hur beror på konfigurationsvärdet `credential.helper`. Det finns flera former det kan ta: [options="header"] diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 3687c09f..2c310f2b 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -34,7 +34,7 @@ b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 70) KBUILD_VERBOSE = $ Observera att det första fältet är den förkortade SHA‑1:an för incheckningen som senast ändrade raden. De två nästa fälten är värden som hämtats från den incheckningen -- författarnamn och författardatum -- så att du lätt kan se vem som ändrade raden och när. Efter det kommer radnumret och filens innehåll. -Notera också `^1da177e4c3f4`‑raderna, där `^`‑prefixet markerar rader som infördes i kodförrådets första incheckning och har varit oförändrade sedan dess. +Lägg också märke till `^1da177e4c3f4`‑raderna, där `^`‑prefixet markerar rader som infördes i kodförrådets första incheckning och har varit oförändrade sedan dess. Det kan vara förvirrande, eftersom du nu har sett minst tre sätt som Git använder `^` för att modifiera en SHA-1-referens, men här är det just den betydelsen som gäller. En annan cool sak med Git är att den inte spårar filnamnsbyten explicit. diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 86d87b1a..83ec45b1 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -1,7 +1,7 @@ [[_interactive_staging]] === Interaktiv köläggning -I det här avsnittet tittar vi på några interaktiva Git-kommandon som kan hjälpa dig att forma dina incheckningar så att de bara innehåller vissa kombinationer och delar av filer. +I avsnittet tittar vi på några interaktiva Git-kommandon som kan hjälpa dig att forma dina incheckningar så att de bara innehåller vissa kombinationer och delar av filer. Dessa verktyg är hjälpsamma om du ändrar många filer i stor utsträckning och sedan bestämmer dig för att du vill dela upp ändringarna i flera fokuserade incheckningar i stället för en stor, rörig incheckning. På så sätt kan du se till att dina incheckningar är logiskt separata ändringsmängder och kan granskas enkelt av utvecklarna som arbetar med dig. diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 90e7a555..82676793 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -8,7 +8,7 @@ Det här är oftast användbart för att ersätta en incheckning i din historik Till exempel, säg att du har en enorm kodhistorik och vill dela upp ditt kodförråd i en kort historik för nya utvecklare och en mycket längre och större historik för personer som är intresserade av datautvinning. Du kan ympa den ena historiken på den andra genom att "ersätta" den tidigaste incheckningen i den nya linjen med den senaste incheckningen i den äldre. -Det är trevligt eftersom det betyder att du faktiskt inte behöver skriva om varje incheckning i den nya historiken, som du annars normalt måste göra för att sammanfoga dem (eftersom föräldraskapet påverkar SHA‑1‑värdena). +Det är trevligt eftersom det betyder att du inte behöver skriva om varje incheckning i den nya historiken, som du annars normalt måste göra för att sammanfoga dem (eftersom föräldraskapet påverkar SHA‑1‑värdena). Låt oss prova. Vi tar ett befintligt kodförråd, delar upp det i två kodförråd, ett nyligt och ett historiskt, och ser sedan hur vi kan kombinera dem igen utan att ändra SHA‑1‑värdena i det nyare kodförrådet med hjälp av `replace`. diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 133a0868..d5497647 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -67,7 +67,7 @@ $ git ls-files -s Återigen använder vi här `git ls-files`, som mer är ett bakom kulisserna-kommando som visar hur indexet ser ut just nu. -Indexet är tekniskt sett inte en trädstruktur – det är faktiskt implementerat som ett platt manifest – men för våra syften räcker det gott. +Indexet är tekniskt sett inte en trädstruktur – det är implementerat som ett platt manifest – men för våra syften räcker det gott. ===== Arbetskatalogen @@ -102,7 +102,7 @@ Nu kör vi `git init`, vilket skapar ett Git‑kodförråd med en HEAD-referens .Nyinitialiserat Git‑kodförråd med ej köad fil i arbetskatalogen image::images/reset-ex1.png[Nyinitialiserat Git‑kodförråd med ej köad fil i arbetskatalogen] -I det här läget har bara arbetskatalogträdet något innehåll. +I nuläget har bara arbetskatalogträdet något innehåll. Nu vill vi checka in den här filen, så vi använder `git add` för att ta innehållet i arbetskatalogen och kopiera det till indexet. @@ -197,7 +197,7 @@ image::images/reset-hard.png[Hård återställning] Så låt oss tänka igenom vad som hände. Du ångrade din senaste incheckning, `git add` och `git commit`-kommandona, *och* allt arbete du gjorde i din arbetskatalog. -Det är viktigt att notera att flaggan (`--hard`) är det enda sättet att göra kommandot `reset` farligt, och ett av de få tillfällen där Git faktiskt kan förstöra data. +Tänk på att flaggan (`--hard`) är det enda sättet att göra kommandot `reset` farligt, och ett av de få tillfällen där Git verkligen kan förstöra data. Alla andra anrop av `reset` kan relativt enkelt ångras, men flaggan `--hard` kan det inte, eftersom den med tvång skriver över filer i arbetskatalogen. I det här fallet har vi fortfarande *v3*-versionen av vår fil i en incheckning i vår Git‑databas, och vi skulle kunna få tillbaka den genom att titta i vår `reflog`, men om vi inte hade checkat in den skulle Git ändå ha skrivit över filen och den hade varit omöjlig att återställa. @@ -214,7 +214,7 @@ Kommandot `reset` skriver över dessa tre träd i en specifik ordning och stanna Det täcker beteendet hos `reset` i sin grundform, men du kan också ange en sökväg som kommandot ska påverka. Om du anger en sökväg kommer `reset` att hoppa över steg 1 och begränsa resten av sina åtgärder till en specifik fil eller uppsättning filer. -Det är faktiskt ganska rimligt -- HEAD är bara en pekare, och du kan inte peka på en del av en incheckning och en annan del av en annan. +Det är ganska rimligt -- HEAD är bara en pekare, och du kan inte peka på en del av en incheckning och en annan del av en annan. Men indexet och arbetskatalogen _kan_ uppdateras delvis, så `reset` fortsätter med steg 2 och 3. Så, anta att vi kör `git reset file.txt`. @@ -242,10 +242,10 @@ Vi skulle då köra något som `git reset eb43bf file.txt`. .Mjuk återställning med sökväg till en specifik incheckning image::images/reset-path3.png[Mjuk återställning med sökväg till en specifik incheckning] -Det gör i praktiken samma sak som om vi hade återställt innehållet i filen till *v1* i arbetskatalogen, kört `git add` på den, och sedan återställt den tillbaka till *v3* igen (utan att faktiskt gå igenom alla de stegen). -Om vi kör `git commit` nu kommer det att registrera en ändring som återställer filen till *v1*, även om vi aldrig faktiskt hade den i arbetskatalogen igen. +Det gör i praktiken samma sak som om vi hade återställt innehållet i filen till *v1* i arbetskatalogen, kört `git add` på den, och sedan återställt den tillbaka till *v3* igen (utan att behöva gå igenom alla de stegen). +Om vi kör `git commit` nu kommer det att registrera en ändring som återställer filen till *v1*, även om vi aldrig hade den i arbetskatalogen igen. -Det är också intressant att notera att likt `git add` accepterar kommandot `reset` flaggan `--patch` för att avköa innehåll diffstycke för diffstycke. +Intressant nog accepterar kommandot `reset`, likt `git add`, flaggan `--patch` för att avköa innehåll diffstycke för diffstycke. Så du kan selektivt avköa eller återställa innehåll. ==== Sammanfoga incheckningar @@ -254,7 +254,7 @@ Låt oss titta på hur du kan göra något intressant med den här nyfunna kraft Säg att du har en serie incheckningar med meddelanden som "oops.", "WIP" och "forgot this file". Du kan använda `reset` för att snabbt och enkelt sammanfoga dem till en enda incheckning som får dig att se riktigt smart ut. -<<_squashing>> visar ett annat sätt att göra detta, men i det här exemplet är det enklare att använda `reset`. +<<_squashing>> visar ett annat sätt att göra detta, men i exemplet är det enklare att använda `reset`. Låt oss säga att du har ett projekt där den första incheckningen har en fil, den andra incheckningen lade till en ny fil och ändrade den första, och den tredje incheckningen ändrade den första filen igen. Den andra incheckningen var ett arbete på gång och du vill sammanfoga den. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index c4c2d560..9451ac09 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -100,7 +100,7 @@ $ git show topic1 Om du vill se vilken specifik SHA‑1 en gren pekar på, eller om du vill se vad något av exemplen i praktiken leder till i termer av SHA‑1, kan du använda ett Git-rörverktyg som heter `rev-parse`. Du kan läsa mer om rörverktyg i <>; kort sagt finns `rev-parse` för lågnivåoperationer och är inte tänkt för dagligt bruk. -Det kan ändå vara hjälpsamt när du behöver se vad som faktiskt händer. +Det kan ändå vara hjälpsamt när du behöver se vad som egentligen händer. Här kan du köra `rev-parse` på din gren. [source,console] @@ -170,7 +170,7 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -Det är viktigt att notera att referenslogg-information är strikt lokal – det är en logg enbart över det _du_ har gjort i _ditt_ kodförråd. +Tänk på att referenslogg-information är strikt lokal – det är en logg enbart över det _du_ har gjort i _ditt_ kodförråd. Referenserna kommer inte att vara desamma i någon annans kopia av kodförrådet; dessutom har du en tom referenslogg direkt efter att du klonat ett kodförråd, eftersom ingen aktivitet ännu skett i ditt kodförråd. Om du kör `git show HEAD@{2.months.ago}` kommer du bara se den matchande incheckningen om du klonade projektet för minst två månader sedan – klonade du det nyligen ser du bara din första lokala incheckning. diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 59b39a7f..dc232f2d 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -6,7 +6,7 @@ En av de fina sakerna med Git är att du kan ta beslut i sista möjliga stund. Du kan bestämma vilka filer som ska hamna i vilka incheckningar precis innan du checkar in med hjälp av köytan, du kan bestämma att du egentligen inte skulle arbeta med något ännu med `git stash`, och du kan skriva om incheckningar som redan hänt så att de ser ut att ha hänt på ett annat sätt. Det kan handla om att ändra ordningen på incheckningar, ändra meddelanden eller modifiera filer i en incheckning, sammanfoga eller dela upp incheckningar, eller ta bort incheckningar helt och hållet -- allt innan du delar ditt arbete med andra. -I det här avsnittet ser du hur du genomför dessa uppgifter så att du kan få din incheckningshistorik att se ut som du vill innan du delar den. +I avsnittet ser du hur du genomför dessa uppgifter så att du kan få din incheckningshistorik att se ut som du vill innan du delar den. [NOTE] .Skicka inte upp ditt arbete förrän du är nöjd med det @@ -34,7 +34,7 @@ När du sparar och stänger redigeraren skriver den en ny incheckning som inneh Om du i stället vill ändra det faktiska _innehållet_ i din senaste incheckning fungerar processen i princip på samma sätt -- gör först de ändringar du tror att du glömde, köa dem, och det efterföljande `git commit --amend` _ersätter_ den senaste incheckningen med din nya, förbättrade incheckning. -Du måste vara försiktig med den här tekniken eftersom en amend ändrar SHA-1 för incheckningen. +Du måste vara försiktig med tekniken eftersom en amend ändrar SHA-1 för incheckningen. Det är som en mycket liten ombasering -- ändra inte din senaste incheckning om du redan har skickat upp den. [TIP] @@ -62,7 +62,7 @@ Du kan köra ombasering interaktivt genom att lägga till flaggan `-i` till `git Du måste ange hur långt tillbaka du vill skriva om incheckningar genom att tala om för kommandot vilken incheckning som ska vara bas för ombaseringen. Till exempel, om du vill ändra de tre senaste incheckningsmeddelandena, eller något av incheckningsmeddelandena i den gruppen, anger du som argument till `git rebase -i` föräldern till den senaste incheckningen du vill redigera, vilket är `HEAD~2^` eller `HEAD~3`. -Det kan vara lättare att komma ihåg `~3` eftersom du försöker redigera de tre senaste incheckningarna, men tänk på att du faktiskt pekar ut föräldern till den senaste incheckningen du vill redigera, vilket är fyra incheckningar tillbaka: +Det kan vara lättare att komma ihåg `~3` eftersom du försöker redigera de tre senaste incheckningarna, men tänk på att du egentligen pekar ut föräldern till den senaste incheckningen du vill redigera, vilket är fyra incheckningar tillbaka: [source,console] ---- @@ -399,4 +399,4 @@ $ git filter-branch --commit-filter ' ---- Detta går igenom och skriver om varje incheckning så att den får din nya adress. -Eftersom incheckningar innehåller SHA-1-värdena för sina föräldrar ändrar det här kommandot varje SHA-1 i din historik, inte bara de som matchar e-postadressen. +Eftersom incheckningar innehåller SHA-1-värdena för sina föräldrar ändrar kommandot varje SHA-1 i din historik, inte bara de som matchar e-postadressen. diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index edad2d3f..c8e26b84 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -231,7 +231,7 @@ Till sist kanske du inte vill lägga undan något arbete eller några filer i di Några vanliga skäl att städa arbetskatalogen kan vara att ta bort skräp som har skapats av sammanslagningar eller externa verktyg eller att ta bort byggartefakter för att köra en ren byggning. -Du vill vara ganska försiktig med det här kommandot, eftersom det är utformat för att ta bort filer från din arbetskatalog som inte är spårade. +Du vill vara ganska försiktig med kommandot, eftersom det är utformat för att ta bort filer från din arbetskatalog som inte är spårade. Om du ändrar dig finns det ofta ingen väg tillbaka till innehållet i dessa filer. Ett säkrare alternativ är att köra `git stash --all` för att ta bort allt men spara det i en undanläggning. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 67ad7b13..1bba4b3b 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -23,7 +23,7 @@ Vi går igenom utvecklingen av ett enkelt projekt som har delats upp i ett huvud Låt oss börja med att lägga till ett befintligt Git-kodförråd som en undermodul till kodförrådet vi arbetar i. För att lägga till en ny undermodul använder du kommandot `git submodule add` med den absoluta eller relativa URL:en till projektet du vill börja spåra. -I det här exemplet lägger vi till ett bibliotek som heter "`DbConnector`". +I exemplet lägger vi till ett bibliotek som heter "`DbConnector`". [source,console] ---- @@ -64,8 +64,8 @@ Det är en konfigurationsfil som lagrar kopplingen mellan projektets URL och den url = https://github.com/chaconinc/DbConnector ---- -Om du har flera undermoduler får du flera poster i den här filen. -Det är viktigt att notera att den här filen är versionshanterad tillsammans med dina övriga filer, som din `.gitignore`‑fil. +Om du har flera undermoduler får du flera poster i filen. +Tänk på att filen är versionshanterad tillsammans med dina övriga filer, som din `.gitignore`‑fil. Den skickas upp och dras tillsammans med resten av projektet. Så vet andra som klonar projektet var undermodulsprojekten ska uppdateras ifrån. @@ -215,7 +215,7 @@ Nu har vi en kopia av ett projekt med undermoduler och kommer att samarbeta med ===== Hämta uppströmsändringar från undermodulens fjärrkodförråd -Den enklaste modellen för att använda undermoduler i ett projekt är när du bara konsumerar ett underprojekt och vill få uppdateringar från det då och då, utan att själv ändra något i din utläggning. +Den enklaste modellen för att använda undermoduler i ett projekt är när du bara använder ett underprojekt och vill få uppdateringar från det då och då, utan att själv ändra något i din utläggning. Låt oss gå igenom ett enkelt exempel. Om du vill kontrollera om det finns nytt arbete i en undermodul kan du gå in i katalogen och köra `git fetch` och `git merge` mot uppströmsgrenen för att uppdatera den lokala koden. @@ -345,7 +345,7 @@ index 6fc0b3d..fd1cc29 100644 > better connection routine ---- -Det här är rätt kul eftersom vi faktiskt kan se loggen över incheckningarna som vi håller på att checka in i vår undermodul. +Det här är rätt kul eftersom vi verkligen kan se loggen över incheckningarna som vi håller på att checka in i vår undermodul. När det är checkat in kan du se informationen i efterhand också när du kör `git log -p`. [source,console] @@ -1035,6 +1035,6 @@ Sedan, när du byter tillbaka, får du av någon anledning en tom `CryptoLibrary Du kan behöva gå in i undermodulkatalogen och köra `git checkout .` för att få tillbaka alla filer. Du kan köra detta i ett `submodule foreach`‑skript för att göra det på flera undermoduler. -Det är viktigt att notera att undermoduler numera håller all sin Git‑data i överprojektets `.git`‑katalog, så till skillnad från mycket äldre Git‑versioner förlorar du inga incheckningar eller grenar genom att radera en undermodulkatalog. +Tänk på att undermoduler numera håller all sin Git‑data i överprojektets `.git`‑katalog, så till skillnad från mycket äldre Git‑versioner förlorar du inga incheckningar eller grenar genom att radera en undermodulkatalog. Med dessa verktyg kan undermoduler vara en ganska enkel och effektiv metod för att utveckla flera relaterade men fortfarande separata projekt samtidigt. diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 80016154..52ee007d 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -5,7 +5,7 @@ Vissa av dessa inställningar kan också anges för en sökväg, så att Git til Dessa sökvägsspecifika inställningar kallas Git‑attribut och sätts antingen i en `.gitattributes`‑fil i någon av dina kataloger (vanligen projektroten) eller i `.git/info/attributes` om du inte vill checka in attributfilen i projektet. Med attribut kan du till exempel ange separata sammanslagningsstrategier för enskilda filer eller kataloger i projektet, tala om för Git hur den ska diffa icke‑textfiler eller låta Git filtrera innehåll innan du checkar in eller lägger ut det. -I det här avsnittet lär du dig om några attribut du kan sätta på sökvägar i ditt Git‑projekt och ser några exempel på hur funktionen används i praktiken. +I avsnittet lär du dig om några attribut du kan sätta på sökvägar i ditt Git‑projekt och ser några exempel på hur funktionen används i praktiken. ==== Binära filer @@ -19,7 +19,7 @@ Du får se hur du talar om för Git vilket som är vilket. Vissa filer ser ut som textfiler men ska i praktiken behandlas som binärdata. Till exempel innehåller Xcode‑projekt på macOS en fil som slutar på `.pbxproj`, som i praktiken är en JSON‑liknande dataset som IDE:n skriver till disk och som beskriver bygginställningar och liknande. Även om det tekniskt sett är en textfil (eftersom den är UTF‑8) vill du inte behandla den som sådan eftersom det i praktiken är en lättviktig databas – du kan inte sammanfoga innehållet om två personer ändrar den, och diffar är sällan hjälpsamma. -Filen är tänkt att konsumeras av en maskin. +Filen är tänkt att läsas av en maskin. I praktiken vill du behandla den som en binär fil. För att tala om för Git att behandla alla `pbxproj`‑filer som binärdata, lägg till följande rad i din `.gitattributes`‑fil: @@ -29,7 +29,7 @@ För att tala om för Git att behandla alla `pbxproj`‑filer som binärdata, l *.pbxproj binary ---- -Nu försöker Git varken konvertera eller fixa CRLF‑problem; inte heller försöker den beräkna eller skriva ut en diff för ändringar i den här filen när du kör `git show` eller `git diff` på projektet. +Nu försöker Git varken konvertera eller fixa CRLF‑problem; inte heller försöker den beräkna eller skriva ut en diff för ändringar i filen när du kör `git show` eller `git diff` på projektet. ===== Diffa binära filer @@ -74,7 +74,7 @@ docx2txt.pl "$1" - ---- Glöm inte `chmod a+x` på den filen. -Till sist konfigurerar du Git att använda det här skriptet: +Till sist konfigurerar du Git att använda skriptet: [source,console] ---- @@ -84,7 +84,7 @@ $ git config diff.word.textconv docx2txt Nu vet Git att om den försöker diffa två ögonblicksbilder och någon fil slutar på `.docx`, ska den köra de filerna genom "`word`"‑filtret, vilket i detta fall är programmet `docx2txt`. Detta ger i praktiken läsbara textversioner av dina Word‑filer innan diffen beräknas. -Här är ett exempel: kapitel 1 i den här boken konverterades till Word‑format och incheckades i ett Git‑kodförråd. +Här är ett exempel: kapitel 1 i boken konverterades till Word‑format och incheckades i ett Git‑kodförråd. Sedan lades ett nytt stycke till. Så här visar `git diff`: @@ -162,7 +162,7 @@ Git‑attribut ger dig två sätt att göra detta. Först kan du automatiskt injicera SHA‑1‑kontrollsumman för en blob i ett `$Id$`‑fält i filen. Om du sätter detta attribut på en fil eller uppsättning filer kommer Git nästa gång du växlar till den grenen att ersätta fältet med blob‑SHA‑1:an. -Det är viktigt att notera att det inte är SHA‑1:an för incheckningen, utan för blobben själv. +Tänk på att det inte är SHA‑1:an för incheckningen, utan för blobben själv. Lägg följande rad i din `.gitattributes`‑fil: [source,ini] diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 0eeb73a2..630f6b85 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -18,7 +18,7 @@ Det första stället Git tittar på är den systemomfattande filen `[sökväg]/e Om du skickar flaggan `--system` till `git config` läser och skriver den specifikt i den filen. Nästa ställe Git tittar på är filen `~/.gitconfig` (eller `~/.config/git/config`), som är specifik för varje användare. -Du kan få Git att läsa och skriva i den här filen genom att skicka flaggan `--global`. +Du kan få Git att läsa och skriva i filen genom att skicka flaggan `--global`. Till sist letar Git efter konfigurationsvärden i konfigurationsfilen i Git‑katalogen (`.git/config`) för det kodförråd du använder just nu. Dessa värden är specifika för just det kodförrådet, och motsvarar flaggan `--local` till `git config`. @@ -83,7 +83,7 @@ feel free to be detailed. [Ticket: X] ---- -Notera hur denna incheckningsmall påminner om att hålla ämnesraden kort (för `git log --oneline`‑utdata), att lägga till mer detaljer under den, och att hänvisa till ett ärende- eller felspårningsnummer om ett sådant finns. +Lägg märke till hur denna incheckningsmall påminner om att hålla ämnesraden kort (för `git log --oneline`‑utdata), att lägga till mer detaljer under den, och att hänvisa till ett ärende- eller felspårningsnummer om ett sådant finns. För att tala om för Git att använda den som standardmeddelande som visas i din redigerare när du kör `git commit`, sätter du konfigurationsvärdet `commit.template`: @@ -185,7 +185,7 @@ The most similar command is ---- Git försöker hjälpsamt lista ut vad du menade, men vägrar ändå att göra det. -Om du sätter `help.autocorrect` till 1 kommer Git faktiskt köra kommandot åt dig: +Om du sätter `help.autocorrect` till 1 kommer Git verkligen köra kommandot åt dig: [source,console] ---- @@ -195,8 +195,8 @@ Continuing under the assumption that you meant 'checkout' in 0.1 seconds automatically... ---- -Notera delen "`0.1 seconds`". -`help.autocorrect` är faktiskt ett heltal som representerar tiondelar av en sekund. +Lägg märke till delen "`0.1 seconds`". +`help.autocorrect` är egentligen ett heltal som representerar tiondelar av en sekund. Så om du sätter den till 50 ger Git dig 5 sekunder att ändra dig innan det kör det autokorrigerade kommandot. ==== Färger i Git @@ -246,7 +246,7 @@ Om du vill ange ett attribut som fet stil i exemplet ovan kan du välja mellan ` ==== Externa sammanslagnings- och diffverktyg (((mergetool)))(((difftool))) -Även om Git har en intern diff‑implementation, vilket är det vi har visat i den här boken, kan du sätta upp ett externt verktyg i stället. +Även om Git har en intern diff‑implementation, vilket är det vi har visat i boken, kan du sätta upp ett externt verktyg i stället. Du kan också sätta upp ett grafiskt verktyg för att lösa sammanslagningskonflikter i stället för att lösa konflikter manuellt. Vi demonstrerar hur man ställer in Perforce Visual Sammanslagning Tool (P4Merge) för att göra dina diffar och sammanslagningslösningar, eftersom det är ett trevligt grafiskt verktyg och det är gratis. diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 46320e07..5a47e971 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -4,7 +4,7 @@ (((krokar))) Likt många andra versionshanteringssystem har Git ett sätt att köra egna skript när vissa viktiga händelser inträffar. Det finns två grupper av krokar: klientsidan och serversidan. -Krokar på klientsidan triggas av operationer som incheckning och sammanslagning, medan krokar på serversidan körs vid nätverksoperationer som att ta emot uppskickade incheckningar. +Krokar på klientsidan utlöses av operationer som incheckning och sammanslagning, medan krokar på serversidan körs vid nätverksoperationer som att ta emot uppskickade incheckningar. Du kan använda dessa krokar av många olika skäl. ==== Installera en krok @@ -26,7 +26,7 @@ Detta avsnitt delar in dem i krokar för incheckningsflödet, skript för e-post [NOTE] ==== -Det är viktigt att notera att krokar på klientsidan *inte* kopieras när du klonar ett kodförråd. +Tänk på att krokar på klientsidan *inte* kopieras när du klonar ett kodförråd. Om din avsikt med dessa skript är att upprätthålla en policy vill du sannolikt göra det på serversidan; se exemplet i <>. ==== @@ -47,7 +47,7 @@ Du kan använda den tillsammans med en incheckningsmall för att programatiskt i Kroken `commit-msg` tar en parameter, vilket återigen är sökvägen till en temporär fil som innehåller incheckningsmeddelandet som utvecklaren har skrivit. Om detta skript avslutas med en icke‑nollkod avbryter Git incheckningsprocessen, så du kan använda det för att validera projektets läge eller incheckningsmeddelandet innan incheckningen får gå igenom. -I sista delen av det här kapitlet visar vi hur du använder denna krok för att kontrollera att incheckningsmeddelandet följer ett obligatoriskt mönster. +I sista delen av kapitlet visar vi hur du använder denna krok för att kontrollera att incheckningsmeddelandet följer ett obligatoriskt mönster. När hela incheckningsprocessen är klar körs kroken `post-commit`. Den tar inga parametrar, men du kan enkelt få den senaste incheckningen genom att köra `git log -1 HEAD`. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 7b75da40..b9cb537e 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -2,8 +2,8 @@ === Ett exempel på Git‑upprätthållen policy (((policy example))) -I det här avsnittet använder du det du lärt dig för att skapa ett Git‑arbetsflöde som kontrollerar ett anpassat format på incheckningsmeddelanden och som bara tillåter vissa användare att ändra vissa underkataloger i ett projekt. -Du bygger klientskript som hjälper utvecklaren att veta om deras uppskickning kommer att nekas, och serverskript som faktiskt upprätthåller policyn. +I avsnittet använder du det du lärt dig för att skapa ett Git‑arbetsflöde som kontrollerar ett anpassat format på incheckningsmeddelanden och som bara tillåter vissa användare att ändra vissa underkataloger i ett projekt. +Du bygger klientskript som hjälper utvecklaren att veta om deras uppskickning kommer att nekas, och serverskript som verkligen upprätthåller policyn. Skripten vi visar är skrivna i Ruby; delvis på grund av vår egen tröghet, men också för att Ruby är lätt att läsa även om du inte nödvändigtvis kan skriva det. Vilket språk som helst fungerar dock – alla exempel‑krokskript som följer med Git är antingen Perl eller Bash, så du kan se gott om krokskript i de språken genom att titta på exemplen. diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index 89ffba93..b5cc97e9 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -173,7 +173,7 @@ $ git log --oneline --graph --decorate --all Eftersom vi använde flaggan `--all` ser vi "`notes`"‑referenserna som används internt av git-remote-hg, men vi kan ignorera dem. Resten är vad vi förväntade oss; `origin/master` har gått framåt med en incheckning, och vår historik har nu divergerat. -Till skillnad från de andra systemen vi arbetar med i det här kapitlet klarar Mercurial av sammanslagningar, så vi behöver inte göra något avancerat. +Till skillnad från de andra systemen vi arbetar med i kapitlet klarar Mercurial av sammanslagningar, så vi behöver inte göra något avancerat. [source,console] ---- @@ -250,7 +250,7 @@ date: Thu Aug 14 20:06:38 2014 -0700 summary: More documentation ---- -Notera raden som börjar med "`branch`". +Lägg märke till raden som börjar med "`branch`". Git kan egentligen inte replikera detta (och behöver inte heller; båda typerna av grenar kan representeras som en Git‑referens), men git-remote-hg behöver förstå skillnaden eftersom Mercurial gör det. Att skapa Mercurial‑bokmärken är lika enkelt som att skapa Git‑grenar. @@ -295,7 +295,7 @@ o 0 0a04b987be5a 2005-08-26 01:20 -0700 mpm Create a standard 'hello, world' program ---- -Notera den nya taggen `[featureA]` på revision 5. +Lägg märke till den nya taggen `[featureA]` på revision 5. De fungerar exakt som Git‑grenar på Git‑sidan, med ett undantag: du kan inte ta bort ett bokmärke från Git‑sidan (detta är en begränsning i fjärrhjälparen). Du kan också arbeta på en "`tungviktig`" Mercurial‑gren: lägg bara en gren i namnrymden `branches`: diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index 50fd50d8..cbdecf26 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -3,9 +3,9 @@ (((Samverkan med andra VCS:er, Perforce))) (((Perforce))) Perforce är ett mycket populärt versionshanteringssystem i organisationsmiljöer. -Det har funnits sedan 1995, vilket gör det till det äldsta systemet som behandlas i det här kapitlet. +Det har funnits sedan 1995, vilket gör det till det äldsta systemet som behandlas i kapitlet. Därför är det utformat med sin tids begränsningar; det antar att du alltid är uppkopplad mot en enda central server och att bara en version hålls på den lokala disken. -För tydlighetens skull är dess funktioner och begränsningar väl lämpade för flera specifika problem, men det finns många projekt som använder Perforce där Git faktiskt skulle fungera bättre. +För tydlighetens skull är dess funktioner och begränsningar väl lämpade för flera specifika problem, men det finns många projekt som använder Perforce där Git egentligen skulle fungera bättre. Det finns två alternativ om du vill kombinera användningen av Perforce och Git. Det första vi går igenom är "`Git Fusion`"‑bryggan från Perforces skapare, som låter dig exponera underträd i din Perforce‑depå som läs‑ och skrivbara Git‑kodförråd. @@ -28,7 +28,7 @@ När det är klart ser du detta: .Git Fusions uppstartsskärm för den virtuella maskinen image::images/git-fusion-boot.png[Git Fusions uppstartsskärm för den virtuella maskinen] -Du bör notera IP‑adressen som visas här; vi använder den senare. +Du bör lägga märke till IP‑adressen som visas här; vi använder den senare. Nästa steg är att skapa en Perforce‑användare. Välj alternativet "`Login`" längst ner och tryck enter (eller SSH:a till maskinen) och logga in som `root`. Använd sedan dessa kommandon för att skapa en användare: @@ -99,7 +99,7 @@ $ tree ---- Katalogen `objects` används internt av Git Fusion för att mappa Perforce‑objekt till Git och vice versa; du behöver inte röra något där. -Det finns en global `p4gf_config`‑fil i den här katalogen, samt en för varje kodförråd – det är konfigurationsfilerna som avgör hur Git Fusion beter sig. +Det finns en global `p4gf_config`‑fil i katalogen, samt en för varje kodförråd – det är konfigurationsfilerna som avgör hur Git Fusion beter sig. Låt oss titta på filen i roten: [source,ini] @@ -132,7 +132,7 @@ parallel-push = False email-case-sensitivity = no ---- -Vi går inte in på betydelsen av dessa flaggor här, men notera att det bara är en INI‑formaterad textfil, ungefär som Git använder för konfiguration. +Vi går inte in på betydelsen av dessa flaggor här, men lägg märke till att det bara är en INI‑formaterad textfil, ungefär som Git använder för konfiguration. Filen anger de globala alternativen, som sedan kan skrivas över av kodförrådsspecifika konfigurationsfiler, som `repos/Talkhouse/p4gf_config`. Om du öppnar denna fil ser du en `[@repo]`‑sektion med vissa inställningar som skiljer sig från de globala standarderna. Du ser också sektioner som ser ut så här: @@ -257,7 +257,7 @@ $ git log --oneline --decorate --graph --all ---- Det ser ut som att någon gjorde det! -Du skulle inte veta det från den här vyn, men incheckningen `6afeb15` skapades faktiskt med en Perforce‑klient. +Du skulle inte veta det från den här vyn, men incheckningen `6afeb15` skapades i själva verket med en Perforce‑klient. Den ser bara ut som en annan incheckning ur Gits perspektiv, vilket är precis poängen. Låt oss se hur Perforce‑servern hanterar en sammanslagningsincheckning: @@ -362,7 +362,7 @@ $ git log --oneline --all --graph --decorate * 70eaf78 (HEAD, p4/master, p4/HEAD, master) Initial import of //depot/www/live/ from the state at revision #head ---- -Notera att det finns ett "`p4`"‑fjärrkodförråd för Perforce‑servern, men i övrigt ser allt ut som en standardklon. +Observera att det finns ett "`p4`"‑fjärrkodförråd för Perforce‑servern, men i övrigt ser allt ut som en standardklon. Det är dock lite missvisande; det finns egentligen inget fjärrkodförråd där. [source,console] @@ -520,10 +520,10 @@ $ git log --oneline --all --graph --decorate * 70eaf78 Initial import of //depot/www/live/ from the state at revision #head ---- -Resultatet motsvarar i praktiken att vi just körde `git push`, vilket ligger nära det som faktiskt hände. +Resultatet motsvarar i praktiken att vi just körde `git push`, vilket ligger nära det som egentligen hände. -Notera att under denna process omvandlas varje Git‑incheckning till en Perforce‑ändringsuppsättning; om du vill sammanfoga dem till en enda ändringsuppsättning kan du göra det med en interaktiv ombasering innan du kör `git p4 submit`. -Notera också att SHA‑1‑hasharna för alla incheckningar som skickades in som ändringsuppsättningar har förändrats; detta beror på att git-p4 lägger till en rad i slutet av varje incheckning som den konverterar: +Observera att under denna process omvandlas varje Git‑incheckning till en Perforce‑ändringsuppsättning; om du vill sammanfoga dem till en enda ändringsuppsättning kan du göra det med en interaktiv ombasering innan du kör `git p4 submit`. +Lägg också märke till att SHA‑1‑hasharna för alla incheckningar som skickades in som ändringsuppsättningar har förändrats; detta beror på att git-p4 lägger till en rad i slutet av varje incheckning som den konverterar: [source,console] ---- @@ -592,7 +592,7 @@ $ git log --oneline --all --graph --decorate * 70eaf78 Initial import of //depot/www/live/ from the state at revision #head ---- -Vår historik blev linjär, precis som om vi hade ombaserat innan vi skickade in (vilket faktiskt är exakt vad som hände). +Vår historik blev linjär, precis som om vi hade ombaserat innan vi skickade in (vilket är precis vad som hände). Det betyder att du kan skapa, arbeta på, kasta bort och sammanfoga grenar på Git‑sidan utan att oroa dig för att historiken på något sätt blir inkompatibel med Perforce. Om du kan ombasera det kan du bidra med det till en Perforce‑server. @@ -638,7 +638,7 @@ $ cd project; git log --oneline --all --graph --decorate * 2b83451 Project init ---- -Notera specifikationen "`@all`" i depå‑sökvägen; den säger till git-p4 att klona inte bara den senaste ändringsuppsättningen för det underträdet, utan alla ändringsuppsättningar som någonsin har rört dessa sökvägar. +Lägg märke till specifikationen "`@all`" i depå‑sökvägen; den säger till git-p4 att klona inte bara den senaste ändringsuppsättningen för det underträdet, utan alla ändringsuppsättningar som någonsin har rört dessa sökvägar. Detta ligger närmare Gits klonbegrepp, men om du arbetar på ett projekt med lång historik kan det ta tid. Flaggan `--detect-branches` säger åt git-p4 att använda Perforces gren‑specifikationer för att mappa grenar till Git‑referenser. diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index 6f07bbf0..d710509d 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -18,7 +18,7 @@ Subversion‑bryggan är inkörsporten till DVCS‑världen. Grundkommandot i Git för alla Subversion‑bryggkommandon är `git svn`. Det har ganska många underkommandon, så vi visar de vanligaste medan vi går igenom några enkla arbetsflöden. -Det är viktigt att notera att när du använder `git svn` så interagerar du med Subversion, som fungerar på ett helt annat sätt än Git. +Tänk på att när du använder `git svn` så interagerar du med Subversion, som fungerar på ett helt annat sätt än Git. Även om du *kan* göra lokala grenar och sammanslagningar är det generellt bäst att hålla historiken så linjär som möjligt genom att ombasera ditt arbete och undvika att samtidigt arbeta mot ett Git‑fjärrkodförråd. Skriv inte om historiken och försök skicka på nytt, och skicka inte upp till ett parallellt Git‑kodförråd för att samarbeta med andra Git‑utvecklare samtidigt. @@ -129,7 +129,7 @@ $ git branch -a remotes/origin/trunk ---- -Notera hur det här verktyget hanterar Subversion‑taggar som fjärrreferenser. +Lägg märke till hur verktyget hanterar Subversion‑taggar som fjärrreferenser. (((git commands, show-ref))) Låt oss titta närmare med Git‑lågnivåkommandot `show-ref`: @@ -205,7 +205,7 @@ Date: Thu Jul 24 03:08:36 2014 +0000 git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68 ---- -Notera att SHA‑1‑kontrollsumman som ursprungligen började med `4af61fd` när du checkade in nu börjar med `95e0222`. +Observera att SHA‑1‑kontrollsumman som ursprungligen började med `4af61fd` när du checkade in nu börjar med `95e0222`. Om du vill skicka till både en Git‑server och en Subversion‑server måste du skicka (`dcommit`) till Subversion‑servern först, eftersom den åtgärden ändrar din incheckningsdata. ===== Hämta in nya ändringar @@ -355,7 +355,7 @@ r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera) ---- Det här motsvarar Subversion‑kommandot `svn copy trunk branches/opera` och arbetar mot Subversion‑servern. -Det är viktigt att notera att det inte växlar till den grenen; om du checkar in nu kommer incheckningen att hamna i `trunk` på servern, inte `opera`. +Tänk på att det inte växlar till den grenen; om du checkar in nu kommer incheckningen att hamna i `trunk` på servern, inte `opera`. ===== Växla aktiva grenar diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index 6bfb0e31..89e0067d 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -355,7 +355,7 @@ Date: Mon Feb 3 01:00:00 2014 -0700 ---- Där har du det – ett snyggt, rent Git‑kodförråd. -Det är viktigt att notera att inget är utcheckat – du har inga filer i arbetskatalogen till att börja med. +Tänk på att inget är utcheckat – du har inga filer i arbetskatalogen till att börja med. För att få dem måste du återställa din gren till där `master` är nu: [source,console] diff --git a/book/09-git-and-other-scms/sections/import-hg.asc b/book/09-git-and-other-scms/sections/import-hg.asc index 39133da5..cfb631f2 100644 --- a/book/09-git-and-other-scms/sections/import-hg.asc +++ b/book/09-git-and-other-scms/sections/import-hg.asc @@ -37,12 +37,12 @@ Bob Jones Joe Smith ---- -I det här exemplet har samma person (Bob) skapat ändringsuppsättningar under fyra olika namn, varav ett ser korrekt ut och ett skulle vara helt ogiltigt som Git‑incheckning. +I exemplet har samma person (Bob) skapat ändringsuppsättningar under fyra olika namn, varav ett ser korrekt ut och ett skulle vara helt ogiltigt som Git‑incheckning. Hg-fast-export låter oss fixa detta genom att omvandla varje rad till en regel: `""=""`, som mappar ett `` till ett ``. I strängarna `` och `` stöds alla escape‑sekvenser som Pythons `string_escape`‑kodning förstår. Om författarmappningsfilen inte innehåller ett matchande `` skickas författaren vidare till Git oförändrad. Om alla användarnamn ser bra ut behöver vi inte filen alls. -I det här exemplet vill vi att filen ska se ut så här: +I exemplet vill vi att filen ska se ut så här: [source] ---- diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index 31410ce1..6962881b 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -183,7 +183,7 @@ Det kan vara ett enormt problem när du konverterar Subversion‑ eller Perforce Eftersom du inte laddar ner hela historiken i de systemen får sådana tillägg små konsekvenser. Om du har importerat från ett annat system eller på annat sätt upptäcker att ditt kodförråd är mycket större än det borde vara, så här hittar och tar du bort stora objekt. -*Varning: den här tekniken är destruktiv för din incheckningshistorik.* +*Varning: tekniken är destruktiv för din incheckningshistorik.* Den skriver om varje incheckningsobjekt sedan det tidigaste träd du måste ändra för att ta bort referensen till en stor fil. Om du gör detta direkt efter en import, innan någon har börjat basera arbete på incheckningen, är det okej – annars måste du meddela alla bidragsgivare att de måste ombasera sitt arbete på dina nya incheckningar. diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index a72f033c..ccc09eee 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -260,7 +260,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d [NOTE] ==== Du kommer att få ett annat hashvärde på grund av olika skapandetid och författardata. -Dessutom, även om varje incheckningsobjekt i teorin kan reproduceras exakt utifrån dessa data, gör historiska detaljer i hur den här boken byggts att de tryckta incheckningshasharna kanske inte motsvarar de givna incheckningarna. +Dessutom, även om varje incheckningsobjekt i teorin kan reproduceras exakt utifrån dessa data, gör historiska detaljer i hur boken byggts att de tryckta incheckningshasharna kanske inte motsvarar de givna incheckningarna. Ersätt inchecknings- och tagghashar med dina egna kontrollsummor längre fram i detta kapitel. ==== diff --git a/book/10-git-internals/sections/plumbing-porcelain.asc b/book/10-git-internals/sections/plumbing-porcelain.asc index aa72cce3..254d8478 100644 --- a/book/10-git-internals/sections/plumbing-porcelain.asc +++ b/book/10-git-internals/sections/plumbing-porcelain.asc @@ -6,12 +6,12 @@ Men eftersom Git från början var en verktygslåda för ett versionshanteringss Dessa kommandon brukar kallas Gits lågnivåkommandon (plumbing‑kommandon), medan de mer användarvänliga kommandona kallas användarkommandon (porcelain‑kommandon). Som du redan har märkt handlar bokens första nio kapitel nästan uteslutande om användarkommandon. -Men i det här kapitlet arbetar du mest med lågnivåkommandon, eftersom de ger dig tillgång till Gits innandöme och hjälper till att visa hur och varför Git gör som det gör. +Men i kapitlet arbetar du mest med lågnivåkommandon, eftersom de ger dig tillgång till Gits innandöme och hjälper till att visa hur och varför Git gör som det gör. Många av dessa kommandon är inte tänkta att användas manuellt på kommandoraden, utan snarare som byggstenar för nya verktyg och anpassade skript. När du kör `git init` i en ny eller befintlig katalog skapar Git katalogen `.git`, där nästan allt som Git lagrar och manipulerar finns. -Om du vill säkerhetskopiera eller klona ditt kodförråd ger det dig nästan allt du behöver att kopiera den här katalogen till en annan plats. -Hela detta kapitel handlar i praktiken om det du kan se i den här katalogen. +Om du vill säkerhetskopiera eller klona ditt kodförråd ger det dig nästan allt du behöver att kopiera katalogen till en annan plats. +Hela detta kapitel handlar i praktiken om det du kan se i katalogen. Så här ser en nyinitierad `.git`‑katalog vanligtvis ut: [source,console] diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index 04d217ca..e51ae8d7 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -167,7 +167,7 @@ Test tag ---- Observera att objektraden pekar på SHA‑1‑värdet för incheckningen du taggade. -Notera också att den inte måste peka på en incheckning; du kan tagga vilket Git‑objekt som helst. +Lägg också märke till att den inte måste peka på en incheckning; du kan tagga vilket Git‑objekt som helst. I Gits källkod har till exempel förvaltaren lagt till sin publika GPG‑nyckel som ett blob‑objekt och sedan taggat det. Du kan se den publika nyckeln genom att köra detta i en klon av Git‑kodförrådet: diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index d7f76eba..e9245b75 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -288,5 +288,5 @@ Svaret på denna förfrågan indikerar framgång eller misslyckande och inkluder ==== Sammanfattning av protokollen Detta avsnitt innehåller en mycket grundläggande översikt av överföringsprotokollen. -Protokollet innehåller många andra funktioner, som kapabiliteterna `multi_ack` eller `side-band`, men att täcka dem ligger utanför den här bokens omfattning. +Protokollet innehåller många andra funktioner, som kapabiliteterna `multi_ack` eller `side-band`, men att täcka dem ligger utanför bokens omfattning. Vi har försökt ge dig en känsla för det allmänna fram‑och‑tillbaka mellan klient och server; om du behöver mer kunskap än detta vill du troligen ta en titt på Gits källkod. diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index ee62b88f..163e95fc 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -5,10 +5,10 @@ Gits hemmiljö är terminalen. Nya funktioner dyker upp där först, och bara på kommandoraden har du full tillgång till Gits kraft. Men ren text är inte det bästa valet för alla uppgifter; ibland behöver du en visuell representation, och vissa användare är mycket mer bekväma med ett peka‑och‑klicka‑gränssnitt. -Det är viktigt att notera att olika gränssnitt är anpassade för olika arbetsflöden. +Tänk på att olika gränssnitt är anpassade för olika arbetsflöden. Vissa klienter exponerar bara en noggrant utvald delmängd av Gits funktionalitet för att stödja ett specifikt sätt att arbeta som författaren tycker är effektivt. Sett i det ljuset kan inget av dessa verktyg kallas "`bättre`" än något av de andra, de är helt enkelt mer lämpade för sitt avsedda syfte. -Notera också att det inte finns något dessa grafiska klienter kan göra som kommandoradsklienten inte kan; kommandoraden är fortfarande där du har mest kraft och kontroll när du arbetar med dina kodförråd. +Lägg också märke till att det inte finns något dessa grafiska klienter kan göra som kommandoradsklienten inte kan; kommandoraden är fortfarande där du har mest kraft och kontroll när du arbetar med dina kodförråd. ==== `gitk` och `git-gui` @@ -79,14 +79,14 @@ image::images/github_mac.png[GitHub för macOS] .GitHub för Windows image::images/github_win.png[GitHub för Windows] -De är utformade för att se ut och fungera mycket lika, så vi behandlar dem som en enda produkt i det här kapitlet. +De är utformade för att se ut och fungera mycket lika, så vi behandlar dem som en enda produkt i kapitlet. Vi kommer inte att göra en detaljerad genomgång av dessa verktyg (de har sin egen dokumentation), men en snabb rundtur i vyn "`changes`" (där du tillbringar mest tid) är på sin plats. * Till vänster finns listan över kodförråd som klienten spårar; du kan lägga till ett kodförråd (antingen genom att klona eller genom att lägga till lokalt) genom att klicka på ikonen "`+`" längst upp i detta område. * I mitten finns ett incheckningsinmatningsområde som låter dig mata in ett incheckningsmeddelande och välja vilka filer som ska inkluderas. På Windows visas incheckningshistoriken direkt under detta; på macOS finns den på en separat flik. * Till höger finns en diffvy som visar vad som har ändrats i din arbetskatalog, eller vilka ändringar som ingick i den valda incheckningen. -* Den sista saken att notera är knappen "`Sync`" uppe till höger, som är det primära sättet du interagerar över nätverket. +* Den sista saken att lägga märke till är knappen "`Sync`" uppe till höger, som är det primära sättet du interagerar över nätverket. [NOTE] ==== @@ -101,7 +101,7 @@ När applikationerna körs första gången leder de dig genom hela Git‑första Båda är "`städse uppdaterade`" – uppdateringar laddas ner och installeras i bakgrunden medan applikationerna är öppna. Detta inkluderar också en medföljande version av Git, vilket betyder att du förmodligen inte behöver oroa dig för att manuellt uppdatera den igen. -I Windows innehåller klienten en genväg för att starta PowerShell med Posh-git, som vi pratar mer om senare i det här kapitlet. +I Windows innehåller klienten en genväg för att starta PowerShell med Posh-git, som vi pratar mer om senare i kapitlet. Nästa steg är att ge verktyget några kodförråd att arbeta med. Klienten visar en lista över de kodförråd du har åtkomst till på GitHub och kan klona dem i ett steg. diff --git a/book/A-git-in-other-environments/sections/jetbrainsides.asc b/book/A-git-in-other-environments/sections/jetbrainsides.asc index a6c2beb8..d600a385 100644 --- a/book/A-git-in-other-environments/sections/jetbrainsides.asc +++ b/book/A-git-in-other-environments/sections/jetbrainsides.asc @@ -2,7 +2,7 @@ (((JetBrains))) JetBrains‑IDE:er (som IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine och andra) levereras med ett insticksprogram för Git‑integration. -Det ger en dedikerad vy i IDE:n för att arbeta med Git och GitHub‑hämta requests. +Det ger en särskild vy i IDE:n för att arbeta med Git och GitHub‑hämta requests. .Versionskontrollverktygsfönster i JetBrains‑IDE:er image::images/jb.png[Versionskontrollverktygsfönster i JetBrains‑IDE:er] diff --git a/book/A-git-in-other-environments/sections/zsh.asc b/book/A-git-in-other-environments/sections/zsh.asc index 0353a12d..48244beb 100644 --- a/book/A-git-in-other-environments/sections/zsh.asc +++ b/book/A-git-in-other-environments/sections/zsh.asc @@ -45,7 +45,7 @@ För mer information om `vcs_info`, se dokumentationen i manualsidan `zshcontrib I stället för `vcs_info` kan du föredra prompt‑anpassningsskriptet som följer med Git, som heter `git-prompt.sh`; se https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[^] för detaljer. `git-prompt.sh` är kompatibelt med både Bash och Zsh. -Zsh är tillräckligt kraftfullt för att det finns hela ramverk som är dedikerade till att bygga vidare på det. +Zsh är tillräckligt kraftfullt för att det finns hela ramverk som är ägnade åt att bygga vidare på det. Ett av dem heter "oh-my-zsh" och finns på https://github.com/ohmyzsh/ohmyzsh[^]. oh-my-zsh:s insticksystem levereras med kraftfull Git‑tabbkomplettering och har en mängd prompt‑"teman", många av vilka visar versionshanteringsdata. <> är bara ett exempel på vad man kan göra med detta system. diff --git a/book/B-embedding-git/sections/command-line.asc b/book/B-embedding-git/sections/command-line.asc index 8ae71d30..d9232e9a 100644 --- a/book/B-embedding-git/sections/command-line.asc +++ b/book/B-embedding-git/sections/command-line.asc @@ -13,4 +13,4 @@ Om ett kodförråd är skadat på något sätt, eller om användaren har ett fel Ytterligare en är processhantering. Git kräver att du upprätthåller en skal‑miljö i en separat process, vilket kan innebära oönskad komplexitet. -Att försöka samordna många av dessa processer (särskilt när man potentiellt kommer åt samma kodförråd från flera processer) kan vara ganska utmanande. +Att försöka samordna många av dessa processer (särskilt när man eventuellt kommer åt samma kodförråd från flera processer) kan vara ganska utmanande. diff --git a/book/B-embedding-git/sections/go-git.asc b/book/B-embedding-git/sections/go-git.asc index 5e6fb5ed..30f8a554 100644 --- a/book/B-embedding-git/sections/go-git.asc +++ b/book/B-embedding-git/sections/go-git.asc @@ -79,5 +79,5 @@ r, err := git.Clone(memory.NewStorage(), nil, &git.CloneOptions{URL: url}) ==== Vidare läsning -En fullständig genomgång av go-gits möjligheter ligger utanför den här bokens omfattning. +En fullständig genomgång av go-gits möjligheter ligger utanför bokens omfattning. Om du vill ha mer information om go-git finns API‑dokumentation på https://pkg.go.dev/github.com/go-git/go-git/v5[^] och en uppsättning användningsexempel på https://github.com/go-git/go-git/tree/master/_examples[^]. diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index 39e1e01a..a3294fcc 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -93,18 +93,18 @@ Det händer ganska mycket här, så låt oss gå igenom det steg för steg. Den första raden hämtar en pekare till referensen `master`. JGit hämtar automatiskt den _faktiska_ `master`‑refen, som ligger på `refs/heads/master`, och returnerar ett objekt som låter dig hämta information om referensen. Du kan få namnet (`.getName()`) och antingen målobjektet för en direkt referens (`.getObjectId()`) eller referensen som en symbolisk ref pekar på (`.getTarget()`). -Ref‑objekt används också för att representera tagg‑refs och objekt, så du kan fråga om taggen är "`peeled`", vilket betyder att den pekar på det slutliga målet i en (potentiellt lång) kedja av taggobjekt. +Ref‑objekt används också för att representera tagg‑refs och objekt, så du kan fråga om taggen är "`peeled`", vilket betyder att den pekar på det slutliga målet i en (möjligen lång) kedja av taggobjekt. Den andra raden hämtar målet för `master`‑referensen, som returneras som en ObjectId‑instans. ObjectId representerar SHA‑1‑hashen för ett objekt, som kanske finns eller inte finns i Gits objektdatabas. Den tredje raden är liknande men visar hur JGit hanterar rev‑parse‑syntaxen (för mer om detta, se <>); du kan skicka vilken objektspecificerare som helst som Git förstår, och JGit returnerar antingen en giltig ObjectId för objektet eller `null`. De nästa två raderna visar hur man laddar det råa innehållet i ett objekt. -I det här exemplet anropar vi `ObjectLoader.copyTo()` för att strömma objektets innehåll direkt till stdout, men ObjectLoader har också metoder för att läsa typ och storlek på ett objekt, samt returnera det som en byte‑array. +I exemplet anropar vi `ObjectLoader.copyTo()` för att strömma objektets innehåll direkt till stdout, men ObjectLoader har också metoder för att läsa typ och storlek på ett objekt, samt returnera det som en byte‑array. För stora objekt (där `.isLarge()` returnerar `true`) kan du anropa `.openStream()` för att få ett InputStream‑liknande objekt som kan läsa rådata utan att dra in allt i minnet på en gång. De följande raderna visar vad som krävs för att skapa en ny gren. -Vi skapar en RefUpdate‑instans, konfigurerar vissa parametrar och anropar `.update()` för att trigga ändringen. +Vi skapar en RefUpdate‑instans, konfigurerar vissa parametrar och anropar `.update()` för att utlösa ändringen. Direkt efter detta följer koden som tar bort samma gren. Observera att `.setForceUpdate(true)` krävs för att detta ska fungera; annars returnerar `.delete()`‑anropet `REJECTED`, och inget händer. @@ -146,7 +146,7 @@ for (Ref ref : remoteRefs) { Det här är ett vanligt mönster med Git‑klassen; metoderna returnerar ett kommandoobjekt som låter dig kedja metodanrop för att sätta parametrar, vilka körs när du anropar `.call()`. I det här fallet frågar vi fjärrkodförrådet `origin` efter taggar, men inte heads. -Notera också användningen av ett `CredentialsProvider`‑objekt för autentisering. +Lägg också märke till användningen av ett `CredentialsProvider`‑objekt för autentisering. Många andra kommandon finns tillgängliga via Git‑klassen, inklusive men inte begränsat till `add`, `blame`, `commit`, `clean`, `push`, `rebase`, `revert` och `reset`. diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 1810f532..856c1037 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -232,6 +232,6 @@ pygit2.Repository("/path/to/repo") # open repository ==== Vidare läsning -En fullständig genomgång av Libgit2:s förmågor ligger utanför den här bokens omfattning. +En fullständig genomgång av Libgit2:s förmågor ligger utanför bokens omfattning. Om du vill ha mer information om Libgit2 självt finns API‑dokumentation på https://libgit2.org[^] och en uppsättning guider på https://libgit2.org/docs[^]. För de andra bindningarna, titta i den medföljande README:n och testerna; där finns ofta små handledningar och hänvisningar till vidare läsning. diff --git a/ch03-git-branching.asc b/ch03-git-branching.asc index 0129b041..f89b1165 100644 --- a/ch03-git-branching.asc +++ b/ch03-git-branching.asc @@ -10,7 +10,7 @@ En del kallar Gits grenmodell för dess "unika signum", och den gör verkligen a Vad är det som är så speciellt? Gits sätt att hantera grenar på är extremt lättviktigt, vilket gör att grenåtgärder går nästan omedelbart, och att byta fram och tillbaka mellan grenar ofta går snabbt. Till skillnad från många andra VCS:er uppmuntrar Git arbetsflöden där man ofta skapar grenar och slår ihop dem, till och med flera gånger om dagen. -Att förstå och behärska den här funktionen ger dig ett kraftfullt och unikt verktyg och kan helt förändra hur du utvecklar. +Att förstå och behärska funktionen ger dig ett kraftfullt och unikt verktyg och kan helt förändra hur du utvecklar. include::book/03-git-branching/sections/nutshell.asc[] diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index 90657c9c..4790ad3d 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -4,7 +4,7 @@ (((distributed git))) Nu när du har ett fjärrkodförråd som samlingspunkt för alla utvecklare och är bekant med de grundläggande Git-kommandona i ett lokalt arbetsflöde ska vi titta på hur du använder de distribuerade arbetsflöden som Git ger. -I det här kapitlet ser du hur du arbetar med Git i en distribuerad miljö, både som bidragslämnare och som integratör. +I kapitlet ser du hur du arbetar med Git i en distribuerad miljö, både som bidragslämnare och som integratör. Det vill säga: hur du bidrar med kod på ett smidigt sätt för både dig och projektets förvaltare, och hur du förvaltar ett projekt där flera utvecklare bidrar. include::book/05-distributed-git/sections/distributed-workflows.asc[] diff --git a/ch06-github.asc b/ch06-github.asc index a38c42d1..02443da3 100644 --- a/ch06-github.asc +++ b/ch06-github.asc @@ -15,7 +15,7 @@ Om du inte vill använda GitHub för att vara värd för egna projekt eller sama .Gränssnitt förändras ==== Det är viktigt att komma ihåg att gränssnittselementen i de här skärmbilderna, precis som på många aktiva webbplatser, kommer att förändras över tid. -Förhoppningsvis finns huvudidén i det vi försöker göra kvar, men om du vill ha mer uppdaterade versioner av skärmarna kan nätversionerna av den här boken ha nyare skärmbilder. +Förhoppningsvis finns huvudidén i det vi försöker göra kvar, men om du vill ha mer uppdaterade versioner av skärmarna kan nätversionerna av boken ha nyare skärmbilder. ==== include::book/06-github/sections/1-setting-up-account.asc[] diff --git a/ch08-customizing-git.asc b/ch08-customizing-git.asc index d0adf911..31a13965 100644 --- a/ch08-customizing-git.asc +++ b/ch08-customizing-git.asc @@ -2,7 +2,7 @@ == Anpassa Git Hittills har vi gått igenom grunderna i hur Git fungerar och hur man använder det, och vi har introducerat flera verktyg som Git erbjuder för att hjälpa dig använda det enkelt och effektivt. -I det här kapitlet ser vi hur du kan få Git att arbeta mer skräddarsytt genom att introducera ett antal viktiga konfigurationsinställningar och krokssystemet. +I kapitlet ser vi hur du kan få Git att arbeta mer skräddarsytt genom att introducera ett antal viktiga konfigurationsinställningar och krokssystemet. Med dessa verktyg är det lätt att få Git att fungera precis som du, din organisation eller ditt team behöver. include::book/08-customizing-git/sections/config.asc[] diff --git a/ch10-git-internals.asc b/ch10-git-internals.asc index a1381cf0..e303d12f 100644 --- a/ch10-git-internals.asc +++ b/ch10-git-internals.asc @@ -13,7 +13,7 @@ Du kommer att lära dig mer om vad det betyder om en stund. I Gits tidiga dagar (främst före 1.5) var användargränssnittet mycket mer komplext eftersom det betonade detta filsystem snarare än ett polerat VCS. De senaste åren har gränssnittet förfinats tills det är lika rent och lätt att använda som vilket annat system som helst, men bilden av att det är svårt och komplext att lära sig lever kvar. -Lagret med det innehållsadresserbara filsystemet är otroligt kraftfullt, så vi börjar med det i det här kapitlet; därefter lär du dig om transportmekanismerna och de kodförrådsförvaltningsuppgifter du kan behöva hantera. +Lagret med det innehållsadresserbara filsystemet är otroligt kraftfullt, så vi börjar med det i kapitlet; därefter lär du dig om transportmekanismerna och de kodförrådsförvaltningsuppgifter du kan behöva hantera. include::book/10-git-internals/sections/plumbing-porcelain.asc[]