Swedish language review: modernized language, consistent terminology

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

@@ -3,12 +3,12 @@
 (((version control)))
 Vad är "`versionshantering`" och varför ska du bry dig?
 Versionshantering är ett system som registrerar ändringar i en fil eller en samling filer över tid så att du kan återskapa särskilda versioner senare.
-I exemplen i denna bok använder vi källkod som de filer som versionshanteras, men i praktiken kan du göra samma sak med nästan vilken typ av fil som helst på en dator.
+I exemplen i den här boken använder vi källkod som de filer som versionshanteras, men i praktiken kan du göra samma sak med nästan vilken typ av fil som helst på en dator.
 
 Om du är grafiker eller webbdesigner och vill spara varje version av en bild eller layout (vilket du med största sannolikhet vill) är ett versionshanteringssystem (VCS, efter engelskans "Version Control System") ett mycket klokt val.
 Det låter dig återställa valda filer eller hela projekt till ett tidigare läge, jämföra ändringar över tid, se vem som senast ändrade något som orsakar problem, vem som införde ett fel och när, och mycket mer.
 Att använda ett VCS betyder också att om du gör fel eller tappar filer kan du i regel återställa allt utan större ansträngning.
-Dessutom får du allt detta med en mycket liten extra arbetsinsats.
+Dessutom får du allt det här med en mycket liten extra arbetsinsats.
 
 ==== Lokala versionshanteringssystem
 
@@ -17,7 +17,7 @@ Många väljer att kopiera filer till en annan katalog (kanske en tidsstämplad
 Detta arbetssätt är mycket vanligt eftersom det är så enkelt, men det är också väldigt felkänsligt.
 Det är lätt att glömma vilken katalog du är i och råka skriva till fel fil eller skriva över filer du inte hade tänkt.
 
-För att hantera detta problem utvecklade programmerare för länge sedan lokala VCS:er som hade en enkel databas som höll reda på alla ändringar i filer som var versionshanterade.
+För att hantera det här problem utvecklade programmerare för länge sedan lokala VCS:er som hade en enkel databas som höll reda på alla ändringar i filer som var versionshanterade.
 
 .Lokalt versionshanteringsdiagram
 image::images/local.png[Lokalt versionshanteringsdiagram]
@@ -29,9 +29,9 @@ 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).
+För att hantera det här 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)))
-Under många år var detta standardmetoden för versionshantering.
+Under många år var det här standardmetoden för versionshantering.
 
 .Centraliserat versionshanteringsdiagram
 image::images/centralized.png[Centraliserat versionshanteringsdiagram]
@@ -57,5 +57,5 @@ Varje klon är i praktiken en fullständig säkerhetskopia av all data.
 .Distribuerat versionshanteringsdiagram
 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.
+Dessutom hanterar många av de här systemen 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.

book/01-introduction/sections/command-line.asc

@@ -8,4 +8,4 @@ Om du kan köra kommandoradsversionen kan du troligen också räkna ut hur du an
 Dessutom är valet av grafisk klient en smakfråga, men _alla_ användare har kommandoradsverktygen installerade och tillgängliga.
 
 Vi utgår därför från att du vet hur du öppnar Terminal i macOS eller Kommandotolken eller PowerShell i Windows.
-Om du inte vet vad vi pratar om kan du behöva stanna upp och snabbt ta reda på detta, så att du kan följa resten av exemplen och beskrivningarna i boken.
+Om du inte vet vad vi pratar om kan du behöva stanna upp och snabbt ta reda på det här, så att du kan följa resten av exemplen och beskrivningarna i boken.

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

@@ -2,19 +2,19 @@
 === Första gången med Git
 
 Nu när du har Git på ditt system vill du göra några inställningar för att anpassa din Git-miljö.
-Du behöver bara göra detta en gång på varje dator; inställningarna ligger kvar mellan uppgraderingar.
+Du behöver bara göra det här en gång på varje dator; inställningarna ligger kvar mellan uppgraderingar.
 Du kan också ändra dem när som helst genom att köra kommandona igen.
 
 Git levereras med ett verktyg som heter `git config` som låter dig läsa och sätta inställningsvariabler som styr alla delar av hur Git ser ut och beter sig.(((git commands, config)))
 Dessa variabler kan lagras på tre olika ställen:
 
 1. Filen `[path]/etc/gitconfig`: Innehåller värden som gäller för varje användare på systemet och alla deras kodförråd.
   Om du ger flaggan `--system` till `git config` läser och skriver det till just den filen.
