docs: improve anglicisms

A-git-in-other-environments.asc

@@ -25,4 +25,4 @@ include::book/A-git-in-other-environments/sections/powershell.asc[]
 
 === Sammanfattning
 
-Du har lärt dig att utnyttja Gits kraft från verktygen du använder i ditt dagliga arbete och även hur du kommer åt Git‑kodförråd från dina egna program.
+Du har lärt dig att nyttja Gits kraft från verktygen du använder i ditt dagliga arbete och även hur du kommer åt Git‑kodförråd från dina egna program.

B-embedding-git-in-your-applications.asc

@@ -2,8 +2,8 @@
 [appendix]
 == 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 eventuellt dra nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier.
+Om din applikation är för utvecklare är chansen stor att den skulle tjäna på integration med versionshantering.
+Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan eventuellt ha 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.

C-git-commands.asc

@@ -24,7 +24,7 @@ Det finns två kommandon som används ganska ofta, från de första anropen av G
 
 Git har ett standard­sätt att göra hundratals saker.
 För många av dessa kan du säga åt Git att som standard göra dem på ett annat sätt, eller ställa in dina efter dina val.
-Detta spänner från att tala om för Git vad du heter till specifika terminalfärgpreferenser eller vilken redigerare du använder.
+Här anger du allt från ditt namn till terminalfärgpreferenser eller vilken redigerare du använder.
 Det finns flera filer som detta kommando läser från och skriver till, så att du kan sätta värden globalt eller för specifika kodförråd.
 
 Kommandot `git config` används i nästan varje kapitel i boken.
@@ -82,7 +82,7 @@ Om du har en 32‑bitars redigerare på ett Windows‑system med 64‑bitars ark
 ==== git help
 
 Kommandot `git help` används för att visa all dokumentation som följer med Git för vilket kommando som helst.
-Även om vi ger en grovöversikt av de flesta av de populära här i appendixet så kan du alltid köra `git help <command>` för en fullständig lista över alla möjliga alternativ och flaggor för varje kommando.
+Även om vi ger en grovöversikt av de flesta populära här i appendixet så kan du alltid köra `git help <command>` för en fullständig lista över alla möjliga alternativ och flaggor för varje kommando.
 
 Vi introducerade kommandot `git help` i <<ch01-getting-started#_git_help>> och visade hur man använder det för att hitta mer information om `git shell` i <<ch04-git-on-the-server#_setting_up_server>>.
 
@@ -116,7 +116,7 @@ I <<ch04-git-on-the-server#_getting_git_on_a_server>> tittar vi på att använda
 
 I <<ch07-git-tools#_bundling>> använder vi det för att packa upp en Git‑bunt.
 
-Slutligen lär vi oss flaggan `--recurse-submodules` i <<ch07-git-tools#_cloning_submodules>> för att göra kloning av ett kodförråd med submoduler lite enklare.
+Slutligen lär vi oss flaggan `--recurse-submodules` i <<ch07-git-tools#_cloning_submodules>> för att göra det lite enklare att klona ett kodförråd med submoduler.
 
 Även om det används på många andra ställen i boken så är de här de som är något mer unika, eller där de används på ett lite annorlunda sätt.
 
@@ -191,7 +191,7 @@ Kommandot `git reset` används främst för att ångra saker, vilket du säkert
 Det flyttar runt `HEAD`‑pekaren och kan valfritt ändra `index` eller köytan, och kan också valfritt ändra arbetskatalogen om du använder `--hard`.
 Det sista alternativet gör att kommandot kan radera ditt arbete om det används fel, så se till att du förstår det innan du använder det.
 
-Vi täcker först den enklaste användningen av `git reset` i <<ch02-git-basics-chapter#_unstaging>>, där vi använder det för att avköa en fil vi hade kört `git add` på.
+Vi visar först hur `git reset` enklast används i <<ch02-git-basics-chapter#_unstaging>>, där vi använder det för att avköa en fil vi hade kört `git add` på.
 
 Vi går sedan igenom det i ganska stor detalj i <<ch07-git-tools#_git_reset>>, som helt ägnas åt att förklara kommandot.
 
