diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 0068c1df..9d1c4554 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/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. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index c0c25a02..4429c518 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -2,7 +2,7 @@ === 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))) @@ -10,11 +10,11 @@ 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 `:(((git commands, config))) diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index af77598b..26db5d99 100644 --- a/book/01-introduction/sections/history.asc +++ b/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 <>). diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 32650bbc..2a429b66 100644 --- a/book/01-introduction/sections/installing.asc +++ b/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] ---- diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index cd15819a..ec5bc03d 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -6,7 +6,7 @@ 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 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]] diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index b9de78cc..e7e7e8d9 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -2,7 +2,7 @@ === Visa incheckningshistoriken Du vill ofta se vad som har hänt efter att du har gjort flera incheckningar, eller om du har klonat ett kodförråd med befintlig historik. -Det mest grundläggande och kraftfulla verktyget för detta är `git log`. +Det mest grundläggande och kraftfulla verktyget för det här är `git log`. Exemplen använder ett mycket enkelt projekt som heter "`simplegit`". Hämta projektet med: @@ -183,7 +183,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit Du undrar kanske vad skillnaden är mellan _författare_ och _incheckare_ (author och committer). Författaren är den som ursprungligen gjorde arbetet, medan incheckaren är den som senast applicerade det. Om du skickar en korrigeringsfil till ett projekt och någon i kärnteamet applicerar den får ni båda erkännande – du som författare och kärnmedlemmen som incheckare. -Vi tar upp detta lite mer i <>. +Vi tar upp det här lite mer i <>. `oneline` och `format` är särskilt användbara tillsammans med ett annat `log`-val: `--graph`. Det lägger till en liten ASCII-graf som visar gren- och sammanslagningshistorik: @@ -268,7 +268,7 @@ Detta anges alltid sist och föregås vanligtvis av två bindestreck (`--`) för $ git log -- path/to/file ---- -I <> listas dessa och några andra vanliga begränsningsval. +I <> listas de här och några andra vanliga begränsningsval. [[limit_options]] .Val för att begränsa `git log` @@ -284,7 +284,7 @@ I <> listas dessa och några andra vanliga begränsningsval. | `-S` | Visa bara incheckningar som lägger till eller tar bort kod som matchar strängen. |================================ -Till exempel, om du bara vill se vilka incheckningar som ändrade testfiler i Gits källkodshistorik, som sparades av Junio Hamano under oktober 2008 och som inte är sammanslagningsincheckningar, kan du köra något i stil med detta:(((log filtering))) +Till exempel, om du bara vill se vilka incheckningar som ändrade testfiler i Gits källkodshistorik, som sparades av Junio Hamano under oktober 2008 och som inte är sammanslagningsincheckningar, kan du köra något i stil med det här:(((log filtering))) [source,console] ---- @@ -298,7 +298,7 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Av de nästan 40 000 incheckningarna i Gits källkodshistorik listar detta kommando de sex incheckningar som uppfyller kriterierna. +Av de nästan 40 000 incheckningarna i Gits källkodshistorik listar det här kommandot de sex incheckningar som uppfyller kriterierna. [TIP] .Förhindra visning av sammanslagningsincheckningar diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index 01745a36..c8043a38 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -129,7 +129,7 @@ Nu är det dåliga namnet helt ersatt av det korrigerade. [WARNING] ==== Att byta namn på en gren som master/main/mainline/default bryter integrationer, tjänster, hjälpskript och bygg-/utgåveskript i ditt kodförråd. -Se till att samråda med dina medarbetare innan du gör detta. +Se till att samråda med dina medarbetare innan du gör det här. Kontrollera också att du uppdaterar alla referenser till det gamla namnet i kod och skript. ==== @@ -166,14 +166,14 @@ Andra medarbetare kommer fortsätta använda `master` som bas tills du gör fler Nu återstår några uppgifter för att slutföra bytet: -* Projekt som är beroende av detta behöver uppdatera kod och/eller konfiguration. +* Projekt som är beroende av det här behöver uppdatera kod och/eller konfiguration. * Uppdatera inställningar för testkörningar. * Justera bygg- och utgåveskript. * Uppdatera inställningar i kodförrådsvärden för standardgren, sammanslagningsregler och annat som matchar grennamn. * Uppdatera referenser till gamla grenen i dokumentation. * Stäng eller sammanfoga eventuella ändringsförslag som riktar sig mot gamla grenen. -När du har gjort allt detta och är säker på att `main` fungerar som `master` kan du ta bort `master`: +När du har gjort allt det här och är säker på att `main` fungerar som `master` kan du ta bort `master`: [source,console] ---- diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 31e818f5..2b08ea63 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -8,7 +8,7 @@ Som du kanske minns från <> lagrar Gi När du gör en incheckning sparar Git ett incheckningsobjekt som innehåller en pekare till ögonblicksbilden av innehållet du köade. Objektet innehåller också författarens namn och e-postadress, meddelandet du skrev och pekare till de incheckningar som kom direkt före (dess föräldrar): inga föräldrar för den första incheckningen, en förälder för en vanlig incheckning och flera föräldrar för en incheckning som är resultatet av en sammanslagning av två eller fler grenar. -För att visualisera detta kan vi anta att du har en katalog med tre filer, att du köar dem och gör en incheckning. +För att visualisera det här kan vi anta att du har en katalog med tre filer, att du köar dem och gör en incheckning. När du köar filerna beräknas en kontrollsumma för varje fil (SHA-1-hashen som nämndes i <>), Git lagrar filversionen i kodförrådet (Git kallar dem _blobbar_) och lägger kontrollsumman i köytan: [source,console] @@ -30,7 +30,7 @@ Om du gör ändringar och checkar in igen sparar nästa incheckning en pekare ti .Incheckningar och deras föräldrar image::images/commits-and-parents.png[Incheckningar och deras föräldrar] -En gren i Git är helt enkelt en lätt flyttbar pekare till en av dessa incheckningar. +En gren i Git är helt enkelt en lätt flyttbar pekare till en av de här incheckningarna. Standardgrenens namn i Git är `master`. När du börjar göra incheckningar får du en `master`-gren som pekar på den senaste incheckningen. Varje gång du checkar in flyttas `master`-pekaren framåt automatiskt. @@ -66,7 +66,7 @@ image::images/two-branches.png[Två grenar pekar på samma serie incheckningar] Hur vet Git vilken gren du står på? Den håller en särskild pekare som heter `HEAD`. -Observera att detta skiljer sig från `HEAD` i andra VCS:er som Subversion eller CVS. +Observera att det här skiljer sig från `HEAD` i andra VCS:er som Subversion eller CVS. I Git är det en pekare till den lokala gren du för närvarande står på. I det här fallet är du fortfarande på `master`. `git branch` _skapade_ bara en ny gren – den bytte inte till den. @@ -74,7 +74,7 @@ I det här fallet är du fortfarande på `master`. .HEAD pekar på en gren image::images/head-to-master.png[HEAD pekar på en gren] -Du kan lätt se detta genom att köra `git log` med flaggan `--decorate`, som visar var grenpekare ligger. +Du kan lätt se det här genom att köra `git log` med flaggan `--decorate`, som visar var grenpekare ligger. [source,console] ---- @@ -148,7 +148,7 @@ I praktiken spolar det tillbaka arbetet du gjorde i `testing` så att du kan gå ==== Tänk på att när du byter gren i Git ändras filerna i arbetskatalogen. Om du byter till en äldre gren återställs arbetskatalogen till hur den såg ut när du senast checkade in på den grenen. -Om Git inte kan göra detta utan konflikter får du inte byta gren. +Om Git inte kan göra det här utan konflikter får du inte byta gren. ==== Vi gör några ändringar och checkar in igen: @@ -162,13 +162,13 @@ $ git commit -a -m 'Make other changes' Nu har projektets historik divergerat (se <>). Du skapade och bytte till en gren, gjorde arbete där, och bytte sedan tillbaka till huvudgrenen och gjorde annat arbete. Båda ändringarna är isolerade i separata grenar: du kan byta fram och tillbaka mellan dem och sammanfoga dem när du är redo. -Och allt detta gjorde du med `branch`, `checkout` och `commit`. +Och allt det här gjorde du med `branch`, `checkout` och `commit`. [[divergent_history]] .Divergerad historik image::images/advance-master.png[Divergerad historik] -Du kan också se detta med `git log`. +Du kan också se det här med `git log`. Om du kör `git log --oneline --decorate --graph --all` skrivs hela historiken ut, samt var grenpekare finns och hur historiken har divergerat. [source,console] diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index c07ab284..74f95922 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -20,7 +20,7 @@ Det gör en trevägssammanslagning mellan de två senaste ögonblicksbilderna (` image::images/basic-rebase-2.png[Sammanslagning för att integrera divergerad historik] Men det finns ett annat sätt: du kan ta ändringspatchen som introducerades i `C4` och applicera den ovanpå `C3`. -I Git kallas detta _rebase(ombasera)_. +I Git kallas det här _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 exemplet växlar du till `experiment` och flyttar den till `master` så här: @@ -53,7 +53,7 @@ image::images/basic-rebase-4.png[Snabbspola `master`] Slutresultatet är alltså detsamma, men ombasering ger en renare historik. Om du granskar loggen för en flyttad gren ser den linjär ut: allt verkar ha skett i serie även om arbetet egentligen skedde parallellt. -Ofta gör du detta för att säkerställa att dina incheckningar går att applicera rent på en fjärrgren – till exempel när du vill bidra till ett projekt du inte förvaltar. +Ofta gör du det här för att säkerställa att dina incheckningar går att applicera rent på en fjärrgren – till exempel när du vill bidra till ett projekt du inte förvaltar. 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. @@ -194,7 +194,7 @@ Till exempel, i scenariot ovan, om du i stället för att sammanfoga vid <<_pre_ * Ta reda på vilket arbete som är unikt för din gren (`C2`, `C3`, `C4`, `C6`, `C7`) * Identifiera vilka som inte är sammanslagningsincheckningar (`C2`, `C3`, `C4`) * Identifiera vilka som inte redan finns omskrivna i målgrenen (bara `C2` och `C3`, eftersom `C4` har samma ändringspatch som `C4'`) -* Applicera dessa incheckningar ovanpå `teamone/master` +* Applicera de här incheckningarna ovanpå `teamone/master` I stället för resultatet i <<_merge_rebase_work>> får du något som liknar <<_rebase_rebase_work>>. @@ -205,7 +205,7 @@ image::images/perils-of-rebasing-5.png[Ombasera ovanpå tvingat uppskriven histo Detta fungerar bara om `C4` och `C4'` som din kollega gjorde är nästan exakt samma ändringspatch. Annars kan en ombasering inte avgöra att det är en dubblett och kommer att lägga till ännu en C4-lik ändringspatch (som sannolikt inte går att applicera rent eftersom ändringarna redan finns där). -Du kan förenkla detta genom att köra `git pull --rebase` i stället för ett vanligt `git pull`. +Du kan förenkla det här genom att köra `git pull --rebase` i stället för ett vanligt `git pull`. Eller så kan du göra det manuellt med `git fetch` följt av `git rebase teamone/master`. Om du använder `git pull` och vill göra `--rebase` till standard kan du sätta `pull.rebase` med något i stil med `git config --global pull.rebase true`. @@ -231,7 +231,7 @@ Så var det, och kodförrådet ska bevara det. Det motsatta perspektivet är att historiken är *berättelsen om hur projektet skapades*. Du publicerar inte första utkastet av en bok, så varför visa allt rörigt arbete? När du jobbar behöver du en logg över alla misslyckade spår, men när du ska visa upp resultatet kan du vilja berätta en mer sammanhängande historia om hur du gick från A till B. -Personer i detta läger använder verktyg som `rebase` och `filter-branch` för att skriva om incheckningar innan de sammanfogas in i huvudlinjen, för att berätta historien på ett sätt som är bäst för framtida läsare. +Personer i det här läger använder verktyg som `rebase` och `filter-branch` för att skriva om incheckningar innan de sammanfogas in i huvudlinjen, för att berätta historien på ett sätt som är bäst för framtida läsare. Så frågan om sammanslagning eller ombasering är bättre har inget enkelt svar. Git är kraftfullt och låter dig göra mycket med historiken, men varje team och projekt är olika. diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 8fe858a5..7ba72f99 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -19,7 +19,7 @@ config id_dsa.pub Du letar efter ett filpar som heter något i stil med `id_dsa` eller `id_rsa` och en matchande `.pub`-fil. `.pub`-filen är din publika nyckel och den andra är den privata nyckeln. -Om du inte har dessa filer (eller ens en `.ssh`-katalog) kan du skapa dem med programmet `ssh-keygen`, som ingår i SSH-paketet på Linux/macOS och följer med Git for Windows: +Om du inte har de här filerna (eller ens en `.ssh`-katalog) kan du skapa dem med programmet `ssh-keygen`, som ingår i SSH-paketet på Linux/macOS och följer med Git for Windows: [source,console] ---- @@ -39,7 +39,7 @@ Först bekräftar den var du vill spara nyckeln (`.ssh/id_rsa`) och sedan fråga Om du väljer att använda en lösenfras ska du se till att använda flaggan `-o`; den sparar den privata nyckeln i ett format som är mer motståndskraftigt mot råstyrkeknäckning än standardformatet. Du kan också använda verktyget `ssh-agent` för att slippa skriva in lösenfrasen varje gång. -Varje användare som gör detta måste skicka sin publika nyckel till dig eller till den som administrerar Git-servern (om ni använder SSH-konfiguration med publika nycklar). +Varje användare som gör det här måste skicka sin publika nyckel till dig eller till den som administrerar Git-servern (om ni använder SSH-konfiguration med publika nycklar). Det enda de behöver göra är att kopiera innehållet i `.pub`-filen och skicka det via e-post. Publika nycklar ser ut ungefär så här: diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 50f99108..33b2cbd6 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -5,7 +5,7 @@ Nu konfigurerar vi upp en demon som levererar kodförråd via "Git"-protokollet. Det är ett vanligt val för snabb, icke-autentiserad åtkomst till Git-data. Kom ihåg att eftersom tjänsten inte är autentiserad är allt du serverar via protokollet offentligt inom nätverket. -Om du kör detta på en server utanför din brandvägg ska det bara användas för projekt som är offentliga. +Om du kör det här på en server utanför din brandvägg ska det bara användas för projekt som är offentliga. Om servern ligger innanför brandväggen kan du använda det för projekt som många personer eller maskiner (till exempel CI- eller byggservrar) bara behöver läsa, och där du inte vill lägga till en SSH-nyckel per användare. Oavsett vilket är Git-protokollet ganska lätt att sätta upp. diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 89905646..6e9936e3 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -6,7 +6,7 @@ Nu går vi igenom hur du sätter upp en Git-tjänst med protokoll på din egen s [NOTE] ==== Här visar vi kommandon och steg för en grundläggande, förenklad installation på en Linuxbaserad server, men det går också att köra tjänsterna på en macOS- eller Windows-servrar. -Att sätta upp en produktionsserver i din infrastruktur innebär förstås skillnader i säkerhetsåtgärder och verktyg, men förhoppningsvis ger detta en tydlig bild av vad som krävs. +Att sätta upp en produktionsserver i din infrastruktur innebär förstås skillnader i säkerhetsåtgärder och verktyg, men förhoppningsvis ger det här en tydlig bild av vad som krävs. ==== För att komma igång behöver du exportera ett befintligt kodförråd till ett nytt bart kodförråd – ett kodförråd utan arbetskatalog. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index a61c1b5d..7a4f53e3 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -75,7 +75,7 @@ Om projektet tillhör en användare har ägaren direkt kontroll över vem som ha Varje projekt har en synlighetsnivå som styr vem som har läsåtkomst till projektets sidor och kodförråd. Om ett projekt är _Private_ måste ägaren uttryckligen ge åtkomst till specifika användare. Ett _Internal_-projekt är synligt för alla inloggade användare, och _Public_ är synligt för alla. -Observera att detta styr både `git fetch`-åtkomst och åtkomst till webbgränssnittet. +Observera att det här styr både `git fetch`-åtkomst och åtkomst till webbgränssnittet. ===== Krokar @@ -94,7 +94,7 @@ Klicka på "`Create Project`" och du är klar. När projektet finns vill du normalt koppla det till ett lokalt Git-kodförråd. Varje projekt är tillgängligt via HTTPS eller SSH, och båda kan konfigurera ett fjärrkodförråd. URL:erna visas högst upp på projektets startsida. -För ett befintligt lokalt kodförråd skapar detta kommando en fjärrreferens som heter `gitlab`: +För ett befintligt lokalt kodförråd skapar det här kommandot en fjärrreferens som heter `gitlab`: [source,console] ---- diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index a8f5d1ec..e3d6f62e 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -2,7 +2,7 @@ (((serving repositories, GitWeb)))(((GitWeb))) Nu när du har grundläggande läs/skriv-åtkomst kanske du vill sätta upp ett enkelt webbaserat gränssnitt. -Git levereras med ett CGI-skript som heter GitWeb som ibland används för detta. +Git levereras med ett CGI-skript som heter GitWeb som ibland används för det här. [[gitweb]] .GitWebs webbaserade gränssnitt @@ -67,4 +67,4 @@ Därefter behöver du konfigurera Apache att köra CGI för skriptet, till exemp ---- GitWeb kan serveras av vilken CGI- eller Perl-kapabel webserver som helst, så om du föredrar något annat bör det vara enkelt att sätta upp. -När detta är klart kan du besöka `http://gitserver/` för att se dina kodförråd på webben. +När det här är klart kan du besöka `http://gitserver/` för att se dina kodförråd på webben. diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index dad522e7..51e56829 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -36,7 +36,7 @@ ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ Om du utelämnar miljövariabeln `GIT_HTTP_EXPORT_ALL` kommer Git bara att servera kodförråd som har filen `git-daemon-export-ok`, precis som Git‑demonen gör. -Till sist behöver du tala om för Apache att tillåta anrop till `git-http-backend` och att skrivningar ska kräva autentisering, till exempel med ett Auth-block som detta: +Till sist behöver du tala om för Apache att tillåta anrop till `git-http-backend` och att skrivningar ska kräva autentisering, till exempel med ett Auth-block som det här: [source,console] ---- diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index d52c458f..ea79deaf 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -30,9 +30,9 @@ Finns det ens en sådan process? Hur många ändringar ska skickas med i taget? Hur ofta? -Alla dessa frågor påverkar hur du bäst bidrar till ett projekt, liksom vilka arbetssätt du själv föredrar eller har tillgång till. +Alla de här frågorna påverkar hur du bäst bidrar till ett projekt, liksom vilka arbetssätt du själv föredrar eller har tillgång till. Vi kommer att gå igenom tillvägagångssätten ur olika aspekter i en serie användarfall, från enkla till mer komplexa. -Du borde känna igen det arbetssätt du förväntas använda i dessa exempel. +Du borde känna igen det arbetssätt du förväntas använda i de här exemplen. [[_commit_guidelines]] ==== Riktlinjer för incheckningar @@ -60,7 +60,7 @@ Projektets ögonblicksbild längst ut på grenen kommer att se likadan ut oavset Försök därför att göra det så enkelt som möjligt för dina kollegor när de ska granska dina ändringar. Med det tillvägagångssättet blir det också enklare att dra ut eller återställa någon av ändringarna i efterhand, om det skulle behövas. -I avsnittet <> finns en mängd användbara tips för att skriva om Git‑historiken och interaktivt köa filer – använd dessa verktyg för att få en logisk och förståelig historik innan du skickar arbetet vidare till någon annan. +I avsnittet <> finns en mängd användbara tips för att skriva om Git‑historiken och interaktivt köa filer – använd de här verktygen för att få en logisk och förståelig historik innan du skickar arbetet vidare till någon annan. Slutligen behövs en struktur för incheckningsmeddelandet. Med vanan att alltid skriva bra meddelanden blir det betydligt enklare att använda Git och samarbeta. @@ -115,7 +115,7 @@ Det enklaste arbetssättet du sannolikt kommer stöta på är ett privat projekt I den här kontexten betyder "privat" sluten källkod – den är inte tillgänglig för utomstående. Du och de andra utvecklarna har skrivrättigheter till kodförrådet. -I den här uppsättningen liknar arbetssättet det som du kanske stöter på när du använder Subversion eller något annat centraliserat versionshanteringssystem. +I den här uppsättningenen liknar arbetssättet det som du kanske stöter på när du använder Subversion eller något annat centraliserat versionshanteringssystem. Du behåller fördelar som att kunna checka in utan uppkoppling och att ha enkel grenhantering, men arbetsprocessen är mycket lik; den största skillnaden är att sammanslagningar sker i klienten i stället för på servern vid incheckning. [source,console] ---- @@ -309,7 +309,7 @@ Här tittar vi på hur arbetsprocessen kan se ut när mindre team samarbetar på Säg att John och Jessica arbetar tillsammans på en funktion (vi kallar den "featureA"). Samtidigt samarbetar Jessica och en tredje utvecklare, Josie, på en annan ("featureB"). I det här fallet använder organisationen ett integrationsstyrt arbetsflöde där arbetet från ett enskilt team sammanfogas med huvudgrenen av särskilda ingenjörer. -Huvudgrenen kan endast uppdateras av dessa. +Huvudgrenen kan endast uppdateras av de här. Allt arbete sker i grenar som sedan sammanfogas senare. [source,console] @@ -565,7 +565,7 @@ Ett alternativ är att skicka det nya arbetet till en annan gren på servern (ti Vi tittar på ytterligare ett alternativ: förvaltarna har tittat på ändringarna i din andra gren och gillar dem mest, men vill att du gör en justering. Du flyttar då avgreningens bas från `featureA` till huvudgrenen. -Du kan göra detta genom att skapa en ny gren från `origin/master`, sammanfoga `featureB` där, lösa konflikter, göra justeringen och skicka det som en ny gren: +Du kan göra det här genom att skapa en ny gren från `origin/master`, sammanfoga `featureB` där, lösa konflikter, göra justeringen och skicka det som en ny gren: (((git commands, merge, squash))) [source,console] @@ -580,7 +580,7 @@ $ git push myfork featureBv2 Flaggan `--squash` komprimerar alla incheckningar på grenen som ska sammanfogas till en enda ändring, vilket ger samma status i kodförrådet som vid en sammanslagning. Det innebär att dina framtida incheckningar bara kommer att ha en förälder och låter dig dra in alla ändringar från en annan gren och göra fler ändringar innan den nya incheckningen skapas. Ibland kan det vara användbart att använda `--no-commit` för att fördröja incheckningen vid en sammanslagning. -När detta är klart kan du meddela förvaltaren att ändringarna finns i `featureBv2`. +När det här är klart kan du meddela förvaltaren att ändringarna finns i `featureBv2`. .Incheckningshistorik efter `featureBv2` image::images/public-small-3.png[Incheckningshistorik efter `featureBv2`.] diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index dba822c9..208c129a 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -79,7 +79,7 @@ I <<_add_email_addresses>> ser vi några av de olika tillstånd som är möjliga Den översta adressen är verifierad och satt som primär adress, vilket betyder att det är dit du får aviseringar och kvitton. Den andra adressen är verifierad och kan alltså göras till primär om du vill byta. Den sista adressen är overifierad, vilket innebär att du inte kan göra den till primär adress. -Om GitHub ser någon av dessa i incheckningsmeddelanden i något kodförråd på webbplatsen kopplas de nu till ditt användarkonto. +Om GitHub ser någon av de här i incheckningsmeddelanden i något kodförråd på webbplatsen kopplas de nu till ditt användarkonto. ==== Tvåfaktorsautentisering diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 9e6fb296..cb9111b5 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -28,7 +28,7 @@ Vi uppehåller oss inte vid det här; om du behöver en uppfräschning, se </`, och över SSH som `\git@github.com:/`. -Git kan uppdatera från och skicka till båda dessa URL:er, men åtkomsten styrs av vilka inloggningsuppgifter användaren har. +Git kan uppdatera från och skicka till båda de här URL:er, men åtkomsten styrs av vilka inloggningsuppgifter användaren har. [NOTE] ==== @@ -50,7 +50,7 @@ image::images/reposettingslink.png[Länken för kodförrådsinställningar] Välj sedan "Medarbetare" i menyn till vänster. Skriv in ett användarnamn i rutan och klicka på "Lägg till medarbetare". -Du kan upprepa detta så många gånger du vill för att ge åtkomst till alla du vill. +Du kan upprepa det här så många gånger du vill för att ge åtkomst till alla du vill. Om du behöver dra tillbaka åtkomst klickar du bara på "X" till höger om deras rad. .Ruta för kodförrådets medarbetare @@ -81,8 +81,8 @@ Det ger dig en länk till ändringsförfrågan på GitHub. Det ger dig också några URL:er du kan använda från kommandoraden. Om du tittar på raden som säger `git pull patch-1` är det ett enkelt sätt att sammanfoga en fjärrgren utan att lägga till ett fjärrkodförråd. -Vi tog upp detta kort i <>. -Om du vill kan du skapa och byta till en ämnesgren och sedan köra detta kommando för att sammanfoga ändringsförfrågans ändringar. +Vi tog upp det här kort i <>. +Om du vill kan du skapa och byta till en ämnesgren och sedan köra det här kommandot för att sammanfoga ändringsförfrågans ändringar. De andra intressanta URL:erna är `.diff`- och `.patch`-adresserna, som ger sammanfogad diff respektive ändringspatchversion av ändringsförfrågan. Du skulle rent tekniskt kunna sammanfoga ändringsförfrågans arbete med något som: @@ -108,7 +108,7 @@ När koden är där du vill ha den och du vill sammanfoga den kan du antingen dr Om sammanslagningen är trivial kan du också bara trycka på knappen "Sammanfoga" på GitHubs webbplats. Det gör en icke-snabbspolad sammanslagning, vilket skapar en sammanslagningsincheckning även om en snabbspolning varit möjlig. Det betyder att oavsett vad skapas en sammanslagningsincheckning varje gång du trycker på sammanslagningsknappen. -Som du ser i <<_merge_button>> ger GitHub all denna information om du klickar på hintlänken. +Som du ser i <<_merge_button>> ger GitHub all den här informationen om du klickar på hintlänken. [[_merge_button]] .Sammanslagningsknapp och instruktioner för att sammanfoga en ändringsförfrågan manuellt @@ -125,10 +125,10 @@ Det här är lite avancerat och vi går igenom detaljerna mer i <>) som heter `ls-remote`. +För att demonstrera det här använder vi ett lågnivåkommando (plumbing‑kommando, som vi läser mer om i <>) som heter `ls-remote`. Det kommandot används normalt inte i vardagliga Git-operationer, men det är användbart för att visa vilka referenser som finns på servern. -Om vi kör detta kommando mot "blink"-kodförrådet vi använde tidigare får vi en lista över alla grenar, taggar och andra referenser i kodförrådet. +Om vi kör det här kommandot mot "blink"-kodförrådet vi använde tidigare får vi en lista över alla grenar, taggar och andra referenser i kodförrådet. [source,console] ---- @@ -145,7 +145,7 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head Om du är i ditt kodförråd och kör `git ls-remote origin` eller vilket fjärrkodförråd du vill kontrollera ser det liknande ut. -Om kodförrådet ligger på GitHub och du har några öppna ändringsförfrågningar får du dessa referenser med prefixet `refs/pull/`. +Om kodförrådet ligger på GitHub och du har några öppna ändringsförfrågningar får du de här referenserna med prefixet `refs/pull/`. Det här är i praktiken grenar, men eftersom de inte ligger under `refs/heads/` får du dem inte normalt när du klonar eller uppdaterar från servern -- uppdateringen ignorerar dem normalt. Det finns två referenser per ändringsförfrågan - den som slutar på `/head` pekar på exakt samma incheckning som den sista incheckningen i ändringsförfrågans gren. @@ -180,7 +180,7 @@ Den bör se ut ungefär så här: Raden som börjar med `fetch =` är en "referensspecifikation". Det är ett sätt att koppla namn på fjärrkodförrådet till namn i din lokala `.git`-katalog. Den här berättar för Git att "det som ligger i fjärrkodförrådet under `refs/heads` ska hamna i mitt lokala kodförråd under `refs/remotes/origin`". -Du kan ändra detta avsnitt för att lägga till ytterligare en referensspecifikation: +Du kan ändra det här avsnittet för att lägga till ytterligare en referensspecifikation: [source,ini] ---- @@ -246,7 +246,7 @@ image::images/maint-05-mentions.png[Börja skriva @ för att nämna någon] Du kan också nämna en användare som inte finns i listan, men autokompletteringen går ofta snabbare. När du publicerar en kommentar med ett användarnamn får den användaren en notis. -Det innebär att detta är ett mycket effektivt sätt att dra in människor i samtal i stället för att få dem att hålla koll själva. +Det innebär att det här är ett mycket effektivt sätt att dra in människor i samtal i stället för att få dem att hålla koll själva. I ändringsförfrågningar på GitHub drar folk ofta in andra personer i sina team eller sin organisation för att granska ett ärende eller en ändringsförfrågan. Om någon nämns i en ändringsförfrågan eller ett ärende blir de "prenumererade" på den och får fortsatt aviseringar varje gång aktivitet sker där. @@ -269,7 +269,7 @@ De två valen är att få aviseringar via "E-post" och via "Webb", och du kan v ====== Webbaserade aviseringar Webbaviseringar finns bara på GitHub och du kan bara se dem där. -Om du har detta alternativ valt i dina inställningar och en avisering utlöses ser du en liten blå prick över aviseringsikonen längst upp på skärmen, som i <<_not_center>>. +Om du har det här alternativ valt i dina inställningar och en avisering utlöses ser du en liten blå prick över aviseringsikonen längst upp på skärmen, som i <<_not_center>>. [[_not_center]] .Aviseringscenter @@ -280,14 +280,14 @@ Du kan filtrera aviseringarna för ett specifikt projekt genom att klicka på pr Du kan också bekräfta aviseringen genom att klicka på bockikonen bredvid en avisering, eller bekräfta _alla_ aviseringar i ett projekt genom att klicka på bocken längst upp i gruppen. Det finns också en tystknapp bredvid varje bock som du kan klicka på för att inte få fler aviseringar om det objektet. -Alla dessa verktyg är mycket användbara för att hantera stora mängder aviseringar. +Alla de här verktygen är mycket användbara för att hantera stora mängder aviseringar. Många avancerade GitHub-användare stänger helt enkelt av e-postnotiser och hanterar alla sina aviseringar via den här skärmen. ====== E-postaviseringar E-postaviseringar är det andra sättet du kan hantera aviseringar via GitHub. -Om du har detta på får du e-post för varje avisering. -Vi såg exempel på detta i <<_email_notification>> och <<_email_pr>>. +Om du har det här på får du e-post för varje avisering. +Vi såg exempel på det här i <<_email_notification>> och <<_email_pr>>. E-postmeddelandena kommer också att trådas korrekt, vilket är trevligt om du använder en e-postklient med trådning. Det finns också en hel del metadata inbäddat i rubrikerna i de e-postmeddelanden som GitHub skickar, vilket kan vara väldigt användbart för att sätta upp egna filter och regler. @@ -365,7 +365,7 @@ image::images/maint-10-default-branch.png[Ändra standardgren för ett projekt] ===== Flytta ett projekt -Om du vill flytta ett projekt till en annan användare eller en organisation i GitHub finns ett alternativ "Transfer ownership" längst ned på samma flik "Options" i kodförrådets inställningar som låter dig göra detta. +Om du vill flytta ett projekt till en annan användare eller en organisation i GitHub finns ett alternativ "Transfer ownership" längst ned på samma flik "Options" i kodförrådets inställningar som låter dig göra det här. [[_transfer_project]] .Flytta ett projekt till en annan GitHub-användare eller organisation diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 5c7927e8..d6259a76 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -4,8 +4,8 @@ (((GitHub, organizations))) Förutom enskilda användarkonton har GitHub det som kallas organisationer. Precis som personliga konton har organisationskonton en namnrymd där alla deras projekt finns, men mycket annat skiljer sig. -Dessa konton representerar en grupp människor med delat ägande av projekt, och det finns många verktyg för att hantera undergrupper av dessa personer. -Vanligen används dessa konton för öppna källkodsgrupper (som "perl" eller "rails") eller organisationer (som "google" eller "twitter"). +Dessa konton representerar en grupp människor med delat ägande av projekt, och det finns många verktyg för att hantera undergrupper av de här personerna. +Vanligen används de här kontona för öppna källkodsgrupper (som "perl" eller "rails") eller organisationer (som "google" eller "twitter"). ==== Grundläggande om organisationer @@ -22,7 +22,7 @@ Precis som personliga konton är organisationer gratis om allt du planerar att l Som ägare i en organisation kan du, när du avgrenar ett kodförråd, välja att avgrena det till organisationens namnrymd. När du skapar nya kodförråd kan du skapa dem antingen under ditt personliga konto eller under valfri organisation där du är ägare. -Du "följer" också automatiskt alla nya kodförråd som skapas under dessa organisationer. +Du "följer" också automatiskt alla nya kodförråd som skapas under de här organisationerna. Precis som i <<_personal_avatar>> kan du ladda upp en profilbild för din organisation för att göra den mer personlig. Och precis som personliga konton har organisationen en startsida som listar alla kodförråd och kan ses av andra. @@ -35,7 +35,7 @@ Organisationer kopplas till enskilda personer via team, som helt enkelt gruppera Till exempel: säg att din organisation har tre kodförråd: `frontend`, `backend` och `deployscripts`. Du vill att dina HTML/CSS/JavaScript-utvecklare ska ha åtkomst till `frontend` och kanske `backend`, och dina driftpersoner ska ha åtkomst till `backend` och `deployscripts`. -Team gör detta enkelt utan att du behöver hantera medarbetare för varje enskilt kodförråd. +Team gör det här enkelt utan att du behöver hantera medarbetare för varje enskilt kodförråd. Organisationssidan visar en enkel översikt över alla kodförråd, användare och team som hör till organisationen. diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 3dc03236..3f01d6be 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -79,7 +79,7 @@ b1ec324 First commit ---- Först behöver vi bestämma intervallet av incheckningar vi vill inkludera i bunten. -Till skillnad från nätverksprotokollen som räknar ut minsta mängden data att överföra åt oss måste vi räkna ut detta manuellt. +Till skillnad från nätverksprotokollen som räknar ut minsta mängden data att överföra åt oss måste vi räkna ut det här manuellt. Du kan förstås göra samma sak och bunta hela kodförrådet, vilket fungerar, men det är bättre att bara bunta skillnaden -- bara de tre incheckningar vi just gjorde lokalt. För att göra det behöver du beräkna skillnaden. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 32310a6b..9fb77c8a 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -39,7 +39,7 @@ Det kan vara förvirrande, eftersom du nu har sett minst tre sätt som Git anvä En annan cool sak med Git är att den inte spårar filnamnsbyten explicit. Den registrerar ögonblicksbilder och försöker sedan lista ut vad som byttes namn implicit i efterhand. -En intressant följd av detta är att du kan be den räkna ut alla möjliga kodförflyttningar också. +En intressant följd av det här är att du kan be den räkna ut alla möjliga kodförflyttningar också. Om du skickar flaggan `-C` till `git blame` analyserar Git filen du annoterar och försöker räkna ut var kodsnuttar i den ursprungligen kom ifrån om de kopierades från någon annanstans. Till exempel, säg att du refaktorerar en fil med namnet `GITServerHandler.m` till flera filer, där en av dem är `GITPackUpload.m`. Genom att köra `git blame` på `GITPackUpload.m` med flaggan `-C` kan du se var kodavsnitt ursprungligen kom ifrån: @@ -137,7 +137,7 @@ $ git bisect reset Det är ett kraftfullt verktyg som kan hjälpa dig att kontrollera hundratals incheckningar efter ett introducerat programfel på några minuter. Har du ett skript som returnerar 0 om projektet är bra eller något annat än 0 om projektet är dåligt kan du helt automatisera `git bisect`. Först anger du återigen intervallet för bisekteringen genom att ange den kända dåliga och den kända bra incheckningen. -Du kan göra detta genom att lista dem med kommandot `bisect start` om du vill, och lista den kända dåliga incheckningen först och den kända bra incheckningen som tvåa: +Du kan göra det här genom att lista dem med kommandot `bisect start` om du vill, och lista den kända dåliga incheckningen först och den kända bra incheckningen som tvåa: [source,console] ---- diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 3042e4fa..30ce2e28 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -5,7 +5,7 @@ I avsnittet tittar vi på några interaktiva Git-kommandon som kan hjälpa dig a 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. -Om du kör `git add` med flaggan `-i` eller `--interactive` går Git in i ett interaktivt skalsläge och visar något i stil med detta: +Om du kör `git add` med flaggan `-i` eller `--interactive` går Git in i ett interaktivt skalsläge och visar något i stil med det här: [source,console] ---- @@ -24,7 +24,7 @@ What now> Du kan se att kommandot visar en annan vy av din köyta än du är van vid -- i stort sett samma information som i `git status`, men mer kortfattat och informativt. Det listar ändringarna du har köat till vänster och icke köade ändringar till höger. -Efter detta kommer en sektion med kommandon, som låter dig göra en rad saker som att köa och avköa filer, köa delar av filer, lägga till ospårade filer och visa diffar för det som köats. +Efter det här kommer en sektion med kommandon, som låter dig göra en rad saker som att köa och avköa filer, köa delar av filer, lägga till ospårade filer och visa diffar för det som köats. ==== Köa och avköa filer @@ -133,7 +133,7 @@ index 4d07108..4335f49 100644