-  Eftersom detta är en systemkonfigurationsfil behöver du administratörs- eller superanvändarbehörighet för att ändra den.
+  Eftersom det här är en systemkonfigurationsfil behöver du administratörs- eller superanvändarbehörighet för att ändra den.
 2. Filen `~/.gitconfig` eller `~/.config/git/config`: Värden som är specifika för dig som användare.
-  Du kan få Git att läsa och skriva till denna fil genom att ge flaggan `--global`, och detta påverkar _alla_ kodförråd du arbetar med på ditt system.
+  Du kan få Git att läsa och skriva till den här filen genom att ge flaggan `--global`, och det här påverkar _alla_ kodförråd du arbetar med på ditt system.
 3. Filen `config` i Git-katalogen (det vill säga `.git/config`) i det kodförråd du använder just nu: Specifikt för just det kodförrådet.
-  Du kan tvinga Git att läsa från och skriva till denna fil med flaggan `--local`, men det är standard.
+  Du kan tvinga Git att läsa från och skriva till den här filen med flaggan `--local`, men det är standard.
   Föga överraskande behöver du befinna dig i ett Git-kodförråd för att flaggan ska fungera.
 
 Varje nivå ersätter värden från föregående nivå, så värden i `.git/config` går före de i `[path]/etc/gitconfig`.
@@ -42,10 +42,10 @@ $ git config --global user.name "John Doe"
 $ git config --global user.email johndoe@example.com
 ----
 
-Återigen behöver du bara göra detta en gång om du använder flaggan `--global`, eftersom Git då alltid använder den informationen för din användare på det systemet.
-Om du vill åsidosätta detta med ett annat namn eller en annan e-postadress för specifika projekt kan du köra kommandot utan flaggan `--global` när du står i det projektet.
+Återigen behöver du bara göra det här en gång om du använder flaggan `--global`, eftersom Git då alltid använder den informationen för din användare på det systemet.
+Om du vill åsidosätta det här med ett annat namn eller en annan e-postadress för specifika projekt kan du köra kommandot utan flaggan `--global` när du står i det projektet.
 
-Många grafiska verktyg hjälper dig med detta första gången du kör dem.
+Många grafiska verktyg hjälper dig med det här första gången du kör dem.
 
 [[_editor]]
 ==== Din textredigerare
@@ -79,7 +79,7 @@ Om du använder någon annan redigerare eller en 32-bitarsversion, leta upp spec
 
 [WARNING]
 ====
-Om du inte ställer in din textredigerare på detta sätt kan du hamna i ett förvirrande läge när Git försöker starta den.
+Om du inte ställer in din textredigerare på det här sättet kan du hamna i ett förvirrande läge när Git försöker starta den.
 Ett exempel i Windows är en Git-operation som avslutas i förtid under en Git-initierad redigering.
 ====
 
@@ -113,7 +113,7 @@ color.diff=auto
 ----
 
 Du kan se nycklar mer än en gång, eftersom Git läser samma nyckel från olika filer (till exempel `[path]/etc/gitconfig` och `~/.gitconfig`).
-I dessa fall använder Git det senaste värdet för varje unik nyckel som den ser.
+I de här fall använder Git det senaste värdet för varje unik nyckel som den ser.
 
 Du kan också kontrollera vad Git tycker att en specifik nyckel har för värde genom att skriva `git config <key>`:(((git commands, config)))
 

book/01-introduction/sections/help.asc

@@ -19,7 +19,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/[^].
-På dessa kanaler samlas regelbundet hundratals personer som är kunniga i Git och ofta villiga att hjälpa till.(((IRC)))
+På de här 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:
 

book/01-introduction/sections/history.asc

@@ -16,5 +16,5 @@ Några av målen med det nya systemet var:
 * Helt distribuerat
 * Kunna hantera stora projekt som Linux-kärnan effektivt (hastighet och datastorlek)
 