@@ -200,7 +200,7 @@ Vi använder `git reset --hard` för att avbryta en sammanslagning i <<ch07-git-
 ==== git rm
 
 Kommandot `git rm` används för att ta bort filer från köytan och arbetskatalogen i Git.
-Det liknar `git add` i det att det köar borttagningen av en fil inför nästa incheckning.
+Det liknar `git add` i det att det köar en fil för borttagning inför nästa incheckning.
 
 Vi går igenom kommandot `git rm` i detalj i <<ch02-git-basics-chapter#_removing_files>>, inklusive att ta bort filer rekursivt och att bara ta bort filer från köytan men lämna dem i arbetskatalogen med `--cached`.
 
@@ -295,7 +295,7 @@ I <<ch07-git-tools#_git_reflog>> använder vi alternativet `-g` för att visa Gi
 
 I <<ch07-git-tools#_searching>> 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.
 
-I <<ch07-git-tools#_signing_commits>> ser vi hur man använder `--show-signature` för att lägga till en valideringssträng till varje incheckning i `git log`‑utdata baserat på om den var giltigt signerad eller inte.
+I <<ch07-git-tools#_signing_commits>> ser vi hur man använder `--show-signature` för att lägga till en valideringssträng till varje incheckning i `git log`‑utdata utifrån om den var giltigt signerad eller inte.
 
 ==== git stash
 
@@ -331,7 +331,7 @@ Vi sätter upp mycket anpassade refspecar för att få `git fetch` att göra nå
 
 ==== git pull
 
-Kommandot `git pull` är i grunden en kombination av kommandona `git fetch` och `git merge`, där Git uppdaterar från fjärrkodförrådet du anger och sedan omedelbart försöker sammanfoga det i grenen du står på.
+Kommandot `git pull` kombinerar i grunden `git fetch` och `git merge`, där Git uppdaterar från fjärrkodförrådet du anger och sedan omedelbart försöker sammanfoga det i grenen du står på.
 
 Vi introducerar det kort i <<ch02-git-basics-chapter#_fetching_and_pulling>> och visar hur man ser vad det kommer att sammanfoga om du kör det i <<ch02-git-basics-chapter#_inspecting_remote>>.
 
@@ -359,7 +359,7 @@ I <<ch07-git-tools#_publishing_submodules>> använder vi flaggan `--recurse-subm
 
 I <<ch08-customizing-git#_other_client_hooks>> pratar vi kort om kroken `pre-push`, som är ett skript vi kan sätta upp för att köras innan en uppskickning slutförs för att verifiera att den ska tillåtas.
 
-Slutligen tittar vi i <<ch10-git-internals#_pushing_refspecs>> på att skicka med en full refspec i stället för de generella genvägar som normalt används.
+Slutligen tittar vi i <<ch10-git-internals#_pushing_refspecs>> på att skicka med en full refspec i stället för de allmänna genvägar som normalt används.
 Det kan hjälpa dig att vara väldigt specifik med vilket arbete du vill dela.
 
 ==== git remote
@@ -409,25 +409,25 @@ Vi visade hur man använder det för att skapa en snygg ändringslogg i <<ch05-d
 ==== git describe
 
 Kommandot `git describe` tar något som kan lösas till en incheckning och producerar en sträng som är någorlunda mänskligt läsbar och stabil över tid.
-Det är ett sätt att få en beskrivning av en incheckning som är lika entydig som en inchecknings‑SHA‑1 men mer lätt att läsa.
+Det är ett sätt att beskriva en incheckning lika entydigt som en inchecknings‑SHA‑1 men mer lättläst.
 
 Vi använder `git describe` i <<ch05-distributed-git#_build_number>> och <<ch05-distributed-git#_preparing_release>> för att få en sträng att namnge vår utgåvefil efter.
 
 === Felsökning
 
