diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 8f501664..ab5a4d0b 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/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. diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index dc268455..f2e64050 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 6ae4fc60..bea592d3 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/help.asc b/book/01-introduction/sections/help.asc index fd512666..8bc61c09 100644 --- a/book/01-introduction/sections/help.asc +++ b/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: diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index 8e72d5e8..ef2f15c6 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/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index b9ff137c..6b2d29be 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/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 <>. +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 <>. ==== 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 <> 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 <> 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. diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index a88a5b69..a4588f1a 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 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]] diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 91b3b398..2c59153b 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -20,7 +20,7 @@ image::images/lifecycle.png[Livscykeln för filernas status] ==== Kontrollera filstatus Det viktigaste verktyget för att avgöra vilka filer som befinner sig i vilket läge är kommandot `git status`.(((git commands, status))) -Om du kör kommandot direkt efter en kloning ser du något i stil med detta: +Om du kör kommandot direkt efter en kloning ser du något i stil med det här: [source,console] ---- @@ -100,7 +100,7 @@ Du minns kanske att när du körde `git init` gjorde du sedan `git add ` ==== Köa ändrade filer Låt oss ändra en fil som redan är spårad. -Om du ändrar en tidigare spårad fil som heter `CONTRIBUTING.md` och kör `git status` igen får du något som liknar detta: +Om du ändrar en tidigare spårad fil som heter `CONTRIBUTING.md` och kör `git status` igen får du något som liknar det här: [source,console] ---- @@ -123,7 +123,7 @@ Changes not staged for commit: `CONTRIBUTING.md` visas under "Changes not staged for commit" – en spårad fil har ändrats i arbetskatalogen men ännu inte köats. För att köa den kör du `git add`. `git add` är ett mångsidigt kommando – du använder det för att börja spåra nya filer, för att köa filer och för att markera sammanslagningskonflikter som lösta. -Det kan vara hjälpsamt att tänka "lägg exakt detta innehåll i nästa incheckning" snarare än "lägg till filen i projektet".(((git commands, add))) +Det kan vara hjälpsamt att tänka "lägg exakt det här innehållet i nästa incheckning" snarare än "lägg till filen i projektet".(((git commands, add))) Låt oss köra `git add` för att köa `CONTRIBUTING.md` och sedan köra `git status` igen: [source,console] @@ -225,7 +225,7 @@ Den andra raden talar om för Git att ignorera alla filer vars namn slutar på t Du kan också ta med logg-, tmp- och pid-kataloger, automatiskt genererad dokumentation och så vidare. Det är ofta en bra idé att skapa en `.gitignore` innan du börjar arbeta med ett nytt kodförråd så att du inte oavsiktligt versionshanterar filer du inte vill ha där. -Mönstren i `.gitignore`-filen följer dessa regler: +Mönstren i `.gitignore`-filen följer de här reglerna: * Tomma rader eller rader som börjar med `#` ignoreras. * Vanliga glob-mönster fungerar och tillämpas rekursivt i hela arbetskatalogen. @@ -408,7 +408,7 @@ index 8ebb991..643e24f 100644 ==== Vi kommer att fortsätta använda `git diff` på olika sätt under resten av boken. Det finns också möjlighet att se skillnaderna i ett grafiskt eller externt diff-verktyg. -Om du kör `git difftool` i stället för `git diff` kan du visa vilken som helst av dessa skillnader i program som emerge, vimdiff och många fler (inklusive kommersiella produkter). +Om du kör `git difftool` i stället för `git diff` kan du visa vilken som helst av de här skillnaderna i program som emerge, vimdiff och många fler (inklusive kommersiella produkter). Kör `git difftool --tool-help` för att se vad som finns tillgängligt på ditt system. ==== diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 698df6a2..d794e207 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -4,9 +4,9 @@ För att kunna samarbeta i ett Git-projekt behöver du veta hur du hanterar fjärrkodförråd. Fjärrkodförråd är versioner av ditt projekt som finns någonstans på nätet eller i ett nätverk. 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 samarbeta innebär att hantera de här fjärrkodförråden 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 det här avsnittet går vi igenom några av de här färdigheterna. [NOTE] .Fjärrkodförråd kan ligga på din lokala maskin @@ -64,10 +64,10 @@ origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- -Det betyder att vi kan uppdatera bidrag från alla dessa ganska enkelt. +Det betyder att vi kan uppdatera bidrag från alla de här 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 det här mer i <>. ==== Lägga till fjärrkodförråd @@ -116,7 +116,7 @@ $ git fetch ---- Kommandot går till fjärrprojektet och uppdaterar all data som du ännu inte har. -Efter detta har du referenser till alla grenar från fjärrkodförrådet som du kan sammanfoga eller inspektera när som helst. +Efter det här har du referenser till alla grenar från fjärrkodförrådet som du kan sammanfoga eller inspektera när som helst. Om du klonar ett kodförråd lägger kommandot automatiskt till fjärrkodförrådet under namnet "origin". `git fetch origin` uppdaterar allt nytt arbete som har skickats till fjärrkodförrådet sedan du klonade (eller senast uppdaterade data). @@ -132,7 +132,7 @@ Det kan vara ett enklare arbetsflöde; normalt gör `git clone` att din lokala m När du har ett projekt du vill dela behöver du skicka det uppströms. Kommandot är enkelt: `git push `.(((git commands, push))) -Om du vill skicka din master-gren till din `origin`-server (kloning ställer normalt in båda) kör du detta för att skicka dina incheckningar: +Om du vill skicka din master-gren till din `origin`-server (kloning ställer normalt in båda) kör du det här för att skicka dina incheckningar: [source,console] ---- @@ -148,7 +148,7 @@ Se <> för mer om hur du skickar till fj ==== Inspektera ett fjärrkodförråd Om du vill se mer information om ett specifikt fjärrkodförråd kan du använda `git remote show `.(((git commands, remote))) -Om du kör detta med till exempel `origin` får du något i stil med: +Om du kör det här med till exempel `origin` får du något i stil med: [source,console] ---- @@ -225,4 +225,4 @@ $ git remote origin ---- -När du tar bort en referens på detta sätt tas även alla spårade grenar och konfigurationsinställningar som hörde till fjärrkodförrådet bort. +När du tar bort en referens på det här sättet tas även alla spårade grenar och konfigurationsinställningar som hörde till fjärrkodförrådet bort. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 54cad41d..707c5c05 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -3,7 +3,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). +Vanligtvis används det här 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. ==== Lista taggar @@ -54,7 +54,7 @@ En lättviktig tagg är ungefär som en gren som aldrig flyttar sig – den är Annoterade taggar lagras däremot som fullvärdiga objekt i Git-databasen. De får en kontrollsumma, innehåller taggarens namn, e-post och datum, har ett taggmeddelande och kan signeras och verifieras med GNU Privacy Guard (GPG). -Det rekommenderas i regel att du skapar annoterade taggar för att få all denna information; men om du vill ha en tillfällig tagg eller inte vill spara den extra informationen finns lättviktiga taggar. +Det rekommenderas i regel att du skapar annoterade taggar för att få all den här informationenen; men om du vill ha en tillfällig tagg eller inte vill spara den extra informationen finns lättviktiga taggar. [[_annotated_tags]] ==== Kommenterade 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 det här 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/`: @@ -289,4 +289,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Om du gör detta och sedan checkar in kommer grenen `version2` att skilja sig från taggen `v2.0.0` eftersom den flyttar sig framåt med dina ändringar, så var försiktig. +Om du gör det här och sedan checkar in kommer grenen `version2` att skilja sig från taggen `v2.0.0` eftersom den flyttar sig framåt med dina ändringar, så var försiktig. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index b2b170b4..0a26ddda 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -36,7 +36,7 @@ Du får en enda incheckning – den andra ersätter resultatet av den första. Det är viktigt att förstå att när du gör ett tillägg av din senaste incheckning så _ersätter_ du den med en ny, förbättrad incheckning som tränger undan den gamla och lägger den nya på dess plats. I praktiken är det som om den föregående incheckningen aldrig existerade, och den syns inte längre i historiken. -Det uppenbara värdet med att göra på detta sätt är att kunna göra små förbättringar i den senaste incheckningen utan att fylla historiken med meddelanden av typen "Oj, glömde lägga till en fil" eller "Hoppsan, rättade ett stavfel". +Det uppenbara värdet med att göra på det här sättet är att kunna göra små förbättringar i den senaste incheckningen utan att fylla historiken med meddelanden av typen "Oj, glömde lägga till en fil" eller "Hoppsan, rättade ett stavfel". ==== [NOTE] @@ -105,7 +105,7 @@ Vi går igenom mycket mer i detalj vad `reset` gör och hur du kan använda det Vad gör du om du inser att du inte vill behålla dina ändringar i `CONTRIBUTING.md`? Hur kan du enkelt återställa den till det skick den hade vid senaste incheckningen (eller när du klonade den, eller hur den nu hamnade i arbetskatalogen)? -Som tur är visar `git status` även detta. +Som tur är visar `git status` även det här. I den senaste utskriften ser den oköade delen ut så här: [source,console] diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 51996c23..b90dfb0b 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/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index e97863f6..6b391243 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,7 +1,7 @@ === Grundläggande gren- och sammanfogningsarbete Låt oss gå igenom ett enkelt exempel på gren- och sammanfogningsarbete i ett arbetsflöde som är vanligt i verkligheten. -Du kommer att följa dessa steg: +Du kommer att följa de här steg: . Gör lite arbete på en webbplats. . Skapa en gren för en ny användarberättelse du jobbar på. @@ -62,7 +62,7 @@ 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. 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 <>. +Det finns sätt att komma runt det här (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`: [source,console] 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 0a44f40a..32411a27 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å ==== Det är viktigt att veta 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. ==== Låt oss göra några ändringar och checka 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 276afc34..41ab3aae 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 det här exemplet växlar du till `experiment` och flyttar den till `master` så här: @@ -53,11 +53,11 @@ 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. -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. @@ -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/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 70222e5f..51c7ed86 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -167,7 +167,7 @@ Switched to a new branch 'sf' Nu kommer din lokala gren `sf` automatiskt att dra från `origin/serverfix`. -Om du redan har en lokal gren och vill koppla den till en fjärrgren du just uppdaterat, eller byta vilken uppströmsgren den spårar, kan du använda `-u` eller `--set-upstream-to` med `git branch` för att sätta detta när som helst. +Om du redan har en lokal gren och vill koppla den till en fjärrgren du just uppdaterat, eller byta vilken uppströmsgren den spårar, kan du använda `-u` eller `--set-upstream-to` med `git branch` för att sätta det här när som helst. [source,console] ---- @@ -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. +Det är viktigt att notera att de här 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: @@ -231,5 +231,5 @@ To https://github.com/schacon/simplegit - [deleted] serverfix ---- -Det enda detta gör är i praktiken att ta bort pekaren på servern. +Det enda det här gör är i praktiken att ta bort pekaren på servern. Git‑servern behåller oftast data en tid tills skräpsamling körs, så om det togs bort av misstag går det ofta att återställa. diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index e858e863..bd8d49be 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -9,7 +9,7 @@ I det här avsnittet går vi igenom några vanliga arbetsflöden som de lättvik Eftersom Git använder enkel trevägssammanfogning är det i regel lätt att sammanfoga en gren in i en annan flera gånger under en längre period. Det betyder att du kan ha flera grenar som alltid är öppna och som används för olika steg i utvecklingscykeln; du kan regelbundet sammanfoga ändringar från vissa av dem in i andra. -Många Git-utvecklare använder ett arbetsflöde som bygger på detta, till exempel att bara ha helt stabil kod i sin `master`-gren – ofta bara kod som har publicerats eller ska publiceras som utgåva. +Många Git-utvecklare använder ett arbetsflöde som bygger på det här, till exempel att bara ha helt stabil kod i sin `master`-gren – ofta bara kod som har publicerats eller ska publiceras som utgåva. De har en parallell gren som heter `develop` eller `next` som de arbetar i eller använder för att testa stabilitet – den är inte alltid stabil, men när den blir stabil kan den sammanfogas in i `master`. Den används för att dra in ämnesgrenar (kortlivade grenar, som din tidigare `iss53`-gren) när de är klara, så att man kan säkerställa att de klarar tester och inte introducerar fel. @@ -59,5 +59,5 @@ image::images/topic-branches-2.png[Historik efter sammanslagning av `dumbidea` o Vi går djupare in i möjliga arbetsflöden för Git i <>, så läs det kapitlet innan du bestämmer vilken grenmodell ditt nästa projekt ska använda. -Det är viktigt att komma ihåg att dessa grenar är helt lokala. +Det är viktigt att komma ihåg att de här grenar är helt lokala. När du skapar grenar och sammanfogar dem görs allt lokalt i ditt Git-kodförråd – ingen kommunikation sker med en server. 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 210b8e05..3a6318e9 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 408ac543..60c01910 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 användas för att 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/protocols.asc b/book/04-git-server/sections/protocols.asc index f77fa06d..1e909d08 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -46,7 +46,7 @@ Därefter kan du skicka och dra från det fjärrkodförrådet via namnet `local_ Fördelarna med filbaserade kodförråd är att de är enkla och använder befintliga filrättigheter och nätverksåtkomst. Om du redan har ett delat filsystem som hela teamet når är det väldigt enkelt att sätta upp ett kodförråd. Du placerar ett bart kodförråd där alla har åtkomst och sätter läs- och skrivrättigheter som för vilken delad katalog som helst. -Vi beskriver hur man exporterar ett bart kodförråd för detta i <>. +Vi beskriver hur man exporterar ett bart kodförråd för det här i <>. Det är också ett bra sätt att snabbt hämta arbete från någon annans arbetskatalog. Om du och en kollega arbetar i samma projekt och hen vill att du ska titta på något, är `git pull /home/john/project` ofta enklare än att hen skickar upp till en server och att du sedan hämtar därifrån. @@ -56,7 +56,7 @@ Om du och en kollega arbetar i samma projekt och hen vill att du ska titta på n Nackdelarna är att delad åtkomst ofta är svårare att sätta upp och nå från flera platser än vanlig nätverksåtkomst. Om du vill skicka från din bärbara dator hemma måste du montera nätverksdisken, vilket kan vara både krångligt och långsamt. -Det är viktigt att nämna att detta inte nödvändigtvis är det snabbaste alternativet om du använder en delad nätverksdisk. +Det är viktigt att nämna att det här inte nödvändigtvis är det snabbaste alternativet om du använder en delad nätverksdisk. Ett lokalt kodförråd är snabbt bara om du har snabb åtkomst till datan. Ett kodförråd på NFS är ofta långsammare än ett kodförråd över SSH på samma server, där Git kan arbeta från lokala diskar på varje system. @@ -113,7 +113,7 @@ Kommandot körs när du skickar upp till kodförrådet (kanske via SSH); däreft $ git clone https://example.com/gitproject.git ---- -I just detta exempel använder vi `/var/www/htdocs`, som är vanligt i Apache-uppsättningar, men du kan använda vilken statisk webbserver som helst – lägg bara det bara kodförrådet där. +I just det här exempel använder vi `/var/www/htdocs`, som är vanligt i Apache-uppsättningar, men du kan använda vilken statisk webbserver som helst – lägg bara det bara kodförrådet där. Gitdata serveras som vanliga statiska filer (se <> för detaljer). I praktiken väljer du antingen en Smart HTTP-server med läs/skriv eller bara tillgång till filer via dum HTTP. @@ -125,12 +125,12 @@ Vi fokuserar på Smart HTTP. Enkelheten i att använda en enda URL för all åtkomst, och att servern bara frågar när autentisering behövs, gör det lätt för slutanvändaren. Att kunna autentisera med användarnamn och lösenord är också en stor fördel jämfört med SSH, eftersom användare inte behöver skapa SSH-nycklar lokalt och ladda upp sin publika nyckel för att kunna arbeta. -För mindre erfarna användare eller system där SSH är mindre vanligt är detta en tydlig användbarhetsvinst. +För mindre erfarna användare eller system där SSH är mindre vanligt är det här en tydlig användbarhetsvinst. Det är dessutom ett snabbt och effektivt protokoll, i nivå med SSH. Du kan också erbjuda kodförråd i läsläge över HTTPS, vilket betyder att du kan kryptera överföringen och i extremfallet kräva signerade SSL-certifikat av klienterna. -En annan fördel är att HTTP och HTTPS är så vanliga att företagsbrandväggar ofta redan tillåter trafik över dessa portar. +En annan fördel är att HTTP och HTTPS är så vanliga att företagsbrandväggar ofta redan tillåter trafik över de här portar. ===== Nackdelarna @@ -185,7 +185,7 @@ 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. 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. +Det innebär att man normalt inte skickar upp via det här protokoll. Du kan tillåta skrivåtkomst, men eftersom det saknar autentisering kan vem som helst på internet skicka om de hittar URL:en. Det är alltså ovanligt. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 747325b9..7e2a99d1 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -7,7 +7,7 @@ Vi antar också att du kör en vanlig Linuxdistribution, till exempel Ubuntu. [NOTE] ==== -Mycket av detta kan automatiseras med `ssh-copy-id` i stället för att manuellt kopiera och installera publika nycklar. +Mycket av det här kan automatiseras med `ssh-copy-id` i stället för att manuellt kopiera och installera publika nycklar. ==== Först skapar du ett användarkonto `git` och en `.ssh`-katalog för användaren. @@ -57,9 +57,9 @@ 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): +Om du kör det här 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): [source,console] ---- @@ -83,14 +83,14 @@ $ git commit -am 'Fix for README file' $ git push origin master ---- -Med denna metod får du snabbt en läs- och skrivbar Git‑server för en handfull utvecklare. +Med den här metod får du snabbt en läs- och skrivbar Git‑server för en handfull utvecklare. -Observera att alla dessa användare också kan logga in på servern och få ett skal som `git`-användaren. +Observera att alla de här användare också kan logga in på servern och få ett skal som `git`-användaren. Om du vill begränsa det behöver du byta skal i `/etc/passwd`. Du kan enkelt begränsa `git`-kontot till Git‑relaterade aktiviteter med ett begränsat skal som heter `git-shell`, som följer med Git. Om du sätter `git-shell` som inloggningsskal kan kontot inte få normal skalåtkomst. -För att göra detta anger du `git-shell` i stället för `bash` eller `csh` som inloggningsskal. +För att göra det här anger du `git-shell` i stället för `bash` eller `csh` som inloggningsskal. Du måste först lägga till den fullständiga sökvägen till `git-shell` i `/etc/shells` om den inte redan finns där: [source,console] @@ -108,7 +108,7 @@ $ sudo chsh git -s $(which git-shell) ---- Nu kan `git`-användaren fortfarande använda SSH‑anslutningen för att skicka och dra Git‑kodförråd, men kan inte få ett interaktivt skal. -Om du försöker ser du ett avvisningsmeddelande som detta: +Om du försöker ser du ett avvisningsmeddelande som det här: [source,console] ---- diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 7878a883..2f282c32 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 3e8a2343..5e9e1ef5 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å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. 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 exempel. [[_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 användningen av – och samarbetet i – Git betydligt enklare. @@ -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 använder då möjligheten att flytta 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 ger dig möjlighet att 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/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 182bc0b8..6c75b8f8 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -282,7 +282,7 @@ Eller kortare: $ git diff $(git merge-base contrib master) ---- -Ingen av dessa varianter är särskilt bekväm, så Git erbjuder en kortform: trepunktssyntaxen. +Ingen av de här varianter är särskilt bekväm, så Git erbjuder en kortform: trepunktssyntaxen. I `git diff` kan du skriva tre punkter efter en annan gren för att jämföra den sista incheckningen på din gren med den gemensamma föregångaren: [source,console] @@ -321,7 +321,7 @@ Det här är kanske det enklaste arbetsflödet, men i större eller stabilare pr Om du har ett viktigare projekt kanske du vill använda en tvåfas-sammanslagning. Då har du två långlivade grenar, `master` och `develop`, där `master` uppdateras först när en mycket stabil version skapas och all ny kod integreras i `develop`. -Du skickar upp båda dessa grenar till det publika kodförrådet. +Du skickar upp båda de här grenar till det publika kodförrådet. När du har en ny funktionsgren att sammanfoga (<>), sammanfogar du den i `develop` (<>); när du taggar en version snabbspolar du `master` till den punkt där `develop` är stabil (<>). [[merwf_c]] @@ -446,8 +446,8 @@ user: "Scott Chacon " ---- Om du signerar taggar kan du få problem med att distribuera den publika PGP-nyckeln som används för att signera taggarna. -Git‑projektets förvaltare löste detta genom att lägga in sin publika nyckel som en blob i kodförrådet och sedan lägga en tagg som pekar direkt på innehållet. -För att göra detta kan du ta reda på vilken nyckel du vill använda genom att köra `gpg --list-keys`: +Git‑projektets förvaltare löste det här genom att lägga in sin publika nyckel som en blob i kodförrådet och sedan lägga en tagg som pekar direkt på innehållet. +För att göra det här kan du ta reda på vilken nyckel du vill använda genom att köra `gpg --list-keys`: [source,console] ---- @@ -513,7 +513,7 @@ Till exempel hoppade Linux-kärnan nyligen från 8 till 10 tecken för att säke (((releasing)))(((git commands, archive))) Nu vill du publicera en ny utgåva. En av de saker du vill göra är att skapa ett arkiv av den senaste ögonblicksbilden av din kod för dem som inte använder Git. -Kommandot för att göra detta är `git archive`: +Kommandot för att göra det här är `git archive`: [source,console] ---- diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index ce316a41..34f8f4dd 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/2-contributing.asc b/book/06-github/sections/2-contributing.asc index c481042e..04695a99 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -44,7 +44,7 @@ Så här ser det i regel ut: 7. Projektägaren sammanfogar eller stänger ändringsförfrågan. 8. Synkronisera den uppdaterade `master` tillbaka till din avgrening. -I grunden är detta samma integrationsstyrda arbetsflöde som i <>, men teamen använder GitHubs webbverktyg i stället för e-post för kommunikation och granskning. +I grunden är det här samma integrationsstyrda arbetsflöde som i <>, men teamen använder GitHubs webbverktyg i stället för e-post för kommunikation och granskning. Vi går igenom ett exempel på hur du föreslår en ändring i ett öppet källkodsprojekt som ligger på GitHub med det här flödet. @@ -129,7 +129,7 @@ image::images/blink-02-pr.png[Knapp för ändringsförfrågan] (((GitHub, pull requests))) Om vi klickar på den gröna knappen får vi en skärm som ber oss ange titel och beskrivning för ändringsförfrågan. -Det är nästan alltid värt att lägga lite tid på detta, eftersom en bra beskrivning hjälper ägaren av ursprungsprojektet att avgöra vad du försökte göra, om de föreslagna ändringarna är riktiga och om det förbättrar projektet att ta in dem. +Det är nästan alltid värt att lägga lite tid på det här, eftersom en bra beskrivning hjälper ägaren av ursprungsprojektet att avgöra vad du försökte göra, om de föreslagna ändringarna är riktiga och om det förbättrar projektet att ta in dem. Vi ser också en lista över incheckningarna i vår ämnesgren som ligger före `master`-grenen (i det här fallet bara en) samt en sammanfogad diff över alla ändringar som görs om grenen sammanfogas av projektägaren. @@ -140,7 +140,7 @@ När du trycker på knappen för att skapa ändringsförfrågan på den här sk [NOTE] ==== -Även om ändringsförfrågningar ofta används för publika projekt som detta när bidragslämnaren har en färdig ändring, används de också ofta i interna projekt _i början_ av utvecklingscykeln. +Även om ändringsförfrågningar ofta används för publika projekt som det här när bidragslämnaren har en färdig ändring, används de också ofta i interna projekt _i början_ av utvecklingscykeln. Eftersom du kan fortsätta skicka till ämnesgrenen även *efter* att ändringsförfrågan öppnats, öppnas den ofta tidigt och används för att iterera arbetet som ett team i ett sammanhang, i stället för att öppnas allra sist i processen. ==== @@ -155,8 +155,8 @@ Projektägaren kan granska den sammanfogade diffen och lämna en kommentar genom .Kommentera en specifik kodrad i en ändringsförfrågan image::images/blink-04-pr-comment.png[Kommentera en specifik kodrad i en ändringsförfrågan] -När förvaltaren gör denna kommentar får den som öppnade ändringsförfrågan (och i själva verket alla som följer kodförrådet) en avisering. -Vi går igenom hur du anpassar det senare, men om han hade e-postaviseringar aktiverade skulle Tony få ett e-postmeddelande som detta: +När förvaltaren gör den här kommentaren får den som öppnade ändringsförfrågan (och i själva verket alla som följer kodförrådet) en avisering. +Vi går igenom hur du anpassar det senare, men om han hade e-postaviseringar aktiverade skulle Tony få ett e-postmeddelande som det här: [[_email_notification]] .Kommentarer skickade som e-postaviseringar @@ -183,7 +183,7 @@ image::images/blink-06-final.png[alt="Ändringsförfrågan, slutligt läge"] En intressant detalj är att om du klickar på fliken för ändrade filer i ändringsförfrågan får du den sammanfogade diffen -- alltså den sammanlagda skillnaden som skulle införas i din huvudgren om ämnesgrenen sammanfogas. I `git diff`-termer visar den i praktiken automatiskt `git diff master...` för grenen som ändringsförfrågan bygger på. -Se <> för mer om denna typ av diff. +Se <> för mer om den här typen av diff. Det andra du märker är att GitHub kontrollerar om ändringsförfrågan sammanfogas rent och erbjuder en knapp för att göra sammanslagningen åt dig på servern. Den knappen visas bara om du har skrivrättigheter till kodförrådet och en enkel sammanslagning är möjlig. @@ -224,7 +224,7 @@ När du trycker på sammanslagningsknappen på webbplatsen skapas medvetet en sa ===== Häng med uppströms Om din ändringsförfrågan blir inaktuell eller på annat sätt inte går att sammanfoga rent vill du åtgärda den så att förvaltaren enkelt kan sammanfoga. -GitHub kontrollerar detta åt dig och talar om längst ner i varje ändringsförfrågan om sammanslagningen är enkel eller inte. +GitHub kontrollerar det här åt dig och talar om längst ner i varje ändringsförfrågan om sammanslagningen är enkel eller inte. [[_pr_fail]] .Ändringsförfrågan sammanfogas inte rent @@ -282,13 +282,13 @@ To https://github.com/tonychacon/blink <4> Åtgärda konflikten som uppstod. <5> Skicka tillbaka till samma ämnesgren. -När du har gjort detta uppdateras ändringsförfrågan automatiskt och kontrolleras igen för att se om den sammanfogas rent. +När du har gjort det här uppdateras ändringsförfrågan automatiskt och kontrolleras igen för att se om den sammanfogas rent. [[_pr_merge_fix]] .Ändringsförfrågan sammanfogas nu rent image::images/pr-02-merge-fix.png[Ändringsförfrågan sammanfogas nu rent] -En av de stora fördelarna med Git är att du kan göra detta kontinuerligt. +En av de stora fördelarna med Git är att du kan göra det här kontinuerligt. Om du har ett projekt som pågår länge kan du enkelt sammanfoga från målgrenen om och om igen och bara behöva hantera konflikter som uppstått sedan senaste sammanslagningen, vilket gör processen lätt att hantera. Om du absolut vill ombasera grenen för att städa till den kan du göra det, men det är starkt rekommenderat att inte tvinga upp en ombaserad gren över den gren som ändringsförfrågan redan pekar på. @@ -348,7 +348,7 @@ Se <<_example_markdown>> för ett exempel på hur kommentarer eller text kan skr image::images/markdown-01-example.png[alt="Ett exempel på GitHub-anpassad Markdown, både skriven och renderad"] 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. +Allt det här är mycket användbart när du skapar bra ändringsförfråge- eller ärendekommentarer eller beskrivningar. ===== Uppgiftslistor @@ -365,7 +365,7 @@ 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 det här i beskrivningen av vår ändringsförfrågan eller vårt ärende ser det renderat ut som i <<_eg_task_lists>>. [[_eg_task_lists]] .Uppgiftslistor renderade i en Markdown-kommentar @@ -413,7 +413,7 @@ image::images/markdown-04-fenced-code.png[Renderat exempel på inhägnad kod] ===== Citat Om du svarar på en liten del av en lång kommentar kan du citera delar av den andra kommentaren genom att inleda raderna med tecknet `>`. -Faktum är att detta är så vanligt och användbart att det finns en kortkommando för det. +Faktum är att det här är så vanligt och användbart att det finns en kortkommando för det. Om du markerar text i en kommentar du vill svara direkt på och trycker `r` får du texten citerad i kommentarsrutan. Citaten ser ut ungefär så här: @@ -444,7 +444,7 @@ Om du skriver en kommentar och börjar med tecknet `:` hjälper en autokomplette image::images/markdown-06-emoji-complete.png[Emoji-autokomplettering i praktiken] Emoji skrivs som `::` var som helst i kommentaren. -Till exempel kan du skriva något i stil med detta: +Till exempel kan du skriva något i stil med det här: [source,text] ---- @@ -514,7 +514,7 @@ $ git push origin master <3> <3> Skicka din `master`-gren till `origin`. Det fungerar, men det är lite krångligt att behöva skriva ut uppdateringsadressen varje gång. -Du kan automatisera detta med lite konfiguration: +Du kan automatisera det här med lite konfiguration: [source,console] ---- @@ -544,5 +544,5 @@ $ git push <3> <3> Skicka din `master`-gren till `origin`. Detta tillvägagångssätt kan vara användbart, men det har sina nackdelar. -Git gör gärna jobbet åt dig i tysthet, men varnar dig inte om du gör en incheckning i `master`, drar från `progit` och sedan skickar upp till `origin` -- alla dessa operationer är giltiga med den här uppsättningen. +Git gör gärna jobbet åt dig i tysthet, men varnar dig inte om du gör en incheckning i `master`, drar från `progit` och sedan skickar upp till `origin` -- alla de här operationerna är giltiga med den här uppsättningenen. Så du måste se till att aldrig checka in direkt i `master`, eftersom den grenen i praktiken tillhör uppströmskodförrådet. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 5421e4a5..ee50a9e6 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 referenser 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 mappa 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 74623f8c..65421e2b 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 personer. +Vanligen används de här konton 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 organisationer. 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 är en g 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/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 7771cc17..e4f3d561 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -57,7 +57,7 @@ Låt oss se ett litet exempel på en webbtjänst som du kan sätta upp för att Vi använder Ruby-ramverket Sinatra eftersom det är ganska kortfattat och det bör vara enkelt att se vad vi gör. Säg att vi vill få ett e-postmeddelande om en specifik person skickar upp till en specifik gren i vårt projekt och ändrar en specifik fil. -Det kan vi ganska enkelt göra med kod som denna: +Det kan vi ganska enkelt göra med kod som den här: [source,ruby] ---- @@ -112,7 +112,7 @@ För mer information om hur du skriver webbkrokar och alla olika händelsetyper ==== GitHub-API:t (((GitHub, API))) -Tjänster och krokar ger dig ett sätt att få skicka-aviseringar om händelser som sker i dina kodförråd, men vad händer om du behöver mer information om dessa händelser? +Tjänster och krokar ger dig ett sätt att få skicka-aviseringar om händelser som sker i dina kodförråd, men vad händer om du behöver mer information om de här händelser? Vad händer om du behöver automatisera något som att lägga till medarbetare eller märka ärenden? Det är här GitHub-API:t kommer till nytta. @@ -123,7 +123,7 @@ I det här avsnittet lär vi oss hur vi autentiserar och ansluter till API:t, hu Det mest grundläggande du kan göra är en enkel GET-begäran mot en ändpunkt som inte kräver autentisering. Det kan vara användar- eller skrivskyddad information om ett projekt med öppen källkod. -Om vi till exempel vill veta mer om en användare som heter "schacon" kan vi köra något i stil med detta: +Om vi till exempel vill veta mer om en användare som heter "schacon" kan vi köra något i stil med det här: [source,javascript] ---- @@ -227,8 +227,8 @@ Du kan använda API:t till nästan allt du kan göra på webbplatsen -- skapa oc Det finns ett sista exempel vi tittar på eftersom det är väldigt användbart om du arbetar med ändringsförfrågningar. Varje incheckning kan ha en eller flera statusar kopplade till sig och det finns ett API för att lägga till och fråga efter den statusen. -De flesta tjänster för kontinuerlig integrering och testning använder detta API för att reagera på uppskickningar genom att testa koden som skickades upp och sedan rapportera tillbaka om incheckningen klarade alla tester. -Du kan också använda detta för att kontrollera om incheckningsmeddelandet är korrekt formaterat, om insändaren följde dina bidragsriktlinjer, om incheckningen var korrekt signerad -- hur många saker som helst. +De flesta tjänster för kontinuerlig integrering och testning använder det här API för att reagera på uppskickningar genom att testa koden som skickades upp och sedan rapportera tillbaka om incheckningen klarade alla tester. +Du kan också använda det här för att kontrollera om incheckningsmeddelandet är korrekt formaterat, om insändaren följde dina bidragsriktlinjer, om incheckningen var korrekt signerad -- hur många saker som helst. Säg att du har satt upp en webbkrok i ditt kodförråd som anropar en liten webbtjänst som letar efter strängen `Signed-off-by` i incheckningsmeddelandet. @@ -275,13 +275,13 @@ post '/payload' do end ---- -Förhoppningsvis är detta ganska enkelt att följa. -I denna webbkrokshanterare går vi igenom varje incheckning som just skickades upp, letar efter strängen "Signed-off-by" i incheckningsmeddelandet och gör sedan en HTTP POST till API-ändpunkten `/repos///statuses/` med statusen. +Förhoppningsvis är det här ganska enkelt att följa. +I den här webbkrokshanterare går vi igenom varje incheckning som just skickades upp, letar efter strängen "Signed-off-by" i incheckningsmeddelandet och gör sedan en HTTP POST till API-ändpunkten `/repos///statuses/` med statusen. I det här fallet kan du skicka ett tillstånd ("success", "failure", "error"), en beskrivning av vad som hände, en mål-URL som användaren kan gå till för mer information och en "context" om det finns flera statusar för en och samma incheckning. -Till exempel kan en testtjänst ge en status och en valideringstjänst som denna kan också ge en status -- fältet "context" är hur de skiljs åt. +Till exempel kan en testtjänst ge en status och en valideringstjänst som den här kan också ge en status -- fältet "context" är hur de skiljs åt. -Om någon öppnar en ny ändringsförfrågan på GitHub och denna krok är konfigurerad kan du se något som <<_commit_status>>. +Om någon öppnar en ny ändringsförfrågan på GitHub och den här kroken är konfigurerad kan du se något som <<_commit_status>>. [[_commit_status]] .Incheckningsstatus via API:t @@ -293,9 +293,9 @@ Det här är väldigt användbart om du använder API:t för testresultat så at ==== Octokit -Även om vi har gjort nästan allt via `curl` och enkla HTTP-begäran i dessa exempel finns det flera bibliotek med öppen källkod som gör API:t tillgängligt på ett mer idiomatiskt sätt. -När detta skrevs fanns stöd för språk som Go, Objective-C, Ruby och .NET. -Se https://github.com/octokit[^] för mer information om dessa, eftersom de hanterar mycket av HTTP åt dig. +Även om vi har gjort nästan allt via `curl` och enkla HTTP-begäran i de här exempel finns det flera bibliotek med öppen källkod som gör API:t tillgängligt på ett mer idiomatiskt sätt. +När det här skrevs fanns stöd för språk som Go, Objective-C, Ruby och .NET. +Se https://github.com/octokit[^] för mer information om de här, eftersom de hanterar mycket av HTTP åt dig. -Förhoppningsvis hjälper dessa verktyg dig att anpassa och ändra GitHub så att det fungerar bättre för dina specifika arbetsflöden. +Förhoppningsvis hjälper de här verktygen dig att anpassa och ändra GitHub så att det fungerar bättre för dina specifika arbetsflöden. För fullständig dokumentation av hela API:t samt guider för vanliga uppgifter, se https://docs.github.com/[^]. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index e1f5f676..a3eaab8b 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 det här avsnittet går vi igenom vad några av de här 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 @@ -19,7 +19,7 @@ Vi tar också upp några olika, icke‑standardiserade typer av sammanslagningar Först och främst, om det alls är möjligt, se till att din arbetskatalog är ren innan du gör en sammanslagning som kan ha konflikter. Om du har arbete på gång, checka in det i en tillfällig gren eller lägg undan det. Det gör att du kan ångra *allt* du försöker här. -Om du har osparade ändringar i arbetskatalogen när du försöker sammanfoga kan några av dessa tips hjälpa dig att bevara arbetet. +Om du har osparade ändringar i arbetskatalogen när du försöker sammanfoga kan några av de här tips hjälpa dig att bevara arbetet. Låt oss gå igenom ett mycket enkelt exempel. Vi har en superenkel Ruby‑fil som skriver ut strängen `hello world`. @@ -135,7 +135,7 @@ Kom ihåg att allt oincheckat arbete kommer att gå förlorat, så se till att d I det här specifika fallet är konflikterna relaterade till blanktecken. Vi vet det eftersom fallet är enkelt, men det är också ganska lätt att se i verkliga fall när man tittar på konflikten eftersom varje rad tas bort på ena sidan och läggs till igen på den andra. -Som standard ser Git alla dessa rader som ändrade, så den kan inte sammanfoga filerna. +Som standard ser Git alla de här rader som ändrade, så den kan inte sammanfoga filerna. Standardstrategin för sammanslagning kan ta argument, och några av dem handlar om att ignorera blankteckensändringar korrekt. Om du ser att du har många blankteckensproblem i en sammanslagning kan du helt enkelt avbryta den och göra om den, den här gången med `-Xignore-all-space` eller `-Xignore-space-change`. @@ -168,10 +168,10 @@ Sedan vill vi ta kopior av vår version av filen, deras version (från grenen vi 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. -Git lagrar alla dessa versioner i indexet under "steg" som vart och ett har ett nummer kopplat till sig. +Git lagrar alla de här 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"). -Du kan extrahera en kopia av var och en av dessa versioner av konfliktfilen med kommandot `git show` och en särskild syntax. +Du kan extrahera en kopia av var och en av de här versioner av konfliktfilen med kommandot `git show` och en särskild syntax. [source,console] ---- @@ -180,7 +180,7 @@ $ git show :2:hello.rb > hello.ours.rb $ git show :3:hello.rb > hello.theirs.rb ---- -Om du vill gå lite mer på djupet kan du också använda lågnivåkommandot `ls-files -u` för att få de faktiska SHA‑1‑värdena för Git‑blobbarna för var och en av dessa filer. +Om du vill gå lite mer på djupet kan du också använda lågnivåkommandot `ls-files -u` för att få de faktiska SHA‑1‑värdena för Git‑blobbarna för var och en av de här filerna. [source,console] ---- @@ -223,7 +223,7 @@ 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. -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 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 de här 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,10 +247,10 @@ 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 faktiskt inför i filen med den här 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. +I det här 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. [source,console] ---- @@ -334,7 +334,7 @@ Automatic merge failed; fix conflicts and then commit the result. ---- Vi vill se vad sammanslagningskonflikten är. -Om vi öppnar filen ser vi något i stil med detta: +Om vi öppnar filen ser vi något i stil med det här: [source,ruby] ---- @@ -388,7 +388,7 @@ end hello() ---- -Om du gillar detta format kan du ställa in det som standard för framtida sammanslagningskonflikter genom att sätta `merge.conflictstyle` till `diff3`. +Om du gillar det här format kan du ställa in det som standard för framtida sammanslagningskonflikter genom att sätta `merge.conflictstyle` till `diff3`. [source,console] ---- @@ -406,7 +406,7 @@ Ett annat användbart verktyg när du löser sammanslagningskonflikter är `git Det kan hjälpa dig att få kontext om vad som kan ha bidragit till konflikterna. Att se lite historik för att minnas varför två utvecklingslinjer rörde samma kodområde kan ibland vara väldigt hjälpsamt. -För att få en fullständig lista över alla unika incheckningar som ingick i någon av grenarna i denna sammanslagning kan vi använda "trippelpunkts"‑syntaxen som vi lärde oss i <>. +För att få en fullständig lista över alla unika incheckningar som ingick i någon av grenarna i den här sammanslagning kan vi använda "trippelpunkts"‑syntaxen som vi lärde oss i <>. [source,console] ---- @@ -493,7 +493,7 @@ index 0399cd5,59727f0..0000000 Det visar att "`hola world`" fanns på vår sida men inte i arbetskopian, att "`hello mundo`" fanns på deras sida men inte i arbetskopian, och att "`hola mundo`" nu finns i arbetskopian trots att den inte fanns på någon sida. Det här kan vara användbart att granska innan du checkar in lösningen. -Du kan också få detta från `git log` för vilken sammanslagning som helst för att se hur något löstes i efterhand. +Du kan också få det här från `git log` för vilken sammanslagning som helst för att se hur något löstes i efterhand. Git skriver ut formatet om du kör `git show` på en sammanslagningsincheckning, eller om du lägger till flaggan `--cc` till `git log -p` (som standard bara visar diffar för icke‑sammanslagningsincheckningar). [source,console] @@ -555,15 +555,15 @@ Här är en snabb uppfräschning: `reset --hard` går vanligtvis igenom tre steg . Få indexet att se ut som HEAD. . Få arbetskatalogen att se ut som indexet. -Nackdelen med denna metod är att den skriver om historik, vilket kan vara problematiskt i ett delat kodförråd. +Nackdelen med den här metod är att den skriver om historik, vilket kan vara problematiskt i ett delat kodförråd. Se <> för mer om vad som kan hända; kortversionen är att om andra människor har incheckningarna du skriver om bör du förmodligen undvika `reset`. -Den här metoden fungerar inte heller om andra incheckningar har skapats sedan sammanslagningen; att flytta referenserna skulle i praktiken förlora dessa ändringar. +Den här metoden fungerar inte heller om andra incheckningar har skapats sedan sammanslagningen; att flytta referenserna skulle i praktiken förlora de här ändringarna. [[_reverse_commit]] ===== Gör en omvänd incheckning Om det inte fungerar att flytta grenpekare ger Git dig möjlighet att skapa en ny incheckning som ångrar alla ändringar från en befintlig. -Git kallar denna operation för en "återställning", och i just det här scenariot skulle du köra den så här: +Git kallar den här operation för en "återställning", och i just det här scenariot skulle du köra den så här: [source,console] ---- @@ -595,7 +595,7 @@ Värre är att om du lägger till arbete i `topic` och sammanfogar igen kommer G .Historik med en dålig sammanslagning image::images/undomerge-revert2.png[Historik med en dålig sammanslagning] -Det bästa sättet runt detta är att ångra återställningen av den ursprungliga sammanslagningen, eftersom du nu vill ta in de ändringar som ångrats, *och sedan* skapa en ny sammanslagningsincheckning: +Det bästa sättet runt det här är att ångra återställningen av den ursprungliga sammanslagningen, eftersom du nu vill ta in de ändringar som ångrats, *och sedan* skapa en ny sammanslagningsincheckning: [source,console] ---- @@ -624,7 +624,7 @@ Vi har redan sett alternativen `ignore-all-space` och `ignore-space-change` som Som standard, när Git ser en konflikt mellan två grenar som sammanfogas, lägger den till konfliktmarkörer i din kod och markerar filen som i konflikt och låter dig lösa den. Om du hellre vill att Git helt enkelt väljer en viss sida och ignorerar den andra sidan i stället för att låta dig manuellt lösa konflikten kan du skicka kommandot `merge` med antingen `-Xours` eller `-Xtheirs`. -Om Git ser detta kommer den inte att lägga till konfliktmarkörer. +Om Git ser det här kommer den inte att lägga till konfliktmarkörer. Alla skillnader som går att sammanfoga kommer den att sammanfoga. Alla skillnader som kolliderar kommer den helt enkelt att välja den sida du angav i sin helhet, inklusive binärfiler. diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 2a01fdd2..c46c636f 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/credentials.asc b/book/07-git-tools/sections/credentials.asc index 0f057345..21636e1b 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -16,7 +16,7 @@ Git har några alternativ direkt ur lådan: Inga lösenord lagras någonsin på disk, och de rensas ur mellanlagringen efter 15 minuter. * Läget "`store`" sparar inloggningsuppgifterna i en klartextfil på disk och de löper aldrig ut. Det betyder att tills du byter lösenord på Git‑värden behöver du aldrig skriva in dina inloggningsuppgifter igen. - Nackdelen med detta är att dina lösenord lagras i klartext i en vanlig fil i din hemmakatalog. + Nackdelen med det här är att dina lösenord lagras i klartext i en vanlig fil i din hemmakatalog. * Om du använder macOS levereras Git med läget "`osxkeychain`", som mellanlagrar inloggningsuppgifter i den säkra nyckelringen som är kopplad till ditt systemkonto. Den här metoden lagrar inloggningsuppgifterna på disk, och de löper aldrig ut, men de är krypterade med samma system som lagrar HTTPS‑certifikat och som Safari använder för autofyll. * Om du använder Windows kan du aktivera funktionen *Git Credential Manager* när du installerar https://gitforwindows.org/[Git for Windows] eller installera https://github.com/git-ecosystem/git-credential-manager/releases/latest[senaste GCM] separat som en fristående tjänst. @@ -24,14 +24,14 @@ Git har några alternativ direkt ur lådan: Den kan också tillhandahålla inloggningsuppgifter till WSL1 eller WSL2. Se https://github.com/git-ecosystem/git-credential-manager[installationsinstruktioner för GCM] för mer information. -Du kan välja en av dessa metoder genom att sätta ett Git‑konfigurationsvärde: +Du kan välja en av de här metoder genom att sätta ett Git‑konfigurationsvärde: [source,console] ---- $ git config --global credential.helper cache ---- -Några av dessa hjälpare har inställningar. +Några av de här hjälpare har inställningar. Hjälparen "`store`" kan ta argumentet `--file `, som anpassar var klartextfilen sparas (standard är `~/.git-credentials`). Hjälparen "`cache`" accepterar alternativet `--timeout `, som ändrar hur länge dess demon hålls igång (standard är "`900`", eller 15 minuter). Här är ett exempel på hur du konfigurerar hjälparen "`store`" med ett anpassat filnamn: @@ -55,7 +55,7 @@ Här är hur en `.gitconfig` kan se ut om du har en inloggningsfil på ett USB ==== Under huven -Hur fungerar allt detta? +Hur fungerar allt det här? Gits rotkommando för systemet med inloggningshjälpare är `git credential`, som tar ett kommando som argument och sedan mer indata via stdin. Det blir tydligare med ett exempel. @@ -104,11 +104,11 @@ Det finns flera former det kan ta: |====== Så hjälparna som beskrivs ovan heter egentligen `git-credential-cache`, `git-credential-store` och så vidare, och vi kan konfigurera dem att ta kommandoradsargument. -Den allmänna formen för detta är "`git-credential-foo [args] .`" +Den allmänna formen för det här är "`git-credential-foo [args] .`" Stdin/stdout‑protokollet är detsamma som git‑credential, men de använder en något annorlunda uppsättning åtgärder: * `get` är en begäran om ett användarnamn/lösenords‑par. -* `store` är en begäran om att spara en uppsättning inloggningsuppgifter i denna hjälpares minne. +* `store` är en begäran om att spara en uppsättning inloggningsuppgifter i den här hjälpares minne. * `erase` rensar inloggningsuppgifterna för de givna egenskaperna ur hjälparens minne. För åtgärderna `store` och `erase` krävs inget svar (Git ignorerar det ändå). @@ -154,7 +154,7 @@ Eftersom `git-credential-store` och dess vänner är separata program från Git Hjälparna som följer med Git täcker många vanliga användningsfall, men inte alla. Till exempel, säg att ditt team har vissa inloggningsuppgifter som delas av hela teamet, kanske för driftsättning. Dessa lagras i en delad katalog, men du vill inte kopiera dem till din egen inloggningslagring, eftersom de ändras ofta. -Inga av de befintliga hjälparna täcker detta fall; låt oss se vad som krävs för att skriva vår egen. +Inga av de befintliga hjälparna täcker det här fallet; låt oss se vad som krävs för att skriva vår egen. Det finns flera nyckelfunktioner som det här programmet behöver ha: . Den enda åtgärden vi behöver bry oss om är `get`; `store` och `erase` är skrivoperationer, så vi avslutar rent när de tas emot. @@ -200,4 +200,4 @@ Eftersom namnet börjar med "`git-`" kan vi använda den enkla syntaxen för kon $ git config --global credential.helper 'read-only --file /mnt/shared/creds' ---- -Som du ser är det ganska rakt på sak att bygga ut detta system och det kan lösa några vanliga problem för dig och ditt team. +Som du ser är det ganska rakt på sak att bygga ut det här system och det kan lösa några vanliga problem för dig och ditt team. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 3687c09f..b00148a5 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. Faktum är att om du har 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 86d87b1a..8847732f 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -5,7 +5,7 @@ I det här avsnittet tittar vi på några interaktiva Git-kommandon som kan hjä 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