-Sedan födseln 2005 har Git utvecklats och mognat till att vara lättanvänt samtidigt som det behållit dessa ursprungliga egenskaper.
+Sedan födseln 2005 har Git utvecklats och mognat till att vara lättanvänt samtidigt som det behållit de här ursprungliga egenskaper.
 Det är fantastiskt snabbt, mycket effektivt med stora projekt och har ett otroligt grensystem för icke-linjär utveckling (se <<ch03-git-branching#ch03-git-branching>>).

book/01-introduction/sections/installing.asc

@@ -36,7 +36,7 @@ För ytterligare alternativ finns installationsinstruktioner för flera olika Un
 (((macOS, installing)))
 Det finns flera sätt att installera Git på macOS.
 Det enklaste är förmodligen att installera Xcode Command Line Tools.(((Xcode)))
-På Mavericks (10.9) eller senare kan du göra detta genom att försöka köra `git` i Terminal första gången.
+På Mavericks (10.9) eller senare kan du göra det här genom att försöka köra `git` i Terminal första gången.
 
 [source,console]
 ----
@@ -56,7 +56,7 @@ image::images/git-osx-installer.png[Git-installationsprogram för macOS]
 Det finns också några sätt för att installera Git på Windows.(((Windows, installing)))
 Den mest officiella versionen finns tillgänglig för nedladdning på Gits webbplats.
 Gå bara till https://git-scm.com/download/win[^] så startar nedladdningen automatiskt.
-Observera att detta är projektet Git for Windows, som är separat från Git självt; för mer information om det, gå till https://gitforwindows.org[^].
+Observera att det här är projektet Git for Windows, som är separat från Git självt; för mer information om det, gå till https://gitforwindows.org[^].
 
 För en automatiserad installation kan du använda https://community.chocolatey.org/packages/git[Git Chocolatey-paketet^].
 Observera att Chocolatey‑paketet underhålls av gemenskapen.
@@ -67,7 +67,7 @@ Vissa kan tycka att det är användbart att installera Git direkt från källkod
 De binära installatörerna ligger ofta lite efter, men eftersom Git har mognat under senare år har det mindre betydelse.
 
 Om du vill installera Git direkt från källkod behöver du följande bibliotek som Git är beroende av: autotools, curl, zlib, openssl, expat och libiconv.
-Till exempel, om du använder ett system som har `dnf` (till exempel Fedora) eller `apt-get` (till exempel en Debianbaserad distribution), kan du använda dessa kommandon för att installera minimala beroenden för att kompilera och installera Git-binärerna:
+Till exempel, om du använder ett system som har `dnf` (till exempel Fedora) eller `apt-get` (till exempel en Debianbaserad distribution), kan du använda de här kommandona för att installera minimala beroenden för att kompilera och installera Git-binärerna:
 
 [source,console]
 ----
@@ -129,7 +129,7 @@ $ make all doc info
 $ sudo make install install-doc install-html install-info
 ----
 
-När detta är klart kan du också hämta Git via Git självt för uppdateringar:
+När det här är klart kan du också hämta Git via Git självt för uppdateringar:
 
 [source,console]
 ----

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

@@ -4,13 +4,13 @@
 Så vad är då egentligen Git?
 Det här avsnittet är viktigt, för om du förstår vad Git är och hur det fungerar blir det mycket enklare att använda Git effektivt.
 När du lär dig Git, försök att lägga åt sidan det du kan om andra VCS:er, som CVS, Subversion eller Perforce – då undviker du en del förvirring.
-Även om Gits användargränssnitt är ganska likt dessa andra VCS:er lagrar och tänker Git på information på ett helt annat sätt, och om du förstår skillnaderna blir det lättare att undvika missförstånd.(((Subversion)))(((Perforce)))
+Även om Gits användargränssnitt är ganska likt de här andra VCS:er lagrar och tänker Git på information på ett helt annat sätt, och om du förstår skillnaderna blir det lättare att undvika missförstånd.(((Subversion)))(((Perforce)))
 
 ==== Ögonblicksbilder, inte skillnader
 
 Den stora skillnaden mellan Git och alla andra VCS:er (Subversion med flera) är hur Git ser på sina data.
 Konceptuellt lagrar de flesta andra system information som en lista med filändringar.
-De systemen (CVS, Subversion, Perforce och så vidare) ser informationen de lagrar som en uppsättning filer och ändringarna som gjorts i varje fil över tid (detta brukar kallas _deltabaserad_ versionshantering).
+De systemen (CVS, Subversion, Perforce och så vidare) ser informationen de lagrar som en uppsättning filer och ändringarna som gjorts i varje fil över tid (det här brukar kallas _deltabaserad_ versionshantering).
 
 .Lagrar data som ändringar av varje fils basversion
 image::images/deltas.png[Lagrar data som ändringar av varje fils basversion]
@@ -27,12 +27,12 @@ image::images/snapshots.png[Git lagrar data som ögonblicksbilder av projektet 
 Det här är en viktig skillnad mellan Git och nästan alla andra VCS:er.
 Den gör att Git ändrar nästan varje del av versionshanteringen som de flesta andra system bara kopierade från föregående generation.
 Det gör Git mer likt ett litet filsystem med några otroligt kraftfulla verktyg ovanpå, snarare än ett VCS.
-Vi utforskar några av fördelarna med att tänka på data på detta sätt när vi går igenom grenar i <<ch03-git-branching#ch03-git-branching>>.
+Vi utforskar några av fördelarna med att tänka på data på det här sättet när vi går igenom grenar i <<ch03-git-branching#ch03-git-branching>>.
 
 ==== Nästan varje åtgärd är lokal
 
 De flesta åtgärder i Git behöver bara lokala filer och resurser – i regel krävs ingen information från en annan dator i nätverket.
-Om du är van vid ett centraliserat VCS där de flesta åtgärder har nätverksfördröjning kommer denna funktion i Git få dig att tro att hastighetsgudarna har välsignat Git med övernaturliga krafter.
+Om du är van vid ett centraliserat VCS där de flesta åtgärder har nätverksfördröjning kommer den här funktionen i Git få dig att tro att hastighetsgudarna har välsignat Git med övernaturliga krafter.
 Eftersom du har hela projektets historik på den lokala disken verkar de flesta åtgärder nästan omedelbara.
 
 Till exempel behöver Git inte kontakta en server för att bläddra i historiken – den läser den direkt från din lokala databas.
@@ -62,7 +62,7 @@ En SHA‑1‑summa ser ut ungefär så här:
 24b9da6552252987aa493b52f8696cd6d3b00373
 ----
 
-Du kommer att se dessa kontrollsummor överallt i Git eftersom Git använder dem så mycket.
+Du kommer att se de här 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 lägger i regel bara till data
@@ -100,10 +100,10 @@ Det är den viktigaste delen av Git och det är den som kopieras när du _klonar
 Det grundläggande arbetsflödet i Git ser ungefär ut så här:
 
 1. Du ändrar filer i arbetskatalogen.
-2. Du köar selektivt bara de ändringar du vill ha med i nästa incheckning, vilket lägger _endast_ dessa ändringar i köytan.
+2. Du köar selektivt bara de ändringar du vill ha med i nästa incheckning, vilket lägger _endast_ de här ändringarna i köytan.
 3. Du gör en incheckning, vilket tar filerna som de ligger i köytan och lagrar ögonblicksbilden permanent i Git‑katalogen.
 
 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 de här tillstånd och hur du antingen kan dra nytta av dem eller hoppa över köytan helt.

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

@@ -6,7 +6,7 @@ Du erhåller 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
 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.
+I båda fallen har du sedan ett Git‑kodförråd på din egen dator, redo att arbeta.
 
 ==== Initiera ett kodförråd i en befintlig katalog
 
@@ -50,7 +50,7 @@ $ git add LICENSE
 $ git commit -m 'Initial project version'
 ----
 
-Vi går igenom vad dessa kommandon gör strax.
+Vi går igenom vad de här kommandona gör strax.
 Nu har du ett Git‑kodförråd med spårade filer och en första incheckning.
 
 [[_git_cloning]]