-Git har ett par kommandon som används för att felsöka ett problem i din kod.
+Git har ett par kommandon för att felsöka problem i din kod.
 Det sträcker sig från att ta reda på var något introducerades till att ta reda på vem som gjorde det.
 
 ==== git bisect
 
-Verktyget `git bisect` är ett otroligt hjälpsamt felsökningsverktyg som används för att hitta vilken specifik incheckning som först introducerade ett programfel eller ett problem genom att göra en automatisk bisektering.
+Med verktyget `git bisect` hittar du vilken specifik incheckning som först introducerade ett programfel genom automatisk bisektering.
 
 Det täcks helt i <<ch07-git-tools#_binary_search>> och nämns bara där.
 
 ==== git blame
 
-Kommandot `git blame` annoterar raderna i en fil med vilken incheckning som senast introducerade en ändring i varje rad och vilken person som författade den incheckningen.
-Det är hjälpsamt för att hitta personen du ska fråga om mer information om en specifik del av din kod.
+Kommandot `git blame` visar för varje rad i en fil vilken incheckning som senast ändrade raden och vem som skrev den.
+Det hjälper dig hitta personen du ska fråga om mer information om en specifik del av din kod.
 
 Det täcks i <<ch07-git-tools#_file_annotation>> och nämns bara där.
 
@@ -439,13 +439,13 @@ Det täcks i <<ch07-git-tools#_git_grep>> och nämns bara där.
 
 === Patchning
 
-Några kommandon i Git kretsar kring konceptet att tänka på incheckningar i termer av de ändringar de introducerar, som om incheckningsserien vore en serie patchar.
+Några kommandon i Git kretsar kring konceptet att tänka på incheckningar utifrån de ändringar de introducerar, som om incheckningsserien vore en serie patchar.
 Dessa kommandon hjälper dig att hantera dina grenar på detta sätt.
 
 ==== git cherry-pick
 
 Kommandot `git cherry-pick` används för att ta ändringen som introducerats i en enskild Git‑incheckning och försöka återinföra den som en ny incheckning på grenen du står på.
-Det kan vara användbart för att bara ta en eller två incheckningar från en gren i stället för att sammanfoga in grenen som tar med alla ändringar.
+Så kan du bara ta en eller två incheckningar från en gren i stället för att sammanfoga in grenen som tar med alla ändringar.
 
 Handplockning beskrivs och demonstreras i <<ch05-distributed-git#_rebase_cherry_pick>>.
 
@@ -472,7 +472,7 @@ Vi använder detta i <<ch07-git-tools#_reverse_commit>> för att ångra en samma
 === E‑post
 
 Många Git‑projekt, inklusive Git självt, förvaltas helt via e‑postlistor.
-Git har ett antal verktyg inbyggda för att underlätta denna process, från att generera patchar som du enkelt kan e‑posta till att tillämpa dessa patchar från en e‑postlåda.
+Git har flera verktyg inbyggda för att underlätta denna process, från att generera patchar som du enkelt kan e‑posta till att tillämpa dessa patchar från en e‑postlåda.
 
 ==== git apply
 
@@ -488,7 +488,7 @@ Det är användbart för att ta emot patchar via e‑post och tillämpa dem på
 
 Vi täckte användning och arbetsflöde kring `git am` i <<ch05-distributed-git#_git_am>>, inklusive flaggorna `--resolved`, `-i` och `-3`.
 
-Det finns också ett antal krokar du kan använda för att hjälpa till med arbetsflödet kring `git am`, och de täcks alla i <<ch08-customizing-git#_email_hooks>>.
+Det finns också flera krokar du kan använda för att hjälpa till med arbetsflödet kring `git am`, och de täcks alla i <<ch08-customizing-git#_email_hooks>>.
 
 Vi använder det också för att tillämpa patch‑formaterade GitHub‑ändringsförfrågningar i <<ch06-github#_email_notifications>>.
 
