From 5c4e93b7d73050dd072b4fd753c517ef9e648998 Mon Sep 17 00:00:00 2001 From: Josef Andersson Date: Sun, 5 Apr 2026 09:09:24 +0200 Subject: [PATCH] docs: improve anglicisms Signed-off-by: Josef Andersson --- A-git-in-other-environments.asc | 2 +- B-embedding-git-in-your-applications.asc | 4 +- C-git-commands.asc | 38 +++++++------- README.asc | 2 +- .../sections/about-version-control.asc | 6 +-- .../sections/first-time-setup.asc | 2 +- book/01-introduction/sections/history.asc | 4 +- book/01-introduction/sections/what-is-git.asc | 4 +- .../sections/getting-a-repository.asc | 6 +-- .../sections/recording-changes.asc | 12 ++--- book/02-git-basics/sections/remotes.asc | 2 +- book/02-git-basics/sections/undoing.asc | 18 +++---- .../sections/viewing-history.asc | 2 +- .../sections/basic-branching-and-merging.asc | 6 +-- book/03-git-branching/sections/nutshell.asc | 14 +++--- book/03-git-branching/sections/rebasing.asc | 2 +- .../sections/remote-branches.asc | 2 +- book/03-git-branching/sections/workflows.asc | 2 +- .../sections/git-on-a-server.asc | 2 +- book/04-git-server/sections/gitlab.asc | 4 +- book/04-git-server/sections/protocols.asc | 10 ++-- .../sections/setting-up-server.asc | 4 +- book/04-git-server/sections/smart-http.asc | 6 +-- .../sections/contributing.asc | 28 +++++------ .../sections/distributed-workflows.asc | 6 +-- .../sections/maintaining.asc | 16 +++--- .../sections/1-setting-up-account.asc | 2 +- book/06-github/sections/2-contributing.asc | 12 ++--- book/06-github/sections/3-maintaining.asc | 12 ++--- .../sections/4-managing-organization.asc | 2 +- book/06-github/sections/5-scripting.asc | 12 ++--- .../sections/advanced-merging.asc | 40 +++++++-------- book/07-git-tools/sections/bundling.asc | 12 ++--- book/07-git-tools/sections/credentials.asc | 6 +-- book/07-git-tools/sections/debugging.asc | 12 ++--- .../sections/interactive-staging.asc | 4 +- book/07-git-tools/sections/replace.asc | 2 +- book/07-git-tools/sections/reset.asc | 24 ++++----- .../sections/revision-selection.asc | 4 +- .../sections/rewriting-history.asc | 14 +++--- book/07-git-tools/sections/searching.asc | 2 +- .../sections/stashing-cleaning.asc | 4 +- book/07-git-tools/sections/submodules.asc | 34 ++++++------- book/07-git-tools/sections/subtree-merges.asc | 2 +- .../sections/attributes.asc | 8 +-- book/08-customizing-git/sections/config.asc | 10 ++-- book/08-customizing-git/sections/hooks.asc | 22 ++++---- book/08-customizing-git/sections/policy.asc | 10 ++-- .../sections/client-hg.asc | 30 +++++------ .../sections/client-p4.asc | 50 +++++++++---------- .../sections/client-svn.asc | 16 +++--- .../sections/import-custom.asc | 8 +-- .../sections/import-hg.asc | 8 +-- .../sections/import-svn.asc | 10 ++-- .../10-git-internals/sections/environment.asc | 16 +++--- .../10-git-internals/sections/maintenance.asc | 14 +++--- book/10-git-internals/sections/objects.asc | 18 +++---- book/10-git-internals/sections/packfiles.asc | 10 ++-- .../sections/plumbing-porcelain.asc | 2 +- book/10-git-internals/sections/refs.asc | 2 +- book/10-git-internals/sections/refspec.asc | 2 +- .../sections/transfer-protocols.asc | 14 +++--- .../sections/bash.asc | 4 +- .../sections/guis.asc | 10 ++-- .../sections/zsh.asc | 2 +- book/B-embedding-git/sections/go-git.asc | 6 +-- book/B-embedding-git/sections/jgit.asc | 14 +++--- book/B-embedding-git/sections/libgit2.asc | 12 ++--- book/introduction.asc | 4 +- book/preface_schacon.asc | 2 +- ch01-getting-started.asc | 2 +- ch02-git-basics-chapter.asc | 2 +- ch06-github.asc | 2 +- ch07-git-tools.asc | 6 +-- ch08-customizing-git.asc | 2 +- ch09-git-and-other-systems.asc | 2 +- ch10-git-internals.asc | 8 +-- 77 files changed, 366 insertions(+), 366 deletions(-) diff --git a/A-git-in-other-environments.asc b/A-git-in-other-environments.asc index e83a67ba..e7f210ad 100644 --- a/A-git-in-other-environments.asc +++ b/A-git-in-other-environments.asc @@ -25,4 +25,4 @@ include::book/A-git-in-other-environments/sections/powershell.asc[] === Sammanfattning -Du har lärt dig att utnyttja Gits kraft från verktygen du använder i ditt dagliga arbete och även hur du kommer åt Git‑kodförråd från dina egna program. +Du har lärt dig att nyttja Gits kraft från verktygen du använder i ditt dagliga arbete och även hur du kommer åt Git‑kodförråd från dina egna program. diff --git a/B-embedding-git-in-your-applications.asc b/B-embedding-git-in-your-applications.asc index 5ff29c35..cf1ff1a8 100644 --- a/B-embedding-git-in-your-applications.asc +++ b/B-embedding-git-in-your-applications.asc @@ -2,8 +2,8 @@ [appendix] == Bädda in Git i dina applikationer -Om din applikation är för utvecklare är chansen stor att den skulle kunna dra nytta av integration med versionshantering. -Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan eventuellt dra nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier. +Om din applikation är för utvecklare är chansen stor att den skulle tjäna på integration med versionshantering. +Även applikationer som inte är för utvecklare, såsom dokumentredigerare, kan eventuellt ha nytta av versionshanteringsfunktioner, och Gits modell fungerar mycket bra för många olika scenarier. Om du behöver integrera Git med din applikation har du i praktiken två alternativ: starta ett skal och anropa kommandoradsprogrammet `git`, eller bädda in ett Git‑bibliotek i din applikation. Här går vi igenom kommandoradsintegration och flera av de mest populära inbäddningsbara Git‑biblioteken. diff --git a/C-git-commands.asc b/C-git-commands.asc index a7c266ec..b6e545fa 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -24,7 +24,7 @@ Det finns två kommandon som används ganska ofta, från de första anropen av G Git har ett standard­sätt att göra hundratals saker. För många av dessa kan du säga åt Git att som standard göra dem på ett annat sätt, eller ställa in dina efter dina val. -Detta spänner från att tala om för Git vad du heter till specifika terminalfärgpreferenser eller vilken redigerare du använder. +Här anger du allt från ditt namn till terminalfärgpreferenser eller vilken redigerare du använder. Det finns flera filer som detta kommando läser från och skriver till, så att du kan sätta värden globalt eller för specifika kodförråd. Kommandot `git config` används i nästan varje kapitel i boken. @@ -82,7 +82,7 @@ Om du har en 32‑bitars redigerare på ett Windows‑system med 64‑bitars ark ==== git help Kommandot `git help` används för att visa all dokumentation som följer med Git för vilket kommando som helst. -Även om vi ger en grovöversikt av de flesta av de populära här i appendixet så kan du alltid köra `git help ` för en fullständig lista över alla möjliga alternativ och flaggor för varje kommando. +Även om vi ger en grovöversikt av de flesta populära här i appendixet så kan du alltid köra `git help ` för en fullständig lista över alla möjliga alternativ och flaggor för varje kommando. Vi introducerade kommandot `git help` i <> och visade hur man använder det för att hitta mer information om `git shell` i <>. @@ -116,7 +116,7 @@ I <> tittar vi på att använda I <> använder vi det för att packa upp en Git‑bunt. -Slutligen lär vi oss flaggan `--recurse-submodules` i <> för att göra kloning av ett kodförråd med submoduler lite enklare. +Slutligen lär vi oss flaggan `--recurse-submodules` i <> för att göra det lite enklare att klona ett kodförråd med submoduler. Även om det används på många andra ställen i boken så är de här de som är något mer unika, eller där de används på ett lite annorlunda sätt. @@ -191,7 +191,7 @@ Kommandot `git reset` används främst för att ångra saker, vilket du säkert Det flyttar runt `HEAD`‑pekaren och kan valfritt ändra `index` eller köytan, och kan också valfritt ändra arbetskatalogen om du använder `--hard`. Det sista alternativet gör att kommandot kan radera ditt arbete om det används fel, så se till att du förstår det innan du använder det. -Vi täcker först den enklaste användningen av `git reset` i <>, där vi använder det för att avköa en fil vi hade kört `git add` på. +Vi visar först hur `git reset` enklast används i <>, där vi använder det för att avköa en fil vi hade kört `git add` på. Vi går sedan igenom det i ganska stor detalj i <>, som helt ägnas åt att förklara kommandot. @@ -200,7 +200,7 @@ Vi använder `git reset --hard` för att avbryta en sammanslagning i <>, inklusive att ta bort filer rekursivt och att bara ta bort filer från köytan men lämna dem i arbetskatalogen med `--cached`. @@ -295,7 +295,7 @@ I <> använder vi alternativet `-g` för att visa Gi I <> tittar vi på att använda alternativen `-S` och `-L` för att göra ganska avancerade sökningar efter något som hände historiskt i koden, såsom att se historiken för en funktion. -I <> ser vi hur man använder `--show-signature` för att lägga till en valideringssträng till varje incheckning i `git log`‑utdata baserat på om den var giltigt signerad eller inte. +I <> ser vi hur man använder `--show-signature` för att lägga till en valideringssträng till varje incheckning i `git log`‑utdata utifrån om den var giltigt signerad eller inte. ==== git stash @@ -331,7 +331,7 @@ Vi sätter upp mycket anpassade refspecar för att få `git fetch` att göra nå ==== git pull -Kommandot `git pull` är i grunden en kombination av kommandona `git fetch` och `git merge`, där Git uppdaterar från fjärrkodförrådet du anger och sedan omedelbart försöker sammanfoga det i grenen du står på. +Kommandot `git pull` kombinerar i grunden `git fetch` och `git merge`, där Git uppdaterar från fjärrkodförrådet du anger och sedan omedelbart försöker sammanfoga det i grenen du står på. Vi introducerar det kort i <> och visar hur man ser vad det kommer att sammanfoga om du kör det i <>. @@ -359,7 +359,7 @@ I <> använder vi flaggan `--recurse-subm I <> pratar vi kort om kroken `pre-push`, som är ett skript vi kan sätta upp för att köras innan en uppskickning slutförs för att verifiera att den ska tillåtas. -Slutligen tittar vi i <> på att skicka med en full refspec i stället för de generella genvägar som normalt används. +Slutligen tittar vi i <> på att skicka med en full refspec i stället för de allmänna genvägar som normalt används. Det kan hjälpa dig att vara väldigt specifik med vilket arbete du vill dela. ==== git remote @@ -409,25 +409,25 @@ Vi visade hur man använder det för att skapa en snygg ändringslogg i <> och <> för att få en sträng att namnge vår utgåvefil efter. === Felsökning -Git har ett par kommandon som används för att felsöka ett problem i din kod. +Git har ett par kommandon för att felsöka problem i din kod. Det sträcker sig från att ta reda på var något introducerades till att ta reda på vem som gjorde det. ==== git bisect -Verktyget `git bisect` är ett otroligt hjälpsamt felsökningsverktyg som används för att hitta vilken specifik incheckning som först introducerade ett programfel eller ett problem genom att göra en automatisk bisektering. +Med verktyget `git bisect` hittar du vilken specifik incheckning som först introducerade ett programfel genom automatisk bisektering. Det täcks helt i <> och nämns bara där. ==== git blame -Kommandot `git blame` annoterar raderna i en fil med vilken incheckning som senast introducerade en ändring i varje rad och vilken person som författade den incheckningen. -Det är hjälpsamt för att hitta personen du ska fråga om mer information om en specifik del av din kod. +Kommandot `git blame` visar för varje rad i en fil vilken incheckning som senast ändrade raden och vem som skrev den. +Det hjälper dig hitta personen du ska fråga om mer information om en specifik del av din kod. Det täcks i <> och nämns bara där. @@ -439,13 +439,13 @@ Det täcks i <> och nämns bara där. === Patchning -Några kommandon i Git kretsar kring konceptet att tänka på incheckningar i termer av de ändringar de introducerar, som om incheckningsserien vore en serie patchar. +Några kommandon i Git kretsar kring konceptet att tänka på incheckningar utifrån de ändringar de introducerar, som om incheckningsserien vore en serie patchar. Dessa kommandon hjälper dig att hantera dina grenar på detta sätt. ==== git cherry-pick Kommandot `git cherry-pick` används för att ta ändringen som introducerats i en enskild Git‑incheckning och försöka återinföra den som en ny incheckning på grenen du står på. -Det kan vara användbart för att bara ta en eller två incheckningar från en gren i stället för att sammanfoga in grenen som tar med alla ändringar. +Så kan du bara ta en eller två incheckningar från en gren i stället för att sammanfoga in grenen som tar med alla ändringar. Handplockning beskrivs och demonstreras i <>. @@ -472,7 +472,7 @@ Vi använder detta i <> för att ångra en samma === E‑post Många Git‑projekt, inklusive Git självt, förvaltas helt via e‑postlistor. -Git har ett antal verktyg inbyggda för att underlätta denna process, från att generera patchar som du enkelt kan e‑posta till att tillämpa dessa patchar från en e‑postlåda. +Git har flera verktyg inbyggda för att underlätta denna process, från att generera patchar som du enkelt kan e‑posta till att tillämpa dessa patchar från en e‑postlåda. ==== git apply @@ -488,7 +488,7 @@ Det är användbart för att ta emot patchar via e‑post och tillämpa dem på Vi täckte användning och arbetsflöde kring `git am` i <>, inklusive flaggorna `--resolved`, `-i` och `-3`. -Det finns också ett antal krokar du kan använda för att hjälpa till med arbetsflödet kring `git am`, och de täcks alla i <>. +Det finns också flera krokar du kan använda för att hjälpa till med arbetsflödet kring `git am`, och de täcks alla i <>. Vi använder det också för att tillämpa patch‑formaterade GitHub‑ändringsförfrågningar i <>. @@ -530,13 +530,13 @@ Detta kommando täcks på djupet i <>. ==== git fast-import -För andra versionshanteringssystem eller import från nästan vilket format som helst kan du använda `git fast-import` för att snabbt mappa det andra formatet till något Git enkelt kan registrera. +För andra versionshanteringssystem eller import från nästan vilket format som helst kan du använda `git fast-import` för att snabbt koppla det andra formatet till något Git enkelt kan registrera. Detta kommando täcks på djupet i <>. === Administration -Om du administrerar ett Git‑kodförråd eller behöver fixa något rejält erbjuder Git ett antal administrativa kommandon för att hjälpa dig. +Om du administrerar ett Git‑kodförråd eller behöver fixa något rejält erbjuder Git flera administrativa kommandon för att hjälpa dig. ==== git gc diff --git a/README.asc b/README.asc index fe02e399..85bbfc92 100644 --- a/README.asc +++ b/README.asc @@ -65,4 +65,4 @@ Problemet kan redan ha rättats, men ändringarna har inte rullats ut ännu. == Bidra -Om du vill hjälpa till genom att göra en ändring, ta en titt på link:CONTRIBUTING.md[bidragsguiden]. +Om du vill hjälpa till genom att göra en ändring, titta i link:CONTRIBUTING.md[bidragsguiden]. diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 2417191d..134a37af 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -30,7 +30,7 @@ https://en.wikipedia.org/wiki/Revision_Control_System[RCS^] fungerar genom att h (((version control, centralized))) Nästa stora problem folk stöter på är att de behöver samarbeta med utvecklare på andra system. För att hantera detta utvecklades centraliserade versionshanteringssystem (CVCS). -Dessa system (till exempel CVS, Subversion och Perforce) har en enda server som innehåller alla versionshanterade filer och ett antal klienter som hämtar ut filer från den centrala platsen.(((CVS)))(((Subversion)))(((Perforce))) +Dessa system (till exempel CVS, Subversion och Perforce) har en enda server som innehåller alla versionshanterade filer och flera klienter som hämtar ut filer från den centrala platsen.(((CVS)))(((Subversion)))(((Perforce))) Under många år var detta standardmetoden för versionshantering. .Centraliserat versionshanteringsdiagram @@ -49,7 +49,7 @@ Lokala VCS:er lider av samma problem – när hela projektets historik finns på ==== Distribuerade versionshanteringssystem (((version control, distributed))) -Det är här distribuerade versionshanteringssystem (DVCS) kommer in. +Här kommer distribuerade versionshanteringssystem (DVCS) in. I ett sådant system (till exempel Git, Mercurial eller Darcs) hämtar klienterna inte bara den senaste ögonblicksbilden av filerna; de speglar hela kodförrådet, inklusive all historik. Om en server dör och systemen samarbetade via den servern kan vilket som helst av klienternas kodförråd kopieras tillbaka till servern för att återställa den. Varje klon är i praktiken en fullständig säkerhetskopia av all data. @@ -58,4 +58,4 @@ Varje klon är i praktiken en fullständig säkerhetskopia av all data. image::images/distributed.png[Distribuerat versionshanteringsdiagram] Dessutom hanterar många av dessa system flera fjärrkodförråd ganska väl, så du kan samarbeta med olika grupper av personer på olika sätt samtidigt inom samma projekt. -Det gör det möjligt att använda flera typer av arbetsflöden som inte är möjliga i centraliserade system, till exempel hierarkiska modeller. +Därmed kan du använda flera typer av arbetsflöden som inte är möjliga i centraliserade system, till exempel hierarkiska modeller. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 6ae4fc60..c0c25a02 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -33,7 +33,7 @@ $ git config --list --show-origin ==== Din identitet -Det första du bör göra när du installerar Git är att sätta ditt användarnamn och din e-postadress. +Börja med att ange ditt användarnamn och din e-postadress när du installerar Git. Det är viktigt eftersom varje incheckning använder den informationen, och den blir oföränderligt inbakad i de incheckningar du gör: [source,console] diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index 8e72d5e8..af77598b 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -3,11 +3,11 @@ Som med många goda saker i livet började Git med en aning kreativ frustration och bittra kontroverser. Linux-kärnan är ett öppet källkodsprojekt av ganska stor omfattning.(((Linux))) -Under de tidiga åren av förvaltningen av Linux-kärnan (1991–2002) skickades ändringar runt som ändringspatchar och arkiverade filer. +Under Linux-kärnans tidiga år (1991–2002) skickades ändringar runt som ändringspatchar och arkiverade filer. År 2002 började Linuxprojektet använda ett proprietärt DVCS som hette BitKeeper.(((BitKeeper))) År 2005 bröt relationen mellan gemenskapen som utvecklade Linux-kärnan och det kommersiella företag som utvecklade BitKeeper samman, och verktygets kostnadsfria version drogs tillbaka. -Detta fick Linux-gemenskapen (och särskilt Linus Torvalds, skaparen av Linux) att utveckla ett eget verktyg baserat på de lärdomar de erhöll när de använde BitKeeper.(((Linus Torvalds))) +Detta fick Linux-gemenskapen (och särskilt Linus Torvalds, skaparen av Linux) att utveckla ett eget verktyg utifrån vad de lärt sig av BitKeeper.(((Linus Torvalds))) Några av målen med det nya systemet var: * Snabbhet diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index b9ff137c..e584f12f 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -63,7 +63,7 @@ En SHA‑1‑summa ser ut ungefär så här: ---- Du kommer att se dessa kontrollsummor överallt i Git eftersom Git använder dem så mycket. -Faktum är att Git lagrar allt i sin databas utifrån innehållets kontrollsumma, inte filnamnet. +Git lagrar nämligen allt i sin databas utifrån innehållets kontrollsumma, inte filnamnet. ==== Git lägger i regel bara till data @@ -106,4 +106,4 @@ Det grundläggande arbetsflödet i Git ser ungefär ut så här: Om en viss version av en fil finns i Git‑katalogen räknas den som _incheckad_. Om den har ändrats och lagts till i köytan är den _köad_. Och om den har ändrats efter att den togs ut men inte köades är den _ändrad_. -I <> 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 dessa tillstånd och hur du antingen kan nyttja 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 bd33f872..cd15819a 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,9 +1,9 @@ [[_getting_a_repo]] -=== Att få tag i ett Git‑kodförråd +=== Skaffa ett Git‑kodförråd -Du erhåller normalt ett Git‑kodförråd på ett av två sätt: +Du skaffar normalt ett Git‑kodförråd på ett av två sätt: -1. Du tar en lokal katalog som ännu inte är versionshanterad än och gör den till ett Git‑kodförråd, eller +1. Du tar en lokal katalog som ännu inte är versionshanterad och gör den till ett Git‑kodförråd, eller 2. Du _klonar_ ett befintligt Git‑kodförråd från någon annanstans. I båda fallen har du sedan ett Git‑kodförråd på din egen dator, redo för arbeta. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 83fca627..a42c64af 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -99,7 +99,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. +Vi ändrar 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: [source,console] @@ -123,8 +123,8 @@ 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))) -Låt oss köra `git add` för att köa `CONTRIBUTING.md` och sedan köra `git status` igen: +Tänk "lägg exakt detta innehåll i nästa incheckning" snarare än "lägg till filen i projektet".(((git commands, add))) +Vi kör `git add` för att köa `CONTRIBUTING.md` och sedan köra `git status` igen: [source,console] ---- @@ -142,7 +142,7 @@ Changes to be committed: Båda filerna är köade och kommer att ingå i nästa incheckning. Anta nu att du kommer på en liten ändring du vill göra i `CONTRIBUTING.md` innan du sparar. -Du öppnar filen igen och gör ändringen, och är redo att göra en incheckning. +Du öppnar filen igen och gör ändringen, och är redo att checka in. Men kör `git status` en gång till: [source,console] @@ -223,7 +223,7 @@ $ cat .gitignore Den första raden talar om för Git att ignorera alla filer som slutar på `.o` eller `.a` – objekt- och arkivfiler som kan skapas när du bygger. Den andra raden talar om för Git att ignorera alla filer vars namn slutar på tilde (`~`), vilket många textredigerare, som Emacs, använder för temporära filer. 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. +Skapa helst 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: @@ -415,7 +415,7 @@ Kör `git difftool --tool-help` för att se vad som finns tillgängligt på ditt [[_committing_changes]] ==== Spara dina ändringar -När köytan innehåller det du vill ha kan du göra en incheckning. +När köytan innehåller det du vill ha kan du checka in. Kom ihåg att allt som fortfarande är oköat – filer du skapat eller ändrat sedan du senast körde `git add` – inte kommer att ingå i den här incheckningen. De ligger kvar som ändrade filer på din hårddisk. Anta att allt är köat och du är redo att spara. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 824214bd..3adf369c 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -120,7 +120,7 @@ Efter detta har du referenser till alla grenar från fjärrkodförrådet som du 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). -Det är viktigt att förstå att `git fetch` bara uppdaterar data till ditt lokala kodförråd – det slår inte automatiskt ihop den med ditt arbete eller ändrar den gren du jobbar på. +`git fetch` uppdaterar bara data till ditt lokala kodförråd – det slår inte automatiskt ihop den med ditt arbete eller ändrar den gren du jobbar på. Du måste manuellt införliva ändringarna när du är redo. Om din nuvarande gren är inställd på att spåra en fjärrgren (se nästa avsnitt och <> för mer information) kan du använda `git pull` för att dra och därefter sammanfoga ändringarna i din aktuella gren.(((git commands, pull))) diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index b2b170b4..02926d47 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -33,10 +33,10 @@ Du får en enda incheckning – den andra ersätter resultatet av den första. [NOTE] ==== -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. +Tänk på att när du ändrar 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". +Fördelen är uppenbar: du kan 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] @@ -50,7 +50,7 @@ För mer om vad som händer och hur man återställer om man drabbas, se <<_reba ==== Ta bort en köad fil De två följande avsnitten visar hur du arbetar med köytan och ändringar i arbetskatalogen. -Det trevliga är att kommandot du använder för att se statusen även påminner dig om hur du ångrar ändringar. +Bekvämt nog påminner statuskommandot dig även om hur du ångrar ändringar. Säg att du har ändrat två filer och vill spara dem som två separata incheckningar, men råkar skriva `git add *` och köar båda. Hur tar du bort en av dem från köytan? `git status` påminner dig: @@ -68,7 +68,7 @@ Changes to be committed: ---- Precis under "Changes to be committed" står det att du kan använda `git reset HEAD ...` för att ta bort från köytan. -Låt oss använda det för `CONTRIBUTING.md`: +Vi använder det för `CONTRIBUTING.md`: [source,console] ---- @@ -118,7 +118,7 @@ Changes not staged for commit: ---- Den talar uttryckligen om hur du kastar bort ändringarna. -Låt oss göra det: +Vi gör det: [source,console] ---- @@ -136,7 +136,7 @@ Du kan se att ändringarna nu är borta. [IMPORTANT] ===== -Det är viktigt att förstå att `git checkout -- ` är ett farligt kommando. +`git checkout -- ` är ett farligt kommando. Alla lokala ändringar i filen försvinner – Git ersätter filen med den senast köade eller incheckade versionen. Använd aldrig kommandot om du inte är helt säker på att du inte vill behålla ändringarna. ===== @@ -154,7 +154,7 @@ Git version 2.23.0 introducerade ett nytt kommando: `git restore`. Det är i praktiken ett alternativ till `git reset`, som vi just gick igenom. Från och med Git 2.23.0 använder Git `git restore` i stället för `git reset` för många åtgärder som ångrar ändringar. -Låt oss gå igenom samma exempel, men använda `git restore` i stället för `git reset`. +Vi går igenom samma exempel, men använder `git restore` i stället för `git reset`. ===== Ta bort en köad fil med git restore @@ -177,7 +177,7 @@ Changes to be committed: ---- Precis under "Changes to be committed" står det att du kan använda `git restore --staged ...`. -Låt oss ta bort `CONTRIBUTING.md` från köytan: +Vi tar bort `CONTRIBUTING.md` från köytan: [source,console] ---- @@ -212,7 +212,7 @@ Changes not staged for commit: ---- Den säger att du ska köra `git restore `. -Låt oss göra det: +Vi gör det: [source,console] ---- diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 51996c23..b9de78cc 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -227,7 +227,7 @@ Det här är bara några av de enklare formateringsvalen för `git log` – det ==== Begränsa loggutskriften -Utöver formateringsvalen tar `git log` även ett antal användbara begränsningar – val som låter dig visa ett urval av incheckningar. +Utöver formateringsvalen tar `git log` även flera användbara begränsningar – val som låter dig visa ett urval av incheckningar. Du har redan sett ett sådant, `-2`, som visar de två senaste incheckningarna. Du kan ange `-` för att visa de `n` senaste incheckningarna. I praktiken använder du det inte så ofta eftersom Git normalt skickar utskriften till en paginerare så att du bara ser en sida i taget. 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 2da8c050..e183c888 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -1,6 +1,6 @@ === 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. +Vi går igenom ett enkelt exempel på gren- och sammanfogningsarbete i ett arbetsflöde som är vanligt i verkligheten. Du kommer att följa dessa steg: . Gör lite arbete på en webbplats. @@ -72,11 +72,11 @@ Switched to branch 'master' ---- Nu ser arbetskatalogen ut exakt som den gjorde innan du började jobba på ärende #53, och du kan fokusera på snabbkorrigeringen. -Det är viktigt att komma ihåg: när du byter gren återställer Git arbetskatalogen till hur den såg ut senast du checkade in på den grenen. +Kom ihåg: när du byter gren återställer Git arbetskatalogen till hur den såg ut senast du checkade in på den grenen. Git lägger till, tar bort och ändrar filer automatiskt så att arbetskopian motsvarar grenen vid senaste incheckningen. Nu ska du göra en snabbkorrigering. -Låt oss skapa en `hotfix`-gren att arbeta i tills den är klar: +Vi skapar en `hotfix`-gren att arbeta i tills den är klar: [source,console] ---- diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 0a44f40a..31e818f5 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -91,7 +91,7 @@ Du ser att `master` och `testing` pekar på samma incheckning `f30ab`. (((branches, switching))) För att byta till en befintlig gren kör du `git checkout`.(((git commands, checkout))) -Låt oss byta till den nya grenen `testing`: +Vi byter till den nya grenen `testing`: [source,console] ---- @@ -104,7 +104,7 @@ Det flyttar `HEAD` så att den pekar på `testing`. image::images/head-to-testing.png[HEAD pekar på aktuell gren] Vad betyder det? -Låt oss göra en incheckning: +Vi gör en incheckning: [source,console] ---- @@ -115,8 +115,8 @@ $ git commit -a -m 'Make a change' .HEAD-grenen flyttas fram när du checkar in image::images/advance-testing.png[HEAD-grenen flyttas fram när en incheckning görs] -Det intressanta är att din `testing`-gren har flyttat fram, medan `master` fortfarande pekar på incheckningen du stod på när du bytte gren. -Låt oss byta tillbaka till `master`: +Din `testing`-gren har nu flyttat fram, medan `master` fortfarande pekar på incheckningen du stod på när du bytte gren. +Vi byter tillbaka till `master`: [source,console] ---- @@ -146,12 +146,12 @@ I praktiken spolar det tillbaka arbetet du gjorde i `testing` så att du kan gå [NOTE] .Byta gren ändrar filer i arbetskatalogen ==== -Det är viktigt att veta att när du byter gren i Git ändras filerna i arbetskatalogen. +Tänk på att när du byter gren i Git ändras filerna i arbetskatalogen. Om du byter till en äldre gren återställs arbetskatalogen till hur den såg ut när du senast checkade in på den grenen. Om Git inte kan göra detta utan konflikter får du inte byta gren. ==== -Låt oss göra några ändringar och checka in igen: +Vi gör några ändringar och checkar in igen: [source,console] ---- @@ -190,7 +190,7 @@ Det kan ta sekunder eller minuter beroende på projektets storlek, medan Git all Eftersom vi lagrar föräldrarna till varje incheckning hittar Git automatiskt en lämplig bas för sammanslagningar, vilket gör dem enkla att genomföra. Detta uppmuntrar utvecklare att skapa och använda grenar ofta. -Låt oss se varför. +Vi ser varför. [NOTE] .Skapa och byta gren samtidigt diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 5c74e8b1..c07ab284 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -147,7 +147,7 @@ Om inte kommer folk bli irriterade och du får höra det. När du flyttar om saker överger du befintliga incheckningar och skapar nya som är lika men ändå annorlunda. Om du skickar upp incheckningar, andra uppdaterar dem och baserar arbete på dem, och du sedan skriver om historiken med `git rebase` och skickar upp igen, måste dina medarbetare sammanfoga sitt arbete på nytt och det blir stökigt när du ska dra in deras ändringar. -Låt oss se ett exempel på hur det kan gå fel när du skriver om arbete du gjort publikt. +Här är ett exempel på hur det kan gå fel när du skriver om arbete du gjort publikt. Anta att du klonar från en central server och gör lite arbete. Historiken ser ut så här: diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index a4e07d4d..d0340a76 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -14,7 +14,7 @@ Fjärrspårade grenar har namnet `/`. Om du till exempel vill se hur `master` i fjärrkodförrådet `origin` såg ut senaste gången du kommunicerade med det, tittar du på `origin/master`. Om du arbetar med en kollega som skickat upp en gren `iss53` kan du ha en egen lokal `iss53`, men grenen på servern representeras av fjärrspårade `origin/iss53`. -Det här kan vara aningen förvirrande, så låt oss visa ett exempel. +Det här kan vara aningen förvirrande, så här är ett exempel. Anta att du har en Git‑server i ditt nätverk på `git.ourcompany.com`. När du klonar från den namnger Git automatiskt fjärrkodförrådet `origin`, hämtar all data, skapar en pekare till var dess `master`-gren ligger och kallar den `origin/master` lokalt. Git ger dig också en lokal `master`-gren som pekar på samma ställe som fjärrkodförrådets `master`, så att du kan arbeta vidare. diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 79212ee7..d3ee3633 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -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. +Kom ihåg att dessa 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/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 210b8e05..89905646 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -67,7 +67,7 @@ $ git init --bare --shared Du ser hur enkelt det är: ta ett kodförråd, skapa en bar version och lägga den på en server som du och dina medarbetare når via SSH. Nu kan ni samarbeta i samma projekt. -Det är viktigt att förstå att det här i praktiken är allt som krävs för att köra en användbar Git-server dit flera personer har åtkomst – lägg till SSH-konton och lägg ett bart kodförråd där alla har läs- och skrivbehörighet. +I praktiken är det här faktiskt allt som krävs för att köra en användbar Git-server dit flera personer har åtkomst – lägg till SSH-konton och lägg ett bart kodförråd där alla har läs- och skrivbehörighet. Klart. I nästa avsnitt går vi igenom mer avancerade uppsättningar. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 408ac543..a61c1b5d 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -37,7 +37,7 @@ image::images/gitlab-menu.png[alt="`Admin area` i GitLab-menyn"] Alla som använder din GitLab-server måste ha ett användarkonto. Användarkonton är ganska enkla och innehåller främst personlig information kopplad till inloggning. -Varje användarkonto har en *namnrymd*, som är en logisk gruppering av projekt som tillhör användaren. +Varje användarkonto har en *namnrymd*, som logiskt samlar de projekt som tillhör användaren. Om användaren +jane+ har ett projekt som heter +project+ är URL:en `http://server/jane/project`. [[gitlab_users]] @@ -92,7 +92,7 @@ Det mesta du anger här är inte permanent och kan ändras senare i inställning 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. +Varje projekt är tillgängligt via HTTPS eller SSH, och båda kan konfigurera ett fjärrkodförråd. URL:erna visas högst upp på projektets startsida. För ett befintligt lokalt kodförråd skapar detta kommando en fjärrreferens som heter `gitlab`: diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 0c31467e..d0114c79 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -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. +Tänk på att detta 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. @@ -90,7 +90,7 @@ För tjänster som GitHub är URL:en du använder för att visa kodförrådet p (((protocols, dumb HTTP))) Om servern inte svarar med Smart HTTP-tjänst försöker Git-klienten falla tillbaka till _Dum HTTP_. Det dumma protokollet förväntar sig att det bara kodförrådet serveras som vanliga filer från webbservern. -Det fina med Dum HTTP är enkelheten i att sätta upp det. +Dum HTTP är enkelt att sätta upp. I praktiken behöver du bara lägga ett bart kodförråd under dokumentroten för din HTTP-server och aktivera en särskild `post-update`-krok, och sedan är du klar (se <>). Därefter kan alla som har åtkomst till webbservern klona kodförrådet. För att ge läsåtkomst över HTTP kan du göra så här: @@ -123,7 +123,7 @@ Det är ovanligt att blanda dem. 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 använda en enda URL för all åtkomst, och att servern bara frågar när autentisering behövs, gör det enkelt 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. Det är dessutom ett snabbt och effektivt protokoll, i nivå med SSH. @@ -139,7 +139,7 @@ Utöver det har andra protokoll få fördelar jämfört med Smart HTTP när det Om du använder HTTP för autentiserad uppsändning kan det ibland vara mer krångligt att ange inloggningsuppgifter än att använda SSH-nycklar. Det finns dock flera verktyg som mellanlagrar uppgifterna, till exempel Nyckelring på macOS och Credential Manager på Windows, vilket brukar göra det smidigt. -Läs <> för hur du sätter upp säker mellanlagring av HTTP‑lösenord. +Läs <> för hur du säkert mellanlagrar HTTP‑lösenord. ==== SSH-protokollet @@ -197,7 +197,7 @@ Det använder samma dataöverföring som SSH men utan påslag från kryptering o ===== Nackdelarna -På grund av avsaknaden av TLS eller annan kryptering kan kloning över `git://` leda till godtycklig kodkörning och bör undvikas om du inte vet exakt vad du gör. +Eftersom TLS och annan kryptering saknas kan kloning över `git://` leda till godtycklig kodkörning och bör undvikas om du inte vet exakt vad du gör. * Om du kör `git clone git://example.com/project.git` kan en angripare som kontrollerar till exempel din router ändra kodförrådet du klonar och stoppa in skadlig kod. Om du sedan kompilerar eller kör koden kommer du att köra den skadliga koden. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index a59bcb28..725bb4d5 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -1,7 +1,7 @@ [[_setting_up_server]] === Konfigurera servern -Låt oss gå igenom hur du sätter upp SSH‑åtkomst på serversidan. +Vi går igenom hur du sätter upp SSH‑åtkomst på serversidan. I exemplet använder du metoden `authorized_keys` för att autentisera användare. Vi antar också att du kör en vanlig Linuxdistribution, till exempel Ubuntu. @@ -58,7 +58,7 @@ Initialized empty Git repository in /srv/git/project.git/ Därefter kan John, Josie eller Jessica skicka den första versionen av projektet genom att lägga till kodförrådet som fjärrkodförråd och skicka en gren. 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. +Vi använder `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): [source,console] diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 7878a883..dad522e7 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -6,7 +6,7 @@ Att sätta upp Smart HTTP handlar i praktiken om att aktivera CGI-skriptet `git- CGI:t läser sökväg och huvudrader som skickas av `git fetch` eller `git push` till en HTTP-URL och avgör om klienten kan prata HTTP (vilket alla klienter kan sedan 1.6.6). Om CGI:t ser att klienten är smart kommunicerar den smart, annars faller den tillbaka till det dumma läget (så att äldre klienter fortfarande kan läsa). -Låt oss gå igenom en enkel uppsättning. +Vi går igenom en enkel uppsättning. Vi använder Apache som CGI-server. Om du inte har Apache kan du installera det på en Linuxmaskin med något i stil med:(((Apache))) @@ -62,9 +62,9 @@ Det här är bara det enklaste exemplet. Du kommer också nästan säkert vilja köra allt över SSL så att data krypteras. Vi går inte djupare i Apachekonfiguration, eftersom du kan använda en annan server eller ha andra autentiseringsbehov. -Poängen är att Git levererar CGI:t `git-http-backend`, som när det anropas sköter hela förhandlingen för att skicka och ta emot data över HTTP. +Git levererar CGI:t `git-http-backend`, som när det anropas sköter hela förhandlingen för att skicka och ta emot data över HTTP. Det implementerar inte autentisering i sig, men det styrs enkelt i webbserverlagret som anropar det. -Det fungerar med nästan vilken CGI-kapabel webserver som helst, så använd den du är mest bekväm med. +Det fungerar med nästan vilken CGI-kapabel webserver som helst, så använd den du är mest van vid. [NOTE] ==== diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index e4beba2a..d52c458f 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -4,14 +4,14 @@ (((contributing))) Det svåra med att beskriva hur du gör för att bidra till ett projekt är att medverkan kan ske på mängder av olika sätt. Tack vare Gits flexibilitet skiljer sig användningen åt, vilket gör det näst intill omöjligt att säga hur du borde göra – varje projekt arbetar på sitt sätt. -Faktorer som påverkar hur ett projekt är organiserat är antalet aktivt involverade, överenskomna arbetsprocesser och fördelningen av behörigheter för att checka in kod. -Det finns dock några generella riktlinjer som kan hjälpa dig att komma igång. +Faktorer som påverkar hur ett projekt är organiserat är antalet aktiva deltagare, överenskomna arbetsprocesser och hur behörigheterna för att checka in kod är fördelade. +Det finns dock några allmänna riktlinjer som kan hjälpa dig att komma igång. -För det första – hur många involverade bidrar aktivt med källkod och hur ofta? +För det första – hur många deltagare bidrar aktivt med källkod och hur ofta? I mindre projekt är det vanligt att ett par, tre utvecklare gör några få incheckningar om dagen, kanske ännu färre om projektet är vilande. I större projekt, eller organisationer för den delen, kan hundratals utvecklare arbeta aktivt med kodbasen och bidra med tusentals incheckningar varje dag. -Det är viktigt att känna till ungefär hur många som arbetar aktivt i kodbasen. +Du bör känna till ungefär hur många som arbetar aktivt i kodbasen. Ju fler utvecklare, desto fler problem kan du stöta på för att få din kod att läggas till och integreras smidigt. Under tiden du arbetar med dina ändringar, eller väntar på att få dem godkända, kan ny kod göra dem icke-funktionella – eller rentav inaktuella. Hur kan du då göra för att din egen kodbas ska hållas uppdaterad och dina incheckningar aktuella? @@ -20,7 +20,7 @@ För det andra, hur ser projektets beslutade arbetsprocess ut? Är det en centraliserad process, så att varje utvecklare har samma skrivrättigheter till koden på huvudgrenen? Har projektet en förvaltare eller integrationsansvarig som granskar alla ändringar? Ska alla ändringar granskas och godkännas av en annan utvecklare? -Kommer du att vara involverad i den processen? +Kommer du att delta i den processen? Eller finns det ett kvalitetssystem med testare på plats som du behöver skicka dina ändringar till först? Till sist spelar behörigheter för incheckningar in. @@ -63,7 +63,7 @@ Med det tillvägagångssättet blir det också enklare att dra ut eller återst 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. 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. +Med vanan att alltid skriva bra meddelanden blir det betydligt enklare att använda Git och samarbeta. Tumregeln är att dina meddelanden ska börja med en mening på max 50 tecken som sammanfattar ändringen, följt av en blank rad och en mer detaljerad beskrivning. Git‑projektet menar att beskrivningen bör inkludera anledningen till ändringen och en jämförelse med tidigare beteende – det är en bra riktlinje att följa. Det är också bra att skriva i imperativ form. @@ -295,9 +295,9 @@ Det här är en av de enklaste arbetsprocesserna. Du arbetar ett tag (ofta i en funktionsgren) och sammanfogar arbetet i huvudgrenen när det är klart. När du vill dela ditt arbete uppdaterar du och sammanfogar din huvudgren med `origin/master` och skickar tillbaka din huvudgren till servern. -Den generella arbetsprocessen ser ut så här: +Den allmänna arbetsprocessen ser ut så här: -.Generell arbetsprocess med Git för flera utvecklare +.Allmän arbetsprocess med Git för flera utvecklare image::images/small-team-flow.png[Generell arbetsprocess med Git för flera utvecklare.] ==== Privat större team @@ -442,8 +442,8 @@ Historiken ser då ut så här: .Jessicas historik efter sammanslagning av ämnesgrenar med huvudgren image::images/managed-team-3.png[Jessicas historik efter sammanslagning av ämnesgrenar med huvudgren.] -Många byter till Git på grund av möjligheten för flera team att arbeta parallellt och kombinera sina grenar sent i processen. -Möjligheten att mindre grupper inom ett team kan samarbeta via fjärrgrenar utan att involvera hela teamet är en av Gits stora fördelar. +Många byter till Git eftersom flera team kan arbeta parallellt och kombinera sina grenar sent i processen. +Att mindre grupper inom ett team kan samarbeta via fjärrgrenar utan att blanda in hela teamet är en av Gits stora fördelar. Arbetsprocessen som precis beskrivits ser ut ungefär så här: .Grundläggande arbetsprocess för flera team @@ -459,7 +459,7 @@ I det första exemplet tittar vi på hur man avgrenar ett kodförråd på värdt Många värdtjänster har stöd för avgreningar (till exempel GitHub, BitBucket, repo.or.cz) och många projektansvariga förväntar sig att andra medverkar på det sättet. Det andra exemplet beskriver arbetsprocessen i projekt som i stället föredrar att ta emot ändringspatchar via e-post. -Det första du behöver göra är troligen att klona grundkodförrådet och skapa en funktionsgren för ändringspatcharna du planerar att bidra med. +Börja troligen med att klona grundkodförrådet och skapa en funktionsgren för ändringspatcharna du planerar att bidra med. Flödet ser ut så här: [source,console] @@ -563,7 +563,7 @@ Eftersom du flyttade grenen behöver du ange `-f` så att du kan ersätta server Ett alternativ är att skicka det nya arbetet till en annan gren på servern (till exempel `featureAv2`). 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 flyttar då avgreningens bas från `featureA` till huvudgrenen. Du kan göra detta genom att skapa en ny gren från `origin/master`, sammanfoga `featureB` där, lösa konflikter, göra justeringen och skicka det som en ny gren: @@ -578,7 +578,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. +Det innebär att dina framtida incheckningar bara kommer att ha en förälder och låter dig dra in alla ändringar från en annan gren och göra fler ändringar innan den nya incheckningen skapas. Ibland kan det vara användbart att använda `--no-commit` för att fördröja incheckningen vid en sammanslagning. När detta är klart kan du meddela förvaltaren att ändringarna finns i `featureBv2`. @@ -658,7 +658,7 @@ Det är en bra plats att förklara varför du gjort ändringarna eller ge testin För att skicka ändringspatchfilen till e-postlistan kan du antingen klistra in innehållet i ditt e-postprogram eller skicka det via kommandoraden. Att klistra in texten orsakar ofta formateringsproblem, särskilt med "smartare" klienter som inte bevarar radbrytningar och mellanslag korrekt. Som tur är har Git ett verktyg som hjälper dig att skicka korrekt formaterade ändringspatchar via IMAP. -Vi visar hur du skickar en ändringspatch via Gmail, som råkar vara den klient vi känner bäst. +Vi visar hur du skickar en ändringspatch via Gmail, som är den klient vi känner bäst. Du kan läsa detaljerade instruktioner för många e‑postklienter i slutet av filen `Documentation/SubmittingPatches` i Gits källkod. (((git commands, config)))(((email))) diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index fe244b06..d0462043 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -5,7 +5,7 @@ Till skillnad från centraliserade versionshanteringssystem (CVCS) ger Gits dist I centraliserade system är varje utvecklare en nod som arbetar mer eller mindre likadant mot ett nav. I Git kan varje utvecklare däremot vara både nod och nav; varje utvecklare kan både bidra med kod till andra kodförråd och själv förvalta ett öppet kodförråd som andra kan bygga vidare på. Det öppnar för en mängd olika sätt att organisera samarbetet i ditt projekt och/eller team. -Vi går igenom några vanliga mönster som utnyttjar den här flexibiliteten. +Vi går igenom några vanliga mönster som nyttjar den här flexibiliteten. Vi tar upp styrkor och möjliga svagheter i varje arbetssätt; du kan välja ett eller blanda delar. ==== Centraliserat arbetsflöde @@ -22,7 +22,7 @@ Det betyder att om två utvecklare klonar navet och båda gör ändringar kan de Den andra måste sammanfoga den förstas arbete innan hen skickar upp, för att inte skriva över ändringarna. Samma sak gäller i Git som i Subversion(((Subversion))) (och andra CVCS), och modellen fungerar väl i Git. -Om du redan är bekväm med ett centraliserat arbetsflöde i en organisation eller ett team kan du enkelt fortsätta med det i Git. +Om du redan är van vid ett centraliserat arbetsflöde i en organisation eller ett team kan du enkelt fortsätta med det i Git. Sätt bara upp ett enda kodförråd och ge alla rätt att skicka; Git låter inte användare skriva över varandra. Säg att John och Jessica börjar arbeta samtidigt. @@ -82,7 +82,7 @@ Flödet ser ut så här (se <>): image::images/benevolent-dictator.png[Den välvillige diktatorns arbetsflöde] Det här arbetsflödet är inte vanligt, men kan vara värdefullt i mycket stora projekt eller hierarkiska miljöer. -Det gör det möjligt för projektledaren (diktatorn) att delegera mycket av arbetet och samla stora kodändringsuppsättningar innan de integreras. +Projektledaren (diktatorn) kan därmed delegera mycket av arbetet och samla stora kodändringsuppsättningar innan de integreras. [[_patterns_for_managing_source_code_branches]] ==== Mönster för att hantera källkod med grenar diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 657cce05..2230d94b 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -3,14 +3,14 @@ (((maintaining a project))) Förutom att veta hur du bidrar effektivt till ett projekt behöver du troligen också veta hur man förvaltar ett. Det kan innebära att acceptera och tillämpa ändringspatchar som genererats via `format-patch` och skickats till dig via e-post, eller att integrera ändringar i fjärrgrenar. -Oavsett om du förvaltar ett huvudkodförråd eller vill hjälpa till med att granska och godkänna bidrag behöver du veta hur du tar emot arbete på ett sätt som är tydligt för andra och hållbart för dig på sikt. +Oavsett om du förvaltar ett huvudkodförråd eller vill hjälpa till med att granska och godkänna bidrag behöver du veta hur du tar emot arbete så att det blir tydligt för andra och hållbart för dig på sikt. ==== Arbeta i ämnesgrenar (((branches, topic))) -När du ska integrera nytt arbete är det i regel en bra idé att prova det i en _ämnesgren_ – en tillfällig gren som skapats för att testa det nya arbetet. +När du ska integrera nytt arbete brukar det vara bäst att prova det i en _ämnesgren_ – en tillfällig gren som skapats för att testa det nya arbetet. Det gör det enkelt att justera en ändringspatch och lämna det om det inte fungerar, tills du har tid att återvända. -Om du skapar ett enkelt grennamn baserat på temat, till exempel `ruby_client`, är det lätt att hitta tillbaka senare. +Om du skapar ett enkelt grennamn utifrån temat, till exempel `ruby_client`, är det lätt att hitta tillbaka senare. Förvaltarna av Git använder ofta en namnrymd också, till exempel `sc/ruby_client`, där `sc` är initialerna för den som bidrog. Som du minns kan du skapa grenen från `master` så här: @@ -186,7 +186,7 @@ När alla ändringspatchar har lagts till och checkats in i din gren behöver du ==== Checka ut fjärrgrenar (((branches, remote))) -Om ett bidrag kommer från en Git‑användare som har växlat till sin egen gren, skickat ett antal ändringar till den och sedan skickat URL:en till sitt kodförråd och namnet på grenen kan du lägga till det som fjärrkodförråd och växla till den lokalt. +Om ett bidrag kommer från en Git‑användare som har växlat till sin egen gren, skickat flera ändringar till den och sedan skickat URL:en till sitt kodförråd och namnet på grenen kan du lägga till det som fjärrkodförråd och växla till den lokalt. Om Jessica till exempel skickar ett e-postmeddelande och skriver att hon har en bra funktion i `ruby-client`-grenen i sitt kodförråd, kan du testa den genom att lägga till hennes kodförråd som fjärrkodförråd och växla till grenen lokalt: @@ -347,7 +347,7 @@ När den grenen är stabil och testerna går igenom sammanfogar du den i `develo (((workflows, "merging (large)"))) Git‑projektet har fyra långlivade grenar: `master`, `next` och `pu` (föreslagna uppdateringar) för nytt arbete, och `maint` för underhållsbackportar. När nytt arbete introduceras samlas det i ämnesgrenar i förvaltarens kodförråd, likt det vi beskrev (se <>). -Vid det här laget utvärderas ämnena för att avgöra om de är säkra och redo eller om de behöver mer arbete. +Här utvärderas ämnena för att avgöra om de är säkra och redo eller om de behöver mer arbete. Om de är säkra sammanfogas de i `next`, och den grenen skickas upp så att alla kan prova ämnena tillsammans. [[merwf_f]] @@ -445,7 +445,7 @@ user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 ---- -Om du signerar taggar kan du få problem med att distribuera den publika PGP-nyckeln som används för att signera taggarna. +Om du signerar taggar kan du få problem med att distribuera den publika PGP-nyckeln du signerar taggarna med. 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`: @@ -503,9 +503,9 @@ På det här sättet får du en sträng som är meningsfull för människor att Om du bygger Git från källkoden klonad från Git‑kodförrådet ger `git --version` dig något som ser ut så här. Om du beskriver en incheckning som du direkt har taggat ger det dig bara taggnamnet. -`git describe` kräver annoterade taggar som standard (taggar som skapats med `-a` eller `-s`); om du vill dra nytta av lättviktiga taggar också lägger du till `--tags`. +`git describe` kräver annoterade taggar som standard (taggar som skapats med `-a` eller `-s`); om du även vill använda lättviktiga taggar lägger du till `--tags`. Du kan också använda strängen som mål för `git checkout` eller `git show`, även om det förlitar sig på det förkortade SHA-1-värdet i slutet, vilket kanske inte är giltigt för alltid. -Till exempel hoppade Linux-kärnan nyligen från 8 till 10 tecken för att säkerställa SHA-1-objektens unicitet, så äldre `git describe`-utdata ogiltigförklarades. +Till exempel hoppade Linux-kärnan nyligen från 8 till 10 tecken för att säkerställa att SHA‑1‑objekten förblir unika, så äldre `git describe`-utdata ogiltigförklarades. [[_preparing_release]] ==== Förbereda en utgåva diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 7a29708c..dba822c9 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,7 +1,7 @@ === Kontoinställning och konfiguration (((GitHub, user accounts))) -Det första du behöver göra är att skapa ett gratis användarkonto. +Börja med att skapa ett gratis användarkonto. Gå till https://github.com[^], välj ett användarnamn som inte redan är taget, fyll i en e‑postadress och ett lösenord och klicka på den stora gröna knappen "Sign up for GitHub". .GitHubs registreringsformulär diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index cb94b24e..ef1f19df 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -64,7 +64,7 @@ image::images/blink-01-start.png[Projektet vi vill bidra till] Det enda problemet är att blinktakten är för hög. Vi tycker att det är trevligare att vänta 3 sekunder i stället för 1 mellan varje lägesändring. -Låt oss förbättra programmet och skicka tillbaka det till projektet som en föreslagen ändring. +Vi förbättrar programmet och skickar tillbaka det till projektet som en föreslagen ändring. Först klickar vi på knappen för att avgrena som nämndes tidigare för att få en egen kopia av projektet. Vårt användarnamn här är "tonychacon", så vår kopia av projektet finns på `https://github.com/tonychacon/blink` och det är där vi kan redigera den. @@ -209,7 +209,7 @@ Nu när vi har gått igenom grunderna i att bidra till ett projekt på GitHub ti ===== Ändringsförfrågningar som ändringspatchar -Det är viktigt att förstå att många projekt inte riktigt ser ändringsförfrågningar som köer av perfekta ändringspatchar som ska appliceras rent i ordning, såsom de flesta e-postlistebaserade projekt ser bidrag i form av ändringspatchserier. +Många projekt ser inte ändringsförfrågningar som köer av perfekta ändringspatchar som ska appliceras rent i ordning, såsom de flesta e-postlistebaserade projekt ser bidrag i form av ändringspatchserier. De flesta GitHub-projekt ser ämnesgrenar för ändringsförfrågningar som iterativa samtal kring en föreslagen ändring, som mynnar ut i en sammanfogad diff som appliceras genom sammanslagning. Det här är en viktig skillnad, eftersom ändringar ofta föreslås innan koden är helt färdig, vilket är betydligt ovanligare i e-postlistebaserade patchserier. @@ -241,7 +241,7 @@ Det som spelar roll är historiken och den slutliga sammanslagningen, så ombase Om du vill sammanfoga målgrenen för att göra ändringsförfrågan sammanslagningsbar lägger du till ursprungskodförrådet som ett nytt fjärrkodförråd, uppdaterar därifrån, sammanfogar huvudgrenen från det kodförrådet in i din ämnesgren, löser eventuella problem och skickar sedan upp tillbaka till samma gren som ändringsförfrågan pekar på. Till exempel, säg att vi i "tonychacon"-exemplet från tidigare använder, gjorde ursprungsförfattaren en ändring som skapade en konflikt i ändringsförfrågan. -Låt oss gå igenom stegen. +Vi går igenom stegen. [source,console] ---- @@ -298,7 +298,7 @@ Skicka i stället upp den ombaserade grenen till en ny gren på GitHub och öppn ===== Referenser Din nästa fråga kan vara "Hur refererar jag den gamla ändringsförfrågan?". -Det visar sig att det finns många sätt att referera till andra saker nästan överallt där du kan skriva i GitHub. +Det finns faktiskt många sätt att referera till andra saker nästan överallt där du kan skriva i GitHub. Vi börjar med hur du korsrefererar en annan ändringsförfrågan eller ett ärende. Alla ändringsförfrågningar och ärenden får nummer och de är unika inom projektet. @@ -306,7 +306,7 @@ Du kan till exempel inte ha ändringsförfrågan +#3+ _och_ ärende +#3+. Om du vill referera till en ändringsförfrågan eller ett ärende från en annan kan du helt enkelt skriva `+#+` i en kommentar eller beskrivning. Du kan också vara mer specifik om ärendet eller ändringsförfrågan ligger någon annanstans: skriv `användare#` om du refererar till ett ärende eller en ändringsförfrågan i en avgrening av kodförrådet du är i, eller `användare/kodförråd#` för att referera till något i ett annat kodförråd. -Låt oss titta på ett exempel. +Här är ett exempel. Säg att vi ombaserade grenen i det föregående exemplet, skapade en ny ändringsförfrågan för den, och nu vill vi referera till den gamla ändringsförfrågan från den nya. Vi vill också referera till ett ärende i avgreningen av kodförrådet och ett ärende i ett helt annat projekt. Vi kan fylla i beskrivningen som i <<_pr_references>>. @@ -413,7 +413,7 @@ image::images/markdown-04-fenced-code.png[Visat 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. +Detta är faktiskt så vanligt och användbart att det finns ett 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: diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 33357d5d..9e6fb296 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -1,11 +1,11 @@ [[_maintaining_gh_project]] === Förvalta ett projekt -Nu när vi är bekväma med att bidra till ett projekt tittar vi på den andra sidan: skapa, förvalta och administrera ditt eget projekt. +Nu när vi är vana vid att bidra till ett projekt tittar vi på den andra sidan: skapa, förvalta och administrera ditt eget projekt. ==== Skapa ett nytt kodförråd -Låt oss skapa ett nytt kodförråd för att dela vår projektkod. +Vi skapar ett nytt kodförråd för att dela vår projektkod. Börja med att klicka på knappen "Nytt kodförråd" på högersidan av översikten, eller på `+`-knappen i den övre verktygsraden bredvid ditt användarnamn som i <<_new_repo_dropdown>>. .Området "Dina kodförråd" @@ -178,7 +178,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. +Det är ett sätt att koppla namn på fjärrkodförrådet till namn i din lokala `.git`-katalog. Den här berättar för Git att "det som ligger i fjärrkodförrådet under `refs/heads` ska hamna i mitt lokala kodförråd under `refs/remotes/origin`". Du kan ändra detta avsnitt för att lägga till ytterligare en referensspecifikation: @@ -221,7 +221,7 @@ Det gör att du kan testa sammanslagningen innan du ens trycker på knappen. ===== Ändringsförfrågningar på ändringsförfrågningar Du kan inte bara öppna ändringsförfrågningar som riktar sig mot huvudgrenen eller `master`-grenen, du kan öppna en ändringsförfrågan mot vilken gren som helst i nätverket. -Faktum är att du till och med kan rikta mot en annan ändringsförfrågan. +Du kan till och med rikta mot en annan ändringsförfrågan. Om du ser en ändringsförfrågan som rör sig i rätt riktning och du har en idé om en ändring som beror på den, eller om du inte är säker på att idén är bra, eller om du helt enkelt inte har skrivrättigheter till målgrenen, kan du öppna en ändringsförfrågan direkt mot den. @@ -307,7 +307,7 @@ List-Unsubscribe: ,... X-GitHub-Recipient-Address: tchacon@example.com ---- -Det finns ett par intressanta saker här. +Några saker är värda att lägga märke till. Om du vill markera eller omdirigera e-post för just det här projektet eller till och med en ändringsförfrågan ger informationen i `Message-ID` dig allt i formatet `///`. Om det till exempel var ett ärende skulle fältet `` ha varit "issues" i stället för "pull". @@ -318,7 +318,7 @@ Värt att veta är också att om du har både e-post- och webbaviseringar aktive ==== Särskilda filer -Det finns ett par särskilda filer som GitHub lägger märke till om de finns i ditt kodförråd. +GitHub lägger märke till några särskilda filer om de finns i ditt kodförråd. ==== README diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 74623f8c..5c7927e8 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -31,7 +31,7 @@ Nu går vi igenom några saker som skiljer sig med ett organisationskonto. ==== Team -Organisationer kopplas till enskilda personer via team, som helt enkelt är en gruppering av individuella användarkonton och kodförråd inom organisationen samt vilken åtkomst de har i kodförråden. +Organisationer kopplas till enskilda personer via team, som helt enkelt grupperar användarkonton och kodförråd inom organisationen och anger vilken åtkomst de har. 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`. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 7d7c1d4f..111f35cb 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -36,7 +36,7 @@ Om du till exempel använder Jenkins för att köra tester på din kodbas kan du ===== Krokar -Om du behöver något mer specifikt eller vill integrera med en tjänst eller webbplats som inte finns i listan kan du i stället använda det mer generella krok-systemet. +Om du behöver något mer specifikt eller vill integrera med en tjänst eller webbplats som inte finns i listan kan du i stället använda det mer allmänna krok-systemet. GitHubs kodförrådskrokar är ganska enkla. Du anger en URL och GitHub skickar en HTTP-last till den URL:en för vilken händelse du vill. @@ -53,7 +53,7 @@ Konfigurationen för en webbkrok är ganska enkel. I de flesta fall anger du bara en URL och en hemlig nyckel och trycker på "Lägg till webbkrok". Det finns några val för vilka händelser du vill att GitHub ska skicka en last för -- standard är att bara få en last för `push`-händelsen, när någon skickar upp ny kod till valfri gren i kodförrådet. -Låt oss se ett litet exempel på en webbtjänst som du kan sätta upp för att hantera en webbkrok. +Här är ett litet exempel på en webbtjänst som du kan sätta upp för att hantera en webbkrok. 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. @@ -115,7 +115,7 @@ För mer information om hur du skriver webbkrokar och alla olika händelsetyper 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? 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. +Här kommer GitHub-API:t till nytta. GitHub har massor av API-ändpunkter för att göra nästan allt du kan göra på webbplatsen på ett automatiserat sätt. I avsnittet lär vi oss hur vi autentiserar och ansluter till API:t, hur vi kommenterar ett ärende och hur vi ändrar status för en ändringsförfrågan via API:t. @@ -188,7 +188,7 @@ Detta har också fördelen att öka din gräns för förfrågningar. Utan autentisering är du begränsad till 60 förfrågningar per timme. Om du autentiserar dig kan du göra upp till 5 000 förfrågningar per timme. -Låt oss använda den för att lämna en kommentar i ett av våra ärenden. +Vi använder den för att lämna en kommentar i ett av våra ärenden. Säg att vi vill lämna en kommentar i ärende #6. För att göra det måste vi göra en HTTP POST-begäran till `repos///issues//comments` med tokenen vi just skapade som en Authorization-header. @@ -279,7 +279,7 @@ 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. 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 rapportera status och en valideringstjänst som denna kan också rapportera 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>>. @@ -293,7 +293,7 @@ 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. +Ä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 naturligt 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. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index dd4a094d..b006f734 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -21,7 +21,7 @@ Om du har arbete på gång, checka in det i en tillfällig gren eller lägg unda 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. -Låt oss gå igenom ett mycket enkelt exempel. +Vi går igenom ett mycket enkelt exempel. Vi har en superenkel Ruby‑fil som skriver ut strängen `hello world`. [source,ruby] @@ -137,7 +137,7 @@ 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. -Standardstrategin för sammanslagning kan ta argument, och några av dem handlar om att ignorera blankteckensändringar korrekt. +Standardsammanslagningsstrategin 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`. Det första alternativet ignorerar blanktecken *helt* när rader jämförs, det andra behandlar sekvenser av ett eller flera blanktecken som likvärdiga. @@ -155,9 +155,9 @@ Eftersom filändringarna i det här fallet inte var i konflikt sammanfogas allt Det här är en räddare i nöden om du har någon i teamet som ibland gillar att omformatera allt från mellanslag till tabbar eller tvärtom. [[_manual_remerge]] -===== Manuell omsammanfogning av filer +===== Sammanfoga filer manuellt -Även om Git hanterar förbehandling av blanktecken ganska bra finns det andra typer av ändringar som Git kanske inte kan hantera automatiskt, men som går att fixa med skript. +Även om Git förbehandlar blanktecken ganska bra finns det andra typer av ändringar som Git kanske inte kan hantera automatiskt, men som går att fixa med skript. Som exempel låtsas vi att Git inte kunde hantera blankteckensändringen och att vi behövde göra det för hand. Det vi egentligen behöver göra är att köra filen vi försöker sammanfoga genom ett `dos2unix`‑program innan vi försöker sammanfoga filen på riktigt. @@ -219,12 +219,12 @@ index 36c06c8,e85207e..0000000 hello() ---- -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 verkligen åtgärdar blankteckensändringarna före sammanslagning i stället för att bara ignorera dem. +Nu har vi snyggt sammanfogat filen. +Det här fungerar i själva verket bättre än alternativet `ignore-space-change` eftersom det verkligen åtgärdar blankteckensändringarna före sammanslagning i stället för att bara ignorera dem. I sammanslagningen med `ignore-space-change` hamnade vi med några rader med DOS‑radslut, vilket gav en blandning. Om du vill få en uppfattning innan du slutför den här incheckningen om vad som egentligen ändrades mellan den ena sidan och den andra kan du be `git diff` jämföra det som ligger i din arbetskatalog och som du är på väg att checka in som resultat av sammanslagningen med något av dessa steg. -Låt oss gå igenom dem allihop. +Vi går 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`: @@ -291,7 +291,7 @@ index ac51efd..44d0a25 100755 hello() ---- -Vid det här laget kan vi använda kommandot `git clean` för att städa bort de extra filer vi skapade för den manuella sammanslagningen men inte längre behöver. +Nu kan vi använda kommandot `git clean` för att städa bort de extra filer vi skapade för den manuella sammanslagningen men inte längre behöver. [source,console] ---- @@ -304,9 +304,9 @@ Removing hello.theirs.rb [[_checking_out_conflicts]] ===== Checka ut konflikter -Kanske är vi inte nöjda med lösningen av någon anledning, eller så fungerade inte manuell redigering av ena eller båda sidor så bra och vi behöver mer kontext. +Kanske är vi inte nöjda med lösningen av någon anledning, eller så fungerade det inte att redigera ena eller båda sidor manuellt och vi behöver mer kontext. -Låt oss ändra exemplet lite. +Vi ändrar exemplet lite. I exemplet har vi två långlivade grenar som båda har några incheckningar i sig men skapar en legitim innehållskonflikt vid sammanslagning. [source,console] @@ -353,13 +353,13 @@ hello() Båda sidorna av sammanslagningen lade till innehåll i filen, men några av incheckningarna ändrade filen på samma ställe, vilket orsakade konflikten. -Låt oss undersöka ett par verktyg som du nu har tillgång till för att avgöra hur konflikten uppstod. +Vi undersöker ett par verktyg som du nu har tillgång till för att avgöra hur konflikten uppstod. Kanske är det inte självklart hur du ska fixa den. Du behöver mer kontext. Ett hjälpsamt verktyg är `git checkout` med flaggan `--conflict`. Det kommer att lägga ut filen igen och ersätta konfliktmarkörerna. -Det kan vara användbart om du vill återställa markörerna och försöka lösa dem igen. +Användbart om du vill återställa markörerna och försöka lösa dem igen. Du kan skicka `--conflict` antingen `diff3` eller `merge` (som är standard). Om du skickar `diff3` använder Git en något annorlunda variant av konfliktmarkörer, som inte bara ger dig "`ours`" och "`theirs`" utan också "`base`"‑versionen infogad för att ge mer kontext. @@ -397,7 +397,7 @@ $ git config --global merge.conflictstyle diff3 Kommandot `git checkout` kan också ta flaggorna `--ours` och `--theirs`, vilket kan vara ett riktigt snabbt sätt att bara välja ena sidan eller den andra utan att sammanfoga alls. -Det kan vara särskilt användbart för konflikter i binärfiler där du helt enkelt väljer ena sidan, eller när du bara vill sammanfoga vissa filer från en annan gren -- då kan du göra sammanslagningen och sedan lägga ut vissa filer från ena sidan eller den andra innan du checkar in. +Särskilt användbart för konflikter i binärfiler där du helt enkelt väljer ena sidan, eller när du bara vill sammanfoga vissa filer från en annan gren -- då kan du göra sammanslagningen och sedan lägga ut vissa filer från ena sidan eller den andra innan du checkar in. [[_merge_log]] ===== Sammanslagningslogg @@ -432,12 +432,12 @@ $ git log --oneline --left-right --merge ---- Om du kör det med flaggan `-p` i stället får du bara diffarna till filen som hamnade i konflikt. -Det kan vara *mycket* hjälpsamt för att snabbt ge dig den kontext du behöver för att förstå varför något kolliderar och hur du kan lösa det smartare. +Så får du snabbt den kontext du behöver för att förstå varför något kolliderar och hur du kan lösa det smartare. ===== Sammanfogat diff‑format Eftersom Git köar alla sammanslagningsresultat som är lyckade kommer `git diff` i ett sammanslagningsläge med konflikter bara visa det som fortfarande är i konflikt. -Det kan vara hjälpsamt för att se vad du fortfarande måste lösa. +Så ser du vad du fortfarande måste lösa. När du kör `git diff` direkt efter en sammanslagningskonflikt får du information i ett ganska unikt diff‑format. @@ -532,7 +532,7 @@ Nu när du vet hur du skapar en sammanslagningsincheckning kommer du förmodlige En av de fina sakerna med att arbeta i Git är att det är okej att göra misstag, eftersom det är möjligt (och i många fall enkelt) att rätta dem. Sammanslagningsincheckningar är inget undantag. -Låt oss säga att du började arbeta på en ämnesgren, råkade sammanfoga den in i `master`, och nu ser din incheckningshistorik ut så här: +Säg att du började arbeta på en ämnesgren, råkade sammanfoga den in i `master`, och nu ser din incheckningshistorik ut så här: .Oavsiktlig sammanslagningsincheckning image::images/undomerge-start.png[Oavsiktlig sammanslagningsincheckning] @@ -573,7 +573,7 @@ $ git revert -m 1 HEAD Flaggan `-m 1` anger vilken förälder som är "huvudlinjen" och ska behållas. När du sammanfogar in i `HEAD` (`git merge topic`) har den nya incheckningen två föräldrar: den första är `HEAD` (`C6`), och den andra är spetsen på grenen som sammanfogas in (`C4`). -I det här fallet vill vi ångra alla ändringar som introducerades av sammanslagningen av förälder #2 (`C4`), samtidigt som vi behåller allt innehåll från förälder #1 (`C6`). +I det här fallet vill vi ångra alla ändringar som fördes in när förälder #2 (`C4`) sammanfogades, samtidigt som vi behåller allt innehåll från förälder #1 (`C6`). Historiken med återställningsincheckningen ser ut så här: @@ -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: +Lösningen är att ångra att den ursprungliga sammanslagningen återställdes, eftersom du nu vill ta in de ändringar som ångrats, *och sedan* skapa en ny sammanslagningsincheckning: [source,console] ---- @@ -612,9 +612,9 @@ I exemplet tar `M` och `^M` ut varandra. ==== Andra typer av sammanslagningar -Hittills har vi täckt den normala sammanslagningen av två grenar, som normalt hanteras med den rekursiva strategin för sammanslagning. +Hittills har vi täckt hur man normalt sammanfogar två grenar, vilket hanteras med den rekursiva sammanslagningsstrategin. Det finns dock andra sätt att sammanfoga grenar. -Låt oss gå igenom några av dem snabbt. +Vi går igenom några av dem snabbt. ===== Ställa in vår eller deras diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 74764934..3dc03236 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -4,16 +4,16 @@ Även om vi har gått igenom de vanliga sätten att överföra Git‑data över nätverk (HTTP, SSH, osv.) finns det ytterligare ett sätt som inte används så ofta men kan vara riktigt användbart. Git kan "bunta" sin data till en enda fil. -Det kan vara användbart i olika scenarier. +Användbart i olika scenarier. Kanske ligger nätverket nere och du vill skicka ändringar till dina kollegor. Kanske jobbar du på annan ort och har inte åtkomst till det lokala nätverket av säkerhetsskäl. Kanske gick ditt trådlösa nätverkskort eller ethernetkort sönder. Kanske har du för tillfället ingen delad server, du vill skicka någon uppdateringar via e-post och du vill inte skicka 40 incheckningar via `format-patch`. -Det är här kommandot `git bundle` kan vara till hjälp. +Här kan kommandot `git bundle` vara till hjälp. Kommandot `git bundle` buntar ihop allt som normalt skulle skickas över tråden med kommandot `git push` i en binärfil som du kan skicka via e-post till någon eller lägga på ett USB‑minne, och sedan packa upp i ett annat kodförråd. -Låt oss se ett enkelt exempel. +Här är ett enkelt exempel. Säg att du har ett kodförråd med två incheckningar: [source,console] @@ -50,7 +50,7 @@ Om du vill att det ska kunna klonas någon annanstans bör du också lägga till Du kan skicka filen `repo.bundle` via e-post till någon annan eller lägga den på ett USB‑minne och bära över. -På andra sidan, säg att du får filen `repo.bundle` och vill arbeta med projektet. +Hos mottagaren: säg att du får filen `repo.bundle` och vill arbeta med projektet. Du kan klona från den binära filen till en katalog, ungefär som du skulle från en URL. [source,console] @@ -95,7 +95,7 @@ c99cf5b Fourth commit - second repo 7011d3d Third commit - second repo ---- -Så nu när vi har listan över incheckningar vi vill inkludera i bunten, låt oss bunta dem. +Nu när vi har listan över incheckningar vi vill inkludera i bunten buntar vi dem. Vi gör det med kommandot `git bundle create`, där vi anger filnamnet vi vill att bunten ska ha och intervallet av incheckningar vi vill stoppa in. [source,console] @@ -144,7 +144,7 @@ $ git bundle list-heads ../commits.bundle ---- Underkommandot `verify` talar också om huvudena. -Poängen är att se vad som kan dras in, så du kan använda kommandona `fetch` eller `pull` för att importera incheckningar från den här bunten. +Det visar vad som kan dras in, och du kan använda kommandona `fetch` eller `pull` för att importera incheckningar från bunten. Här uppdaterar vi `master`‑grenen från bunten till en gren som heter `other-master` i vårt kodförråd: [source,console] diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 551f6103..0dc16167 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -1,5 +1,5 @@ [[_credential_caching]] -=== Lagring av inloggningsuppgifter +=== Lagra inloggningsuppgifter (((credentials))) (((git commands, credential))) @@ -53,7 +53,7 @@ Här är hur en `.gitconfig` kan se ut om du har en inloggningsfil på ett USB helper = cache --timeout 30000 ---- -==== Under huven +==== Internt Hur fungerar allt detta? Gits rotkommando för systemet med inloggningshjälpare är `git credential`, som tar ett kommando som argument och sedan mer indata via stdin. @@ -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 detta fall, så vi ser 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. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 2c310f2b..32310a6b 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -1,16 +1,16 @@ === Felsöka med Git Förutom att i första hand vara ett verktyg för versionshantering erbjuder Git också några kommandon som hjälper dig att felsöka källkodsprojekt. -Eftersom Git är byggt för att hantera nästan vilken typ av innehåll som helst är verktygen ganska generella, men de kan ofta hjälpa dig att jaga ett programfel eller en skyldig när något går snett. +Eftersom Git är byggt för att hantera nästan vilken typ av innehåll som helst är verktygen ganska allmänna, men de kan ofta hjälpa dig att jaga ett programfel eller en skyldig när något går snett. [[_file_annotation]] ==== Filannotering Om du spårar ett programfel i din kod och vill veta när det introducerades och varför, är filannotering ofta ditt bästa verktyg. Det visar vilken incheckning som senast ändrade varje rad i en fil. -Så om du ser att en metod i din kod är felaktig kan du annotera filen med `git blame` för att avgöra vilken incheckning som var ansvarig för att den raden introducerades. +Så om du ser att en metod i din kod är felaktig kan du annotera filen med `git blame` för att avgöra vilken incheckning som införde den raden. -Följande exempel använder `git blame` för att avgöra vilken incheckning och incheckare som var ansvarig för rader i Linuxkärnans `Makefile` på toppnivå och använder dessutom flaggan `-L` för att begränsa utdata till raderna 69–82 i filen: +Följande exempel använder `git blame` för att avgöra vilken incheckning och incheckare som låg bakom raderna i Linuxkärnans `Makefile` på toppnivå och använder dessutom flaggan `-L` för att begränsa utdata till raderna 69–82 i filen: [source,console] ---- @@ -89,9 +89,9 @@ Bisecting: 6 revisions left to test after this ---- Git räknade ut att ungefär 12 incheckningar låg mellan incheckningen du markerade som senaste bra (v1.0) och den nuvarande trasiga versionen, och växlade till den mittersta åt dig. -Vid det här laget kan du köra ditt test för att se om problemet finns i den här incheckningen. +Nu kan du köra ditt test för att se om problemet finns i den här incheckningen. Om det gör det introducerades det någon gång före den här mittersta incheckningen; om det inte gör det introducerades problemet någon gång efter den mittersta incheckningen. -Det visar sig att det inte finns något problem här, och du talar om för Git genom att skriva `git bisect good` och fortsätter din resa: +Det finns inget problem här, och du talar om för Git genom att skriva `git bisect good` och fortsätter din resa: [source,console] ---- @@ -135,7 +135,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`. +Har du ett skript som returnerar 0 om projektet är bra eller något annat än 0 om projektet är dåligt kan du helt automatisera `git bisect`. Först anger du återigen intervallet för bisekteringen genom att ange den kända dåliga och den kända bra incheckningen. Du kan göra detta genom att lista dem med kommandot `bisect start` om du vill, och lista den kända dåliga incheckningen först och den kända bra incheckningen som tvåa: diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 83ec45b1..3042e4fa 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -71,7 +71,7 @@ What now> s ---- Nu kan du se att filerna `TODO` och `index.html` är köade och att filen `simplegit.rb` fortfarande inte är köad. -Om du vill avköa filen `TODO` vid det här laget använder du alternativet `r` eller `3` (för återställning): +Vill du avköa `TODO` nu använder du alternativet `r` eller `3` (för återställning): [source,console] ---- @@ -196,7 +196,7 @@ What now> 1 Statusen för filen `simplegit.rb` är intressant. Den visar att några rader är köade och några är ej köade. Du har köat den här filen delvis. -Vid det här laget kan du avsluta det interaktiva köläggningsskriptet och köra `git commit` för att checka in de delvis köade filerna. +Nu kan du avsluta det interaktiva köläggningsskriptet och köra `git commit` för att checka in de delvis köade filerna. Du behöver inte heller vara i interaktivt köläggningsläge för att köa delar av filer -- du kan starta samma skript genom att använda `git add -p` eller `git add --patch` på kommandoraden. diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 82676793..424cd9fc 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -10,7 +10,7 @@ Till exempel, säg att du har en enorm kodhistorik och vill dela upp ditt kodfö Du kan ympa den ena historiken på den andra genom att "ersätta" den tidigaste incheckningen i den nya linjen med den senaste incheckningen i den äldre. Det är trevligt eftersom det betyder att du inte behöver skriva om varje incheckning i den nya historiken, som du annars normalt måste göra för att sammanfoga dem (eftersom föräldraskapet påverkar SHA‑1‑värdena). -Låt oss prova. +Vi provar. Vi tar ett befintligt kodförråd, delar upp det i två kodförråd, ett nyligt och ett historiskt, och ser sedan hur vi kan kombinera dem igen utan att ändra SHA‑1‑värdena i det nyare kodförrådet med hjälp av `replace`. Vi använder ett enkelt kodförråd med fem enkla incheckningar: diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index d5497647..9f36163e 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -1,7 +1,7 @@ [[_git_reset]] === Nollställning förklarad -Innan vi går vidare till mer specialiserade verktyg, låt oss prata om Gits kommandon `reset` och `checkout`. +Innan vi går vidare till mer specialiserade verktyg pratar vi om Gits kommandon `reset` och `checkout`. Dessa kommandon är två av de mest förvirrande delarna av Git när du stöter på dem första gången. De gör så många saker att det verkar hopplöst att verkligen förstå dem och använda dem korrekt. För detta rekommenderar vi en enkel metafor. @@ -28,7 +28,7 @@ HEAD är pekaren till den aktuella grenreferensen, som i sin tur pekar på den s Det betyder att HEAD blir förälder till nästa incheckning som skapas. Det är i allmänhet enklast att se HEAD som ögonblicksbilden av *din senaste incheckning på den grenen*. -Faktum är att det är ganska lätt att se hur den ögonblicksbilden ser ut. +Det är i själva verket ganska lätt att se hur den ögonblicksbilden ser ut. Här är ett exempel på hur du hämtar den faktiska kataloglistan och SHA‑1-kontrollsummorna för varje fil i HEAD-ögonblicksbilden: [source,console] @@ -95,7 +95,7 @@ Gits typiska arbetsflöde är att spela in ögonblicksbilder av ditt projekt i s .Gits typiska arbetsflöde image::images/reset-workflow.png[Gits typiska arbetsflöde] -Låt oss visualisera processen: säg att du går in i en ny katalog med en enda fil. +Vi visualiserar processen: säg att du går in i en ny katalog med en enda fil. Vi kallar detta filens *v1*, och vi markerar den i blått. Nu kör vi `git init`, vilket skapar ett Git‑kodförråd med en HEAD-referens som pekar på den ännu ofödda `master`-grenen. @@ -129,7 +129,7 @@ Nästa steg är att köa den med `git add`. .Köar ändring till index image::images/reset-ex5.png[Köar ändring till index] -Vid det här laget, om vi kör `git status`, ser vi filen i grönt under "Ändringar att checka in" eftersom indexet och HEAD skiljer sig -- det vill säga, vår föreslagna nästa incheckning skiljer sig nu från vår senaste incheckning. +Om vi nu kör `git status`, ser vi filen i grönt under "Ändringar att checka in" eftersom indexet och HEAD skiljer sig -- det vill säga, vår föreslagna nästa incheckning skiljer sig nu från vår senaste incheckning. Till sist kör vi `git commit` för att färdigställa incheckningen. .Steget `git commit` med ändrad fil @@ -144,13 +144,13 @@ När du växlar till en gren ändrar det *HEAD* till att peka på den nya grenre Kommandot `reset` blir mer begripligt när man ser det i detta sammanhang. -För att exemplen ska bli tydligare, låt oss säga att vi har ändrat `file.txt` igen och checkat in den en tredje gång. +För att exemplen ska bli tydligare: säg att vi har ändrat `file.txt` igen och checkat in den en tredje gång. Så nu ser historiken ut så här: .Git‑kodförråd med tre incheckningar image::images/reset-start.png[Git‑kodförråd med tre incheckningar] -Låt oss nu gå igenom exakt vad `reset` gör när du anropar det. +Nu går vi igenom exakt vad `reset` gör när du anropar det. Det manipulerar direkt dessa tre träd på ett enkelt och förutsägbart sätt. Det gör upp till tre grundläggande operationer. @@ -194,7 +194,7 @@ Om du använder `--hard` fortsätter den till detta steg. .Hård återställning image::images/reset-hard.png[Hård återställning] -Så låt oss tänka igenom vad som hände. +Vi tänker igenom vad som hände. Du ångrade din senaste incheckning, `git add` och `git commit`-kommandona, *och* allt arbete du gjorde i din arbetskatalog. Tänk på att flaggan (`--hard`) är det enda sättet att göra kommandot `reset` farligt, och ett av de få tillfällen där Git verkligen kan förstöra data. @@ -234,7 +234,7 @@ Om vi tittar på diagrammet för det kommandot och tänker på vad `git add` gö .Köar fil till index image::images/reset-path2.png[Köar fil till index] -Det är anledningen till att utdata från `git status` föreslår att du kör det här för att avköa en fil (se <> för mer om detta). +Därför föreslår `git status` att du kör det här för att avköa en fil (se <> för mer om detta). Vi skulle lika gärna kunna hindra Git från att anta att vi menade "dra data från HEAD" genom att ange en specifik incheckning att hämta den filversionen från. Vi skulle då köra något som `git reset eb43bf file.txt`. @@ -250,13 +250,13 @@ Så du kan selektivt avköa eller återställa innehåll. ==== Sammanfoga incheckningar -Låt oss titta på hur du kan göra något intressant med den här nyfunna kraften -- sammanfoga incheckningar. +Vi tittar på hur du kan göra något intressant med den här nyfunna kraften -- sammanfoga incheckningar. Säg att du har en serie incheckningar med meddelanden som "oops.", "WIP" och "forgot this file". Du kan använda `reset` för att snabbt och enkelt sammanfoga dem till en enda incheckning som får dig att se riktigt smart ut. <<_squashing>> visar ett annat sätt att göra detta, men i exemplet är det enklare att använda `reset`. -Låt oss säga att du har ett projekt där den första incheckningen har en fil, den andra incheckningen lade till en ny fil och ändrade den första, och den tredje incheckningen ändrade den första filen igen. +Säg att du har ett projekt där den första incheckningen har en fil, den andra incheckningen lade till en ny fil och ändrade den första, och den tredje incheckningen ändrade den första filen igen. Den andra incheckningen var ett arbete på gång och du vill sammanfoga den. .Git‑kodförråd @@ -285,7 +285,7 @@ Likt `reset` manipulerar `checkout` de tre träden, och det är lite olika beroe Att köra `git checkout [gren]` är ganska likt att köra `git reset --hard [gren]` genom att det uppdaterar alla tre träd så att de ser ut som `[gren]`, men det finns två viktiga skillnader. För det första, till skillnad från `reset --hard`, är `checkout` säkert för arbetskatalogen; den kontrollerar att den inte skriver över filer som har ändringar i sig. -Faktum är att den är lite smartare än så -- den försöker göra en trivialsammanfogning i arbetskatalogen, så alla filer du _inte_ har ändrat blir uppdaterade. +Den är i själva verket lite smartare än så -- den försöker göra en trivialsammanfogning i arbetskatalogen, så alla filer du _inte_ har ändrat blir uppdaterade. `reset --hard` kommer däremot helt enkelt ersätta allt utan att kontrollera. Den andra viktiga skillnaden är hur `checkout` uppdaterar HEAD. @@ -312,7 +312,7 @@ Dessutom, precis som `git reset` och `git add`, accepterar `checkout` flaggan `- ==== Sammanfattning -Förhoppningsvis förstår du nu och känner dig mer bekväm med kommandot `reset`, men du är sannolikt fortfarande lite förvirrad över hur exakt det skiljer sig från `checkout` och kan knappast minnas alla regler för de olika varianterna. +Förhoppningsvis förstår du nu och känner dig tryggare med kommandot `reset`, men du är sannolikt fortfarande lite förvirrad över hur exakt det skiljer sig från `checkout` och kan knappast minnas alla regler för de olika varianterna. Här är en fusklapp för vilka kommandon som påverkar vilka träd. Kolumnen "HEAD" visar "REF" om det kommandot flyttar referensen (grenen) som HEAD pekar på, och "HEAD" om det flyttar HEAD självt. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 9451ac09..d1bba0bf 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -98,7 +98,7 @@ $ git show ca82a6dff817ec66f44342007202690a93763949 $ git show topic1 ---- -Om du vill se vilken specifik SHA‑1 en gren pekar på, eller om du vill se vad något av exemplen i praktiken leder till i termer av SHA‑1, kan du använda ett Git-rörverktyg som heter `rev-parse`. +Om du vill se vilken specifik SHA‑1 en gren pekar på, eller om du vill se vad något av exemplen i praktiken leder till uttryckt som SHA‑1, kan du använda ett Git-rörverktyg som heter `rev-parse`. Du kan läsa mer om rörverktyg i <>; kort sagt finns `rev-parse` för lågnivåoperationer och är inte tänkt för dagligt bruk. Det kan ändå vara hjälpsamt när du behöver se vad som egentligen händer. Här kan du köra `rev-parse` på din gren. @@ -297,7 +297,7 @@ Du kan också kombinera dessa syntaxer – du kan få den andra föräldern till [[_commit_ranges]] ==== Incheckningsintervall -Nu när du kan ange enskilda incheckningar, låt oss se hur du anger intervall av incheckningar. +Nu när du kan ange enskilda incheckningar ser vi hur du anger intervall av incheckningar. Det är särskilt användbart när du hanterar grenar – om du har många grenar kan du använda intervallspecifikationer för att besvara frågor som "Vilket arbete finns i den här grenen som jag ännu inte har sammanfogat in i min huvudgren?". ===== Dubbelpunkt diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index dc232f2d..3a4bdb2a 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -3,7 +3,7 @@ Många gånger när du arbetar med Git vill du revidera din lokala incheckningshistorik. En av de fina sakerna med Git är att du kan ta beslut i sista möjliga stund. -Du kan bestämma vilka filer som ska hamna i vilka incheckningar precis innan du checkar in med hjälp av köytan, du kan bestämma att du egentligen inte skulle arbeta med något ännu med `git stash`, och du kan skriva om incheckningar som redan hänt så att de ser ut att ha hänt på ett annat sätt. +Du kan bestämma vilka filer som ska hamna i vilka incheckningar precis innan du checkar in via köytan, du kan bestämma att du egentligen inte skulle arbeta med något ännu med `git stash`, och du kan skriva om incheckningar som redan hänt så att de ser ut att ha hänt på ett annat sätt. Det kan handla om att ändra ordningen på incheckningar, ändra meddelanden eller modifiera filer i en incheckning, sammanfoga eller dela upp incheckningar, eller ta bort incheckningar helt och hållet -- allt innan du delar ditt arbete med andra. I avsnittet ser du hur du genomför dessa uppgifter så att du kan få din incheckningshistorik att se ut som du vill innan du delar den. @@ -19,7 +19,7 @@ Kort sagt bör du undvika att skicka ditt arbete innan du är nöjd med det och [[_git_amend]] ==== Ändra den senaste incheckningen -Att ändra din senaste incheckning är troligen den vanligaste omskrivningen av historik du gör. +Att ändra din senaste incheckning är troligen det vanligaste du gör för att skriva om historiken. Ofta vill du göra två grundläggande saker med din senaste incheckning: helt enkelt ändra incheckningsmeddelandet, eller ändra själva innehållet i incheckningen genom att lägga till, ta bort och ändra filer. Om du bara vill ändra ditt senaste incheckningsmeddelande är det enkelt: @@ -107,7 +107,7 @@ pick a5f4a0d Add cat-file # Note that empty commits are commented out ---- -Det är viktigt att förstå att dessa incheckningar listas i motsatt ordning än du normalt ser dem med `log`-kommandot. +Dessa incheckningar listas i omvänd ordning jämfört med `log`-kommandot. Om du kör `log` ser du något som detta: [source,console] @@ -310,11 +310,11 @@ pick 461cb2a This commit is OK drop 5aecc10 This commit is broken ---- -På grund av hur Git bygger incheckningsobjekt kommer borttagning eller ändring av en incheckning att skriva om alla incheckningar som följer efter den. +Att ta bort eller ändra en incheckning skriver om alla efterföljande incheckningar, på grund av hur Git bygger incheckningsobjekt. Ju längre bak i historiken du går, desto fler incheckningar måste skapas om. Det här kan ge många sammanslagningskonflikter om senare incheckningar i sekvensen bygger på den du just tog bort. -Om du kommer halvvägs in i en ombasering som detta och bestämmer dig för att det inte var en bra idé kan du alltid avbryta. +Om du kommer halvvägs in i en ombasering som detta och bestämmer dig för att det inte var rätt kan du alltid avbryta. Skriv `git rebase --abort`, så återställs ditt kodförråd till det läge det var i innan du började ombasera. Om du avslutar en ombasering och bestämmer dig för att det inte var vad du ville kan du använda `git reflog` för att återställa en tidigare version av din gren. @@ -356,12 +356,12 @@ Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21) Ref 'refs/heads/master' was rewritten ---- -Flaggan `--tree-filter` kör det angivna kommandot efter varje utläggning av projektet och checkar in sedan resultaten. +Flaggan `--tree-filter` lägger ut varje incheckning, kör det angivna kommandot och checkar sedan in resultaten. I det här fallet tar du bort en fil som heter `passwords.txt` från varje ögonblicksbild, oavsett om den finns eller inte. Om du vill ta bort alla av misstag checkade in säkerhetskopior från redigerare kan du köra något som `git filter-branch --tree-filter 'rm -f *~' HEAD`. Du kan se Git skriva om träd och incheckningar och sedan flytta grenpekaren i slutet. -Det är i allmänhet en bra idé att göra detta i en testgren och sedan göra en hård återställning av `master` när du har fastställt att resultatet är det du vill. +Gör helst detta i en testgren och gör sedan en hård återställning av `master` när du har fastställt att resultatet är det du vill. För att köra `filter-branch` på alla dina grenar kan du skicka `--all` till kommandot. ===== Gör en underkatalog till ny rot diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index d5aad518..58faac11 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -57,7 +57,7 @@ date.c=int parse_date_basic(const char *date, timestamp_t *timestamp, int *offse date.c: /* gmtime_r() in match_digit() may have clobbered it */ ---- -Som du kan se anropas rutinen `gmtime_r` från både funktionerna `match_multi_number` och `match_digit` i filen `date.c` (den tredje träffen som visas representerar bara att strängen förekommer i en kommentar). +Här syns att rutinen `gmtime_r` anropas från både funktionerna `match_multi_number` och `match_digit` i filen `date.c` (den tredje träffen som visas representerar bara att strängen förekommer i en kommentar). Du kan också söka efter mer komplexa kombinationer av strängar med flaggan `--and`, som säkerställer att flera träffar måste förekomma på samma textrad. Till exempel kan vi leta efter rader som definierar en konstant vars namn innehåller _antingen_ delsträngen "`LINK`" eller "`BUF_MAX`", specifikt i en äldre version av Git-kodbasen representerad av taggen `v1.8.0` (vi lägger till `--break` och `--heading` som gör utdata mer läsbar): diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index c8e26b84..122644d1 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -11,7 +11,7 @@ Att lägga undan tar det smutsiga tillståndet i din arbetskatalog -- alltså ä .Migrera till `git stash push` ==== Sedan slutet av oktober 2017 har det förts en omfattande diskussion på Gits e-postlista där kommandot `git stash save` håller på att fasas ut till förmån för det befintliga alternativet `git stash push`. -Den främsta orsaken är att `git stash push` introducerar möjligheten att lägga undan valda _sökvägsspecifikationer_, något som `git stash save` inte stödjer. +Den främsta orsaken är att `git stash push` låter dig lägga undan valda _sökvägsspecifikationer_, något som `git stash save` inte stödjer. `git stash save` försvinner inte i första taget, så oroa dig inte för att det plötsligt ska försvinna. Men du kan vilja börja gå över till `push`-alternativet för den nya funktionaliteten. @@ -58,7 +58,7 @@ $ git status nothing to commit, working directory clean ---- -Vid det här laget kan du byta gren och arbeta på annat håll; dina ändringar ligger sparade på din stapel. +Nu kan du byta gren och arbeta på annat håll; dina ändringar ligger sparade på din stapel. För att se vilka undanläggningar du har sparat kan du använda `git stash list`: [source,console] diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 1bba4b3b..4061756c 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -21,7 +21,7 @@ Det låter dig klona ett annat kodförråd in i ditt projekt och hålla dina inc Vi går igenom utvecklingen av ett enkelt projekt som har delats upp i ett huvudprojekt och några underprojekt. -Låt oss börja med att lägga till ett befintligt Git-kodförråd som en undermodul till kodförrådet vi arbetar i. +Vi börjar med att lägga till ett befintligt Git-kodförråd som en undermodul till kodförrådet vi arbetar i. För att lägga till en ny undermodul använder du kommandot `git submodule add` med den absoluta eller relativa URL:en till projektet du vill börja spåra. I exemplet lägger vi till ett bibliotek som heter "`DbConnector`". @@ -39,7 +39,7 @@ Checking connectivity... done. Som standard lägger undermoduler in underprojektet i en katalog med samma namn som kodförrådet, i det här fallet "`DbConnector`". Du kan lägga till en annan sökväg i slutet av kommandot om du vill att det ska hamna någon annanstans. -Om du kör `git status` vid det här laget märker du några saker. +Om du kör `git status` nu märker du några saker. [source,console] ---- @@ -55,7 +55,7 @@ Changes to be committed: ---- Först bör du lägga märke till den nya filen `.gitmodules`. -Det är en konfigurationsfil som lagrar kopplingen mellan projektets URL och den lokala underkatalog du drog in det i: +Det är en konfigurationsfil som kopplar projektets URL till den lokala underkatalog du drog in det i: [source,ini] ---- @@ -216,7 +216,7 @@ Nu har vi en kopia av ett projekt med undermoduler och kommer att samarbeta med ===== Hämta uppströmsändringar från undermodulens fjärrkodförråd Den enklaste modellen för att använda undermoduler i ett projekt är när du bara använder ett underprojekt och vill få uppdateringar från det då och då, utan att själv ändra något i din utläggning. -Låt oss gå igenom ett enkelt exempel. +Vi går igenom ett enkelt exempel. Om du vill kontrollera om det finns nytt arbete i en undermodul kan du gå in i katalogen och köra `git fetch` och `git merge` mot uppströmsgrenen för att uppdatera den lokala koden. @@ -245,7 +245,7 @@ Submodule DbConnector c3f01dc..d0354fc: > better connection routine ---- -Om du checkar in vid det här laget kommer du att låsa undermodulen till den nya koden när andra uppdaterar. +Checkar du in nu låser du undermodulen till den nya koden när andra uppdaterar. Det finns även ett enklare sätt om du föredrar att inte uppdatera och sammanfoga manuellt i underkatalogen. Om du kör `git submodule update --remote` kommer Git att gå in i dina undermoduler, uppdatera och växla åt dig. @@ -265,7 +265,7 @@ Submodule path 'DbConnector': checked out 'd0354fc054692d3906c85c3af05ddce39a1c0 Det här kommandot antar som standard att du vill uppdatera utläggningen till standardgrenen på fjärrkodförrådet för undermodulen (den som pekas ut av `HEAD` i fjärrkodförrådet). Du kan dock ställa in detta till något annat om du vill. Om du till exempel vill att undermodulen `DbConnector` ska spåra kodförrådets "`stable`"‑gren kan du ställa in det antingen i `.gitmodules`‑filen (så att alla andra också spårar det) eller bara i din lokala `.git/config`‑fil. -Låt oss ställa in det i `.gitmodules`‑filen: +Vi ställer in det i `.gitmodules`‑filen: [source,console] ---- @@ -283,7 +283,7 @@ Submodule path 'DbConnector': checked out 'c87d55d4c6d4b05ee34fbc8cb6f7bf4585ae6 Om du lämnar bort `-f .gitmodules` görs ändringen bara lokalt, men det är oftast rimligare att spåra den informationen i kodförrådet så att alla andra gör det också. -När vi kör `git status` vid det här laget visar Git att vi har "`new commits`" i undermodulen. +Kör vi `git status` nu visar Git att vi har "`new commits`" i undermodulen. [source,console] ---- @@ -378,7 +378,7 @@ Om du har många kan du vilja skicka namnet på just den undermodul du vill uppd ===== Dra uppströmsändringar från projektets fjärrkodförråd -Låt oss nu kliva in i din kollegas skor, som har sin egen lokala klon av MainProject‑kodförrådet. +Nu kliver vi in i din kollegas skor, som har sin egen lokala klon av MainProject‑kodförrådet. Att bara köra `git pull` för att få dina nyincheckade ändringar räcker inte: [source,console] @@ -458,7 +458,7 @@ $ git submodule update --init --recursive Det är ganska sannolikt att om du använder undermoduler så gör du det för att du verkligen vill arbeta med koden i undermodulen samtidigt som du arbetar med koden i huvudprojektet (eller över flera undermoduler). Annars skulle du förmodligen använda ett enklare beroendehanteringssystem (som Maven eller Rubygems). -Låt oss nu gå igenom ett exempel där vi gör ändringar i undermodulen samtidigt som huvudprojektet och checkar in och publicerar dessa ändringar samtidigt. +Nu går vi igenom ett exempel där vi gör ändringar i undermodulen samtidigt som huvudprojektet och checkar in och publicerar dessa ändringar samtidigt. Hittills, när vi kört `git submodule update` för att uppdatera ändringar från undermodulkodförråden, har Git uppdaterat ändringarna och uppdaterat filerna i underkatalogen men lämnat underkodförrådet i ett så kallat "frikopplat HEAD"‑läge. Det betyder att det inte finns någon lokal arbetsgren (som till exempel `master`) som spårar ändringar. @@ -470,7 +470,7 @@ Du behöver gå in i varje undermodul och växla till en gren att arbeta på. Sedan behöver du tala om för Git vad den ska göra om du har gjort ändringar och senare kör `git submodule update --remote` som drar in nytt arbete från uppströms. Alternativen är att du kan sammanfoga dem med ditt lokala arbete, eller försöka ombasera ditt lokala arbete ovanpå de nya ändringarna. -Låt oss först gå in i vår undermodulkatalog och växla till en gren. +Först går vi in i vår undermodulkatalog och växlar till en gren. [source,console] ---- @@ -479,7 +479,7 @@ $ git checkout stable Switched to branch 'stable' ---- -Låt oss försöka uppdatera vår undermodul med "`merge`"‑alternativet. +Vi försöker uppdatera vår undermodul med "`merge`"‑alternativet. För att ange det manuellt kan vi helt enkelt lägga till flaggan `--merge` till vårt `update`‑anrop. Här ser vi att det fanns en ändring på servern för undermodulen och den sammanfogas in. @@ -501,7 +501,7 @@ Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5e ---- Om vi går in i katalogen `DbConnector` har vi de nya ändringarna redan sammanfogade i vår lokala `stable`‑gren. -Låt oss nu se vad som händer när vi gör en egen lokal ändring i biblioteket och någon annan samtidigt skickar upp en annan ändring uppströms. +Nu ser vi vad som händer när vi gör en egen lokal ändring i biblioteket och någon annan samtidigt skickar upp en annan ändring uppströms. [source,console] ---- @@ -684,7 +684,7 @@ Så, i det här fallet är `eb41d76` incheckningen i vår undermodul som *vi* ha Om vi går in i undermodulkatalogen ska den redan stå på `eb41d76` eftersom sammanslagningen inte rörde den. Om den av någon anledning inte gör det kan du helt enkelt skapa och växla till en gren som pekar på den. -Det viktiga är SHA‑1‑värdet för incheckningen på den andra sidan. +Viktigt här är SHA‑1‑värdet för incheckningen på den andra sidan. Det är det du måste sammanfoga in och lösa. Du kan antingen försöka sammanfoga med SHA‑1:an direkt, eller skapa en gren för den och sedan försöka sammanfoga den. Vi föreslår det senare, om inte annat för att få ett trevligare sammanslagningsmeddelande. @@ -792,7 +792,7 @@ Det finns några saker du kan göra för att göra arbetet med undermoduler lite ===== Undermodul‑foreach Det finns ett `foreach`‑kommando för undermoduler som kör ett godtyckligt kommando i varje undermodul. -Det kan vara riktigt användbart om du har flera undermoduler i samma projekt. +Riktigt användbart om du har flera undermoduler i samma projekt. Till exempel, säg att vi vill starta en ny funktion eller åtgärda ett programfel och att vi har arbete på gång i flera undermoduler. Vi kan enkelt lägga undan allt arbete i alla våra undermoduler. @@ -862,7 +862,7 @@ Det här är förstås ett förenklat exempel, men förhoppningsvis ger det en b ===== Nyttiga alias -Du kanske vill sätta upp alias för några av dessa kommandon eftersom de kan vara ganska långa och du kan inte ställa in konfigurationsalternativ för de flesta av dem för att göra dem till standard. +Du kanske vill sätta upp alias för några av dessa kommandon eftersom de kan vara ganska långa och du kan inte ställa in konfigurationsalternativ för de flesta för att göra dem till standard. Vi tog upp hur man sätter upp Git‑alias i <>, men här är ett exempel på vad du kan vilja ställa in om du planerar att arbeta mycket med undermoduler i Git. [source,console] @@ -872,7 +872,7 @@ $ git config alias.spush 'push --recurse-submodules=on-demand' $ git config alias.supdate 'submodule update --remote --merge' ---- -På så sätt kan du helt enkelt köra `git supdate` när du vill uppdatera dina undermoduler, eller `git spush` för att skicka med kontroll av undermodulsberoenden. +På så sätt kan du helt enkelt köra `git supdate` när du vill uppdatera dina undermoduler, eller `git spush` för att skicka och kontrollera undermodulsberoenden. ==== Problem med undermoduler @@ -973,7 +973,7 @@ Att använda flaggan `--recurse-submodules` i `git checkout` kan också vara anv När du byter mellan grenar som registrerar undermodulen vid olika incheckningar kommer undermodulen att visas som "`modified`" och indikera "`new commits`" när du kör `git status`. Det beror på att undermodulens läge som standard inte följer med när du byter gren. -Det kan vara riktigt förvirrande, så det är en bra idé att alltid köra `git checkout --recurse-submodules` när ditt projekt har undermoduler. +Riktigt förvirrande, så kör alltid `git checkout --recurse-submodules` när ditt projekt har undermoduler. För äldre Git‑versioner som saknar flaggan `--recurse-submodules` kan du efter utcheckning köra `git submodule update --init --recursive` för att få undermodulerna i rätt läge. Lyckligtvis kan du tala om för Git (>=2.14) att alltid använda flaggan `--recurse-submodules` genom att sätta konfigurationsalternativet `submodule.recurse`: `git config submodule.recurse true`. diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 4359be0e..f1559916 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -58,7 +58,7 @@ $ git read-tree --prefix=rack/ -u rack_branch ---- När vi checkar in ser det ut som att vi har alla Rack‑filer under den underkatalogen -- ungefär som om vi kopierat in dem från en tar‑fil. -Det som blir intressant är att vi ganska enkelt kan sammanfoga ändringar från den ena grenen till den andra. +Det intressanta är att vi ganska enkelt kan sammanfoga ändringar från den ena grenen till den andra. Så om Rack‑projektet uppdateras kan vi dra in uppströmsändringar genom att byta till den grenen och dra: [source,console] diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 52ee007d..916eb44b 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -36,7 +36,7 @@ Nu försöker Git varken konvertera eller fixa CRLF‑problem; inte heller förs Du kan också använda Git‑attribut för att i praktiken diffa binära filer. Det gör du genom att tala om för Git hur den ska konvertera binärdata till ett textformat som kan jämföras med en vanlig diff. -Först använder vi tekniken för att lösa ett av de mest frustrerande problemen som finns: versionshantering av Microsoft Word‑dokument. +Först använder vi tekniken för att lösa ett av de mest frustrerande problemen som finns: att versionshantera Microsoft Word‑dokument. Om du vill versionshantera Word‑dokument kan du lägga dem i ett Git‑kodförråd och checka in då och då; men vad hjälper det? Om du kör `git diff` som vanligt ser du bara något i stil med detta: @@ -49,7 +49,7 @@ Binary files a/chapter1.docx and b/chapter1.docx differ ---- Du kan inte jämföra två versioner direkt om du inte lägger ut dem och granskar dem manuellt, eller hur? -Det visar sig att du kan göra detta ganska bra med Git‑attribut. +Du kan faktiskt göra detta ganska bra med Git‑attribut. Lägg följande rad i din `.gitattributes`‑fil: [source,ini] @@ -190,7 +190,7 @@ $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $ Detta resultat har dock begränsad nytta. Om du har använt nyckelordssubstitution i CVS eller Subversion kan du inkludera en datumstämpel – SHA‑1:an är inte särskilt hjälpsam, eftersom den är ganska slumpmässig och du kan inte se om en SHA‑1 är äldre eller nyare än en annan bara genom att titta på dem. -Det visar sig att du kan skriva egna filter för att göra substitutioner i filer vid incheckning/utläggning. +Du kan också skriva egna filter för att göra substitutioner i filer vid incheckning/utläggning. Dessa kallas "`clean`"‑ och "`smudge`"‑filter. I `.gitattributes`‑filen kan du sätta ett filter för vissa sökvägar och sedan sätta upp skript som bearbetar filer strax innan de läggs ut ("`smudge`", se <>) och strax innan de köas ("`clean`", se <>). Dessa filter kan ställas in för att göra många olika saker. @@ -349,7 +349,7 @@ Det resulterande arkivet lämpar sig för driftsättning, men som vilket exporte Du kan också använda Git‑attribut för att tala om för Git att använda olika sammanslagningsstrategier för specifika filer i ditt projekt. Ett mycket användbart alternativ är att tala om för Git att inte försöka sammanfoga vissa filer när de har konflikter, utan i stället använda din sida av sammanslagningen framför någon annans. -Det här är hjälpsamt om en gren i projektet har glidit isär eller är specialiserad, men du vill kunna sammanfoga in ändringar från den och samtidigt ignorera vissa filer. +Det hjälper om en gren i projektet har glidit isär eller är specialiserad, men du vill kunna sammanfoga in ändringar från den och samtidigt ignorera vissa filer. Säg att du har en databasinställningsfil som heter `database.xml` som är olika i två grenar, och du vill sammanfoga den andra grenen utan att stöka till databasfilen. Du kan ställa in ett attribut så här: diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 630f6b85..adc9fd7b 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -35,7 +35,7 @@ Det är dock oftast enklare att köra kommandot `git config`. ==== Grundläggande klientkonfiguration Konfigurationsalternativen som Git känner igen delas in i två kategorier: klientsidan och serversidan. -Majoriteten av alternativen är på klientsidan – konfiguration av dina personliga arbetsvanor. +Majoriteten av alternativen är på klientsidan – de styr dina personliga arbetsvanor. Många, _många_ konfigurationsalternativ stöds, men en stor del av dem är bara användbara i vissa kantfall; här går vi igenom de vanligaste och mest användbara alternativen. Om du vill se en lista över alla alternativ som din version av Git känner igen kan du köra: @@ -291,7 +291,7 @@ $ sudo chmod +x /usr/local/bin/extDiff ---- Nu kan du konfigurera din konfigurationsfil att använda din anpassade sammanslagningslösning och diffverktyg. -Detta kräver ett antal egna inställningar: `merge.tool` för att tala om för Git vilken strategi som ska användas, `mergetool..cmd` för att ange hur kommandot körs, `mergetool..trustExitCode` för att tala om för Git om exit‑koden från programmet indikerar en lyckad sammanslagning eller inte, och `diff.external` för att tala om för Git vilket kommando som ska köras för diffar. +Detta kräver flera egna inställningar: `merge.tool` talar om för Git vilken strategi den ska använda, `mergetool..cmd` anger hur kommandot körs, `mergetool..trustExitCode` talar om för Git om exit‑koden från programmet indikerar en lyckad sammanslagning eller inte, och `diff.external` talar om för Git vilket kommando den ska köra för diffar. Så du kan antingen köra fyra config‑kommandon: [source,console] @@ -330,7 +330,7 @@ image::images/p4merge.png[P4Merge] Om du försöker sammanfoga två grenar och därefter får sammanslagningskonflikter kan du köra kommandot `git mergetool`; det startar P4Merge så att du kan lösa konflikterna med det grafiska verktyget. -Det fina med denna omslagsuppsättning är att du lätt kan byta diff‑ och sammanslagningsverktyg. +Med den här omslagsuppsättningen kan du lätt byta diff‑ och sammanslagningsverktyg. Till exempel, för att byta dina `extDiff`‑ och `extMerge`‑verktyg till att köra KDiff3 i stället räcker det att redigera din `extMerge`‑fil: [source,console] @@ -472,7 +472,7 @@ Om du har checkat in blankteckensproblem men ännu inte har skickat upp kan du k ==== Serverkonfiguration -Det finns inte i närheten lika många konfigurationsalternativ på serversidan av Git, men det finns några intressanta du kan vilja lägga märke till. +Det finns inte i närheten lika många konfigurationsalternativ på serversidan av Git, men det finns några intressanta värda att känna till. ===== `receive.fsckObjects` @@ -512,6 +512,6 @@ För att undvika detta sätter du `receive.denyDeletes` till true: $ git config --system receive.denyDeletes true ---- -Detta nekar all radering av grenar eller taggar -- ingen användare kan göra det. +Detta hindrar att grenar eller taggar raderas -- ingen användare kan göra det. För att ta bort fjärrgrenar måste du ta bort ref‑filerna på servern manuellt. Det finns också mer intressanta sätt att göra detta per användare via ACL:er, som du kommer att lära dig i <>. diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 5a47e971..a0d3c94e 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -12,7 +12,7 @@ Du kan använda dessa krokar av många olika skäl. Alla krokar lagras i underkatalogen `hooks` i Git‑katalogen. I de flesta projekt är det `.git/hooks`. När du initierar ett nytt kodförråd med `git init` fyller Git krok‑katalogen med en uppsättning exempelskript, varav många är användbara i sig själva; de dokumenterar också vilka indata varje skript får. -Alla exempel är skrivna som skalskript, med lite Perl insprängt, men alla korrekt namngivna körbara skript fungerar – du kan skriva dem i Ruby, Python eller vilket språk du nu är bekväm med. +Alla exempel är skrivna som skalskript, med lite Perl insprängt, men alla korrekt namngivna körbara skript fungerar – du kan skriva dem i Ruby, Python eller vilket språk du är van vid. Om du vill använda de medföljande krok‑skripten behöver du byta namn på dem; deras filnamn slutar med `.sample`. För att aktivera ett krok‑skript lägger du en fil i underkatalogen `hooks` i din `.git`‑katalog som är rätt namngiven (utan filändelse) och körbar. @@ -32,7 +32,7 @@ Om din avsikt med dessa skript är att upprätthålla en policy vill du sannolik ===== Krokar för incheckningsflödet -De första fyra hooksen har att göra med incheckningsprocessen. +De första fyra krokarna gäller incheckningsprocessen. Kroken `pre-commit` körs först, innan du ens skriver in ett incheckningsmeddelande. Den används för att inspektera ögonblicksbilden som ska checkas in, för att se om du glömt något, för att se till att tester körs, eller för att granska det du behöver i koden. @@ -43,10 +43,10 @@ Kroken `prepare-commit-msg` körs innan redigeraren för incheckningsmeddelandet Den låter dig redigera standardmeddelandet innan författaren ser det. Kroken tar några parametrar: sökvägen till filen som innehåller incheckningsmeddelandet hittills, typen av incheckning och incheckningens SHA‑1 om det gäller en ändrad incheckning. Denna krok är i allmänhet inte användbar för normala incheckningar; snarare är den bra för incheckningar där standardmeddelandet genereras automatiskt, såsom mallade incheckningsmeddelanden, sammanslagningsincheckningar, sammanfogade incheckningar och ändrade incheckningar. -Du kan använda den tillsammans med en incheckningsmall för att programatiskt infoga information. +Du kan använda den tillsammans med en incheckningsmall för att automatiskt infoga information. Kroken `commit-msg` tar en parameter, vilket återigen är sökvägen till en temporär fil som innehåller incheckningsmeddelandet som utvecklaren har skrivit. -Om detta skript avslutas med en icke‑nollkod avbryter Git incheckningsprocessen, så du kan använda det för att validera projektets läge eller incheckningsmeddelandet innan incheckningen får gå igenom. +Om detta skript avslutas med en icke‑nollkod avbryter Git incheckningsprocessen, så du kan använda det för att kontrollera projektets läge eller incheckningsmeddelandet innan incheckningen får gå igenom. I sista delen av kapitlet visar vi hur du använder denna krok för att kontrollera att incheckningsmeddelandet följer ett obligatoriskt mönster. När hela incheckningsprocessen är klar körs kroken `post-commit`. @@ -78,32 +78,32 @@ Du kan inte stoppa själva appliceringen med detta skript. ===== Andra krokar på klientsidan Kroken `pre-rebase` körs innan du ombaserar något och kan stoppa processen genom att avslutas med en icke‑nollkod. -Du kan använda denna krok för att förhindra ombasering av incheckningar som redan har skickats upp. +Du kan använda denna krok för att förhindra att incheckningar som redan skickats upp ombaseras. Exempelkroken `pre-rebase` som Git installerar gör detta, även om den gör vissa antaganden som kanske inte matchar ditt arbetsflöde. Kroken `post-rewrite` körs av kommandon som ersätter incheckningar, såsom `git commit --amend` och `git rebase` (men inte av `git filter-branch`). Dess enda argument är vilket kommando som utlöste omskrivningen, och den tar emot en lista över omskrivningar på `stdin`. -Denna krok har många av samma användningar som hooksen `post-checkout` och `post-merge`. +Denna krok har många av samma användningar som krokarna `post-checkout` och `post-merge`. Efter att du har kört en lyckad `git checkout` körs kroken `post-checkout`; du kan använda den för att ställa in din arbetskatalog korrekt för projektets miljö. Det kan innebära att flytta in stora binärfiler som du inte vill versionshantera, auto‑generera dokumentation eller något i den stilen. Kroken `post-merge` körs efter en lyckad `merge`. Du kan använda den för att återställa data i arbetsträdet som Git inte kan spåra, såsom behörighetsdata. -Kroken kan också validera att filer som ligger utanför Gits kontroll finns på plats, sådant du vill kopiera in när arbetsträdet förändras. +Kroken kan också kontrollera att filer som ligger utanför Gits kontroll finns på plats, sådant du vill kopiera in när arbetsträdet förändras. Kroken `pre-push` körs under `git push`, efter att fjärrreferenserna uppdaterats men innan några objekt har överförts. Den tar namnet och platsen för fjärrkodförrådet som parametrar, samt en lista över referenser som ska uppdateras via `stdin`. -Du kan använda den för att validera uppsättningen referensuppdateringar innan en uppskickning sker (en icke‑nollkod avbryter uppskickningen). +Du kan använda den för att kontrollera uppsättningen referensuppdateringar innan en uppskickning sker (en icke‑nollkod avbryter uppskickningen). Git gör ibland skräpsamling som en del av sin normala drift, genom att anropa `git gc --auto`. -Kroken `pre-auto-gc` anropas precis innan skräpsamlingen sker, och kan användas för att meddela dig att detta händer, eller för att avbryta samlingen om det inte är ett bra tillfälle. +Kroken `pre-auto-gc` anropas precis innan skräpsamlingen sker, och kan meddela dig att detta händer, eller avbryta samlingen om det inte är ett bra tillfälle. ==== Krokar på serversidan Utöver krokar på klientsidan kan du använda ett par viktiga krokar på serversidan som systemadministratör för att upprätthålla nästan vilken policy som helst för ditt projekt. Dessa skript körs före och efter uppskickningar till servern. -Pre‑hooksen kan avslutas med en icke‑nollkod när som helst för att neka uppskickningen och skriva ett felmeddelande tillbaka till klienten; du kan sätta upp en uppskickningspolicy som är så komplex som du vill. +Pre‑krokarna kan avslutas med en icke‑nollkod när som helst för att neka uppskickningen och skriva ett felmeddelande tillbaka till klienten; du kan sätta upp en uppskickningspolicy som är så komplex som du vill. ===== `pre-receive` @@ -120,7 +120,7 @@ Om skriptet `update` avslutas med en icke‑nollkod avslås bara den referensen; ===== `post-receive` -Kroken `post-receive` körs efter att hela processen är klar och kan användas för att uppdatera andra tjänster eller meddela användare. +Kroken `post-receive` körs efter att hela processen är klar och kan uppdatera andra tjänster eller meddela användare. Den tar samma stdin‑data som kroken `pre-receive`. Exempel är att skicka e-post till en lista, meddela en CI‑server eller uppdatera ett ärendehanteringssystem – du kan till och med analysera incheckningsmeddelanden för att se om ärenden behöver öppnas, modifieras eller stängas. Detta skript kan inte stoppa uppskickningsprocessen, men klienten kopplar inte ned förrän det är klart, så var försiktig om du försöker göra något som kan ta lång tid. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index b9cb537e..ed8956ff 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -18,7 +18,7 @@ Kroken `update` körs en gång per gren som skickas upp och tar tre argument: * Den nya revisionen som skickas upp Du har också tillgång till användaren som skickar upp om uppskickningen körs över SSH. -Om du har tillåtit alla att ansluta med en enda användare (som "`git`") via publika nycklar kan du behöva ge den användaren ett skalomslag som avgör vilken användare som ansluter baserat på den publika nyckeln, och sätta en miljövariabel därefter. +Om du har tillåtit alla att ansluta med en enda användare (som "`git`") via publika nycklar kan du behöva ge den användaren ett skalomslag som avgör vilken användare som ansluter utifrån den publika nyckeln, och sätta en miljövariabel därefter. Här antar vi att anslutande användare ligger i miljövariabeln `$USER`, så ditt update‑skript börjar med att samla in all information du behöver: [source,ruby] @@ -236,7 +236,7 @@ To git@gitserver:project.git error: failed to push some refs to 'git@gitserver:project.git' ---- -Det finns ett par intressanta saker här. +Några saker är värda att lägga märke till. Först ser du det här när kroken börjar köra. [source,console] @@ -281,7 +281,7 @@ Från och med nu, så länge `update`‑skriptet finns där och är körbart, ko ==== Krokar på klientsidan -Nackdelen med detta angreppssätt är det gnäll som ofrånkomligen uppstår när användarnas uppskick av incheckningar nekas. +Nackdelen med detta angreppssätt är det gnäll som ofrånkomligen uppstår när användare nekas att skicka upp sina incheckningar. Att få sitt omsorgsfullt skapade arbete nekat i sista stund kan vara extremt frustrerande och förvirrande; dessutom måste de redigera sin historik för att rätta det, vilket inte alltid är för den lättskrämde. Svaret på detta dilemma är att tillhandahålla några krokar på klientsidan som användarna kan köra för att få en varning när de gör något som servern sannolikt kommer att neka. @@ -391,13 +391,13 @@ files_modified = `git diff-index --cached --name-only HEAD` ---- Men det är de enda två skillnaderna – i övrigt fungerar skriptet på samma sätt. -En varning är att det förutsätter att du kör lokalt som samma användare som du skickar upp som till fjärrmaskinen. +Tänk på att det förutsätter att du kör lokalt som samma användare som du skickar upp som till fjärrmaskinen. Om det skiljer sig måste du sätta variabeln `$user` manuellt. En annan sak vi kan göra här är att se till att användaren inte skickar upp icke‑snabbspolade referenser. För att få en referens som inte är en snabbspolning måste du antingen ombasera förbi en incheckning du redan har skickat upp eller försöka skicka en annan lokal gren till samma fjärrgren. -Förmodligen är servern redan konfigurerad med `receive.denyDeletes` och `receive.denyNonFastForwards` för att upprätthålla den policyn, så det enda oavsiktliga du kan försöka fånga är ombasering av incheckningar som redan har skickats upp. +Förmodligen är servern redan konfigurerad med `receive.denyDeletes` och `receive.denyNonFastForwards` för att upprätthålla den policyn, så det enda oavsiktliga du kan försöka fånga är att incheckningar som redan skickats upp ombaseras. Här är ett exempel på ett pre‑ombasering‑skript som kontrollerar det. Det får en lista över alla incheckningar du är på väg att skriva om och kontrollerar om de finns i någon av dina fjärrreferenser. diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index b5cc97e9..426ac4ce 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -3,11 +3,11 @@ (((Samverkan med andra VCS:er, Mercurial))) (((Mercurial))) DVCS‑världen är större än bara Git. -Faktum är att det finns många andra system i det här området, vart och ett med sin egen syn på hur distribuerad versionshantering ska fungera. +Det finns faktiskt många andra system i det här området, vart och ett med sin egen syn på hur distribuerad versionshantering ska fungera. Förutom Git är Mercurial det mest populära, och de två är mycket lika på många sätt. -Den goda nyheten, om du föredrar Gits klientbeteende men arbetar med ett projekt vars källkod hanteras med Mercurial, är att det finns ett sätt att använda Git som klient mot ett Mercurial‑värdat kodförråd. -Eftersom Git kommunicerar med serverkodförråd via fjärrkodförråd är det ingen överraskning att den här bryggan är implementerad som en fjärrhjälpare. +Om du föredrar Gits klientbeteende men arbetar med ett projekt vars källkod hanteras med Mercurial finns det ett sätt att använda Git som klient mot ett Mercurial‑värdat kodförråd. +Eftersom Git kommunicerar med serverkodförråd via fjärrkodförråd, är bryggan naturligt nog implementerad som en fjärrhjälpare. Projektet heter git-remote-hg och finns på https://github.com/felipec/git-remote-hg[^]. ===== git-remote-hg @@ -66,8 +66,8 @@ Det beror på att git-remote-hg arbetar på ganska låg nivå och använder en m Eftersom Git och Mercurial båda är utformade för att varje klient ska ha en fullständig kopia av kodförrådshistoriken gör kommandot en full klon, inklusive hela projektets historik, och gör det ganska snabbt. Kommandot `log` visar två incheckningar, där den senaste pekas ut av en hel svärm av referenser. -Det visar sig att några av dem inte finns där. -Låt oss titta på vad som verkligen ligger i `.git`‑katalogen: +Några av dem finns faktiskt inte där. +Vi tittar på vad som verkligen ligger i `.git`‑katalogen: [source,console] ---- @@ -91,13 +91,13 @@ $ tree .git/refs 9 directories, 5 files ---- -Git‑fjärrkodförråd-hg försöker göra saker mer idiomatiska för Git, men under huven hanterar det den konceptuella mappningen mellan två något olika system. +Git‑fjärrkodförråd-hg försöker anpassa saker till Git, men internt hanterar det den underliggande kopplingen mellan två något olika system. Katalogen `refs/hg` är där de faktiska fjärrreferenserna lagras. Till exempel är `refs/hg/origin/branches/default` en Git‑reffil som innehåller SHA‑1:an som börjar med "`ac7955c`", vilket är incheckningen som `master` pekar på. -Så katalogen `refs/hg` är lite som ett låtsas‑`refs/remotes/origin`, men med den extra distinktionen mellan bokmärken och grenar. +Så katalogen `refs/hg` är lite som ett låtsas‑`refs/remotes/origin`, men med den extra skillnaden mellan bokmärken och grenar. -Filen `notes/hg` är startpunkten för hur git-remote-hg mappar Git‑incheckningshashar till Mercurial‑ändringsuppsättnings‑ID:n. -Låt oss utforska lite: +Filen `notes/hg` är startpunkten för hur git-remote-hg kopplar Git‑incheckningshashar till Mercurial‑ändringsuppsättnings‑ID:n. +Vi utforskar lite: [source,console] ---- @@ -123,10 +123,10 @@ Så `refs/notes/hg` pekar på ett träd, som i Gits objektdatabas är en lista `git ls-tree` skriver ut läge, typ, objekthash och filnamn för objekt i ett träd. När vi gräver oss ner till ett av trädobjekten hittar vi inuti en blob som heter "`ac9117f`" (SHA‑1‑hashen för incheckningen som `master` pekar på), med innehållet "`0a04b98`" (vilket är ID:t för Mercurial‑ändringsuppsättningen längst fram på grenen `default`). -Den goda nyheten är att vi för det mesta inte behöver bekymra oss om allt detta. +I praktiken behöver vi sällan bekymra oss om allt detta. Det typiska arbetsflödet skiljer sig inte särskilt mycket från att arbeta med ett Git‑fjärrkodförråd. -Det finns en sak till vi bör ta hand om innan vi fortsätter: ignoreringsregler. +En sak till behöver ordnas innan vi fortsätter: ignoreringsregler. Mercurial och Git använder en mycket liknande mekanism för detta, men du vill sannolikt inte checka in en `.gitignore`‑fil i ett Mercurial‑kodförråd. Lyckligtvis har Git ett sätt att ignorera filer lokalt i ett kodförråd på disk, och Mercurial‑formatet är kompatibelt med Git, så du behöver bara kopiera det: @@ -139,7 +139,7 @@ Filen `.git/info/exclude` fungerar precis som en `.gitignore`, men ingår inte i ===== Arbetsflöde -Låt oss anta att vi har gjort lite arbete och gjort några incheckningar på grenen `master`, och att du är redo att skicka det till fjärrkodförrådet. +Anta att vi har gjort lite arbete och gjort några incheckningar på grenen `master`, och att du är redo att skicka det till fjärrkodförrådet. Så här ser vårt kodförråd ut just nu: [source,console] @@ -152,7 +152,7 @@ $ git log --oneline --graph --decorate ---- Vår gren `master` ligger två incheckningar före `origin/master`, men de två incheckningarna finns bara på vår lokala maskin. -Låt oss se om någon annan har gjort viktigt arbete samtidigt: +Vi ser om någon annan har gjort viktigt arbete samtidigt: [source,console] ---- @@ -347,7 +347,7 @@ o changeset: 5:bd5ac26f11f9 Grennamnet "`permanent`" registrerades tillsammans med ändringsuppsättningen markerad _7_. Från Git‑sidan är arbetet med båda dessa grenstilar detsamma: växla bara till, checka in, uppdatera, sammanfoga, dra och skicka som du brukar. -En sak du bör känna till är att Mercurial inte stödjer omskrivning av historik, bara tillägg. +En sak du bör känna till är att Mercurial inte kan skriva om historiken, bara lägga till. Så här ser vårt Mercurial‑kodförråd ut efter en interaktiv ombasering och en tvångsuppskickning: [source,console] @@ -393,4 +393,4 @@ Det kan vara *mycket* förvirrande för dina teamkamrater som använder Mercuria ===== Sammanfattning för Mercurial Git och Mercurial är tillräckligt lika för att arbete över gränsen ska vara ganska smärtfritt. -Om du undviker att ändra historik som har lämnat din maskin (som generellt rekommenderas) kanske du inte ens märker att den andra änden är Mercurial. +Om du undviker att ändra historik som har lämnat din maskin (som i allmänhet rekommenderas) kanske du inte ens märker att den andra änden är Mercurial. diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index cbdecf26..6154eb4d 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -7,9 +7,9 @@ Det har funnits sedan 1995, vilket gör det till det äldsta systemet som behand Därför är det utformat med sin tids begränsningar; det antar att du alltid är uppkopplad mot en enda central server och att bara en version hålls på den lokala disken. För tydlighetens skull är dess funktioner och begränsningar väl lämpade för flera specifika problem, men det finns många projekt som använder Perforce där Git egentligen skulle fungera bättre. -Det finns två alternativ om du vill kombinera användningen av Perforce och Git. +Det finns två alternativ om du vill använda både Perforce och Git. Det första vi går igenom är "`Git Fusion`"‑bryggan från Perforces skapare, som låter dig exponera underträd i din Perforce‑depå som läs‑ och skrivbara Git‑kodförråd. -Det andra är git-p4, en brygga på klientsidan som låter dig använda Git som Perforce‑klient utan att kräva någon omkonfigurering av Perforce‑servern. +Det andra är git-p4, en brygga på klientsidan som låter dig använda Git som Perforce‑klient utan att behöva konfigurera om Perforce‑servern. [[_p4_git_fusion]] ===== Git Fusion @@ -22,7 +22,7 @@ Perforce tillhandahåller en produkt som heter Git Fusion (tillgänglig på http I våra exempel använder vi den enklaste installationsmetoden för Git Fusion, vilket är att ladda ner en virtuell maskin som kör Perforce‑demonen och Git Fusion. Du kan hämta den virtuella maskinavbildningen från https://www.perforce.com/downloads[^], och när nedladdningen är klar importerar du den i din favorit‑virtualiseringsmjukvara (vi använder VirtualBox). -När du startar maskinen första gången ber den dig att anpassa lösenordet för tre Linux‑användare (`root`, `perforce` och `git`) samt ange ett instansnamn som kan användas för att skilja installationen från andra på samma nätverk. +När du startar maskinen första gången ber den dig att anpassa lösenordet för tre Linux‑användare (`root`, `perforce` och `git`) samt ange ett instansnamn som skiljer installationen från andra på samma nätverk. När det är klart ser du detta: .Git Fusions uppstartsskärm för den virtuella maskinen @@ -75,7 +75,7 @@ Här klonar vi över HTTPS, med användaren `john` som vi skapade ovan; Git ber ====== Fusion-konfiguration När du har installerat Git Fusion vill du justera konfigurationen. -Det är ganska enkelt att göra med din favorit‑Perforce‑klient; mappa bara katalogen `//.git-fusion` på Perforce‑servern till din arbetskatalog. +Det är ganska enkelt att göra med din favorit‑Perforce‑klient; koppla bara katalogen `//.git-fusion` på Perforce‑servern till din arbetskatalog. Filstrukturen ser ut så här: [source,console] @@ -98,9 +98,9 @@ $ tree 498 directories, 287 files ---- -Katalogen `objects` används internt av Git Fusion för att mappa Perforce‑objekt till Git och vice versa; du behöver inte röra något där. +Katalogen `objects` används internt av Git Fusion för att koppla Perforce‑objekt till Git och vice versa; du behöver inte röra något där. Det finns en global `p4gf_config`‑fil i katalogen, samt en för varje kodförråd – det är konfigurationsfilerna som avgör hur Git Fusion beter sig. -Låt oss titta på filen i roten: +Vi tittar på filen i roten: [source,ini] ---- @@ -147,7 +147,7 @@ view = //depot/Talkhouse/main-dev/... ... Det här är en mappning mellan en Perforce‑gren och en Git‑gren. Sektionen kan heta vad du vill, så länge namnet är unikt. `git-branch-name` låter dig omvandla en depot‑sökväg som skulle vara besvärlig i Git till ett mer vänligt namn. -Inställningen `view` styr hur Perforce‑filer mappas in i Git‑kodförrådet med hjälp av standard‑syntax för view‑mappning. +Inställningen `view` styr hur Perforce‑filer kopplas till Git‑kodförrådet med hjälp av standard‑syntax för view‑mappning. Mer än en mappning kan anges, som i detta exempel: [source,ini] @@ -160,7 +160,7 @@ view = //depot/project1/main/... project1/... På så sätt kan du, om din normala arbetsytemappning inkluderar förändringar i katalogstrukturen, replikera det med ett Git‑kodförråd. -Den sista filen vi tar upp är `users/p4gf_usermap`, som mappar Perforce‑användare till Git‑användare, och som du kanske inte ens behöver. +Den sista filen vi tar upp är `users/p4gf_usermap`, som kopplar Perforce‑användare till Git‑användare, och som du kanske inte ens behöver. När man konverterar från en Perforce‑ändringsuppsättning till en Git‑incheckning är Git Fusions standardbeteende att slå upp Perforce‑användaren och använda e‑postadressen och fullständiga namnet som är lagrat där i Git‑fältet för författare/incheckare. När man konverterar åt andra hållet är standarden att slå upp Perforce‑användaren med e‑postadressen som finns i Git‑incheckningens author‑fält och skicka in ändringsuppsättningen som den användaren (med tillhörande behörigheter). I de flesta fall fungerar detta alldeles utmärkt, men titta på följande mappningsfil: @@ -174,8 +174,8 @@ joe employeeY@example.com "Anon Y. Mouse" ---- Varje rad har formatet ` ""` och skapar en användarmappning. -De två första raderna mappar två olika e‑postadresser till samma Perforce‑användarkonto. -Det här är användbart om du har skapat Git‑incheckningar under flera olika e‑postadresser (eller byter e‑postadress) men vill att de ska mappas till samma Perforce‑användare. +De två första raderna kopplar två olika e‑postadresser till samma Perforce‑användarkonto. +Det här är användbart om du har skapat Git‑incheckningar under flera olika e‑postadresser (eller byter e‑postadress) men vill att de ska kopplas till samma Perforce‑användare. När en Git‑incheckning skapas från en Perforce‑ändringsuppsättning används den första raden som matchar Perforce‑användaren för Git‑författarinformationen. De två sista raderna maskerar Bobs och Joes riktiga namn och e‑postadresser i Git‑incheckningarna som skapas. @@ -185,7 +185,7 @@ Observera att e‑postadresserna och fullständiga namnen bör vara unika, om du ====== Arbetsflöde Perforce Git Fusion är en tvåvägsbrygga mellan Perforce och Git. -Låt oss titta på hur det känns att arbeta från Git‑sidan. +Vi tittar på hur det känns att arbeta från Git‑sidan. Vi antar att vi har mappat in projektet "`Jam`" med en konfigurationsfil som visas ovan, vilket vi kan klona så här: [source,console] @@ -215,13 +215,13 @@ $ git log --oneline --decorate --graph --all ---- Första gången du gör detta kan det ta en stund. -Det som händer är att Git Fusion konverterar alla relevanta ändringsuppsättningar i Perforce‑historiken till Git‑incheckningar. +Git Fusion konverterar då alla relevanta ändringsuppsättningar i Perforce‑historiken till Git‑incheckningar. Det sker lokalt på servern, så det går relativt snabbt, men om du har mycket historik kan det ändå ta tid. Efterföljande uppdateringar gör inkrementell konvertering, så det känns mer som Gits egen hastighet. Som du ser liknar vårt kodförråd vilket annat Git‑kodförråd som helst. Det finns tre grenar, och Git har hjälpsamt skapat en lokal `master`‑gren som spårar `origin/master`. -Låt oss göra lite arbete och skapa ett par nya incheckningar: +Vi gör lite arbete och skapar ett par nya incheckningar: [source,console] ---- @@ -259,7 +259,7 @@ $ git log --oneline --decorate --graph --all Det ser ut som att någon gjorde det! Du skulle inte veta det från den här vyn, men incheckningen `6afeb15` skapades i själva verket med en Perforce‑klient. Den ser bara ut som en annan incheckning ur Gits perspektiv, vilket är precis poängen. -Låt oss se hur Perforce‑servern hanterar en sammanslagningsincheckning: +Vi ser hur Perforce‑servern hanterar en sammanslagningsincheckning: [source,console] ---- @@ -286,7 +286,7 @@ To https://10.0.1.254/Jam ---- Git tycker att det fungerade. -Låt oss titta på historiken för filen `README` ur Perforces perspektiv, med hjälp av revisionsgraf‑funktionen i `p4v`: +Vi tittar på historiken för filen `README` ur Perforces perspektiv, med revisionsgraf‑funktionen i `p4v`: .Perforce‑revisionsgraf som resultat av Git‑uppskickning image::images/git-fusion-perforce-graph.png[Perforce‑revisionsgraf som resultat av Git‑uppskickning] @@ -296,9 +296,9 @@ Vi tittar på historiken för filen `README`, så katalogträdet uppe till väns Uppe till höger har vi en visuell graf över hur olika revisioner av filen hänger ihop, och översiktsvyn av grafen finns nere till höger. Resten av vyn är detaljvyn för den valda revisionen (i det här fallet `2`). -En sak att lägga märke till är att grafen ser exakt ut som den i Gits historik. +Lägg märke till att grafen ser exakt ut som den i Gits historik. Perforce hade ingen namngiven gren för att lagra incheckningarna `1` och `2`, så den skapade en "`anonym`"‑gren i katalogen `.git-fusion` för att hålla dem. -Detta händer även för namngivna Git‑grenar som inte motsvarar en namngiven Perforce‑gren (och du kan senare mappa dem till en Perforce‑gren med hjälp av konfigurationsfilen). +Detta händer även för namngivna Git‑grenar som inte motsvarar en namngiven Perforce‑gren (och du kan senare koppla dem till en Perforce‑gren via konfigurationsfilen). Det mesta av detta sker bakom kulisserna, men slutresultatet är att en person i ett team kan använda Git, en annan kan använda Perforce, och ingen av dem behöver veta om den andres val. @@ -375,7 +375,7 @@ Git-p4 har skapat vissa referenser som representerar serverns tillstånd, och de ====== Arbetsflöde -Okej, låt oss göra lite arbete. +Okej, vi gör lite arbete. Anta att du har gjort en del framsteg på en mycket viktig funktion och är redo att visa den för resten av teamet. [source,console] @@ -387,7 +387,7 @@ $ git log --oneline --all --graph --decorate ---- Vi har gjort två nya incheckningar som vi är redo att skicka in till Perforce‑servern. -Låt oss se om någon annan arbetade i dag: +Vi ser om någon annan arbetade i dag: [source,console] ---- @@ -538,7 +538,7 @@ Date: Sun Aug 31 10:31:44 2014 -0800 ---- Vad händer om du försöker skicka in en sammanslagningsincheckning? -Låt oss prova. +Vi provar. Här är läget vi har försatt oss i: [source,console] @@ -560,7 +560,7 @@ $ git log --oneline --all --graph --decorate Git‑ och Perforce‑historiken divergerar efter `775a46f`. Git‑sidan har två incheckningar, sedan en sammanslagningsincheckning med Perforce‑toppen, och sedan en till incheckning. Vi ska försöka skicka in dessa ovanpå en enda ändringsuppsättning på Perforce‑sidan. -Låt oss se vad som skulle hända om vi försökte skicka in nu: +Vi ser vad som skulle hända om vi försökte skicka in nu: [source,console] ---- @@ -575,7 +575,7 @@ Would apply Flaggan `-n` är en förkortning för `--dry-run`, som försöker rapportera vad som skulle hända om submit‑kommandot kördes på riktigt. I det här fallet ser det ut som att vi skulle skapa tre Perforce‑ändringsuppsättningar, som motsvarar de tre icke‑sammanfogade incheckningarna som ännu inte finns på Perforce‑servern. -Det låter precis som vad vi vill, så låt oss se hur det går: +Det låter precis som vad vi vill, så vi ser hur det går: [source,console] ---- @@ -641,7 +641,7 @@ $ cd project; git log --oneline --all --graph --decorate Lägg märke till specifikationen "`@all`" i depå‑sökvägen; den säger till git-p4 att klona inte bara den senaste ändringsuppsättningen för det underträdet, utan alla ändringsuppsättningar som någonsin har rört dessa sökvägar. Detta ligger närmare Gits klonbegrepp, men om du arbetar på ett projekt med lång historik kan det ta tid. -Flaggan `--detect-branches` säger åt git-p4 att använda Perforces gren‑specifikationer för att mappa grenar till Git‑referenser. +Flaggan `--detect-branches` säger åt git-p4 att använda Perforces gren‑specifikationer för att koppla grenar till Git‑referenser. Om dessa mappningar inte finns på Perforce‑servern (vilket är ett helt giltigt sätt att använda Perforce) kan du tala om för git-p4 vad grenmappningarna är, och då får du samma resultat: [source,console] @@ -664,8 +664,8 @@ Om du sammanfogar två grenar i Git och försöker skicka in den nya ändringsup ===== Sammanfattning om Git och Perforce -Git-p4 gör det möjligt att använda ett Git‑arbetsflöde med en Perforce‑server, och det fungerar ganska bra. +Med Git-p4 kan du använda ett Git‑arbetsflöde med en Perforce‑server, och det fungerar ganska bra. Det är dock viktigt att komma ihåg att Perforce styr källan och att du bara använder Git för att arbeta lokalt. Var mycket försiktig med att dela Git‑incheckningar; om du har ett fjärrkodförråd som andra använder, skicka inte in några incheckningar som inte redan har skickats in till Perforce‑servern. -Om du vill blanda användningen av Perforce och Git fritt som klienter för versionshantering, och du kan övertyga serveradministratören att installera det, gör Git Fusion Git till en förstklassig versionshanteringsklient för en Perforce‑server. +Om du fritt vill växla mellan Perforce och Git som versionshanteringsklienter, och du kan övertyga serveradministratören att installera det, gör Git Fusion Git till en förstklassig versionshanteringsklient för en Perforce‑server. diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index d710509d..4e90ba58 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -19,7 +19,7 @@ Grundkommandot i Git för alla Subversion‑bryggkommandon är `git svn`. Det har ganska många underkommandon, så vi visar de vanligaste medan vi går igenom några enkla arbetsflöden. Tänk på att när du använder `git svn` så interagerar du med Subversion, som fungerar på ett helt annat sätt än Git. -Även om du *kan* göra lokala grenar och sammanslagningar är det generellt bäst att hålla historiken så linjär som möjligt genom att ombasera ditt arbete och undvika att samtidigt arbeta mot ett Git‑fjärrkodförråd. +Även om du *kan* göra lokala grenar och sammanslagningar är det i allmänhet bäst att hålla historiken så linjär som möjligt genom att ombasera ditt arbete och undvika att samtidigt arbeta mot ett Git‑fjärrkodförråd. Skriv inte om historiken och försök skicka på nytt, och skicka inte upp till ett parallellt Git‑kodförråd för att samarbeta med andra Git‑utvecklare samtidigt. Subversion kan bara ha en enda linjär historik, och det är mycket lätt att förvirra den. @@ -131,7 +131,7 @@ $ git branch -a Lägg märke till hur verktyget hanterar Subversion‑taggar som fjärrreferenser. (((git commands, show-ref))) -Låt oss titta närmare med Git‑lågnivåkommandot `show-ref`: +Vi tittar närmare med Git‑lågnivåkommandot `show-ref`: [source,console] ---- @@ -190,7 +190,7 @@ Resetting to the latest refs/remotes/origin/trunk Det här tar alla dina lokala incheckningar ovanpå Subversion-koden, gör en Subversion-incheckning för var och en och skriver sedan om de lokala Git-incheckningarna med en unik identifierare. Det är viktigt, eftersom alla SHA-1-kontrollsummor för dina incheckningar ändras. -Delvis av den anledningen är det ingen bra idé att arbeta samtidigt med Git‑baserade fjärrversioner av dina projekt parallellt med en Subversion‑server. +Delvis av den anledningen bör du inte arbeta samtidigt med Git‑baserade fjärrversioner av dina projekt parallellt med en Subversion‑server. Om du tittar på den senaste incheckningen kan du se den nya `git-svn-id` som lagts till: [source,console] @@ -283,7 +283,7 @@ W: a0253d06732169107aa020390d9fefd2b1d92806 and refs/remotes/origin/trunk differ First, rewinding head to replay your work on top of it... ---- -Det är viktigt att komma ihåg, eftersom resultatet kan bli ett projekttillstånd som inte fanns på någon av era datorer vid uppskickning. +Kom ihåg detta, eftersom resultatet kan bli ett projekttillstånd som inte fanns på någon av era datorer vid uppskickning. Om ändringarna är inkompatibla men inte i konflikt kan du få problem som är svåra att felsöka. Till skillnad från en Git-server kan du i Git testa hela tillståndet lokalt innan publicering, medan du i SVN inte kan vara säker på att tillstånden före och efter incheckning är identiska. @@ -305,9 +305,9 @@ Om du har lokala ändringar måste du antingen lägga undan arbetet med `git sta ===== Problem med Git‑grenar -När du har blivit bekväm med ett Git‑arbetsflöde skapar du sannolikt ämnesgrenar, gör arbete på dem och sammanfogar dem sedan. +När du har blivit van vid ett Git‑arbetsflöde skapar du sannolikt ämnesgrenar, gör arbete på dem och sammanfogar dem sedan. Om du skickar upp till en Subversion‑server via `git svn` kan du vilja ombasera ditt arbete till en enda gren varje gång i stället för att sammanfoga grenar. -Anledningen till att föredra ombasering är att Subversion har en linjär historik och inte hanterar sammanslagningar som Git gör, så `git svn` följer bara den första föräldern när den konverterar ögonblicksbilderna till Subversion‑incheckningar. +Ombasering passar bättre eftersom Subversion har en linjär historik och inte hanterar sammanslagningar som Git gör, så `git svn` följer bara den första föräldern när den konverterar ögonblicksbilderna till Subversion‑incheckningar. Anta att din historik ser ut så här: du skapade en gren `experiment`, gjorde två incheckningar och sammanfogade dem sedan tillbaka till `master`. När du kör `dcommit` ser du utdata som detta: @@ -381,7 +381,7 @@ För att undvika problem bör du ta bort den lokala grenen (i detta fall `opera` ===== Subversion-kommandon -Verktygsuppsättningen `git svn` ger ett antal kommandon som underlättar övergången till Git genom att erbjuda funktionalitet som liknar det du hade i Subversion. +Verktygsuppsättningen `git svn` ger flera kommandon som underlättar övergången till Git genom att erbjuda funktionalitet som liknar det du hade i Subversion. Här är några kommandon som ger dig det Subversion brukade ge. ====== SVN-stil på historiken @@ -487,4 +487,4 @@ För att undvika problem, försök att följa dessa riktlinjer: Du kan till och med vilja lägga till en `pre-receive`‑krok som kontrollerar varje incheckningsmeddelande efter ett `git-svn-id` och avvisar uppskickningar som innehåller incheckningar utan det. Om du följer dessa riktlinjer kan arbete mot en Subversion‑server bli mer uthärdligt. -Men om det är möjligt att flytta till en riktig Git‑server ger det teamet mycket mer. +Men om det går att flytta till en riktig Git‑server ger det teamet mycket mer. diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index 89e0067d..1a889720 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -30,7 +30,7 @@ Allt du behöver göra är att tala om för `fast-import` vilka ögonblicksbilde Din strategi blir att gå igenom ögonblicksbilderna en i taget och skapa incheckningar med innehållet i varje katalog, där varje incheckning länkar tillbaka till den föregående. Som vi gjorde i <> skriver vi detta i Ruby, eftersom det är det vi vanligtvis arbetar med och det brukar vara lätt att läsa. -Du kan skriva exemplet ganska enkelt i vilket språk du är bekväm med – det behöver bara skriva rätt information till standardutmatningen. +Du kan skriva exemplet ganska enkelt i vilket språk du är van vid – det behöver bara skriva rätt information till standardutmatningen. Och om du kör på Windows betyder det att du måste vara extra noga med att inte introducera vagnreturer i slutet av dina rader – `git fast-import` vill absolut bara ha radmatningar (LF) och inte de vagnretur‑radmatningar (CRLF) som Windows använder. Till att börja med byter du till målkatalogen och identifierar varje underkatalog, som var och en är en ögonblicksbild du vill importera som en incheckning. @@ -142,7 +142,7 @@ def export_data(string) end ---- -Allt som återstår är att ange filinnehållet för varje ögonblicksbild. +Nu återstår bara att ange filinnehållet för varje ögonblicksbild. Det är enkelt eftersom du har varje ögonblicksbild i en katalog – du kan skriva ut kommandot `deleteall` följt av innehållet i varje fil i katalogen. Git registrerar sedan varje ögonblicksbild på rätt sätt: @@ -182,7 +182,7 @@ end Du återanvänder metoden `export_data` som du definierade tidigare, eftersom den är densamma som när du angav data för incheckningsmeddelandet. -Det sista du behöver göra är att returnera den aktuella markeringen så att den kan skickas vidare till nästa varv: +Slutligen returnerar du den aktuella markeringen så att den kan skickas vidare till nästa varv: [source,ruby] ---- @@ -354,7 +354,7 @@ Date: Mon Feb 3 01:00:00 2014 -0700 imported from back_2014_02_03 ---- -Där har du det – ett snyggt, rent Git‑kodförråd. +Så har du ett snyggt, rent Git‑kodförråd. Tänk på att inget är utcheckat – du har inga filer i arbetskatalogen till att börja med. För att få dem måste du återställa din gren till där `master` är nu: diff --git a/book/09-git-and-other-scms/sections/import-hg.asc b/book/09-git-and-other-scms/sections/import-hg.asc index cfb631f2..c1447c3c 100644 --- a/book/09-git-and-other-scms/sections/import-hg.asc +++ b/book/09-git-and-other-scms/sections/import-hg.asc @@ -1,14 +1,14 @@ ==== Mercurial (((Mercurial)))(((Importing, from Mercurial))) -Eftersom Mercurial och Git har ganska liknande modeller för att representera versioner, och eftersom Git är lite mer flexibelt, är det ganska okomplicerat att konvertera ett kodförråd från Mercurial till Git med hjälp av verktyget "hg-fast-export", som du behöver ha en kopia av: +Eftersom Mercurial och Git har ganska liknande modeller för att representera versioner, och eftersom Git är lite mer flexibelt, är det ganska okomplicerat att konvertera ett kodförråd från Mercurial till Git med verktyget "hg-fast-export", som du behöver ha en kopia av: [source,console] ---- $ git clone https://github.com/frej/fast-export.git ---- -Det första steget i konverteringen är att göra en fullständig klon av Mercurial‑kodförrådet du vill konvertera: +Det första steget i konverteringen är att fullständigt klona Mercurial‑kodförrådet du vill konvertera: [source,console] ---- @@ -38,7 +38,7 @@ Joe Smith ---- I exemplet har samma person (Bob) skapat ändringsuppsättningar under fyra olika namn, varav ett ser korrekt ut och ett skulle vara helt ogiltigt som Git‑incheckning. -Hg-fast-export låter oss fixa detta genom att omvandla varje rad till en regel: `""=""`, som mappar ett `` till ett ``. +Hg-fast-export låter oss fixa detta genom att omvandla varje rad till en regel: `""=""`, som kopplar ett `` till ett ``. I strängarna `` och `` stöds alla escape‑sekvenser som Pythons `string_escape`‑kodning förstår. Om författarmappningsfilen inte innehåller ett matchande `` skickas författaren vidare till Git oförändrad. Om alla användarnamn ser bra ut behöver vi inte filen alls. @@ -52,7 +52,7 @@ I exemplet vill vi att filen ska se ut så här: "bob jones company com>"="Bob Jones " ---- -Samma typ av mappningsfil kan användas för att byta namn på grenar och taggar när Mercurial‑namnet inte tillåts av Git. +Med samma typ av mappningsfil kan du byta namn på grenar och taggar när Mercurial‑namnet inte tillåts av Git. Nästa steg är att skapa vårt nya Git‑kodförråd och köra exportskriptet: diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc index d18c88c0..36dbeb3f 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -9,7 +9,7 @@ Importen är dock inte perfekt, och eftersom den ändå tar lång tid kan du lik Det första problemet är författarinformationen. I Subversion har varje person som checkar in en användare i systemet som registreras i incheckningsinformationen. Exemplen i föregående avsnitt visar `schacon` på vissa ställen, till exempel i `blame`‑utdata och `git svn log`. -Om du vill mappa detta till bättre Git‑författardata behöver du en mappning från Subversion‑användare till Git‑författare. +Om du vill koppla detta till bättre Git‑författardata behöver du en mappning från Subversion‑användare till Git‑författare. Skapa en fil som heter `users.txt` med denna mappning i ett format som ser ut så här: [source] @@ -36,7 +36,7 @@ Om du provar detta på en Windows‑maskin är det här punkten där du kommer a Microsoft har lagt upp några bra råd och exempel på https://learn.microsoft.com/en-us/azure/devops/repos/git/perform-migration-from-svn-to-git[^]. ==== -Du kan ge denna fil till `git svn` för att hjälpa den mappa författardata mer exakt. +Du kan ge denna fil till `git svn` för att hjälpa den koppla författardata mer exakt. Du kan också säga åt `git svn` att inte inkludera metadata som Subversion normalt importerar genom att skicka `--no-metadata` till kommandot `clone` eller `init`. Metadata innehåller en `git-svn-id` i varje incheckningsmeddelande som Git skapar under importen. Det kan göra din Git‑logg onödigt stor och svårare att läsa. @@ -106,7 +106,7 @@ $ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git Det kan hända att du ser några extra grenar som slutar med `@xxx` (där xxx är ett nummer), trots att du i Subversion bara ser en gren. Det här är en Subversion‑funktion som kallas "`peg‑revisioner`", vilket är något som Git helt saknar en syntaktisk motsvarighet till. -Därför lägger `git svn` helt enkelt till SVN‑versionsnumret i grennamnet på samma sätt som du hade skrivit det i SVN för att adressera peg‑revisionen för den grenen. +Därför lägger `git svn` helt enkelt till SVN‑versionsnumret i grennamnet på samma sätt som du hade skrivit det i SVN för att referera till peg‑revisionen för den grenen. Om du inte längre bryr dig om peg‑revisionerna kan du bara ta bort dem: [source,console] @@ -117,8 +117,8 @@ $ for p in $(git for-each-ref --format='%(refname:short)' | grep @); do git bran Nu är alla de gamla grenarna riktiga Git‑grenar och alla de gamla taggarna riktiga Git‑taggar. Det finns en sista sak att städa upp. -Tyvärr skapar `git svn` en extra gren som heter `trunk`, som mappar till Subversions standardgren, men referensen `trunk` pekar på samma ställe som `master`. -Eftersom `master` är mer idiomatiskt Git gör du så här för att ta bort den extra grenen: +Tyvärr skapar `git svn` en extra gren som heter `trunk`, som motsvarar Subversions standardgren, men referensen `trunk` pekar på samma ställe som `master`. +Eftersom `master` är mer typiskt för Git, gör du så här för att ta bort den extra grenen: [source,console] ---- diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index 37ff8718..ffac6ca7 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -1,7 +1,7 @@ === Miljövariabler -Git kör alltid i ett `bash`‑skal och använder ett antal miljövariabler i skalet för att avgöra hur det beter sig. -Ibland är det praktiskt att veta vilka dessa är och hur de kan användas för att få Git att bete sig som du vill. +Git kör alltid i ett `bash`‑skal och använder flera miljövariabler i skalet för att avgöra hur det beter sig. +Ibland är det praktiskt att veta vilka dessa är och hur du kan använda dem för att styra Gits beteende. Det här är inte en komplett lista över alla miljövariabler Git uppmärksammar, men vi tar upp de mest användbara. ==== Globalt beteende @@ -17,10 +17,10 @@ Om du vill ha en verkligt portabel Git‑installation med global konfiguration k Liknande gäller *`PREFIX`*, men för systemomfattande konfiguration. Git letar efter denna fil vid `$PREFIX/etc/gitconfig`. -*`GIT_CONFIG_NOSYSTEM`* inaktiverar, om den är satt, användningen av den systemomfattande konfigurationsfilen. +*`GIT_CONFIG_NOSYSTEM`* hindrar, om den är satt, Git från att läsa den systemomfattande konfigurationsfilen. Det är användbart om din systemkonfiguration stör dina kommandon, men du inte har åtkomst att ändra eller ta bort den. -*`GIT_PAGER`* styr programmet som används för att visa flersidiga utdata på kommandoraden. +*`GIT_PAGER`* styr programmet som visar flersidiga utdata på kommandoraden. Om den är osatt används `PAGER` som reserv. *`GIT_EDITOR`* är redigeraren som Git startar när användaren behöver redigera text (till exempel ett incheckningsmeddelande). @@ -41,10 +41,10 @@ Om `--git-dir` eller `GIT_DIR` anges men inget av `--work-tree`, `GIT_WORK_TREE` *`GIT_INDEX_FILE`* är sökvägen till indexfilen (endast icke‑bara kodförråd). -*`GIT_OBJECT_DIRECTORY`* kan användas för att ange platsen för katalogen som vanligtvis ligger på `.git/objects`. +Med *`GIT_OBJECT_DIRECTORY`* anger du platsen för katalogen som vanligtvis ligger på `.git/objects`. *`GIT_ALTERNATE_OBJECT_DIRECTORIES`* är en kolon‑separerad lista (formaterad som `/dir/one:/dir/two:…`) som talar om för Git var det ska leta efter objekt om de inte finns i `GIT_OBJECT_DIRECTORY`. -Om du råkar ha många projekt med stora filer som har exakt samma innehåll kan detta användas för att undvika att lagra för många kopior av dem. +Om du råkar ha många projekt med stora filer som har exakt samma innehåll kan du undvika att lagra för många kopior av dem. ==== Pathspecar @@ -61,7 +61,7 @@ Du kan åsidosätta detta i enskilda fall genom att börja pathspecen med `:(glo ==== Incheckning -Det slutliga skapandet av ett Git‑incheckningsobjekt görs vanligtvis av `git-commit-tree`, som använder dessa miljövariabler som sin primära informationskälla och bara faller tillbaka på konfigurationsvärden om dessa inte finns. +Git‑incheckningsobjekt skapas slutligen vanligtvis av `git-commit-tree`, som använder dessa miljövariabler som sin primära informationskälla och bara faller tillbaka på konfigurationsvärden om dessa inte finns. *`GIT_AUTHOR_NAME`* är det mänskligt läsbara namnet i fältet "`author`". @@ -221,7 +221,7 @@ Det är programmet som anropas när Git behöver be användaren om autentisering *`GIT_NAMESPACE`* styr åtkomst till namnrymda refs och är likvärdigt med flaggan `--namespace`. Det är mest användbart på serversidan, där du kan vilja lagra flera namnrymder för ett enda kodförråd i samma kodförråd och hålla refs separerade. -*`GIT_FLUSH`* kan användas för att tvinga Git att använda icke‑buffrad I/O när det skriver inkrementellt till stdout. +Med *`GIT_FLUSH`* kan du tvinga Git att använda icke‑buffrad I/O när det skriver inkrementellt till stdout. Ett värde på 1 gör att Git flushar oftare, ett värde på 0 gör att all utdata buffras. Standardvärdet (om variabeln inte är satt) är att välja en lämplig buffringsstrategi beroende på aktivitet och utdataläge. diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index 6962881b..3ca26048 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -9,7 +9,7 @@ Det här avsnittet går igenom några av dessa scenarier. Ibland kör Git automatiskt ett kommando som kallas "`auto gc`". För det mesta gör det ingenting. Men om det finns för många lösa objekt (objekt som inte ligger i en packfil) eller för många packfiler startar Git ett fullständigt `git gc`‑kommando. -"`gc`" står för skräpinsamling och kommandot gör ett antal saker: det samlar ihop alla lösa objekt och placerar dem i packfiler, det konsoliderar packfiler till en stor packfil, och det tar bort objekt som inte kan nås från någon incheckning och som är några månader gamla. +"`gc`" står för skräpinsamling och kommandot gör flera saker: det samlar ihop alla lösa objekt och placerar dem i packfiler, det konsoliderar packfiler till en stor packfil, och det tar bort objekt som inte kan nås från någon incheckning och som är några månader gamla. Du kan köra `auto gc` manuellt så här: @@ -89,7 +89,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit Du har i praktiken förlorat de två senaste incheckningarna – du har ingen gren från vilken dessa incheckningar är nåbara. Du behöver hitta SHA‑1:an för den senaste incheckningen och sedan lägga till en gren som pekar på den. -Tricket är att hitta den senaste SHA‑1:an – det är inte direkt så att du har den i huvudet, eller hur? +Utmaningen är att hitta den senaste SHA‑1:an – det är inte direkt så att du har den i huvudet, eller hur? Ofta är det snabbast att använda verktyget `git reflog`. När du arbetar registrerar Git tyst vad `HEAD` pekar på varje gång du ändrar den. @@ -153,7 +153,7 @@ $ rm -Rf .git/logs/ ---- Eftersom reflogdata lagras i katalogen `.git/logs/` har du i praktiken ingen reflogg. -Hur kan du återställa den incheckningen vid det här laget? +Hur kan du nu återställa den incheckningen? Ett sätt är att använda verktyget `git fsck`, som kontrollerar din databas för integritet. Om du kör det med alternativet `--full` visar det alla objekt som inte pekas på av ett annat objekt: @@ -241,9 +241,9 @@ size-garbage: 0 ---- Posten `size-pack` är storleken på dina packfiler i kilobyte, så du använder nästan 5 MB. -Före den senaste incheckningen använde du närmare 2K – det är tydligt att borttagningen av filen i den föregående incheckningen inte tog bort den ur historiken. +Före den senaste incheckningen använde du närmare 2K – det är tydligt att filen inte försvann ur historiken när du tog bort den i föregående incheckning. Varje gång någon klonar detta kodförråd måste de klona hela 5 MB bara för att få detta lilla projekt, eftersom du av misstag lade till en stor fil. -Låt oss bli av med den. +Nu blir vi av med den. Först måste du hitta den. I det här fallet vet du redan vilken fil det är. @@ -297,7 +297,7 @@ Ref 'refs/heads/master' was rewritten Alternativet `--index-filter` liknar alternativet `--tree-filter` som användes i <>, förutom att du i stället för att skicka ett kommando som ändrar filer som är utlagda på disk, ändrar din köyta eller index varje gång. I stället för att ta bort en specifik fil med något som `rm file` måste du ta bort den med `git rm --cached` – du måste ta bort den från indexet, inte från disk. -Anledningen till att göra det så här är hastighet – eftersom Git inte behöver lägga ut varje revision till disk innan filtret körs kan processen gå mycket, mycket snabbare. +Det görs så här för att det går snabbare – Git behöver inte lägga ut varje revision till disk innan filtret körs. Du kan åstadkomma samma uppgift med `--tree-filter` om du vill. Alternativet `--ignore-unmatch` till `git rm` säger åt det att inte ge fel om mönstret du försöker ta bort inte finns där. Slutligen ber du `filter-branch` att skriva om historiken bara från incheckningen `7b30847` och uppåt, eftersom du vet att det var där problemet började. @@ -319,7 +319,7 @@ Writing objects: 100% (15/15), done. Total 15 (delta 1), reused 12 (delta 0) ---- -Låt oss se hur mycket utrymme du sparade. +Vi ser hur mycket utrymme du sparade. [source,console] ---- diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index ccc09eee..a26149e7 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -34,7 +34,7 @@ d670460b4b4aece5915caf5c68d12f560a9fe3e4 I sin enklaste form skulle `git hash-object` ta innehållet du gav det och bara returnera den unika nyckel som _skulle_ användas för att lagra det i din Git‑databas. Flaggan `-w` säger sedan åt kommandot att inte bara returnera nyckeln utan också skriva objektet till databasen. -Slutligen säger alternativet `--stdin` åt `git hash-object` att hämta innehållet som ska behandlas från stdin; annars skulle kommandot förvänta sig ett filnamn i slutet av kommandot som innehåller innehållet som ska användas. +Slutligen säger alternativet `--stdin` åt `git hash-object` att hämta innehållet som ska behandlas från stdin; annars förväntar sig kommandot ett filnamn med innehållet som ska behandlas. Utdata från kommandot ovan är en kontrollsumma på 40 tecken. Det är SHA‑1‑summan – en kontrollsumma av innehållet du lagrar plus ett huvud, som du får lära dig mer om strax. @@ -62,7 +62,7 @@ test content Nu kan du lägga till innehåll i Git och hämta tillbaka det igen. Du kan också göra detta med innehåll i filer. -Du kan till exempel göra enkel versionshantering av en fil. +Du kan till exempel enkelt versionshantera en fil. Först skapar du en ny fil och sparar dess innehåll i databasen: [source,console] @@ -91,7 +91,7 @@ $ find .git/objects -type f .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 ---- -Vid det här laget kan du ta bort din lokala kopia av filen `test.txt` och sedan använda Git för att hämta antingen den första versionen du sparade från objektdatabasen: +Nu kan du ta bort din lokala kopia av filen `test.txt` och sedan använda Git för att hämta antingen den första versionen du sparade från objektdatabasen: [source,console] ---- @@ -126,7 +126,7 @@ Nästa typ av Git‑objekt vi tittar på är _trädet_, som löser problemet med Git lagrar innehåll på ett sätt som liknar ett UNIX‑filsystem, men lite förenklat. Allt innehåll lagras som träd‑ och blob‑objekt, där träd motsvarar UNIX‑katalogposter och blobbar motsvarar ungefär inoder eller filinnehåll. Ett enskilt trädobjekt innehåller en eller flera poster, där varje post är SHA‑1‑summan för en blob eller ett underträd tillsammans med tillhörande läge, typ och filnamn. -Låt oss till exempel säga att du har ett projekt där det senaste trädet ser ut ungefär så här: +Säg till exempel att du har ett projekt där det senaste trädet ser ut ungefär så här: [source,console] ---- @@ -236,7 +236,7 @@ $ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 ---- Om du skapade en arbetskatalog från det nya träd du just skrev skulle du få de två filerna på toppnivån i arbetskatalogen och en underkatalog som heter `bak` som innehåller den första versionen av filen `test.txt`. -Du kan tänka på den data Git innehåller för dessa strukturer ungefär så här: +Gits data för dessa strukturer ser ungefär ut så här: .Innehållsstrukturen för dina nuvarande Git‑data image::images/data-model-2.png[Innehållsstrukturen för dina nuvarande Git‑data] @@ -326,7 +326,7 @@ Date: Fri May 22 18:09:34 2009 -0700 Toppen. Du har just gjort lågnivåoperationerna för att bygga upp en Git‑historik utan att använda några av gränssnittskommandona. I stort sett är det här vad Git gör när du kör `git add` och `git commit`: lagrar blobbar för ändrade filer, uppdaterar indexet, skriver träd och skapar incheckningsobjekt som pekar på toppnivåträd och föregående incheckningar. -Dessa tre huvudsakliga Git‑objekt – blobben, trädet och incheckningen – lagras initialt som separata filer i din `.git/objects`‑katalog. +Dessa tre huvudsakliga Git‑objekt – blobben, trädet och incheckningen – lagras till en början som separata filer i din `.git/objects`‑katalog. Här är alla objekt i exempelkatalogen nu, kommenterade med vad de lagrar: [source,console] @@ -352,7 +352,7 @@ image::images/data-model-3.png[Alla nåbara objekt i din Git‑katalog] ==== Objektlagring Vi nämnde tidigare att det finns ett huvud som lagras tillsammans med varje objekt du checkar in i Git‑objektdatabasen. -Låt oss kort se hur Git lagrar sina objekt. +Vi tittar kort på hur Git lagrar sina objekt. Du får se hur man lagrar ett blob‑objekt – i det här fallet strängen "`what is up, doc?`" – interaktivt i Ruby‑skriptspråket. Du kan starta interaktivt Ruby‑läge med kommandot `irb`: @@ -386,7 +386,7 @@ Du kan beräkna SHA‑1‑värdet för en sträng i Ruby genom att inkludera SHA => "bd9dbf5aae1a3862dd1526723246b20206e5fc37" ---- -Låt oss jämföra det med utdata från `git hash-object`. +Vi jämför det med utdata från `git hash-object`. Här använder vi `echo -n` för att undvika att lägga till en radbrytning i indata. [source,console] @@ -423,7 +423,7 @@ I Ruby kan du använda funktionen `FileUtils.mkdir_p()` för att skapa underkata => 32 ---- -Låt oss kontrollera innehållet i objektet med `git cat-file`: +Vi kontrollerar innehållet i objektet med `git cat-file`: [source,console] ---- diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index e8d75328..468f7334 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -53,7 +53,7 @@ $ git cat-file -s 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 22044 ---- -Vid det här laget ändrar du filen lite och ser vad som händer: +Nu ändrar du filen lite och ser vad som händer: [source,console] ---- @@ -84,7 +84,7 @@ $ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e Du har två nästan identiska 22 KB‑objekt på disken (vart och ett komprimerat till ungefär 7 KB). Vore det inte fint om Git kunde lagra ett av dem helt och hållet men sedan lagra det andra objektet bara som differensen mellan det och det första? -Det visar sig att det kan det. +Det kan det. Det ursprungliga formatet som Git sparar objekt på disk i kallas "`löst`" objektformat. Men ibland packar Git ihop flera av dessa objekt till en enda binär fil som kallas en "`packfil`" för att spara utrymme och bli mer effektivt. Git gör detta om du har för många lösa objekt, om du kör kommandot `git gc` manuellt eller om du skickar till en fjärrserver. @@ -100,7 +100,7 @@ Writing objects: 100% (18/18), done. Total 18 (delta 3), reused 0 (delta 0) ---- -Om du tittar i katalogen `objects` ser du att de flesta av dina objekt är borta, och att ett nytt filpar har dykt upp: +Om du tittar i katalogen `objects` ser du att de flesta objekt är borta, och att ett nytt filpar har dykt upp: [source,console] ---- @@ -157,8 +157,8 @@ chain length = 1: 3 objects Här är blobben `033b4`, som om du minns var den första versionen av din `repo.rb`‑fil, och den refererar till blobben `b042a`, som var den andra versionen av filen. Den tredje kolumnen i utdata är storleken på objektet i packen, så du kan se att `b042a` tar upp 22K av filen, men att `033b4` bara tar upp 9 byte. -Det som också är intressant är att den andra versionen av filen är den som lagras intakt, medan originalversionen lagras som en delta – det beror på att du sannolikt behöver snabbare åtkomst till den senaste versionen av filen. +Intressant nog lagras den andra versionen av filen intakt, medan originalversionen lagras som en delta – det beror på att du sannolikt behöver snabbare åtkomst till den senaste versionen av filen. -Det riktigt trevliga med detta är att det kan packas om när som helst. +En stor fördel är att allt kan packas om när som helst. Git kommer ibland att packa om databasen automatiskt, alltid i försök att spara mer utrymme, men du kan också packa om manuellt när som helst genom att köra `git gc` för hand. diff --git a/book/10-git-internals/sections/plumbing-porcelain.asc b/book/10-git-internals/sections/plumbing-porcelain.asc index 254d8478..280c23a0 100644 --- a/book/10-git-internals/sections/plumbing-porcelain.asc +++ b/book/10-git-internals/sections/plumbing-porcelain.asc @@ -2,7 +2,7 @@ === Lågnivådel och användardel Den här boken handlar främst om hur du använder Git med ett trettiotal underkommandon som `checkout`, `branch`, `remote` och så vidare. -Men eftersom Git från början var en verktygslåda för ett versionshanteringssystem snarare än ett helt användarvänligt VCS har det ett antal underkommandon som gör lågnivåarbete och är tänkta att kedjas ihop i UNIX‑stil eller anropas från skript. +Men eftersom Git från början var en verktygslåda för ett versionshanteringssystem snarare än ett helt användarvänligt VCS har det flera underkommandon som gör lågnivåarbete och är tänkta att kedjas ihop i UNIX‑stil eller anropas från skript. Dessa kommandon brukar kallas Gits lågnivåkommandon (plumbing‑kommandon), medan de mer användarvänliga kommandona kallas användarkommandon (porcelain‑kommandon). Som du redan har märkt handlar bokens första nio kapitel nästan uteslutande om användarkommandon. diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index e51ae8d7..a3d174e6 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -57,7 +57,7 @@ cac0cab538b970a37ea1e769cbbde608743bc96d Second commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit ---- -Nu ser din Git‑databas konceptuellt ut ungefär så här: +Nu ser din Git‑databas i princip ut ungefär så här: .Git‑katalogobjekt med grenhuvudreferenser image::images/data-model-4.png[Git‑katalogobjekt med grenhuvudreferenser] diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index 7c8b6f82..82fc6a7d 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -61,7 +61,7 @@ From git@github.com:schacon/simplegit * [new branch] topic -> origin/topic ---- -I det här fallet nekades uppdateringen av grenen `master` eftersom den inte var listad som en fast‑forward‑referens. +I det här fallet kunde grenen `master` inte uppdateras eftersom den inte var listad som en fast‑forward‑referens. Du kan åsidosätta det genom att ange `+` framför refspecen. Du kan också ange flera refspecar för uppdatering i din konfigurationsfil. diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index e9245b75..14311a4a 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -15,7 +15,7 @@ Det är svårt att säkra eller göra privat, så de flesta Git‑värdar (både Generellt rekommenderas det smarta protokollet, som vi beskriver lite längre fram. ==== -Låt oss följa `http-fetch`‑processen för biblioteket simplegit: +Vi följer `http-fetch`‑processen för biblioteket simplegit: [source,console] ---- @@ -23,7 +23,7 @@ $ git clone http://server/simplegit-progit.git ---- Det första kommandot gör är att hämta filen `info/refs`. -Denna fil skrivs av kommandot `update-server-info`, vilket är anledningen till att du måste aktivera det som en `post-receive`‑krok för att HTTP‑transporten ska fungera korrekt: +Denna fil skrivs av kommandot `update-server-info`, därför måste du aktivera det som en `post-receive`‑krok för att HTTP‑transporten ska fungera korrekt: [source] ---- @@ -41,7 +41,7 @@ ref: refs/heads/master ---- Du behöver växla till grenen `master` när du har slutfört processen. -Vid det här laget är du redo att börja vandringsprocessen. +Nu är du redo att börja vandringsprocessen. Eftersom din startpunkt är incheckningsobjektet `ca82a6` som du såg i filen `info/refs` börjar du med att hämta det: [source] @@ -82,7 +82,7 @@ Hämta trädobjektet: ---- Oj – det ser ut som att trädobjektet inte ligger i löst format på servern, så du får ett 404‑svar tillbaka. -Det finns ett par skäl till detta – objektet kan ligga i ett alternativt kodförråd, eller så kan det ligga i en packfil i detta kodförråd. +Det kan bero på att objektet ligger i ett alternativt kodförråd, eller i en packfil i detta kodförråd. Git kontrollerar först om några alternativ listats: [source] @@ -243,9 +243,9 @@ Efter att `fetch-pack` ansluter skickar `upload-pack` tillbaka något i stil med Det här är mycket likt vad `receive-pack` svarar med, men kapabiliteterna är annorlunda. Dessutom skickar det tillbaka vad HEAD pekar på (`symref=HEAD:refs/heads/master`) så att klienten vet vad som ska läggas ut om detta är en klon. -Vid det här laget tittar `fetch-pack`‑processen på vilka objekt den har och svarar med de objekt den behöver genom att skicka "`want`" och sedan SHA‑1:an den vill ha. +Här tittar `fetch-pack`‑processen på vilka objekt den har och svarar med de objekt den behöver genom att skicka "`want`" och sedan SHA‑1:an den vill ha. Den skickar alla objekt den redan har med "`have`" och sedan SHA‑1:an. -I slutet av listan skriver den "`done`" för att initiera `upload-pack`‑processen att börja skicka packfilen med den data den behöver: +I slutet av listan skriver den "`done`" så att `upload-pack`‑processen börjar skicka packfilen med den data den behöver: [source] ---- @@ -289,4 +289,4 @@ Svaret på denna förfrågan indikerar framgång eller misslyckande och inkluder Detta avsnitt innehåller en mycket grundläggande översikt av överföringsprotokollen. Protokollet innehåller många andra funktioner, som kapabiliteterna `multi_ack` eller `side-band`, men att täcka dem ligger utanför bokens omfattning. -Vi har försökt ge dig en känsla för det allmänna fram‑och‑tillbaka mellan klient och server; om du behöver mer kunskap än detta vill du troligen ta en titt på Gits källkod. +Vi har försökt visa hur klient och server kommunicerar; vill du veta mer kan du titta i Gits källkod. diff --git a/book/A-git-in-other-environments/sections/bash.asc b/book/A-git-in-other-environments/sections/bash.asc index e9c03c61..7cf0e382 100644 --- a/book/A-git-in-other-environments/sections/bash.asc +++ b/book/A-git-in-other-environments/sections/bash.asc @@ -1,7 +1,7 @@ === Git i Bash (((bash)))(((tab completion, bash)))(((shell prompts, bash))) -Om du använder Bash kan du dra nytta av några av skalets funktioner för att göra din Git‑upplevelse betydligt trevligare. +Om du använder Bash kan du nyttja några av skalets funktioner för att göra din Git‑upplevelse betydligt trevligare. Git levereras med insticksprogram för flera skal, men de är inte aktiverade som standard. Först behöver du hämta en kopia av kompletteringsfilen från källkoden till den Git‑version du använder. @@ -40,4 +40,4 @@ Nu kommer din bash‑prompt att se ut så här när du befinner dig någonstans .Anpassad `bash`‑prompt image::images/git-bash.png[Anpassad `bash`‑prompt] -Båda dessa skript har hjälpsam dokumentation; ta en titt på innehållet i `git-completion.bash` och `git-prompt.sh` för mer information. +Båda dessa skript har hjälpsam dokumentation; titta i `git-completion.bash` och `git-prompt.sh` för mer information. diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 163e95fc..fe4f99db 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -3,7 +3,7 @@ (((GUIs)))(((Graphical tools))) Gits hemmiljö är terminalen. Nya funktioner dyker upp där först, och bara på kommandoraden har du full tillgång till Gits kraft. -Men ren text är inte det bästa valet för alla uppgifter; ibland behöver du en visuell representation, och vissa användare är mycket mer bekväma med ett peka‑och‑klicka‑gränssnitt. +Men ren text är inte det bästa valet för alla uppgifter; ibland behöver du en visuell representation, och vissa användare är mycket vana vid ett peka‑och‑klicka‑gränssnitt. Tänk på att olika gränssnitt är anpassade för olika arbetsflöden. Vissa klienter exponerar bara en noggrant utvald delmängd av Gits funktionalitet för att stödja ett specifikt sätt att arbeta som författaren tycker är effektivt. @@ -16,7 +16,7 @@ Lägg också märke till att det inte finns något dessa grafiska klienter kan g När du installerar Git får du också dess visuella verktyg, `gitk` och `git-gui`. `gitk` är en grafisk historikvisare. -Tänk på det som ett kraftfullt GUI‑skal ovanpå `git log` och `git grep`. +Det fungerar som ett kraftfullt GUI‑skal ovanpå `git log` och `git grep`. Det här är verktyget att använda när du försöker hitta något som hände i det förflutna eller visualisera projektets historik. Enklast är att starta `gitk` från kommandoraden. @@ -37,7 +37,7 @@ image::images/gitk.png[Gitks historikvisare] Längst upp är något som ser lite ut som utdata från `git log --graph`; varje punkt representerar en incheckning, linjerna representerar föräldrarelationer och refs visas som färgade rutor. Den gula punkten representerar HEAD, och den röda punkten representerar ändringar som ännu inte blivit en incheckning. Längst ned finns en vy av den valda incheckningen; kommentarerna och ändringspatchen till vänster och en sammanfattningsvy till höger. -Mellan dessa finns en samling kontroller som används för att söka i historiken. +Mellan dessa finns en samling kontroller för att söka i historiken. `git-gui` är däremot främst ett verktyg för att skapa incheckningar. Även det är lättast att starta från kommandoraden: @@ -80,7 +80,7 @@ image::images/github_mac.png[GitHub för macOS] image::images/github_win.png[GitHub för Windows] De är utformade för att se ut och fungera mycket lika, så vi behandlar dem som en enda produkt i kapitlet. -Vi kommer inte att göra en detaljerad genomgång av dessa verktyg (de har sin egen dokumentation), men en snabb rundtur i vyn "`changes`" (där du tillbringar mest tid) är på sin plats. +Vi kommer inte att gå igenom dessa verktyg i detalj (de har sin egen dokumentation), men en snabb rundtur i vyn "`changes`" (där du tillbringar mest tid) är på sin plats. * Till vänster finns listan över kodförråd som klienten spårar; du kan lägga till ett kodförråd (antingen genom att klona eller genom att lägga till lokalt) genom att klicka på ikonen "`+`" längst upp i detta område. * I mitten finns ett incheckningsinmatningsområde som låter dig mata in ett incheckningsmeddelande och välja vilka filer som ska inkluderas. @@ -146,6 +146,6 @@ Men om ditt arbetsflöde är annorlunda, eller om du vill ha mer kontroll över ==== Andra GUI:er -Det finns ett antal andra grafiska Git‑klienter, och de spänner från specialiserade verktyg för enstaka uppgifter ända till appar som försöker exponera allt Git kan göra. +Det finns flera andra grafiska Git‑klienter, och de spänner från specialiserade verktyg för enstaka uppgifter ända till appar som försöker exponera allt Git kan göra. Den officiella Git‑webbplatsen har en utvald lista över de mest populära klienterna på https://git-scm.com/downloads/guis[^]. En mer omfattande lista finns på Git‑wiki‑sidan, på https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools.html#Graphical_Interfaces[^]. diff --git a/book/A-git-in-other-environments/sections/zsh.asc b/book/A-git-in-other-environments/sections/zsh.asc index 48244beb..778aad4f 100644 --- a/book/A-git-in-other-environments/sections/zsh.asc +++ b/book/A-git-in-other-environments/sections/zsh.asc @@ -33,7 +33,7 @@ RPROMPT='${vcs_info_msg_0_}' zstyle ':vcs_info:git:*' formats '%b' ---- -Detta resulterar i en visning av aktuell gren på höger sida av terminalfönstret när ditt skal befinner sig i ett Git‑kodförråd. +Då visas aktuell gren på höger sida av terminalfönstret när ditt skal befinner sig i ett Git‑kodförråd. Vänster sida stöds också förstås; avkommentera bara tilldelningen till `PROMPT`. Det ser ut ungefär så här: diff --git a/book/B-embedding-git/sections/go-git.asc b/book/B-embedding-git/sections/go-git.asc index 30f8a554..6035b3b6 100644 --- a/book/B-embedding-git/sections/go-git.asc +++ b/book/B-embedding-git/sections/go-git.asc @@ -2,8 +2,8 @@ (((go-git)))(((Go))) Om du vill integrera Git i en tjänst skriven i Go finns det också en ren Go‑biblioteksimplementation. -Den här implementationen har inga inbyggda beroenden och är därför inte benägen att ge manuella minneshanteringsfel. -Den är också transparent för standardverktyg i Go för prestandaanalys som CPU‑ och minnesprofilerare, datakapplöpningsdetektor och liknande. +Den här implementationen har inga inbyggda beroenden och riskerar därför inte manuella minneshanteringsfel. +Den stöder också Gos standardverktyg för prestandaanalys som CPU‑ och minnesprofilerare, datakapplöpningsdetektor och liknande. go-git fokuserar på utbyggbarhet och kompatibilitet samt stöder de flesta lågnivå‑API:er, vilket dokumenteras på https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md[^]. @@ -19,7 +19,7 @@ r, err := git.PlainClone("/tmp/foo", false, &git.CloneOptions{ }) ---- -Så snart du har en `Repository`‑instans kan du hämta information och göra förändringar i den: +Så snart du har en `Repository`‑instans kan du hämta information och ändra i den: [source, go] ---- diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index a3294fcc..1d781e73 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -8,7 +8,7 @@ JGit‑projektet ligger under Eclipse‑paraplyet, och dess hem finns på https: ==== Kom igång Det finns flera sätt att koppla ditt projekt till JGit och börja skriva kod mot det. -Det enklaste är förmodligen att använda Maven – integrationen görs genom att lägga till följande kodsnutt i taggen `` i din `pom.xml`‑fil: +Det enklaste är förmodligen att använda Maven – du integrerar genom att lägga till följande kodsnutt i taggen `` i din `pom.xml`‑fil: [source,xml] ---- @@ -36,7 +36,7 @@ java -cp .:org.eclipse.jgit-3.5.0.201409260305-r.jar App JGit har två grundläggande API‑nivåer: lågnivådel och användardel. Terminologin kommer från Git självt, och JGit är uppdelat i ungefär samma typer av områden: användar‑API:er (porcelain) är ett vänligt gränssnitt för vanliga användaråtgärder (sådant en normal användare skulle använda Gits kommandoradsverktyg för), medan lågnivå‑API:erna (plumbing) används för att interagera direkt med kodförrådets lågnivåobjekt. -Startpunkten för de flesta JGit‑sessioner är klassen `Repository`, och det första du vill göra är att skapa en instans av den. +Startpunkten för de flesta JGit‑sessioner är klassen `Repository`, och du börjar med att skapa en instans av den. För ett filsystemsbaserat kodförråd (ja, JGit tillåter andra lagringsmodeller) görs detta med `FileRepositoryBuilder`: [source,java] @@ -88,7 +88,7 @@ Config cfg = repo.getConfig(); String name = cfg.getString("user", null, "name"); ---- -Det händer ganska mycket här, så låt oss gå igenom det steg för steg. +Det händer ganska mycket här, så vi går igenom det steg för steg. Den första raden hämtar en pekare till referensen `master`. JGit hämtar automatiskt den _faktiska_ `master`‑refen, som ligger på `refs/heads/master`, och returnerar ett objekt som låter dig hämta information om referensen. @@ -112,7 +112,7 @@ Det sista exemplet visar hur du hämtar värdet `user.name` från Git‑konfigur Denna Config‑instans använder kodförrådet vi öppnade tidigare för lokal konfiguration, men upptäcker automatiskt de globala och systemomfattande konfigurationsfilerna och läser värden från dem också. Det här är bara ett litet smakprov av hela lågnivå‑API:t; det finns många fler metoder och klasser. -Inte heller visat här är hur JGit hanterar fel, vilket sker genom undantag. +Vi visar inte heller här hur JGit hanterar fel, vilket sker genom undantag. JGit‑API:er kastar ibland vanliga Java‑undantag (som `IOException`), men det finns också en uppsättning JGit‑specifika undantagstyper (som `NoRemoteRepositoryException`, `CorruptObjectException` och `NoMergeBaseException`). ==== Användardel @@ -127,8 +127,8 @@ Repository repo; Git git = new Git(repo); ---- -Klassen Git har en bra uppsättning _builder_-liknande metoder på hög nivå som kan användas för att konstruera ganska komplexa beteenden. -Låt oss titta på ett exempel – att göra något i stil med `git ls-remote`: +Klassen Git har en bra uppsättning _builder_-liknande metoder på hög nivå som kan konstruera ganska komplexa beteenden. +Här är ett exempel – att göra något i stil med `git ls-remote`: [source,java] ---- @@ -146,7 +146,7 @@ for (Ref ref : remoteRefs) { Det här är ett vanligt mönster med Git‑klassen; metoderna returnerar ett kommandoobjekt som låter dig kedja metodanrop för att sätta parametrar, vilka körs när du anropar `.call()`. I det här fallet frågar vi fjärrkodförrådet `origin` efter taggar, men inte heads. -Lägg också märke till användningen av ett `CredentialsProvider`‑objekt för autentisering. +Lägg också märke till att ett `CredentialsProvider`‑objekt används för autentisering. Många andra kommandon finns tillgängliga via Git‑klassen, inklusive men inte begränsat till `add`, `blame`, `commit`, `clean`, `push`, `rebase`, `revert` och `reset`. diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 856c1037..96e9d178 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -5,7 +5,7 @@ Ett annat alternativ du har tillgängligt är att använda Libgit2. Libgit2 är en beroendefri implementation av Git, med fokus på ett trevligt API för användning i andra program. Du hittar det på https://libgit2.org[^]. -Låt oss först titta på hur C‑API:t ser ut. +Först tittar vi på hur C‑API:t ser ut. Här är en blixtgenomgång: [source,c] @@ -33,7 +33,7 @@ git_repository_free(repo); De första raderna öppnar ett Git‑kodförråd. Typen `git_repository` representerar ett handtag till ett kodförråd med en mellanlagring i minnet. Det här är den enklaste metoden, när du känner till den exakta sökvägen till kodförrådets arbetskatalog eller `.git`‑mapp. -Det finns också `git_repository_open_ext` med alternativ för sökning, `git_clone` och vänner för att göra en lokal klon av ett fjärrkodförråd, samt `git_repository_init` för att skapa ett helt nytt kodförråd. +Det finns också `git_repository_open_ext` med alternativ för sökning, `git_clone` och vänner för att lokalt klona ett fjärrkodförråd, samt `git_repository_init` för att skapa ett helt nytt kodförråd. Den andra kodbiten använder rev‑parse‑syntax (se <> för mer om detta) för att hämta incheckningen som HEAD till slut pekar på. Den returnerade typen är en `git_object`‑pekare, som representerar något som finns i Git‑objektdatabasen för ett kodförråd. @@ -54,7 +54,7 @@ Av det här exemplet framträder ett par mönster: (((Ruby))) Det sista betyder att det inte är särskilt troligt att du skriver C när du använder Libgit2. Lyckligtvis finns det en rad språkspecifika bindningar som gör det ganska enkelt att arbeta med Git‑kodförråd från ditt språk och din miljö. -Låt oss titta på exemplet ovan skrivet med Ruby‑bindningarna för Libgit2, som heter Rugged och finns på https://github.com/libgit2/rugged[^]. +Vi tittar på exemplet ovan skrivet med Ruby‑bindningarna för Libgit2, som heter Rugged och finns på https://github.com/libgit2/rugged[^]. [source,ruby] ---- @@ -68,7 +68,7 @@ tree = commit.tree Som du ser är koden mycket mindre rörig. För det första använder Rugged undantag; det kan kasta saker som `ConfigError` eller `ObjectError` för att signalera fel. För det andra finns det ingen explicit frigöring av resurser, eftersom Ruby är skräpsamlande. -Låt oss titta på ett lite mer komplicerat exempel: att skapa en incheckning från grunden +Vi tittar på ett lite mer komplicerat exempel: att skapa en incheckning från grunden [source,ruby] ---- @@ -111,10 +111,10 @@ Om du inte är Ruby‑användare tar vi upp några andra bindningar i <<_libgit2 ==== Avancerad funktionalitet Libgit2 har ett par förmågor som ligger utanför kärn‑Git. -Ett exempel är insticksbarhet: Libgit2 låter dig tillhandahålla anpassade bakändar för flera typer av operationer, så att du kan lagra saker på ett annat sätt än standard‑Git gör. +Ett exempel är att Libgit2 är utbyggbart: du kan tillhandahålla anpassade bakändar för flera typer av operationer, så att du kan lagra saker på ett annat sätt än standard‑Git gör. Libgit2 tillåter anpassade bakändar för konfiguration, ref‑lagring och objektdatabasen, bland annat. -Låt oss titta på hur detta fungerar. +Vi ser hur detta fungerar. Koden nedan är hämtad från uppsättningen bakändsexempel som Libgit2‑teamet tillhandahåller (som finns på https://github.com/libgit2/libgit2-backends[^]). Så här sätts en anpassad bakänd för objektdatabasen upp: diff --git a/book/introduction.asc b/book/introduction.asc index 7da1bdc1..cd75e262 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -1,7 +1,7 @@ [preface] == Introduktion -Du är på väg att lägga flera timmar av ditt liv på att läsa om Git. Låt oss kort berätta vad som väntar. Här är en snabb översikt över bokens tio kapitel och tre bilagor. +Du är på väg att lägga flera timmar av ditt liv på att läsa om Git. Här berättar vi kort vad som väntar. Här är en snabb översikt över bokens tio kapitel och tre bilagor. I *Kapitel 1* går vi igenom versionshanteringssystem (VCS) och grunderna i Git – inget tekniskt, bara vad Git är, varför det uppstod i en värld full av andra VCS:er, vad som skiljer det från andra system och varför så många använder det. Därefter förklarar vi hur du laddar ner Git och gör första installationen om du inte redan har det. @@ -19,7 +19,7 @@ I *Kapitel 2* går vi igenom grundläggande användning av Git – hur du använ *Kapitel 8* handlar om att anpassa din Git‑miljö. Det omfattar hur du sätter upp krokskript för att driva igenom eller uppmuntra egna regler och hur du använder miljöinställningar så att du kan arbeta som du vill. Vi går även igenom hur du bygger en egen uppsättning skript för en skräddarsydd incheckningspolicy. -*Kapitel 9* handlar om Git och andra versionshanteringssystem. Det omfattar Git i en Subversion‑värld och hur man konverterar projekt från andra system till Git. Många organisationer använder fortfarande SVN och tänker inte byta, men vid det här laget har du lärt dig hur kraftfullt Git är – och kapitlet visar hur du klarar dig om du fortfarande måste använda en SVN‑server. Vi går också igenom hur man importerar projekt från flera olika system om du lyckas övertyga alla om att byta. +*Kapitel 9* handlar om Git och andra versionshanteringssystem. Det omfattar Git i en Subversion‑värld och hur man konverterar projekt från andra system till Git. Många organisationer använder fortfarande SVN och tänker inte byta, men nu har du lärt dig hur kraftfullt Git är – och kapitlet visar hur du klarar dig om du fortfarande måste använda en SVN‑server. Vi går också igenom hur man importerar projekt från flera olika system om du lyckas övertyga alla om att byta. *Kapitel 10* går ner i Gits mörka men vackra innandöme. Nu när du kan Git och kan hantera det med säkerhet och precision kan du gå vidare till hur Git lagrar objekt, vad objektmodellen är, detaljer om packfiler, serverprotokoll och mer. Genom hela boken hänvisar vi till delar av detta kapitel om du vill fördjupa dig där och då; men om du, liksom vi, vill gå rakt på de tekniska detaljerna kanske du vill läsa Kapitel 10 först. Det väljer du själv. diff --git a/book/preface_schacon.asc b/book/preface_schacon.asc index a00124a3..65e29c08 100644 --- a/book/preface_schacon.asc +++ b/book/preface_schacon.asc @@ -20,7 +20,7 @@ Vid publiceringen fanns kanske några tusen personer som använde webbplatsen oc När jag skriver den här inledningen uppger GitHub att plattformen nått tio miljoner projekt, med nästan fem miljoner registrerade utvecklarkonton och över 230 anställda. Älska det eller hata det, GitHub har kraftigt förändrat stora delar av öppen källkodsgemenskapen på ett sätt som knappt var tänkbart när jag satte mig ned för att skriva första upplagan. -Jag skrev ett litet avsnitt i den ursprungliga versionen av Pro Git om GitHub som ett exempel på en Git‑värdtjänst från en leverantör som jag inte kände mig riktigt bekväm med. +Jag skrev ett litet avsnitt i den ursprungliga versionen av Pro Git om GitHub som ett exempel på en Git‑värdtjänst från en leverantör som jag inte var riktigt nöjd med. Jag gillade inte att jag skrev om något jag tyckte var en resurs för gemenskapen och samtidigt pratade om mitt företag. Även om jag fortfarande inte direkt älskar den intressekonflikten är GitHubs betydelse i Git‑gemenskapen omöjlig att bortse från. I stället för ett exempel på en Git‑värdtjänst har jag bestämt mig för att låta den delen av boken beskriva vad GitHub är och hur man använder det effektivt. diff --git a/ch01-getting-started.asc b/ch01-getting-started.asc index a3baec48..a703cac2 100644 --- a/ch01-getting-started.asc +++ b/ch01-getting-started.asc @@ -21,6 +21,6 @@ include::book/01-introduction/sections/help.asc[] === Sammanfattning -Du bör nu ha en grundläggande förståelse för vad Git är och hur det skiljer sig från centraliserade versionshanteringssystem du kanske har använt tidigare. +Nu bör du i grunden förstå vad Git är och hur det skiljer sig från centraliserade versionshanteringssystem du kanske har använt tidigare. Du bör också ha en fungerande version av Git på ditt system som är inställd med din identitet. Nu är det dags att lära sig några grunder i Git. diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index f11ad41a..a51a5fd7 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -22,5 +22,5 @@ include::book/02-git-basics/sections/aliases.asc[] === Sammanfattning -Vid det här laget kan du göra alla grundläggande lokala Git-åtgärder – skapa eller klona ett kodförråd, göra ändringar, köa och spara dem samt se historiken över allt som har hänt i kodförrådet. +Nu kan du göra alla grundläggande lokala Git-åtgärder – skapa eller klona ett kodförråd, göra ändringar, köa och spara dem samt se historiken över allt som har hänt i kodförrådet. Härnäst går vi vidare till Gits främsta kännetecken: dess grenmodell. diff --git a/ch06-github.asc b/ch06-github.asc index 02443da3..46de8810 100644 --- a/ch06-github.asc +++ b/ch06-github.asc @@ -14,7 +14,7 @@ Om du inte vill använda GitHub för att vara värd för egna projekt eller sama [WARNING] .Gränssnitt förändras ==== -Det är viktigt att komma ihåg att gränssnittselementen i de här skärmbilderna, precis som på många aktiva webbplatser, kommer att förändras över tid. +Kom ihåg att gränssnittselementen i de här skärmbilderna, precis som på många aktiva webbplatser, kommer att förändras över tid. Förhoppningsvis finns huvudidén i det vi försöker göra kvar, men om du vill ha mer uppdaterade versioner av skärmarna kan nätversionerna av boken ha nyare skärmbilder. ==== diff --git a/ch07-git-tools.asc b/ch07-git-tools.asc index 9cc034a6..96e51389 100644 --- a/ch07-git-tools.asc +++ b/ch07-git-tools.asc @@ -1,10 +1,10 @@ [[ch07-git-tools]] == Git-verktyg -Vid det här laget har du lärt dig de flesta av de dagliga kommandona och arbetsflödena du behöver för att hantera eller förvalta ett Git-kodförråd för versionshantering av källkod. +Nu har du lärt dig de flesta dagliga kommandon och arbetsflöden du behöver för att hantera eller förvalta ett Git-kodförråd för versionshantering av källkod. Du har klarat av de grundläggande uppgifterna att spåra och checka in filer, och du har tagit vara på kraften i köytan samt lätta ämnesgrenar och sammanslagningar. -Nu går vi vidare till ett antal mycket kraftfulla saker som Git kan göra och som du kanske inte använder dagligen, men som du ändå kan behöva någon gång. +Nu går vi vidare till flera mycket kraftfulla saker som Git kan göra och som du kanske inte använder dagligen, men som du ändå kan behöva någon gång. include::book/07-git-tools/sections/revision-selection.asc[] @@ -39,4 +39,4 @@ include::book/07-git-tools/sections/credentials.asc[] Du har sett flera avancerade verktyg som låter dig hantera dina incheckningar och din köyta mer precist. När du märker problem ska du enkelt kunna ta reda på vilken incheckning som införde dem, när, och av vem. Om du vill använda underprojekt i ditt projekt har du lärt dig hur du kan tillgodose de behoven. -Vid det här laget bör du kunna göra det mesta du behöver i Git från kommandoraden till vardags och känna dig bekväm med det. +Nu bör du kunna göra det mesta du behöver i Git från kommandoraden till vardags och känna dig hemma med det. diff --git a/ch08-customizing-git.asc b/ch08-customizing-git.asc index 31a13965..971e308d 100644 --- a/ch08-customizing-git.asc +++ b/ch08-customizing-git.asc @@ -2,7 +2,7 @@ == Anpassa Git Hittills har vi gått igenom grunderna i hur Git fungerar och hur man använder det, och vi har introducerat flera verktyg som Git erbjuder för att hjälpa dig använda det enkelt och effektivt. -I kapitlet ser vi hur du kan få Git att arbeta mer skräddarsytt genom att introducera ett antal viktiga konfigurationsinställningar och krokssystemet. +I kapitlet ser vi hur du kan få Git att arbeta mer skräddarsytt genom att introducera flera viktiga konfigurationsinställningar och krokssystemet. Med dessa verktyg är det lätt att få Git att fungera precis som du, din organisation eller ditt team behöver. include::book/08-customizing-git/sections/config.asc[] diff --git a/ch09-git-and-other-systems.asc b/ch09-git-and-other-systems.asc index 1ab67c1a..46a81646 100644 --- a/ch09-git-and-other-systems.asc +++ b/ch09-git-and-other-systems.asc @@ -13,7 +13,7 @@ Den andra delen av kapitlet beskriver hur du migrerar ditt projekt till Git frå (((Git som klient))) Git ger utvecklare en så bra upplevelse att många har lärt sig att använda det på sin arbetsstation, även om resten av teamet använder ett annat VCS. -Det finns ett antal sådana adaptrar, kallade "`bryggor`". +Det finns flera sådana adaptrar, kallade "`bryggor`". Här går vi igenom de du troligast stöter på i praktiken. include::book/09-git-and-other-scms/sections/client-svn.asc[] diff --git a/ch10-git-internals.asc b/ch10-git-internals.asc index e303d12f..f4b9b665 100644 --- a/ch10-git-internals.asc +++ b/ch10-git-internals.asc @@ -6,7 +6,7 @@ Vi har märkt att en förståelse för den här informationen är grundläggande Därför har vi lagt den här diskussionen sist i boken, så att du kan läsa den när det passar i din inlärningsprocess. Det avgör du själv. -Nu när du är här, låt oss sätta igång. +Nu när du är här sätter vi igång. Först, om det ännu inte är tydligt, är Git i grunden ett innehållsadresserbart filsystem med ett VCS‑gränssnitt ovanpå. Du kommer att lära dig mer om vad det betyder om en stund. @@ -33,9 +33,9 @@ include::book/10-git-internals/sections/environment.asc[] === Sammanfattning -Vid det här laget bör du ha en ganska god förståelse för vad Git gör i bakgrunden och till en viss del hur det är implementerat. -Det här kapitlet har gått igenom ett antal lågnivåkommandon – kommandon som ligger på en lägre nivå och är enklare än de användarkommandon du har lärt dig om i resten av boken. +Nu bör du förstå ganska väl vad Git gör i bakgrunden och till en viss del hur det är implementerat. +Det här kapitlet har gått igenom flera lågnivåkommandon – kommandon som ligger på en lägre nivå och är enklare än de användarkommandon du har lärt dig om i resten av boken. Att förstå hur Git fungerar på en lägre nivå bör göra det lättare att förstå varför det gör som det gör samt att skriva egna verktyg och hjälpskript så att ditt specifika arbetsflöde fungerar för dig. Git som innehållsadresserbart filsystem är ett mycket kraftfullt verktyg som du enkelt kan använda till mer än bara ett VCS. -Vi hoppas att du kan använda din nyvunna kunskap om Gits innandöme för att skapa din egen spännande tillämpning av tekniken och känna dig mer bekväm med att använda Git på avancerade sätt. +Vi hoppas att du kan använda din nyvunna kunskap om Gits innandöme för att skapa din egen spännande tillämpning av tekniken och känna dig tryggare med att använda Git på avancerade sätt.