@@ -530,13 +530,13 @@ Detta kommando täcks på djupet i <<ch09-git-and-other-systems#_git_svn>>.
 
 ==== git fast-import
 
-För andra versionshanteringssystem eller import från nästan vilket format som helst kan du använda `git fast-import` för att snabbt mappa det andra formatet till något Git enkelt kan registrera.
+För andra versionshanteringssystem eller import från nästan vilket format som helst kan du använda `git fast-import` för att snabbt koppla det andra formatet till något Git enkelt kan registrera.
 
 Detta kommando täcks på djupet i <<ch09-git-and-other-systems#_custom_importer>>.
 
 === Administration
 
-Om du administrerar ett Git‑kodförråd eller behöver fixa något rejält erbjuder Git ett antal administrativa kommandon för att hjälpa dig.
+Om du administrerar ett Git‑kodförråd eller behöver fixa något rejält erbjuder Git flera administrativa kommandon för att hjälpa dig.
 
 ==== git gc
 

README.asc

@@ -65,4 +65,4 @@ Problemet kan redan ha rättats, men ändringarna har inte rullats ut ännu.
 
 == Bidra
 
-Om du vill hjälpa till genom att göra en ändring, ta en titt på link:CONTRIBUTING.md[bidragsguiden].
+Om du vill hjälpa till genom att göra en ändring, titta i link:CONTRIBUTING.md[bidragsguiden].

book/01-introduction/sections/about-version-control.asc

@@ -30,7 +30,7 @@ https://en.wikipedia.org/wiki/Revision_Control_System[RCS^] fungerar genom att h
 (((version control, centralized)))
 Nästa stora problem folk stöter på är att de behöver samarbeta med utvecklare på andra system.
 För att hantera detta utvecklades centraliserade versionshanteringssystem (CVCS).
-Dessa system (till exempel CVS, Subversion och Perforce) har en enda server som innehåller alla versionshanterade filer och ett antal klienter som hämtar ut filer från den centrala platsen.(((CVS)))(((Subversion)))(((Perforce)))
+Dessa system (till exempel CVS, Subversion och Perforce) har en enda server som innehåller alla versionshanterade filer och flera klienter som hämtar ut filer från den centrala platsen.(((CVS)))(((Subversion)))(((Perforce)))
 Under många år var detta standardmetoden för versionshantering.
 
 .Centraliserat versionshanteringsdiagram
@@ -49,7 +49,7 @@ Lokala VCS:er lider av samma problem – när hela projektets historik finns på
 ==== Distribuerade versionshanteringssystem
 
 (((version control, distributed)))
-Det är här distribuerade versionshanteringssystem (DVCS) kommer in.
+Här kommer distribuerade versionshanteringssystem (DVCS) in.
 I ett sådant system (till exempel Git, Mercurial eller Darcs) hämtar klienterna inte bara den senaste ögonblicksbilden av filerna; de speglar hela kodförrådet, inklusive all historik.
 Om en server dör och systemen samarbetade via den servern kan vilket som helst av klienternas kodförråd kopieras tillbaka till servern för att återställa den.
 Varje klon är i praktiken en fullständig säkerhetskopia av all data.
@@ -58,4 +58,4 @@ Varje klon är i praktiken en fullständig säkerhetskopia av all data.
 image::images/distributed.png[Distribuerat versionshanteringsdiagram]
 
 Dessutom hanterar många av dessa system flera fjärrkodförråd ganska väl, så du kan samarbeta med olika grupper av personer på olika sätt samtidigt inom samma projekt.
-Det gör det möjligt att använda flera typer av arbetsflöden som inte är möjliga i centraliserade system, till exempel hierarkiska modeller.
+Därmed kan du använda flera typer av arbetsflöden som inte är möjliga i centraliserade system, till exempel hierarkiska modeller.

book/01-introduction/sections/first-time-setup.asc

@@ -33,7 +33,7 @@ $ git config --list --show-origin
 
 ==== Din identitet
 
-Det första du bör göra när du installerar Git är att sätta ditt användarnamn och din e-postadress.
+Börja med att ange ditt användarnamn och din e-postadress när du installerar Git.
 Det är viktigt eftersom varje incheckning använder den informationen, och den blir oföränderligt inbakad i de incheckningar du gör:
 
 [source,console]

book/01-introduction/sections/history.asc

@@ -3,11 +3,11 @@
 Som med många goda saker i livet började Git med en aning kreativ frustration och bittra kontroverser.
 
 Linux-kärnan är ett öppet källkodsprojekt av ganska stor omfattning.(((Linux)))
-Under de tidiga åren av förvaltningen av Linux-kärnan (1991–2002) skickades ändringar runt som ändringspatchar och arkiverade filer.
+Under Linux-kärnans tidiga år (1991–2002) skickades ändringar runt som ändringspatchar och arkiverade filer.
 År 2002 började Linuxprojektet använda ett proprietärt DVCS som hette BitKeeper.(((BitKeeper)))
 
 År 2005 bröt relationen mellan gemenskapen som utvecklade Linux-kärnan och det kommersiella företag som utvecklade BitKeeper samman, och verktygets kostnadsfria version drogs tillbaka.
-Detta fick Linux-gemenskapen (och särskilt Linus Torvalds, skaparen av Linux) att utveckla ett eget verktyg baserat på de lärdomar de erhöll när de använde BitKeeper.(((Linus Torvalds)))
+Detta fick Linux-gemenskapen (och särskilt Linus Torvalds, skaparen av Linux) att utveckla ett eget verktyg utifrån vad de lärt sig av BitKeeper.(((Linus Torvalds)))
 Några av målen med det nya systemet var:
 
 * Snabbhet

book/01-introduction/sections/what-is-git.asc

@@ -63,7 +63,7 @@ En SHA‑1‑summa ser ut ungefär så här:
 ----
 
 Du kommer att se dessa kontrollsummor överallt i Git eftersom Git använder dem så mycket.
-Faktum är att Git lagrar allt i sin databas utifrån innehållets kontrollsumma, inte filnamnet.
+Git lagrar nämligen allt i sin databas utifrån innehållets kontrollsumma, inte filnamnet.
 
 ==== Git lägger i regel bara till data
 
@@ -106,4 +106,4 @@ Det grundläggande arbetsflödet i Git ser ungefär ut så här:
 Om en viss version av en fil finns i Git‑katalogen räknas den som _incheckad_.
 Om den har ändrats och lagts till i köytan är den _köad_.
 Och om den har ändrats efter att den togs ut men inte köades är den _ändrad_.
-I <<ch02-git-basics-chapter#ch02-git-basics-chapter>> får du lära dig mer om dessa tillstånd och hur du antingen kan dra nytta av dem eller hoppa över köytan helt.
+I <<ch02-git-basics-chapter#ch02-git-basics-chapter>> får du lära dig mer om dessa tillstånd och hur du antingen kan nyttja dem eller hoppa över köytan helt.

book/02-git-basics/sections/getting-a-repository.asc

@@ -1,9 +1,9 @@
 [[_getting_a_repo]]
-=== Att få tag i ett Git‑kodförråd
+=== Skaffa ett Git‑kodförråd
 
-Du erhåller normalt ett Git‑kodförråd på ett av två sätt:
+Du skaffar normalt ett Git‑kodförråd på ett av två sätt:
 
-1. Du tar en lokal katalog som ännu inte är versionshanterad än och gör den till ett Git‑kodförråd, eller
+1. Du tar en lokal katalog som ännu inte är versionshanterad och gör den till ett Git‑kodförråd, eller
 2. Du _klonar_ ett befintligt Git‑kodförråd från någon annanstans.
 
 I båda fallen har du sedan ett Git‑kodförråd på din egen dator, redo för arbeta.