From f0112bb01417e2c4d2006cecb456eebb22396f0c Mon Sep 17 00:00:00 2001 From: ttaylorr Date: Sun, 29 Sep 2024 04:35:08 +0000 Subject: [PATCH] book: update sv Updated via the `update-book.yml` GitHub workflow. --- ...her-Environments-Graphical-Interfaces.html | 2 +- ...-A:-Git-in-Other-Environments-Summary.html | 2 +- ...ga-C:-Git-Commands-Basic-Snapshotting.html | 4 +- ...C:-Git-Commands-Branching-and-Merging.html | 6 +- .../sv/v2/Bilaga-C:-Git-Commands-Email.html | 12 +- ...it-Commands-Inspection-and-Comparison.html | 4 +- .../v2/Bilaga-C:-Git-Commands-Patching.html | 2 +- ...ommands-Sharing-and-Updating-Projects.html | 8 +- .../book/sv/v2/Customizing-Git-Summary.html | 2 +- ...it-Distribuerade-arbetsfl\303\266den.html" | 162 +++ ...tribuerade-Git-Medverka-i-ett-projekt.html | 986 ++++++++++++++++++ .../v2/Distribuerade-Git-Sammanfattning.html | 26 + ...de-Git-Underh\303\245lla-ett-projekt.html" | 689 ++++++++++++ ...ributed-Git-Contributing-to-a-Project.html | 965 ----------------- ...Distributed-Git-Distributed-Workflows.html | 160 --- ...Distributed-Git-Maintaining-a-Project.html | 675 ------------ .../book/sv/v2/Distributed-Git-Summary.html | 26 - .../book/sv/v2/Git-Internals-Summary.html | 2 +- .../sv/v2/Git-Tools-Reset-Demystified.html | 2 +- .../content/book/sv/v2/Git-Tools-Summary.html | 2 +- ...Git-and-Other-Systems-Git-as-a-Client.html | 2 +- .../sv/v2/Git-and-Other-Systems-Summary.html | 2 +- ...ningar-Arbetsfl\303\266de-med-grenar.html" | 2 +- ...Git-p\303\245-servern-Sammanfattning.html" | 2 +- ...itHub-Account-Setup-and-Configuration.html | 2 +- .../v2/GitHub-Contributing-to-a-Project.html | 6 +- .../sv/v2/GitHub-Maintaining-a-Project.html | 2 +- .../content/book/sv/v2/GitHub-Summary.html | 2 +- .../sv/v2/Grunder-i-Git-Visa-historiken.html | 2 +- external/book/content/book/sv/v2/_index.html | 2 +- .../_applicera_en_mejlad_patch_med_apply.html | 4 + .../v2/ch00/_applying_a_patch_with_apply.html | 4 - .../ch00/_arbeta_i_\303\244mnesgrenar.html" | 4 + ...303\266de_med_stora_sammanslagningar.html" | 4 + ...betsfl\303\266den_med_sammanslagning.html" | 4 + .../book/sv/v2/ch00/_build_number.html | 2 +- .../v2/ch00/_centraliserad_arbetsprocess.html | 4 + .../sv/v2/ch00/_centralized_workflow.html | 4 - .../sv/v2/ch00/_checking_out_remotes.html | 2 +- .../book/sv/v2/ch00/_commit_guidelines.html | 2 +- .../sv/v2/ch00/_contributing_project.html | 2 +- .../_dictator_and_lieutenants_workflow.html | 4 - ...03\266jtnanternas_arbetsfl\303\266de.html" | 4 + .../_distribuerade_arbetsfl\303\266den.html" | 4 + .../sv/v2/ch00/_distributed_workflows.html | 4 - .../book/content/book/sv/v2/ch00/_git_am.html | 2 +- .../ch00/_integrating_contributed_work.html | 4 - .../book/sv/v2/ch00/_integration_manager.html | 2 +- ...od_fr\303\245n_bidragsl\303\244mnare.html" | 4 + .../sv/v2/ch00/_large_merging_workflows.html | 4 - .../sv/v2/ch00/_maintaining_a_project.html | 4 - .../book/sv/v2/ch00/_merging_workflows.html | 4 - .../book/sv/v2/ch00/_patches_from_email.html | 2 +- .../book/sv/v2/ch00/_preparing_release.html | 2 +- .../v2/ch00/_privat_st\303\266rre_team.html" | 4 + .../sv/v2/ch00/_private_managed_team.html | 4 - .../book/sv/v2/ch00/_private_team.html | 2 +- .../book/sv/v2/ch00/_project_over_email.html | 2 +- .../book/sv/v2/ch00/_public_project.html | 2 +- .../book/sv/v2/ch00/_rebase_cherry_pick.html | 2 +- .../book/content/book/sv/v2/ch00/_rerere.html | 2 +- .../book/sv/v2/ch00/_sammanfattning_5.html | 4 + .../book/sv/v2/ch00/_sammanfattning_6.html | 4 + ...ammanfattning_av_arbetsfl\303\266den.html" | 4 + .../content/book/sv/v2/ch00/_summary.html | 2 +- .../content/book/sv/v2/ch00/_summary_10.html | 4 - .../content/book/sv/v2/ch00/_summary_11.html | 4 - .../content/book/sv/v2/ch00/_summary_2.html | 2 +- .../content/book/sv/v2/ch00/_summary_3.html | 2 +- .../content/book/sv/v2/ch00/_summary_4.html | 2 +- .../content/book/sv/v2/ch00/_summary_5.html | 2 +- .../content/book/sv/v2/ch00/_summary_6.html | 2 +- .../content/book/sv/v2/ch00/_summary_7.html | 2 +- .../content/book/sv/v2/ch00/_summary_8.html | 2 +- .../content/book/sv/v2/ch00/_summary_9.html | 2 +- .../book/sv/v2/ch00/_tagging_releases.html | 2 +- .../book/sv/v2/ch00/_the_shortlog.html | 2 +- .../ch00/_underh\303\245lla_ett_projekt.html" | 4 + .../book/sv/v2/ch00/_what_is_introduced.html | 2 +- .../book/sv/v2/ch00/_workflows_summary.html | 4 - .../v2/ch00/_working_in_topic_branches.html | 4 - .../book/sv/v2/ch00/ch05-distributed-git.html | 2 +- .../book/content/book/sv/v2/ch00/merwf_a.html | 2 +- .../book/content/book/sv/v2/ch00/merwf_b.html | 2 +- .../book/content/book/sv/v2/ch00/merwf_c.html | 2 +- .../book/content/book/sv/v2/ch00/merwf_d.html | 2 +- .../book/content/book/sv/v2/ch00/merwf_e.html | 2 +- .../book/content/book/sv/v2/ch00/merwf_f.html | 2 +- .../book/content/book/sv/v2/ch00/psp_b.html | 2 +- .../content/book/sv/v2/ch00/wfdiag_b.html | 2 +- .../content/book/sv/v2/ch00/wfdiag_c.html | 2 +- external/book/data/book/sv.yml | 18 +- external/book/sync/book-sv.sha | 2 +- 93 files changed, 1996 insertions(+), 1959 deletions(-) create mode 100644 "external/book/content/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsfl\303\266den.html" create mode 100644 external/book/content/book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt.html create mode 100644 external/book/content/book/sv/v2/Distribuerade-Git-Sammanfattning.html create mode 100644 "external/book/content/book/sv/v2/Distribuerade-Git-Underh\303\245lla-ett-projekt.html" delete mode 100644 external/book/content/book/sv/v2/Distributed-Git-Contributing-to-a-Project.html delete mode 100644 external/book/content/book/sv/v2/Distributed-Git-Distributed-Workflows.html delete mode 100644 external/book/content/book/sv/v2/Distributed-Git-Maintaining-a-Project.html delete mode 100644 external/book/content/book/sv/v2/Distributed-Git-Summary.html create mode 100644 external/book/content/book/sv/v2/ch00/_applicera_en_mejlad_patch_med_apply.html delete mode 100644 external/book/content/book/sv/v2/ch00/_applying_a_patch_with_apply.html create mode 100644 "external/book/content/book/sv/v2/ch00/_arbeta_i_\303\244mnesgrenar.html" create mode 100644 "external/book/content/book/sv/v2/ch00/_arbetsfl\303\266de_med_stora_sammanslagningar.html" create mode 100644 "external/book/content/book/sv/v2/ch00/_arbetsfl\303\266den_med_sammanslagning.html" create mode 100644 external/book/content/book/sv/v2/ch00/_centraliserad_arbetsprocess.html delete mode 100644 external/book/content/book/sv/v2/ch00/_centralized_workflow.html delete mode 100644 external/book/content/book/sv/v2/ch00/_dictator_and_lieutenants_workflow.html create mode 100644 "external/book/content/book/sv/v2/ch00/_diktatorns_och_l\303\266jtnanternas_arbetsfl\303\266de.html" create mode 100644 "external/book/content/book/sv/v2/ch00/_distribuerade_arbetsfl\303\266den.html" delete mode 100644 external/book/content/book/sv/v2/ch00/_distributed_workflows.html delete mode 100644 external/book/content/book/sv/v2/ch00/_integrating_contributed_work.html create mode 100644 "external/book/content/book/sv/v2/ch00/_integrera_kod_fr\303\245n_bidragsl\303\244mnare.html" delete mode 100644 external/book/content/book/sv/v2/ch00/_large_merging_workflows.html delete mode 100644 external/book/content/book/sv/v2/ch00/_maintaining_a_project.html delete mode 100644 external/book/content/book/sv/v2/ch00/_merging_workflows.html create mode 100644 "external/book/content/book/sv/v2/ch00/_privat_st\303\266rre_team.html" delete mode 100644 external/book/content/book/sv/v2/ch00/_private_managed_team.html create mode 100644 external/book/content/book/sv/v2/ch00/_sammanfattning_5.html create mode 100644 external/book/content/book/sv/v2/ch00/_sammanfattning_6.html create mode 100644 "external/book/content/book/sv/v2/ch00/_sammanfattning_av_arbetsfl\303\266den.html" delete mode 100644 external/book/content/book/sv/v2/ch00/_summary_10.html delete mode 100644 external/book/content/book/sv/v2/ch00/_summary_11.html create mode 100644 "external/book/content/book/sv/v2/ch00/_underh\303\245lla_ett_projekt.html" delete mode 100644 external/book/content/book/sv/v2/ch00/_workflows_summary.html delete mode 100644 external/book/content/book/sv/v2/ch00/_working_in_topic_branches.html diff --git a/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces.html b/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces.html index 12f0740796..72ee7c1dfd 100644 --- a/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces.html +++ b/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces.html @@ -236,7 +236,7 @@

Recommended Workflow

-

Summary

+

Summary

These tools are very well-suited for the workflow they’re designed for. Developers and non-developers alike can be collaborating on a project within minutes, and many of the best practices for this kind of workflow are baked into the tools. diff --git a/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary.html b/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary.html index 0ae2973b45..747f749169 100644 --- a/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary.html +++ b/external/book/content/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary.html @@ -18,7 +18,7 @@ title: Git - Summary url: "/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary.html" --- -

Summary

+

Summary

You’ve learned how to harness Git’s power from inside the tools that you use during your everyday work, and also how to access Git repositories from your own programs.

diff --git a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Basic-Snapshotting.html b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Basic-Snapshotting.html index 787d149974..5417aedeb4 100644 --- a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Basic-Snapshotting.html +++ b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Basic-Snapshotting.html @@ -67,10 +67,10 @@

git diff

We first look at the basic uses of git diff in }}">Visa dina förberedda och oförberedda ändringar, where we show how to see what changes are staged and which are not yet staged.

-

We use it to look for possible whitespace issues before committing with the --check option in }}">Commit Guidelines.

+

We use it to look for possible whitespace issues before committing with the --check option in }}">Riktlinjer för incheckningar.

-

We see how to check the differences between branches more effectively with the git diff A...B syntax in }}">Determining What Is Introduced.

+

We see how to check the differences between branches more effectively with the git diff A...B syntax in }}">Avgöra vad som ska integreras.

We use it to filter out whitespace differences with -b and how to compare different stages of conflicted files with --theirs, --ours and --base in }}">Advanced Merging.

diff --git a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Branching-and-Merging.html b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Branching-and-Merging.html index 4662096bd4..b5919ff69a 100644 --- a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Branching-and-Merging.html +++ b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Branching-and-Merging.html @@ -71,7 +71,7 @@

git merge

Though it is used in various places in the book, there are very few variations of the merge command — generally just git merge <branch> with the name of the single branch you want to merge in.

-

We covered how to do a squashed merge (where Git merges the work but pretends like it’s just a new commit without recording the history of the branch you’re merging in) at the very end of }}">Forked Public Project.

+

We covered how to do a squashed merge (where Git merges the work but pretends like it’s just a new commit without recording the history of the branch you’re merging in) at the very end of }}">Öppet, litet projekt.

We went over a lot about the merge process and command, including the -Xignore-space-change command and the --abort flag to abort a problem merge in }}">Advanced Merging.

@@ -110,7 +110,7 @@

git log

In }}">Skapa en ny gren we use it with the --decorate option to easily visualize where our branch pointers are located and we also use the --graph option to see what divergent histories look like.

-

In }}">Private Small Team and }}">Commit Ranges we cover the branchA..branchB syntax to use the git log command to see what commits are unique to a branch relative to another branch. +

In }}">Privat, litet team and }}">Commit Ranges we cover the branchA..branchB syntax to use the git log command to see what commits are unique to a branch relative to another branch. In }}">Commit Ranges we go through this fairly extensively.

@@ -143,7 +143,7 @@

git tag

Generally this is used for things like releases.

-

This command is introduced and covered in detail in }}">Taggning and we use it in practice in }}">Tagging Your Releases.

+

This command is introduced and covered in detail in }}">Taggning and we use it in practice in }}">Versionsmarkeringar.

We also cover how to create a GPG signed tag with the -s flag and verify one with the -v flag in }}">Signing Your Work.

diff --git a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Email.html b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Email.html index 526240643f..b7ea8034ef 100644 --- a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Email.html +++ b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Email.html @@ -30,7 +30,7 @@

git apply

It is similar to what the patch command might do with a few small differences.

-

We demonstrate using it and the circumstances in which you might do so in }}">Applying Patches from Email.

+

We demonstrate using it and the circumstances in which you might do so in }}">Arbeta via mejl.

@@ -40,7 +40,7 @@

git am

This is useful for receiving patches over email and applying them to your project easily.

-

We covered usage and workflow around git am in }}">Applying a Patch with am including using the --resolved, -i and -3 options.

+

We covered usage and workflow around git am in }}">Applicera en mejlad patch med am including using the --resolved, -i and -3 options.

There are also a number of hooks you can use to help with the workflow around git am and they are all covered in }}">Email Workflow Hooks.

@@ -55,7 +55,7 @@

git format-patch

The git format-patch command is used to generate a series of patches in mbox format that you can use to send to a mailing list properly formatted.

-

We go through an example of contributing to a project using the git format-patch tool in }}">Public Project over Email.

+

We go through an example of contributing to a project using the git format-patch tool in }}">Öppet, större projekt via mejl.

@@ -64,7 +64,7 @@

git imap-send

The git imap-send command uploads a mailbox generated with git format-patch into an IMAP drafts folder.

-

We go through an example of contributing to a project by sending patches with the git imap-send tool in }}">Public Project over Email.

+

We go through an example of contributing to a project by sending patches with the git imap-send tool in }}">Öppet, större projekt via mejl.

@@ -73,7 +73,7 @@

git send-email

The git send-email command is used to send patches that are generated with git format-patch over email.

-

We go through an example of contributing to a project by sending patches with the git send-email tool in }}">Public Project over Email.

+

We go through an example of contributing to a project by sending patches with the git send-email tool in }}">Öppet, större projekt via mejl.

@@ -83,7 +83,7 @@

git request-pull

If you have a branch on a public server and want to let someone know how to integrate those changes without sending the patches over email, you can run this command and send the output to the person you want to pull the changes in.

-

We demonstrate how to use git request-pull to generate a pull message in }}">Forked Public Project.

+

We demonstrate how to use git request-pull to generate a pull message in }}">Öppet, litet projekt.

\ No newline at end of file diff --git a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Inspection-and-Comparison.html b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Inspection-and-Comparison.html index 8723848ce7..848a59171c 100644 --- a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Inspection-and-Comparison.html +++ b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Inspection-and-Comparison.html @@ -42,7 +42,7 @@

git shortlog

It will take many of the same options that the git log command will but instead of listing out all of the commits it will present a summary of the commits grouped by author.

-

We showed how to use it to create a nice changelog in }}">The Shortlog.

+

We showed how to use it to create a nice changelog in }}">Shortlog.

@@ -52,7 +52,7 @@

git describe

It’s a way to get a description of a commit that is as unambiguous as a commit SHA-1 but more understandable.

-

We use git describe in }}">Generating a Build Number and }}">Preparing a Release to get a string to name our release file after.

+

We use git describe in }}">Generera versionsnummer and }}">Förbereda ett släpp to get a string to name our release file after.

\ No newline at end of file diff --git a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Patching.html b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Patching.html index c681ce3957..186b22c12f 100644 --- a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Patching.html +++ b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Patching.html @@ -30,7 +30,7 @@

git cherry-pick

This can be useful to only take one or two commits from a branch individually rather than merging in the branch which takes all the changes.

-

Cherry picking is described and demonstrated in }}">Rebasing and Cherry-Picking Workflows.

+

Cherry picking is described and demonstrated in }}">Arbetsflöden med ombasering och plocka russin ur kakan.

diff --git a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Sharing-and-Updating-Projects.html b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Sharing-and-Updating-Projects.html index 7dd32ec837..345404ae6a 100644 --- a/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Sharing-and-Updating-Projects.html +++ b/external/book/content/book/sv/v2/Bilaga-C:-Git-Commands-Sharing-and-Updating-Projects.html @@ -32,7 +32,7 @@

git fetch

We first look at this command in }}">Hämta och uppdatera från dina fjärrförvar and we continue to see examples of its use in }}">Fjärrgrenar.

-

We also use it in several of the examples in }}">Contributing to a Project.

+

We also use it in several of the examples in }}">Medverka i ett projekt.

We use it to fetch a single specific reference that is outside of the default space in }}">Pull Request Refs and we see how to fetch from a bundle in }}">Bundling.

@@ -53,7 +53,7 @@

git pull

We also see how to use it to help with rebasing difficulties in }}">Flytta en gren när du flyttar en gren.

-

We show how to use it with a URL to pull in changes in a one-off fashion in }}">Checking Out Remote Branches.

+

We show how to use it with a URL to pull in changes in a one-off fashion in }}">Checka ut fjärrgrenar.

Finally, we very quickly mention that you can use the --verify-signatures option to it in order to verify that commits you are pulling have been GPG signed in }}">Signing Commits.

@@ -72,7 +72,7 @@

git push

In }}">Ta bort Fjärrgrenar we use the --delete flag to delete a branch on the server with git push.

-

Throughout }}">Contributing to a Project we see several examples of using git push to share work on branches through multiple remotes.

+

Throughout }}">Medverka i ett projekt we see several examples of using git push to share work on branches through multiple remotes.

We see how to use it to share tags that you have made with the --tags option in }}">Dela taggar.

@@ -108,7 +108,7 @@

git archive

The git archive command is used to create an archive file of a specific snapshot of the project.

-

We use git archive to create a tarball of a project for sharing in }}">Preparing a Release.

+

We use git archive to create a tarball of a project for sharing in }}">Förbereda ett släpp.

diff --git a/external/book/content/book/sv/v2/Customizing-Git-Summary.html b/external/book/content/book/sv/v2/Customizing-Git-Summary.html index fa192c0637..8b154fd949 100644 --- a/external/book/content/book/sv/v2/Customizing-Git-Summary.html +++ b/external/book/content/book/sv/v2/Customizing-Git-Summary.html @@ -17,7 +17,7 @@ next: book/sv/v2/Git-and-Other-Systems-Git-as-a-Client title: Git - Summary --- -

Summary

+

Summary

We’ve covered most of the major ways that you can customize your Git client and server to best fit your workflow and projects. You’ve learned about all sorts of configuration settings, file-based attributes, and event hooks, and you’ve built an example policy-enforcing server. diff --git "a/external/book/content/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsfl\303\266den.html" "b/external/book/content/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsfl\303\266den.html" new file mode 100644 index 0000000000..55bbb5ff03 --- /dev/null +++ "b/external/book/content/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsfl\303\266den.html" @@ -0,0 +1,162 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +category: book +section: documentation +subsection: book +sidebar: book +book: + language_code: sv + chapter: + title: Distribuerade Git + number: 5 + section: + title: Distribuerade arbetsflöden + number: 1 + cs_number: '5.1' + previous: book/sv/v2/Git-på-servern-Sammanfattning + next: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt +title: Git - Distribuerade arbetsflöden +url: "/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden.html" +--- +

+Nu när du har ett fjärrarkiv för Git inställt som en hub för samtliga utvecklare, och du är bekant med grundläggande Git-kommandon lokalt, ska vi titta på hur man använder några av de distribuerade arbetsflöden som Git erbjuder.

I det här kapitlet kommer du att lära dig att arbeta med Git i en distribuerad miljö, både som bidragslämnare och förvaltare. +Du kommer alltså att lära dig hur du framgångsrikt bidar med kod till ett projekt och gör det så enkelt för dig och den som underhåller projektet som möjligt, samt hur du framgångsrikt förvaltar ett projekt med flera utvecklare som bidrar.

+

Distribuerade arbetsflöden

+
+

+Till skillnad från centraliserade versionshanteringssystem (CVCS) tillåter Gits distribuerade natur mer flexibilitet när utvecklare ska samarbeta. +I centraliserade system är varje utvecklare en nod som arbetar mer eller mindre likvärdigt mot ett nav. +I Git däremot, kan varje utvecklare både en nod och ett nav samtidigt; varje utvecklare kan parallellt bidra med kod till andras arkiv och själv underhålla ett öppet arkiv som andra kan bidra till. +Det öppnar upp för en mängd olika möjligheter att organisera samarbetet i ditt projekt och/eller i ditt team. +Vi kommer att titta närmare på några vanliga processer som drar nytta av den här flexibiliteten. +Vi går igenom både styrkor och svagheter för varje arbetsprocess; du kan välja att använda en enda eller blanda och matcha de finesser som verkar passa bäst.

+
+
+

Centraliserad arbetsprocess

+
+

+Centraliserade system har i stort sett en enda samarbetsmodell — den centraliserade arbetsprocessen. +Ett nav, eller arkiv, accepterar kod från utvecklarna, som alla synkroniserar sitt arbete mot det. +Utvecklarna är noder till den centrala enheten.

+
+
+
+}}" alt="Centraliserad arbetsprocess."> +
+
Figur 54. Centraliserad arbetsprocess.
+
+
+

Det innebär att om två utvecklare klonar navet och gör ändringar, så kan den första utvecklaren som skickar upp sina ändringar göra det utan problem. +Den andra utvecklaren måste däremot sammanfoga den första utvecklarens arbete innan den skickar upp sina ändringar, annars kommer de nya ändringarna att skrivas över. +Det är likadant i Git som i Subversion (eller något annat CVCS), och i Git fungerar modellen utmärkt.

+
+
+

Om du redan är bekväm med en centraliserad arbetsprocess i ditt företag eller team kan du enkelt fortsätta använda den i Git. +Det är bara att sätta upp ett enda arkiv och ge alla i teamet skrivbehörighet; Git kommer inte att låta användare skriva över varandras arbeten.

+
+
+

Låt oss säga att John och Jessika båda börjar arbeta samtidigt. +John avslutar sina ändringar och skickar upp dem till servern. +Sen försöker Jessika att skicka upp sina, men servern avvisar dem. +Hon får veta att hon försöker skicka upp ändringar som inte kan snabbspolas, och att hon inte kommer att kunna göra det förrän hon först hämtar och sammanfogar incheckade ändringar. +Detta arbetsflöde är tilltalande för många eftersom det är ett tillvägagångssätt många är bekanta och bekväma med.

+
+
+

Det är heller inte begränsat till små team. +Gits grenmodell gör det möjligt för hundratals utvecklare att arbeta framgångsrikt på ett enda projekt genom dussintals grenar på en och samma gång.

+
+
+
+

Integrationsstyrd arbetsprocess

+
+

+Eftersom Git tillåter dig att ha flera fjärrarkiv är det möjligt att med ett arbetsflöde där varje utvecklare har skrivbehörighet till sitt eget öppna arkiv och läsbehörighet till andras. +Detta scenario inkluderar ofta ett arkiv som representerar det “officiella” projektet. +För att bidra till det projektet gör du en öppen klon av det som du skickar dina ändringar till. +Sen kan du skicka en förfrågan till den som förvaltar det officiella projektet att hämta dina ändringar. +Förvaltaren kan då lägga till ditt arkiv som ett fjärrarkiv, testa dina ändringar lokalt, sammanfoga dem i sin gren och skicka till det officiella arkivet. +Processen ser ut så här (se }}">Integrationssstyrt arbetsflöde.):

+
+
+
    +
  1. +

    Förvaltaren skickar till sitt öppna arkiv.

    +
    2. +
  2. +

    En deltagare klonar arkivet och gör ändringar.

    +
    3. +
  3. +

    Deltagaren skickar sina ändringar till sin egna öppna klon.

    +
    4. +
  4. +

    Deltagaren skickar ett e-postmeddelande till förvaltaren och ber denne att hämta ändringarna.

    +
    5. +
  5. +

    Förvaltaren lägger till deltagarens arkiv som ett fjärrarkiv och slår ihop ändringarna lokalt.

    +
    6. +
  6. +

    Förvaltaren skickar de sammanslagna ändringarna till det officiella arkivet.

    +
    7. +
+
+
+
+}}" alt="Integrationsstyrt arbetsflöde."> +
+
Figur 55. Integrationssstyrt arbetsflöde.
+
+
+

+Detta är ett mycket vanligt arbetsflöde som används av verktyg som GitHub eller GitLab, där det är enkelt att förgrena ett projekt och skicka upp sina ändringar. +En av de största fördelarna med detta tillvägagångssätt är att du kan fortsätta att arbeta vidare, och den som underhåller det officiella arkivet kan hämta in dina ändringar när som helst. +Bidragslämnaren behöver inte vänta på att ändringarna ska slås samman innan hen kan börja på något nytt — varje part kan istället arbeta i sin egen takt.

+
+
+
+

Diktatorns och löjtnanternas arbetsflöde

+
+

+Diktatorns och löjtnanternas arbetsflöde är en variant av ett flerarkivsarbetsflöde. +Det används vanligtvis i stora projekt med hundratals medarbetare; ett känt exempel är Linuxkärnan. +Där har integrationsansvariga hand om varsin del av arkivet; de kallas löjtnanter. +Löjtnanterna har en gemensam integrationsansvarig som kallas den välvillige diktatorn. +Den välvillige diktatorn är den enda med skrivrättigheter till det heliga referensarkiv, som alla medverkande hämtar kod från. +Flödet fungerar så här (se }}">Den välvillige diktatorns arbetsflöde.):

+
+
+
    +
  1. +

    Utvecklarna arbetar på sina egna funktionsgrenar och ombaserar sitt arbete till toppen av “master”. +“Master”-grenen är det referensarkiv som endast diktatorn skickar ändringar till.

    +
    2. +
  2. +

    Löjtnanterna slår samman utvecklarnas funktionsgrenar med sina respektive “master”-grenar.

    +
    3. +
  3. +

    Diktatorn slår samman löjtnanternas “master”-grenar med sin egen “master”-gren.

    +
    4. +
  4. +

    Slutligen skickar diktatorn sin “master”-gren till referensarkivet, så att de andra utvecklarna kan ombasera från den.

    +
    5. +
+
+
+
+}}" alt="Den välvillige diktatorns arbetsflöde."> +
+
Figur 56. Den välvillige diktatorns arbetsflöde.
+
+
+

Det här arbesflödet är inte så vanligt, men kan vara användbart 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.

+
+
+
+

Sammanfattning av arbetsflöden

+
+

Det här är några av de vanligaste arbetsflödena i distribuerade system, som till exempel Git, men det är möjligt att anpassa dem efter specifika omständigheter i ett projekt. +Nu när du (förhoppningsvis) kan avgöra vilken kombination av arbetsflöden som kan fungera för dig, kommer vi att gå igenom några mer specifika exempel på hur du kan utföra de huvudsakliga rollerna som ingår i processerna. +I näste avsnitt kommer du att lära dig om några vanliga tillvägagångssätt för att bidra till ett projekt.

+
+
+ \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt.html b/external/book/content/book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt.html new file mode 100644 index 0000000000..425d655fc0 --- /dev/null +++ b/external/book/content/book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt.html @@ -0,0 +1,986 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +category: book +section: documentation +subsection: book +sidebar: book +book: + language_code: sv + chapter: + title: Distribuerade Git + number: 5 + section: + title: Medverka i ett projekt + number: 2 + cs_number: '5.2' + previous: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden + next: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt +title: Git - Medverka i ett projekt +--- +

Medverka i ett projekt

+
+

+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 flexibelt 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.

+
+
+

För det första — hur många involverade bidrar aktivt med källkod och hur ofta? +I mindre pojekt ä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 företag 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. +Ju fler utvecklare, ju mer problem kan du stöta på för att få din kod att läggas till och integreras sömlöst. +Under tiden du arbetar med dina ändringar, eller väntar på att få dem godkända, kan ny kod göra dem ofunktionella — eller rentav inaktuella. +Hur kan du då göra för att din egen kodbas ska hållas uppdaterad och dina incheckningar aktuella?

+
+
+

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 patcher? +Ska samtliga patcher granskas och godkännas av en annan utvecklare? +Kommer du att vara involverad i den processen? +Eller finns det ett kvalitetsledningssystem med testare på plats som du behöver skicka dina ändringar till först?

+
+
+

Till sist spelar behörigheter för incheckningar in. +Din medverkan kommer att skilja sig mycket åt beroende på om du har skrivrättigheter till kodbasen eller inte. +Om du inte har det, hur ser processen ut för att granska och godkänna bidrag? +Finns det ens en sådan process? +Hur många ändringar ska skickas med i taget? +Hur ofta?

+
+
+

Alla dessa frågor påverkar hur du bäst bidrar till ett projekt, liksom vilka arbetssätt du själv föredrar eller har tillgång till. +Vi kommer att gå igenom tillvägagångssätten ur olika aspekter i en serie användarfall, från enkla till mer komplexa. +Du borde känna igen det specifika arbetssätt du förväntas använda i dessa exempel.

+
+
+

Riktlinjer för incheckningar

+
+

Innan vi går in på användarfallen kommer en kort kommentar om incheckningsmeddelanden. +Att ha bra riktlinjer för incheckningar, och att hålla sig till dem, gör det betydligt enklare att använda Git tillsammans med andra. +I Git-projektet finns ett dokument med flera bra tips på saker att tänka på för att göra incheckningar till en patch. +Du hittar det i filen Documentation/SubmittingPatches i Gits källkod.

+
+
+

+Först av allt, så bör dina bidrag inte ha några felaktiga mellanslag. +Git har ett lätt sätt att kontrollera det — innan du gör en incheckning, kör kommandot git diff --check. +Det ger dig en lista över möjliga mellanslag som kan vara felaktiga.

+
+
+
+}}" alt="Output av `git diff --check`."> +
+
Figur 57. Output of git diff --check.
+
+
+

Kör kommandot innan en incheckning för att snabbt kontrollera om du är på väg att checka in mellanslag som kan irritera andra utvecklare.

+
+
+

För det andra, försök att göra varje incheckning till logiskt separat enhet. +Om du kan, försök att hålla dina ändringar lättsmälta - koda inte en hel helg på fem olika uppgifter, för att sen skicka dem som en enda gigantisk incheckning på måndan. +Även om du inte har checkat in på en hel helg, använd köområdet för att dela upp ditt arbete i minst fem incheckningar på måndagen, med ett tydligt meddelande per incheckning. +Om några av ändringarna är i samma fil, försök att använda git add --patch för att delvis köa filer (läs mer i }}">Interactive Staging). +Projektets ögonblicksbild längst ut på grenen kommer att se likadan ut oavsett om du gör en incheckning eller fem, så länge som alla ändringar läggs till förr eller senare. +Försök därför att göra det så enkelt som möjligt för dina kollegor när de ska granska dina ändringar.

+
+
+

Med det tillvägagångssättet blir det också enklare att dra ut eller återställa någon av ändringarna i efterhand, om det skulle behövas. +I avsnittet }}">Rewriting History 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. +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 gör gällande 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. +Med andra ord, ge order. +Istället för “Jag lade till test för” eller “Lägger till test för,” skriv “Lägg till test för” +Här är en mall ursprungligen skriven av Tim Pope:

+
+
+
+
Kort (50 tecken max), befallande sammanfattning
+
+Mer detaljerad text, om nödvändigt. Håll den till cirka 72 tecken eller
+så. Första raden kan ofta jämföras med ämnet på ett mejl och resten av
+innehållet med brödtexten. Den tomma raden mellan titel och brödtext
+är absolut nödvändig (om du inte utelämnar innehållet helt); verktyg som
+ombasera kan bli förvirrade om de skrivs ihop.
+
+Ytterligare paragrafer skrivs efter en tom rad.
+
+  - Punktlistor är också ok
+
+  - Efter en tom rad och ett inledande mellanslag används ofta
+    bindestreck eller asterisk som punkt, men det finns olika
+    konventioner.
+
+
+
+

Om alla dina incheckningsmeddelande följer den här mallen kommer det att bli lättare, både för dig och dem du samarbetar med. +Git-projektet har välformatterade incheckningsmeddelanden — kör git log --no-merges där för att få inspiration till hur en väl formatterad incheckningshistorik kan se ut.

+
+
+ + + + + +
+
Notera
+		 +
Gör som vi säger och inte som vi gör
+
+

För att vara helt ärliga, många av exemplen i den här boken har inte så värst välformatterade incheckningsmeddelanden; vi använder ofta -m efter git commit, helt enkelt.

+
+
+

Som sagt, gör som vi säger, inte som vi gör.

+
+
+
+
+
+

Privat, litet team

+
+

+Det enklaste arbetssättet du sannolikt kommer stöta på är ett privat projekt med en eller två involverade utvecklare. +I den här kontexten betyder “privat” sluten källkod — den är inte tillgänglig för någon utomstående. +Du och de andra utvecklarna har skrivbehörigheter till arkivet.

+
+
+

I den här uppsättningen liknar arbetssättet det som du kanske stöter på när du använder Subversion eller något annat centraliserat versionshanteringssystem. +Du behåller fördelarna med saker som att kunna checka in offline, en betydligt enklare förgrening och sammanslagning, men arbetsprocesserna är mycket lika; den största skillnaden är att sammanslagningar sker i klienten istället för från servern vid incheckning. +Låt oss ta ett exempel på hur det kan gå till när två utvecklare börjar samarbeta i ett gemensamt arkiv. +Den första utvecklaren, John, klonar arkivet och gör en ändring som checkas in lokalt. +(Informationsmeddelandena har ersatts med ... för att korta ner exemplen.)

+
+
+
+
# Johns dator
+$ git clone john@githost:simplegit.git
+Klonar till 'simplegit'...
+...
+$ cd simplegit/
+$ vim lib/simplegit.rb
+$ git commit -am 'remove invalid default value'
+[master 738ee87] remove invalid default value
+ 1 fil ändrad, 1 tillagd(+), 1 borttagen(-)
+
+
+
+

Jessika, den andra utvecklaren, gör samma sak — klonar arkivet och checkar in en ändring:

+
+
+
+
# Jessikas dator
+$ git clone jessika@githost:simplegit.git
+Klonar till 'simplegit'...
+...
+$ cd simplegit/
+$ vim TODO
+$ git commit -am 'add reset task'
+[master fbff5bc] add reset task
+ 1 fil ändrad, 1 tillagd(+), 0 borttagen(-)
+
+
+
+

Sen skickar Jessika sina ändringar till servern, vilket funkar bra:

+
+
+
+
# Jessikas dator
+$ git push origin master
+...
+Till jessika@githost:simplegit.git
+   1edee6b..fbff5bc  master -> master
+
+
+
+

Den sista raden i outputen är ett användbart meddelande från sändningen. +Formateringen är <gammalref>..<nyref> frånref -> tillref, där gammalref betyder tidigare referens, nyref är den nya referensen, frånref är namnet på den lokala referens som ändringen kommer från och tillref är fjärreferensen som har blivit uppdaterad. +Du kommer att se liknande output i exemplen nedanför, en grundförståelse kommer göra det lättare att förstå innebörden av arkivens varierade stadier. +Mer detaljer finns i git-push dokumentation.

+
+
+

För att fortsätta med det här exemeplet — kort efteråt gör John några ändringar, checkar in dem lokalt och försöker skicka dem till samma server som Jessika:

+
+
+
+
# Johns dator
+$ git push origin master
+Till john@githost:simplegit.git
+ ! [refuserad]        master -> master (ej snabbspolad)
+error: misslyckades sända vissa referenser till 'john@githost:simplegit.git'
+
+
+
+

I det här fallet kan John inte skicka sina incheckningar på grund av Jessikas tidigare incheckning av sina ändringar. +Det här är särskilt viktigt att förstå om du tidigare har använt Subversion, för du kommer att märka att de två utvecklarna inte ändrade i samma fil. +Subversion gör en sammanslagning automatiskt på servern om olika filer har ändrats, men med Git behöver du själv först sammanfoga incheckningarna lokalt. +Med andra ord, John måste först hämta Jessikas ändringar i fjärrarkivet och sammanfoga dem i sitt lokala arkiv innan han kommer att få tillåtelse att skicka ändringarna.

+
+
+

Som ett första steg hämtar John Jessikas ändringar(Jessikas ändringar hämtas bara, de slås inte ihop med hans filer):

+
+
+
+
$ git fetch origin
+...
+Från john@githost:simplegit
+ + 049d078...fbff5bc master     -> origin/master
+
+
+
+

Johns arkiv ser nu ut ungefär så här:

+
+
+
+}}" alt="Johns divergerande historik."> +
+
Figur 58. Johns divergerande historik.
+
+
+

Nu kan John slå ihop de ändringar han hämtade av Jessika med filerna på sin dator:

+
+
+
+
$ git merge origin/master
+Sammanslagning gjord med metoden 'recursive'.
+ TODO |    1 +
+ 1 fil ändrad, 1 tillägg(+), 0 borttagna(-)
+
+
+
+

Om den lokala sammanslagningen går smidigt kommer Johns uppdaterade historik se ut ungefär så här:

+
+
+
+}}" alt="Johns arkiv efter sammanslagning av ändringar från `origin/master`."> +
+
Figur 59. Johns arkiv efter sammanslagning av ändringar från origin/master.
+
+
+

Nu kanske John vill testa den nya koden för att vara helt säker på att ingen av Jessikas ändringar påverkat hans, och om allt går bra kan han slutligen skicka sina sammanslagna ändringar till servern:

+
+
+
+
$ git push origin master
+...
+Till john@githost:simplegit.git
+   fbff5bc..72bbc59  master -> master
+
+
+
+

Till sist ser Johns incheckningshistorik ut så här:

+
+
+
+}}" alt="Johns historik efter att ha skickat sina ändringar till servern `origin`."> +
+
Figur 60. Johns historik eftervatt ha skickat sina ändringar till servern origin.
+
+
+

Under tiden har Jessika skapat en ny gren med namnet issue54, och gjort tre incheckningar till den nya grenen. +Hon har inte hämtat Johns ändringar än, så hennes incheckningshistorik ser ut så här:

+
+
+
+}}" alt="Jessikas gren."> +
+
Figur 61. Jessikas gren.
+
+
+

Plötsligt får Jessika veta att John har skickat nya ändringar till servern och vill kika på dem, så hon hämtar alla ändringar från servern med kommandot:

+
+
+
+
# Jessikas dator
+$ git fetch origin
+...
+Från jessika@githost:simplegit
+   fbff5bc..72bbc59  master     -> origin/master
+
+
+
+

Nu hämtas Johns incheckade ändringar ner. +Jessikas historik kommer att se ut så här:

+
+
+
+}}" alt="Jessikas historik efter att ha hämtat Johns ändringar."> +
+
Figur 62. Jessikas historik efter att ha hämtat Johns ändringar.
+
+
+

Jessika tycker att ändringarna på hennes nya gren är klara, men hon vill veta vilka delar av Johns arbete som hon måste slå ihop med sitt arbete så att hon kan skicka dem. +Hon kör git log för att få reda på det:

+
+
+
+
$ git log --no-merges issue54..origin/master
+commit 738ee872852dfaa9d6634e0dea7a324040193016
+Författare: John Smith <jsmith@example.com>
+Datum:   Fri May 29 16:01:27 2009 -0700
+
+   ta bort ogiltigt standardvärde
+
+
+
+

Syntaxen issue54..origin/master används för att filtrera loggar. +Git ombeds att bara visa de incheckningar i den senare referensen (origin/master i det här fallet) som inte finns på den första referensen (här issue54). +Vi kommer att gå igenom syntaxen i detalj i avsnitt }}">Commit Ranges.

+
+
+

Från ovanstående output kan vi utläsa att det bara är en enda av Johns incheckningar som Jessika inte har slagit ihop med sitt arbete lokalt. +Om hon slår ihop sina ändringar med ändringarna på origin/master är det bara den incheckningen som kommer att påverka hennes lokala arkiv.

+
+
+

Nu kan Jessika slå ihop sin lokala funktionsgren med sin huvudgren, slå samman Johns ändringar (origin/master) med sin master gren och sen skicka sitt arbete till servern igen. .

+
+
+

När alla ändringar på grenen issue54 har checkats in, börjar Jessika med att byta tillbaka till sin huvudgren:

+
+
+
+
$ git checkout master
+Byter till gren 'master'
+Din gren ligger efter 'origin/master' med 2 incheckningar, kan snabbspolas.
+
+
+
+

Jessika kan slå ihop antingen origin/master eller issue54 först — de är båda uppströms, så ordningen spelar ingen roll. +Den slutliga ögonblicksbilden blir identisk oavsett vilken ordning hon väljer, det är bara historiken som kommer att skilja sig åt. +Hon bestämmer sig för att slå ihop grenen issue54 först:

+
+
+
+
$ git merge issue54
+Uppdaterar fbff5bc..4af4298
+Snabbspolar
+ README           |    1 +
+ lib/simplegit.rb |    6 +++++-
+ 2 filer ändrade, 6 tillägg(+), 1 borttagen(-)
+
+
+
+

Inget oväntat händer, som du kan se var det en sammanslagning som kunde snabbspolas framåt. +Jessika kan nu avsluta sammanslagningarna lokalt genom att slå ihop de ändringar hon hämtade tidigare från John och som är väntar kvar på origin/master:

+
+
+
+
$ git merge origin/master
+Slår ihop lib/simplegit.rb automatiskt
+Sammanslagning gjorde med metoden 'recursive'.
+ lib/simplegit.rb |    2 +-
+ 1 fil ändrad, 1 tillägg(+), 1 borttagning(-)
+
+
+
+

Allt slogs ihop smidigt, Jessikas historik ser nu ut så här:

+
+
+
+}}" alt="Jessikas historik efter att ha slagit ihop Johns ändringar infogats."> +
+
Figur 63. Jessikas historik efter att ha slagit ihop Johns ändringar.
+
+
+

Fjärreferensen origin/master kan nås från Jessikas huvudgren, så hon borde kunna skicka sina ändringar utan problem (förutsatt att John inte har skickat fler ändringar under tiden):

+
+
+
+
$ git push origin master
+...
+Till jessika@githost:simplegit.git
+   72bbc59..8059c15  master -> master
+
+
+
+

Båda utvecklarna har nu checkat in sina versioner av filerna några gånger och fått in varandras ändringar i sina lokala kodbaser.

+
+
+
+}}" alt="Jessikas historik efter att ha skickat tillbaka ändringarna till servern."> +
+
Figur 64. Jessikas historik efter att ha skickat tillbaka ändringarna till servern.
+
+
+

Det här är en av de enklaste arbetsprocesserna.

+
+
+

Du arbetar ett tag (vanligtvis i en funktionsgren), och slår ihop arbetet i huvudgrenen när det är klart. +När du vill dela ditt arbete, hämtar du och slår ihop din huvudgren med origin/master och skickar tillbaka din huvudgren till servern. +Den generella arbetsprocessen ser ut ungefär så här:

+
+
+
+}}" alt="Generell arbetsprocess med Git för flera utvecklare."> +
+
Figur 65. Generell arbetsprocess med Git för flera utvecklare.
+
+
+
+

Privat större team

+
+

+Nästa exempel är medverkan i ett större, privat team. +Här tittar vi närmre på hur arbetsprocessen kan se ut när mindre team samarbetar på features, som därefter slås ihop av andra team.

+
+
+

Säg att John och Jessika arbetar tillsammans på en funktion (vi kallar den “featureA”). +Samtidigt samarbetar Jessika och en tredje utecklare, Josie, på en annan, (“featureB”). +I det här fallet använder sig företaget av en slags integrationsstyrt arbetsprocess, där arbetet av ett enskilt team slås samman med huvudgrenen av specifika ingengörer. +Arkivets huvudgren kan endast uppdateras av dessa. +Allt arbete sker på förgreningar som sedan slås ihop av andra i ett senare skede.

+
+
+

Vi följer med Jessika medan hon arbetar på sina features parallellt, med två olika utvecklare, i en sådan här miljö. +Vi utgår ifrån att hon redan har klonat arkivet, när hon bestämmer sig för att börja med featureA. +Hon skapar en ny gren för funktionen och jobbar lite på den:

+
+
+
+
# Jessikas dator
+$ git checkout -b featureA
+Bytte till en ny gren 'featureA'
+$ vim lib/simplegit.rb
+$ git commit -am 'add limit to log function'
+[featureA 3300904] add limit to log function
+ 1 fil ändrades, 1 tillägg(+), 1 borttagning(-)
+
+
+
+

I det här läget behöver hon dela sitt jobb med John, så hon skickar sin featureA-gren med incheckningarna till servern. +Jessika har inte behörighet att slå ihop sina ändringar med huvuudgrenen, så hon behöver skicka dem till en annan gren för att kunna samarbeta med John:

+
+
+
+
$ git push -u origin featureA
+...
+Till jessica@githost:simplegit.git
+ * [new branch]      featureA -> featureA
+
+
+
+

Jessika mejlar John för att berätta att hon har skickat ändringar till en gren med namnet featureA och att han kan kolla på dem nu. +Medan hon väntar på feedback från John bestämmer hon sig för att börja jobba på featureB tillsammans med Josie. +Hon börjar med att skapa en ny gren från serverns huvudgren:

+
+
+
+
# Jessikas dator
+$ git fetch origin
+$ git checkout -b featureB origin/master
+Bytte till en ny gren 'featureB'
+
+
+
+

Nu gör Jessika ett par inckeckningar på `featureB`grenen:

+
+
+

`[source,console]

+
+
+
+
$ vim lib/simplegit.rb
+$ git commit -am 'made the ls-tree function recursive'
+[featureB e5b0fdc] made the ls-tree function recursive
+ 1 fil ändrad, 1 tillägg(+), 1 borttagen(-)
+$ vim lib/simplegit.rb
+$ git commit -am 'add ls-files'
+[featureB 8512791] add ls-files
+ 1 fil ändrad, 5 tillägg(+), 0 borttagna(-)
+
+
+
+

Jessikas arkiv ser nu ut så här:

+
+
+
+}}" alt="Jessikas initiala versionshistorik."> +
+
Figur 66. Jessikas initiala versionshistorik.
+
+
+

Hon är redo att skicka sina ändringar när hon får ett mejl från Josie som skriver att en gren hon har börjat på för featureB redan har skickats till servern som grenen featureBee. +Jessika behöver slå ihop de ändringarna med sina innan hon kan skicka sitt arbete till den gren Josie skickat till servern. +Jessika hämtar först Josies ändringar med git fetch:

+
+
+
+
$ git fetch origin
+...
+Från jessika@githost:simplegit
+ * [new branch]      featureBee -> origin/featureBee
+
+
+
+

Om vi antar att Jessika fortfarande är utcheckad på grenen featureB, så kan hon nu slå Josies arbete med den grenen med kommandot git merge:

+
+
+
+
$ git merge origin/featureBee
+Slår ihop lib/simplegit.rb automatiskt.
+Sammanslagning gjord med metoden 'recursive'.
+ lib/simplegit.rb |    6 ++++++
+ 1 fil ändrad, 6 tillägg(+), 0 borttagna(-)
+Sammanslagning gjord med metoden 'recursive'.
+ lib/simplegit.rb |    4 ++++
+ 1 fil ändrad, 4 tillägg(+), 0 borttagna(-)
+
+
+
+

I det här läget vill Jessika skicka allt som finns på featureB tillbaka till servern, men utan att skicka upp sin egna gren. +Eftersom Josie redan har påbörjat en uppströms featureBee-gren så vill Jessika skicka till den grenen. +Det gör hon med:

+
+
+
+
$ git push -u origin featureB:featureBee
+...
+Till jessick@githost:simplegit.git
+   fba9af8..cd685d1  featureB -> featureBee
+
+
+
+

Detta kallas för en referensspecifikation. +Se }}">The Refspec för mer information om Gits referensspecifikationer och hur du kan använda dem. +Lägg också märke till -u-flaggan; det är en kortversion av kommandot --set-upstream, som sparar en referens till den fjärrgren som din lokala gren spårar.

+
+
+

Plötsligt får Jessika ett mail från John, som berättar att han har skickat några ändringar till featureA-grenen och ber henne kolla på dem. +Återigen kör Jessika ett enkelt git fetch för att hämta allt nytt innehåll från servern, inklusive Johns senaste arbete:

+
+
+
+
$ git fetch origin
+...
+Från jessika@githost:simplegit
+   3300904..aad881d  featureA   -> origin/featureA
+
+
+
+

Jessika kan nu läsa loggarna med Johns senaste ändringar genom att jämföra innehållet som hämtades för featureA med den lokala kopian av samma gren:

+
+
+
+
$ git log featureA..origin/featureA
+commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
+Författare: John Smith <jsmith@example.com>
+Datum:   Fri May 29 19:57:33 2009 -0700
+
+    changed log output to 30 from 25
+
+
+
+

Om Jessika gillar det hon ser kan hon fusionera Johns nya arbete till sin lokala featureA gren med:

+
+
+
+
$ git checkout featureA
+Bytte till gren 'featureA'
+$ git merge origin/featureA
+Uppdaterar 3300904..aad881d
+Snabbspolar
+ lib/simplegit.rb |   10 +++++++++-
+1 fil ändrad, 9 tillägg(+), 1 borttagen(-)
+
+
+
+

Till sist kanske Jessika vill göra några mindre ändringar i det sammanslagna innehållet. +Hon har full frihet att göra sina ändringar, checka in dem till sin lokala gren featureA och skicka tillbaka slutresultatet till servern.

+
+
+
+
$ git commit -am 'small tweak'
+[featureA 774b3ed] small tweak
+ 1 fil ändrad, 1 tillägg(+), 1 borttagen(-)
+$ git push
+...
+Till jessika@githost:simplegit.git
+   3300904..774b3ed  featureA -> featureA
+
+
+
+

Jessikas incheckningshistorik kommer nu att se ut ungefär så här:

+
+
+
+}}" alt="Jessikas historik efter incheckningar på funktionsgrenen."> +
+
Figur 67. Jessikas historik efter incheckningar till funktionsgrenen.
+
+
+

Vid någon tidpunkt kommer Jessika, John och Josie att behöva informera dem som ansvarar för huvudgrenen att featureA och featureB är redo att slås ihop med den. +När sammanslagningen med huvudgrenen då är klar, kommer en hämtning av den att få med den nya versionsincheckningen. +Historiken kommer då att se ut så här:

+
+
+
+}}" alt="Jessikas historik efter sammanslagning av ämnesgrenar med huvudgren."> +
+
Figur 68. Jessikas 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 förgreningar sent i processen. +Möjligheten att mindre grupperingar inom ett team kan samarbeta via fjärrgrenar utan att nödvändigtvis behöva involvera hela teamet är utan tvekan en av Gits stora fördelar. +Arbetsprocessen som precis har beskrivts ser ut ungefär såhär:

+
+
+
+}}" alt="Grundläggande arbetsflöde för flera team."> +
+
Figur 69. Grundläggande arbetsprocess för flera team.
+
+
+
+

Öppet, litet projekt

+
+

+Att bidra till öppna projekt är ofta lite annorlunda än privata. +Eftersom du vanligtvis inte har behörighet att göra ändringar direkt i projektet behöver förvaltarna få ditt arbete på något annat sätt. +I det första exemplet ska vi titta på hur man förgrenar ett arkiv på de hostingsajter för Git som tillåter det. +Många hostingsajter har stöd för förgreningar, (såsom GitHub, BitBucket, repo.or.cz med flera) och många projektansvariga förväntar sig att andra medverkar på det sättet. +Det andra exemplet beskriver arbetsprocessen i de projekt som istället föredrar att acceptera patchade bidrag via mejl.

+
+
+

Det första du behöver göra är troligen att klona grundarkivet och skapa en funktionsgren för patcherna du planerar att bidra med +Flödet ser helt enkelt ut så här:

+
+
+
+
$ git clone <url>
+$ cd project
+$ git checkout -b featureA
+  ... arbeta ...
+$ git commit
+  ... arbeta ...
+$ git commit
+
+
+
+ + + + + +
+
Notera
+		 +
+

Du kanske kommer att vilja använda rebase -i för att komprimera ditt arbete till en enda incheckning, eller arrangera om incheckningnarna så att de blir enklare för de ansvariga att granska — se }}">Rewriting History för mer information om att ombasera grenar interaktivt.

+
+
+
+
+

När arbetet är klart och du är redo att dela det med förvaltarnas, gå till ursprungsarkivets projektsida och klicka på knappen ``Fork`` för att skapa en kopia av projektet som du har full behörighet till. +Därefter lägger du till det nya repots URL som ett nytt fjärrarkiv för ditt lokala arkiv; i det här exemplet kan vi kalla det för mingaffel:

+
+
+
+
$ git remote add mingaffel <url>
+
+
+
+

Sedan behöver du skicka ditt arbete till det här arkivet. +Det är enklare att skicka den finessgren du arbetar på till ditt kopierade arkiv än att fusionera det arbetet i din huvudgren och fusionera den. +Om ditt arbete inte bli godkänt, eller om din incheckning inte blir cherry-pickad, så slipper du spola tillbaka din huvudgren (läs mer om Gits cherry-pick i }}">Arbetsflöden med ombasering och plocka russin ur kakan). +Om de ansvariga å andra sidan slår ihop, ombaserar eller cherry-pickar din funktion, så kommer du att få tillbaka den genom att dra ner ändringar från deras repo ändå. +Hur du än gör kan du skicka ditt arbete med:

+
+
+
+
$ git push -u mingaffel featureA
+
+
+
+

+När ditt arbete har skickats till din förgrening av arkivet behöver du meddela förvaltarna av originalprojektet att du har arbete som du skulle vilja att de slår samman. +Detta kallas ofta för en pull request och du behöver vanligtvis göra en sådan begäran antingen via websida — GitHub har sin egen ``Pull Request``-mekanism som vi kommer att gå igenom i }}">GitHub — eller så kan du köra kommandot git request-pull och mejla den efterföljande utdatan till de ansvariga.

+
+
+

Kommandot git request-pull tar basgrenenen, det vill säga den gren du vill att din funktionsgren dras in i, och Git-arkivets URL som du vill att de accepterar kod ifrån, och sammanfattar alla ändringar du begär ska tas in. +Om Jessika till exempel vill skicka en pull request till John, och hon har gjort två incheckningar på funktionsgrenen som hon just har skickat, så kan hon använda det så här:

+
+
+
+
$ git request-pull origin/master mingaffel
+Följande ändringar sen incheckning 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
+Jessika Smith (1):
+        added a new function
+
+är tillgängliga i git-arkivet på:
+
+  git://githost/simplegit.git featureA
+
+Jessika Smith (2):
+      add limit to log function
+      change log output to 30 from 25
+
+ lib/simplegit.rb |   10 +++++++++-
+ 1 fil ändrad, 9 tillägg(+), 1 borttagning(-)
+
+
+
+

Den här utdatan kan skickas till de ansvariga — den beskriver från vilken gren arbetet förgrenades, ger en sammanfattning av incheckningarna och varifrån den nya funktionen kan hämtas.

+
+
+

I ett projekt där du inte är ansvarig är det oftast enklast att ha en huvudgren, t.ex master, som alltid följer origin/master och sen arbeta i funktionsgrenar som du enkelt kan radera om de inte godkänns. +Att isolera funktioner tll funktionsgrenar gör det också lättare för dig att flytta ditt arbete om änden på huvudarkivet har rört sig under tiden du arbetat så att din version inte längre kan sammanfogas på ett smidigt sätt. +Om du till exempel vill skicka in en andra funktionsgren till projektet, fortsätt inte att arbeta på den funktionsgren du nyss skickade upp — börja istället om från arkivets huvudgren:

+
+
+
+
$ git checkout -b featureB origin/master
+  ... arbeta ...
+$ git commit
+$ git push mingaffel featureB
+$ git request-pull origin/master myfork
+  ... e-postbrevet genererar förfrågan att hämta till ansvarig ...
+$ git fetch origin
+
+
+
+

Now, each of your topics is contained within a silo — similar to a patch queue — that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: +Nu är båda dina funktioner i varsitt silo — som en kö för patchar — som du kan skriva om, ombasera och ändra utan att funktionerna påverkar eller blir beroende av varandra:

+
+
+
+}}" alt="Initial versionshistorik för `featureB`."> +
+
Figur 70. Initial versionshistorik för featureB.
+
+
+

Om vi säger att projektets ansvariga har dragit in ett gäng andra patches innan de testar din första gren, så kan den inte sammanfogas automatiskt. +I det här fallet kan du försöka att ombasera den grenen så att den hamnar längst ut på toppen av origin/master, lösa eventuella konflikter och skicka in din version igen:

+
+
+
+
$ git checkout featureA
+$ git rebase origin/master
+$ git push -f mingaffel featureA
+
+
+
+

Det här skriver om historiken enligt bilden nedan }}">Versionshistorik efter avslutat arbete med featureA..

+
+
+
+}}" alt="Versionshistorik efter avslutat arbete med `featureA`."> +
+
Figur 71. Versionshistorik efter avslutat arbete med featureA.
+
+
+

Eftersom du flyttade grenen behöver du ange -f till ditt kommando för att kunna ersätta serverns featureA-gren med en annan incheckning än den ursprungliga. +Ett alternativ vore att skicka det här nya arbetet till en annnan gren på servern (som kanske kan heta featureAv2),

+
+
+

Vi tittar närmre på ytterligare ett alternativ: ansvariga har tittat ändringarna i din andra gren och gillar dem mestadels, men de skulle vilja att du gjorde en justering. +Du använder möjligheten att flytta förgreningen från featureA till huvudgrenen.

+
+
+

Du kan göra det här genom att skapa en ny gren från origin/master, sammanfoga featureB där, lösa eventuella konflikter, göra ändringen och skicka det som en ny gren: +

+
+
+
+
$ git checkout -b featureBv2 origin/master
+$ git merge --squash featureB
+  ... justera ...
+$ git commit
+$ git push mingaffel featureBv2
+
+
+
+

Flaggan --squash komprimerar alla incheckningar på grenen som ska slås ihop till en enda versionsändring, vilket ger samma status i arkivet som vid en sammanslagning. +Det innnebä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 kommer på pränt. +Ibland kan det vara användarbart att använda flaggan --no-commit för att fördröja en ny incheckning vid en sammanslagning istället för som i den ordinarie sammanslagningsprocessen. +I det här läget kan du meddela ansvarig att du har gjort de begärda ändringarna och att de kan hitta dessa i din featureBv2.

+
+
+
+}}" alt="Versionshistorik efter `featureBv2`."> +
+
Figur 72. Versionshistorik efter featureBv2.
+
+
+
+

Öppet, större projekt via mejl

+
+

+Många projekt har sina rutiner för att acceptera patchar — du behöver kolla upp de specifika reglerna för varje projekt, eftersom de kommer att skilja sig åt. +Eftersom det finns flera äldre, större projekt som endast accepterar patchar via en mejllista för utvecklare, så kommer vi att gå igenom ett exempel på hur det går till.

+
+
+

Arbetsprocessen liknar den i föregående exemplet — du skapar finessgrenar som du arbetar på. +Den stora skillnaden är att du inte kan skicka dina inceckningar till fjärrarkivet. +Istället behöver du mejla varje commit till en mejllista för utvecklare.

+
+
+
+
$ git checkout -b topicA
+  ... arbeta ...
+$ git commit
+  ... arbeta ...
+$ git commit
+
+
+
+

+Nu har du två incheckningar som du vill skicka till mejllistan. +För att generera mbox-formatterade filer som du kan mejla till listan, använder du git format-patch — det gör om varje incheckning till ett mejl med den första raden i incheckningsmeddelandet som ämne och resten av meddelandet plus patchen som innehåll. +Det fina med det här är att när en patch från ett mejl genererat med format-patch appliceras, så bevaras incheckningsinformationen korrekt.

+
+
+
+
$ git format-patch -M origin/master
+0001-add-limit-to-log-function.patch
+0002-changed-log-output-to-30-from-25.patch
+
+
+
+

format-patch-kommandot skriver ut namnen på de patchfiler som skapas. +Flaggan -M talar om för Git att leta efter omdöpta filer. +Filerna kommer att se ut så här:

+
+
+
+
$ cat 0001-add-limit-to-log-function.patch
+Av 330090432754092d704da8e76ca5c05c198e71a8 Mån Sep 17 00:00:00 2001
+Från: Jessica Smith <jessica@example.com>
+Datum: Sön, 6 apr 2008 10:17:23 -0700
+Ämne: [PATCH 1/2] add limit to log function
+
+Limit log functionality to the first 20
+
+---
+ lib/simplegit.rb |    2 +-
+ 1 fil ändrad, 1 tillagd(+), 1 borttagen(-)
+
+diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+index 76f47bc..f9815f1 100644
+--- a/lib/simplegit.rb
++++ b/lib/simplegit.rb
+@@ -14,7 +14,7 @@ class SimpleGit
+   end
+
+   def log(treeish = 'master')
+-    command("git log #{treeish}")
++    command("git log -n 20 #{treeish}")
+   end
+
+   def ls_tree(treeish = 'master')
+--
+2.1.0
+
+
+
+

Du kan också redigera patchfilerna för att lägga till mer information till mejllistan som du inte vill ska visas i incheckningsmeddelandet. +Om du lägger till text mellan raden --- och början av patchen (inleds med raden diff --git), så kan utvecklarna läsa meddelandet, men det ignoreras i patchningsprocessen. +Det är en bra plats att lägga till information om varför du gjorde ändringarna, eller om du har några speciella instruktioner för att testa dem.

+
+
+

För att skicka patchfilen till mejllistan kan du antingen klistra in innehållet i ditt mejlprogram eller skicka det via kommandoraden. +Att klistra in texten orsakar ofta formatteringsproblem, speciellt med “smartare” klienter som inte bevarar radbrytningar och mellanslag korrekt. +Som tur är har Git ett verktyg som hjälper dig att skicka korrekt formatterade patchar via IMAP, vilket gör det enklare. +Vi kommer att visa hur du skickar en patch via Gmail, som råkar vara den e-postklient vi känner till bäst. +Du kan läsa detaljerade instruktioner för en mängd e-postklienter i slutet av filen Documentation/SubmittingPatches i Gits källkod.

+
+
+

+Först behöver du sätta upp IMAP-sektionen i din ~/.gitconfig-fil. +Du kan sätta varje värde separat med en serie git config-kommandon, eller lägga till dem manuellt. +I slutänden ska din konfigurationsfil se ut något så här:

+
+
+
+
[imap]
+  folder = "[Gmail]/Drafts"
+  host = imaps://imap.gmail.com
+  user = user@gmail.com
+  pass = YX]8g76G_2^sFbd
+  port = 993
+  sslverify = false
+
+
+
+

Om din IMAP-server inte använder SSL så är de två sista raderna nog inte nödvändiga, och värdet för host kommer då att vara imap:// istället för imaps://. +När det är inställt kan du använda git imap-send för att placera patchserien i mappen Drafts på den angivna IMAP-servern:

+
+
+
+
$ cat *.patch |git imap-send
+Analyserar imap.gmail.com... ok
+Ansluter till [74.125.142.109]:993... ok
+Loggar in...
+skickar 2 meddelanden
+100% (2/2) klart
+
+
+
+

Nu borde du kunna gå till din Drafts-mapp, ändra To-fältet till mejllistan du ska skicka patchen till, eventuellt lägga till cc:a till den person som är ansvarig, och skicka iväg det.

+
+
+

Du kan också skicka patcharna via en SMTP-server. +Precis som tidigare kan du sätta varje värde separat med en serie git config-kommandon, eller lägga till dem manuellt i ~/.gitconfig-filen:

+
+
+
+
[sendemail]
+  smtpencryption = tls
+  smtpserver = smtp.gmail.com
+  smtpuser = user@gmail.com
+  smtpserverport = 587
+
+
+
+

När det är inställt kan du använda git send-email för att skicka patcharna:

+
+
+
+
$ git send-email *.patch
+0001-added-limit-to-log-function.patch
+0002-changed-log-output-to-30-from-25.patch
+Från vem ska breven skickas? [Jessica Smith <jessica@example.com>]
+E-postbreven kommer att skickas från: Jessica Smith <jessica@example.com>
+Till vem ska breven sändas (om någon)? jessica@example.com
+Message-ID att använda som In-Reply-To för det första brevet? y
+
+
+
+

Git kommer att ställa en rad frågor om hur du vill att e-posten ska se ut för varje skickad patch. +De kommer att se ut ungefär så här:

+
+
+
+
(mbox) Lägger till cc: Jessica Smith <jessica@example.com> från
+  \line 'From: Jessica Smith <jessica@example.com>'
+OK. Loggen säger:
+Sendmail: /usr/sbin/sendmail -i jessica@example.com
+Från: Jessica Smith <jessica@example.com>
+Till: jessica@example.com
+Ämne: [PATCH 1/2] added limit to log function
+Datum: Sat, 30 May 2009 13:29:15 -0700
+Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
+X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
+In-Reply-To: <y>
+References: <y>
+
+Result: OK
+
+
+
+
+

Sammanfattning

+
+

I den här delen har vi gått igenom en mängd olika arbetsflöden för olika slags Git-projekt som du troligen kommer att stöta på, samt introducerat ett par nya verktyg för att hjälpa dig att hantera processerna. +I nästa del kommer du att få lära dig hur du hanterar den andra sidan av myntet: att underhålla ett Git-projekt. +Du får lära dig att vara en välvillig diktator eller integrationsansvarig.

+
+
+ \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Distribuerade-Git-Sammanfattning.html b/external/book/content/book/sv/v2/Distribuerade-Git-Sammanfattning.html new file mode 100644 index 0000000000..27f236ca74 --- /dev/null +++ b/external/book/content/book/sv/v2/Distribuerade-Git-Sammanfattning.html @@ -0,0 +1,26 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +category: book +section: documentation +subsection: book +sidebar: book +book: + language_code: sv + chapter: + title: Distribuerade Git + number: 5 + section: + title: Sammanfattning + number: 4 + cs_number: '5.4' + previous: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt + next: book/sv/v2/GitHub-Account-Setup-and-Configuration +title: Git - Sammanfattning +--- +

Sammanfattning

+
+

Du borde känna dig ganska bekväm med att bidra till ett projekt i Git samt underhålla ditt eget projekt och integrera andra användares bidrag. +Gratulerar på vägen till att bli en effektiv Git-utvecklare! +I nästa kapitel får du lära dig mer om hur du använder den största och mest populära Git-hostingtjänsten, GitHub.

+
+ \ No newline at end of file diff --git "a/external/book/content/book/sv/v2/Distribuerade-Git-Underh\303\245lla-ett-projekt.html" "b/external/book/content/book/sv/v2/Distribuerade-Git-Underh\303\245lla-ett-projekt.html" new file mode 100644 index 0000000000..459aecd822 --- /dev/null +++ "b/external/book/content/book/sv/v2/Distribuerade-Git-Underh\303\245lla-ett-projekt.html" @@ -0,0 +1,689 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +category: book +section: documentation +subsection: book +sidebar: book +book: + language_code: sv + chapter: + title: Distribuerade Git + number: 5 + section: + title: Underhålla ett projekt + number: 3 + cs_number: '5.3' + previous: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt + next: book/sv/v2/Distribuerade-Git-Sammanfattning +title: Git - Underhålla ett projekt +url: "/book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt.html" +--- +

Underhålla ett projekt

+
+

+Förutom att veta hur du bidrar effektivt till ett projekt, behöver du troligen kunskap om hur man underhåller ett. +Det kan innebära att acceptera och tillämpa patcher som genererats via format-patch och skickats till dig via mejl, eller att integrera ändringar i fjärrgrenar. +Oavsett om du underhåller ett eget arkiv eller vill hjälpa till med att godkänna patcher, behöver du veta hur man accepterar bidrag på ett strukturerat sätt, dels för att underlätta för bidragslämnare och dels för att underhållet ska bli hållbart för dig över tid.

+
+
+

Arbeta i ämnesgrenar

+
+

+När det gäller att integrera nytt arbete är det generellt en bra idé att prova hur den fungerar i en ämnesgren — det vill säga en tillfällig gren som är specifikt skapad för att prova det nya arbetet. +Det gör det enkelt att justera patcherna individuellt och kunna lämna dem som inte fungerar tills bidragslämnaren har tid att återkomma med förbättringar. +Om du skapar ett grennamn baserat på temat för den patch du testar, till exempel ruby_client eller liknande, kommer du enkelt påmind om syftet med grenen om du måste lämna den och komma tillbaka senare. +Underhållarna av Git anger en namnrymd för dessa grenar också — till exempel sc/ruby_client, där prefixet sc är förkortningen för personen som bidrog med arbetet. +Som du säkert kommer ihåg kan du skapa grenen från din master-gren på följande sätt:

+
+
+
+
$ git branch sc/ruby_client master
+
+
+
+

Vill du byta till den direkt använder du istället checkout -b:

+
+
+
+
$ git checkout -b sc/ruby_client master
+
+
+
+

Nu är du redo att lägga till det bidragande arbetet när du har bestämt dig för om du vill applicera förslaget i någon av dina långlivade grenar eller inte

+
+
+
+

Arbeta via mejl

+
+

+Om du tar emot patcher som ska integreras i ditt projekt via mejl, behöver du först du applicera patchen i din ämnesgren för att kunna granska den. +Det finns två sätt att applicera en mejlad patch: med git apply eller med git am.

+
+
+

Applicera en mejlad patch med apply +

+
+

+Om du har fått patchen av någon som genererade den med git diff eller någon variant av Unix diff-kommandot (rekommenderas inte; se mer i nästa avsnitt), kan du applicera den med git apply. +Om vi utgår från att du sparade patchen på /tmp/patch-ruby-client.patch, ser det ut så här:

+
+
+
+
$ git apply /tmp/patch-ruby-client.patch
+
+
+
+

Kommandot ändrar filerna i ditt lokala arkiv. +Det är nästan identiskt som att köra patch -p1 för att applicera patchen, men det accepterar inte lika luddiga matchningar som patch. +Det hanterar också filer som läggs till, tas bort och döps om om de beskrivs i git diff-formatet, vilket patch inte gör. +Slutligen är git apply en “applicera allt eller avbryt allt”-modell, där allt eller inget appliceras. +patch kan å andra sidan applicera delar av patchfiler, men det kan lämna ditt lokala arkiv i ett lite märkligt tillstånd. +Övergripande sett är git apply ett mer konservativt kommando än patch. +Det kommer inte att göra en inceckning åt dig — när du har kört kommandot behöver du köa och checka in ändringarna manuellt.

+
+
+

git apply kan också användas för att se om en patch kan läggas till utan konflikter innan du försöker applicera den — kör git apply --check följt av patchen-filen:

+
+
+
+
$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
+error: patch misslyckades: ticgit.gemspec:1
+error: ticgit.gemspec: patchen kan inte tillämpas
+
+
+
+

Om det inte finns någon utdata kan patchen integreras utan problem. +Detta kommando avslutar med ett nollskilt tal om kontrollen misslyckas, så det kan användas i skript med om du vill.

+
+
+
+

Applicera en mejlad patch med am +

+
+

+Om bidragslämnaren är en van Git-användare som använde kommandot format-patch för att generera sin patch, blir ditt jobb genast enklare. +Patchen innehåller då även författarinformation och ett incheckningsmeddelande. +Om du har möjlighet, uppmuntra dina bidragslämnare att använda format-patch istället för diff för att generera patchar till ditt projekt. +git apply borde bara användas för patchar till legacy projekt.

+
+
+

För att applicera en patch som genererats av format-patch använder du git am (kommandot heter am eftersom det används för att "applicera en serie patchar från en mejlbox"). +Tekniskt sett är git am byggt för att läsa en mbox-fil, som är ett enkelt, textbaserat format för att lagra ett eller flera e-postmeddelanden i en textfil. +Det ser ut så här:

+
+
+
+
Från 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
+Från: Jessica Smith <jessica@example.com>
+Datum: Sun, 6 Apr 2008 10:17:23 -0700
+Ämne: [PATCH 1/2] add limit to log function
+
+Limit log functionality to the first 20
+
+
+
+

Det här är början på utdata från git format-patch-kommandot som du såg i föregående avsnitt; det är också ett giltigt mbox-e-postformat. +Om någon har mejlat patchen till dig på rätt sätt med git send-email och du laddar ner den i mbox-format, kan du peka git am till mbox-filen för att den ska börja applicera alla patchar den ser. +Om du använder en mejlklient som kan spara flera mejl i mbox-format, kan hela patchserier sparas i en fil och sen kan du köra git am för att applicera dem en i sänder.

+
+
+

Om någon däremot laddade upp en patchfil som genererats via git format-patch till ett ärendehanteringssystem eller liknande, kan du spara filen lokalt och sedan köra git am för att applicera den:

+
+
+
+
$ git am 0001-limit-log-function.patch
+Applicerar: add limit to log function
+
+
+
+

Den applicerades utan konflikt och skapade automatiskt en ny incheckning åt dig. +Informationen om författaren tas från mejlets Från- och Datum-rubriker, meddelandet i incheckningen tas från Ämne och brödtexten (innan patchen) i mejlet. +Om den här patchen applicerades från mbox-exemplet ovan, skulle den genererade incheckningen se ut ungefär så här:

+
+
+
+
$ git log --pretty=fuller -1
+commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+Författare:     Jessica Smith <jessica@example.com>
+Författardatum: Sun Apr 6 10:17:23 2008 -0700
+Incheckning:     Scott Chacon <schacon@gmail.com>
+Inchdeckningsdatum: Thu Apr 9 09:19:06 2009 -0700
+
+   add limit to log function
+
+   Limit log functionality to the first 20
+
+
+
+

Incheckningsinformationen anger vem som applicerade patchen och vid vilken tidpunkt. +Författarinformation anger vem som skapade den och när.

+
+
+

Det är inte omöjligt att patchen inte kan appliceras på grund av konflikter. +Kanske har din huvudgren divergerat för långt från den gren patchen byggdes från, eller så förgrenades den från en patch som du inte har applicerat än. +git am-processen kommer då att misslyckas och du blir tillfrågad om hur du vill lösa konflikten:

+
+
+
+
$ git am 0001-seeing-if-this-helps-the-gem.patch
+Tillämpar: seeing if this helps the gem
+error: patch misslyckades: ticgit.gemspec:1
+error: ticgit.gemspec: patchen kan inte tillämpas
+Patchen misslyckades på 0001.
+När du har löst problemet, kör "git am --resolved".
+Om du hellre vill hoppa över patchen, kör "git am --skip" istället.
+För att återgå till ursprunglig gren och sluta patcha, kör "git am --abort".
+
+
+
+

Det här kommandot anger i vilka berörda filer det finns konflikter, precis som vid en sammanslagning eller ombasering. +Du löser det här problemet på ungefär samma sätt — redigerar filen för att lösa konflikten, köar den nya filen och kör sedan git am --resolved för att fortsätta till nästa patch:

+
+
+
+
$ (fix the file)
+$ git add ticgit.gemspec
+$ git am --resolved
+Tillämpar: seeing if this helps the gem
+
+
+
+

Om du vill att Git ska försöka göra en lite mer intelligent operation för att lösa konflikten kan du lägga till en -3-flagga. +Git försöker då att göra en trefältsfusion. +Det är inte förvalt eftersom det inte fungerar om den incheckning som patchen förgrenades ifrån inte finns i ditt arkiv. +Om patchen däremot förgrenades från en offentlig incheckning är -3-flaggan generellt mycket smartare för att applicera en patch med konflikter:

+
+
+
+
$ git am -3 0001-seeing-if-this-helps-the-gem.patch
+Tillämpar: seeing if this helps the gem
+error: patch misslyckades: ticgit.gemspec:1
+error: ticgit.gemspec: patchen kan inte tillämpas
+Använder indexinfo för att återskapa ett basträd...
+Faller tillbaka på att patcha grundversionen och trevägssammanslagning...
+Inga ändringar -- Patchen har redan tillämpats.
+
+
+
+

Utan -3-flaggan skulle patchen i det här fallet ha betraktats som konfliktfylld. +Med -3-flaggan appliceras den utan problem.

+
+
+

Om du applicerar ett helt gäng patcher från en mbox kan du också köra am-kommandot i interaktivt läge, vilket stannar processen vid varje patch för att fråga om du vill applicera den:

+
+
+
+
$ git am -3 -i mbox
+Incheckningskroppen är:
+--------------------------
+seeing if this helps the gem
+--------------------------
+Tillämpa? [Y]=ja/[N]=nej/[E]=redigera/[V]=visa patch/[A]=godta alla:
+
+
+
+

Det här är användbart om du har många patcher för att kunna se dem först om du inte skulle komma ihåg vad någon handlar om, eller hoppa över någon som du redan har lagt till.

+
+
+

När alla patcher har lagts till och checkats in i din gren behöver du bestämma om och hur du ska integrera dem i en långlivad gren.

+
+
+
+
+

Checka ut fjärrgrenar

+
+

+Om ditt bidrag kom från en Git-användare som har checkat ut sin egen gren, skickat ett antal ändringar till den och sedan skickat URL:en till sitt repo och namnet på den grenen som ändringarna finns i till dig, kan du lägga till den som en fjärrgren och göra sammanslagning lokalt.

+
+
+

Om Jessika till exempel skickar ett mejl och skriver att hon har en bra ny funktion i ruby-client-grenen i sitt arkiv, kan du testa den genom att lägga till den som fjärrgren och checka ut den lokalt:

+
+
+
+
$ git remote add jessica git://github.com/jessica/myproject.git
+$ git fetch jessica
+$ git checkout -b rubyclient jessica/ruby-client
+
+
+
+

Om hon mejlar dig igen med en annan gren som har en annan bra funktion kan du direkt köra fetch och checkout eftersom du redan har ställt in fjärrgrenen.

+
+
+

Det här är mest användbart om du arbetar regelbundet med en person. +Om någon bara bidrar med en patch lite då och då är det mindre tidskrävande att acceptera den via e-post än att kräva att alla kör sina egna servrar och ständigt lägga till och ta bort fjärrgrenar för att få några patcher. +Du kommer sannolikt inte heller att vilja ha hundratals fjärrgrenar, där de flesta är från någon som bara bidrar med en patch eller två. +Hur som helst, skript och hostade tjänster kan göra det enklare — det beror till stor del på hur du och dina bidragslämnare utvecklar.

+
+
+

Den andra fördelen med den här metoden är att du behåller historiken för incheckningarna. +Även om du kanske har sammanslagningskonflikter, så vet du var i historiken deras arbete är baserat; en korrekt trefältsfusion är standard istället för att behöva ange en -3 och hoppas att patchen genererades från en offentlig incheckning som du har tillgång till.

+
+
+

Om du inte samarbetar kontinuerligt med en person men ändå vill dra in kod från dem på det här sättet kan du ange URL:en till fjärrarkivet när du kör git pull. +Det gör en enstaka hämtning från ett fjärrarkiv utan att spara URL:en som en fjärreferens:

+
+
+
+
$ git pull https://github.com/onetimeguy/project
+Från https://github.com/onetimeguy/project
+ * branch            HEAD       -> FETCH_HEAD
+Sammanslagning genomförd med strategi 'recursive'.
+
+
+
+
+

Avgöra vad som ska integreras

+
+

+Nu har du en ämnesgren som innehåller ett bidrag. +Du behöver nu bestämma vad du vill göra med den. +I det här avsnittet går vi igenom några kommandon som du kan använda för att granska exakt vad som kommer att tillämpas om du sammanfogar den här grenen med din huvudgren.

+
+
+

Det är ofta användbart att få en överblick över alla de incheckningar i den här grenen som inte finns i din huvudgren. +Du kan utesluta incheckningar i huvudgrenen genom att lägga till --not-flaggan före grennamnet. +Det gör samma sak som kommandot master..contrib som vi använde tidigare. +Om din bidragslämnare skickar två patchar, du skapar en gren som heter contrib och applicerar dessa patchar där kan du köra detta:

+
+
+
+
$ git log contrib --not master
+commit 5b6235bd297351589efc4d73316f0a68d484f118
+Författare: Scott Chacon <schacon@gmail.com>
+Datum:   Fri Oct 24 09:53:59 2008 -0700
+
+    seeing if this helps the gem
+
+commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
+Författare: Scott Chacon <schacon@gmail.com>
+Datum:   Mon Oct 22 19:38:36 2008 -0700
+
+    updated the gemspec to hopefully work better
+
+
+
+

För att se vad varje incheckning gör, kom ihåg att du kan ange -p-flaggan till git log. +Då läggs diffen till som tillämpandet av en patch ger.

+
+
+

För att se en fullständig diff över vad som skulle hända om du sammanfogade hela ämnesgrenen med en annan gren, kan du behöva använda ett lite märkligt trick för att få korrekta resultat. +Du kanske tror att du kan köra detta:

+
+
+
+
$ git diff master
+
+
+
+

Det här kommandot ger dig mycket riktigt en diff, men om din master-gren har flyttats framåt sedan du förgrenade ämnesgrenen från den är de något vilseledande. +Detta beror på att Git direkt jämför ögonblicksbilder av den sista incheckningen på den ämnesgren du är på och ögonblicksbilden av den senaste incheckningen på master-grenen. +Om du, till exempel, har lagt till en rad i en fil på master-grenen, kommer en direkt jämförelse av grenarnas ögonblicksbilder få det att se ut som att ämnesgrenen kommer att ta bort den raden.

+
+
+

Om master-grenen inte har rört sig är det inte ett problem, men har historiken divergerat kommer diffen att se ut som att du lägger till allt nytt i din ämnesgren och tar bort allt unikt för master-grenen.

+
+
+

Vad du verkligen vill se är ändringarna som lagts till i funktionsgrenen — resultatet av de ändringar som bblir om du slår ihop den här grenen med master. +Det gör du genom att be Git jämföra den sista incheckningen på din temagren med den första gemensamma föregångaren den har med master-grenen.

+
+
+

Tekniskt sett kan du göra det genom att explicit räkna ut den gemensamma föregångaren och sedan köra diff på den:

+
+
+
+
$ git merge-base contrib master
+36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
+$ git diff 36c7db
+
+
+
+

Eller, mer koncist:

+
+
+
+
$ git diff $(git merge-base contrib master)
+
+
+
+

Hur som helst så är ingen av dessa särskilt bekväma, så Git ger en annan förkortning för att göra samma sak: trepunktssyntaxen. +I kontexten git diff-kommandot kan du sätta tre punkter efter en annan gren för att göra en diff mellan den sista incheckningen på den gren du är på och dess gemensamma föregångare med en annan gren:

+
+
+
+
$ git diff master...contrib
+
+
+
+

Det här kommandot visar dig exakt vad som har lagts till i den här grenen sedan den delade föregångaren med master-grenen. +Det är en mycket användbar syntax att lägga på minnet.

+
+
+
+

Integrera kod från bidragslämnare

+
+

+När allt arbete i din funktionsgren är redo att slås ihop i din huvudgren är frågan hur du ska göra det. +Vidare, vilken övergripande arbetsflöde vill du använda för att underhålla ditt projekt? +Du har ett antal metoder att välja mellan, och vi kommer att gå igenom några av dem

+
+
+

Arbetsflöden med sammanslagning

+
+

+Ett grundläggande arbetsflöde är att helt enkelt slå ihop allt arbete direkt i din master-gren. +I det här scenariot har du en master-gren som innehåller stabil kod. +När du har arbete i en funktionsgren som du tror att du har slutfört, eller arbete som någon annan har bidragit med och du har verifierat, slår du ihop det i din master-gren, tar bort den just sammanfogade temagrenen och upprepar.

+
+
+

Om vi har ett arkiv med arbete i två grenar som heter ruby_client och php_client som ser ut som }}">Historik med flera funktionsgrenar, och vi slår ihop ruby_client följt av php_client, kommer din historik att se ut som }}">Efter en sammanslagning med en funktionsgren..

+
+
+
+}}" alt="Historik med flera funktionsgrenar."> +
+
Figur 73. Historik med flera funktionsgrenar
+
+
+
+}}" alt="Efter en sammanslagning med en funktionsgren."> +
+
Figur 74. Efter en sammanslagning med en funktionsgren.
+
+
+

Det här är förmodligen det enklaste arbetsflödet, men det kan bli problematiskt om du arbetar med större eller mer stabila projekt där du vill vara riktigt försiktig med vad du introducerar.

+
+
+

Om du har ett viktigare projekt kanske du vill använda en tvåfas-sammanslagningcykel. +I det scenariot har du två långlivade grenar, master och develop, där du bestämmer att master uppdateras endast när en mycket stabil version skapas och all ny kod integreras i develop-grenen. +Du skickar regelbundet båda dessa grenar till det publika arkivet. +Varje gång du har en ny funktionsgren att slå ihop (}}">Före en sammanslagning av en funktionsgren.), slår du ihop den i develop (}}">Efter en sammanslagning av en funktionsgren.); sedan, när du taggar en version, snabbspolar du master till där develop-grenen är stabil (}}">Efter en ny version.).

+
+
+
+}}" alt="Före en sammanslagning av en funktionsgren."> +
+
Figur 75. Före en sammanslagning av en funktionsgren.
+
+
+
+}}" alt="Efter en sammanslagning av en funktionsgren."> +
+
Figur 76. Efter en sammanslagning av en funktionsgren.
+
+
+
+}}" alt="Efter en ny version."> +
+
Figur 77. Efter en ny version.
+
+
+

På det här sättet, när folk klonar ditt projekts arkiv, kan de antingen kolla ut master för att bygga den senaste stabila versionen och enkelt hålla sig uppdaterade på den, eller kolla ut develop, som är den mer skärpta innehållet. +Du kan också utöka det här konceptet genom att ha en integrate-gren där allt arbete sammanfogas. +När kodbasen på den grenen är stabil och passerar tester, slår du ihop den i en develop-gren; och när den har visat sig vara stabil under en tid, snabbspolar du din master-gren.

+
+
+
+

Arbetsflöde med stora sammanslagningar

+
+

+
+
+

+Git-projektet har fyra långlivade grenar: master, next och pu (proposed updates) för nytt arbete, och maint för underhållsbackportar. +När nytt arbete introduceras av bidragslämnare samlas det i temagrenar i förvaltarens arkiv på ett sätt som liknar det som har beskrivits (se }}">Hantera en komplex serie med parallella ämnesgrenar.). +Vid det här laget utvärderas temana för att avgöra om de är säkra och redo för användning eller om de behöver mer arbete. +Om de är säkra slås de ihop i next, och den grenen pushas upp så att alla kan prova temana integrerade tillsammans.

+
+
+
+}}" alt="Hantera en komplex serie med parallella ämnesgrenar."> +
+
Figur 78. Hantera en komplex serie med parallella ämnesgrenar.
+
+
+

Om det behövs mer arbete på en temagren slås den ihop med pu istället. +När det har bestämts att de är helt stabila slås de ihop med master-grenen. +next- och pu-grenarna byggs sedan om från master. +Det här innebär att master nästan alltid rör sig framåt, next ombaseras ibland, och pu ombaseras ännu oftare:

+
+
+
+}}" alt="Slå ihop ämnesgrenar med långlivade integrationsgrenar."> +
+
Figur 79. Slå ihop ämnesgrenar med långlivade integrationsgrenar.
+
+
+

När en ämnesgren äntligen har slagits ihop med master-grenen tas den bort från arkivet. +Git-projektet hr också en maint-gren som är en gren som är förgrenad från den senaste versionen för att tillhandahålla bakåtkompatibla patchar om en underhållsversion krävs. +Så, när du klonar Git-arkivet har du fyra grenar som du kan kolla ut för att utvärdera projektet i olika utvecklingsstadier, beroende på hur nyskapande du vill vara eller hur du vill bidra; och förvaltaren har ett strukturerat arbetsflöde för att hjälpas åt att granska nya bidrag. +Git-projektet har ett specialiserat arbetsflöde. +För att förstå det bättre kan du läsa mer på Git Maintainer’s guide.

+
+
+
+

Arbetsflöden med ombasering och plocka russin ur kakan

+
+

+När du har arbete i en temagren och har bestämt att du vill integrera det, kan du göra det på två sätt: genom att ombasera eller plocka russin ur kakan. +Vissa förvaltare föredrar att ombasera eller plocka russin ur kakan för att hålla en mestadels linjär historik. +När du har arbete i en temagren och har bestämt att du vill integrera det, flyttar du till den grenen och kör ombasera-kommandot för att bygga om ändringarna på din nuvarande master-gren (eller develop, och så vidare). +Om det går bra kan du snabbspola din master-gren. +I slutänden får du en linjär projektshistorik.

+
+
+

+Ett annat sätt att flytta in arbete från en gren till en annan är att plocka russin ur kakan. +Att plocka russin ur kakan i Git är som en ombasering men för en enskild incheckning. +Det tar en patch från en incheckning och försöker applicera den på den gren du är på. +Detta är användbart om du har ett antal incheckningar på en temagren och du baran vill integrera en av dem, eller om du föredrar att plocka in incheckningarna en och en istället för att göra en ombasering. +Om du till exempel har ett projekt som ser ut så här:

+
+
+
+}}" alt="Exempel historik före russin plockats ur kakan."> +
+
Figur 80. Exempel historik före russin plockats ur kakan.
+
+
+

Om du vill dra in incheckningen e43a6 i din master-gren kan du köra

+
+
+
+
$ git cherry-pick e43a6
+Avslutade en cherry-pick.
+[master]: created a0a41a9: "More friendly message when locking the index fails."
+ 3 filer ändrade, 17 tillagda(+), 3 borttagna(-)
+
+
+
+

Det här drar in ändringarna i incheckning e43a6 in i din master-gren., men du får ett nytt SHA-1-värde för incheckningen eftersom datumet som den tillämpades är annorlunda. +Din historik ser nu ut så här:

+
+
+
+}}" alt="Historik efter russinplockning av en inceckning på en funktionsgren."> +
+
Figur 81. Historik efter russinplockning av en inceckning på en funktionsgren.
+
+
+

Nu kan du radera din funktionsgren och släppa incheckningarna som du inte vill få in.

+
+
+
+

Rerere

+
+

+Om du gör massor av sammanslagningar och ombaseringar, eller om du underhåller en långlivad funktionsgren, har Git en funktion som heter “rerere” som kan vara användbar.

+
+
+

Rerere står för “reuse recorded resolution” — det är ett sätt att förkorta manuell konflikthantering. +När rerere är aktiverat kommer Git att behålla en uppsättning före- och efterbilder från lyckade sammanslagningar, och om det märker att det finns en konflikt som ser precis ut som en du redan har löst, kommer Git bara att använda lösningen från förra gången, utan att störa dig med den. +Rerere stands for “reuse recorded resolution” — it’s a way of shortcutting manual conflict resolution. +When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there’s a conflict that looks exactly like one you’ve already fixed, it’ll just use the fix from last time, without bothering you with it.

+
+
+

Funktionen har två delar: en konfigurationsinställning och ett kommando. +Konfigurationsinställningen är rerere.enabled, och det är tillräckligt användbart för att lägga i din globala konfiguration:

+
+
+
+
$ git config --global rerere.enabled true
+
+
+
+

När du än gör en sammanslagning som löser konflikter, kommer lösningen nu att sparas i cachen om den skulle behövas i framtiden.

+
+
+

Om du behöver kan du interagera med rerere-cachen med hjälp av kommandot git rerere. +När det används ensamt, kollar Git sin databas med lösningar och försöker hitta en matchning med eventuella aktuella konflikter och lösa dem (även om det görs automatiskt om rerere.enabled är inställt på true). +Det finns också underkommandon för att se vad som kommer att sparas, för att radera specifika lösningar från cachen och för att rensa hela cachen. +Vi kommer att gå in på rerere mer i detalj i }}">Rerere.

+
+
+
+
+

Versionsmarkeringar

+
+

+När du har bestämt dig för att släppa en ny version av ditt projekt, vill du förmodligen tilldela en tagg så att du kan återskapa den versionen när som helst framöver. +Du kan skapa en ny tagg som diskuterats i }}">Grunder i Git. +Om du bestämmer dig för att signera taggen som underhållare ser taggningen ut så här:

+
+
+
+
$ git tag -s v1.5 -m 'my signed 1.5 tag'
+You need a passphrase to unlock the secret key for
+user: "Scott Chacon <schacon@gmail.com>"
+1024-bit DSA key, ID F721C45A, created 2009-02-09
+
+
+
+

Om du signerar dina taggar kan du få problem med att distribuera den offentliga PGP-nyckeln som används för att signera dina taggar. +Förvaltaren för Git-projektet har löst detta problem genom att inkludera sin offentliga nyckel som en blob i arkivet och sedan lägga till en tagg som pekar direkt på det 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:

+
+
+
+
$ gpg --list-keys
+/Users/schacon/.gnupg/pubring.gpg
+---------------------------------
+pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
+uid                  Scott Chacon <schacon@gmail.com>
+sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
+
+
+
+

Du kan då importera nyckeln direkt i Git-databasen genom att exportera den och skicka den genom git hash-object, som skriver en ny blob med de innehållen i Git och ger dig tillbaka SHA-1 för blobben:

+
+
+
+
$ gpg -a --export F721C45A | git hash-object -w --stdin
+659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+
+
+

Nu när du har innehållet i din nyckel i Git kan du skapa en tagg som pekar direkt på den genom att ange det nya SHA-1-värdet från hash-object:

+
+
+
+
$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+
+
+

Med kommandot git push --tags kan du nu dela taggen maintainer-pgp-pub med alla. +Om någon vill verifiera en tagg kan de direkt importera din PGP-nyckel genom att dra ut blobben direkt ur databasen och importera den i GPG:

+
+
+
+
$ git show maintainer-pgp-pub | gpg --import
+
+
+
+

De kan också använda den nyckeln för att verifiera alla dina signerade taggar. +Om du dessutom inkluderar instruktioner i taggmeddelandet kan körning av git show <tagg> låta dig ge slutanvändaren mer specifika instruktioner om taggverifiering.

+
+
+
+

Generera versionsnummer

+
+

+I Git finns det inget inbyggt sätt att generera löpande versionsnummer som v123 eller liknande för varje incheckning. +Om du vill ha ett versionnummber som är logiskt för människor för varje incheckning, kan du köra git describe på incheckningen. +Till svar genererar Git en sträng som består av namnet på den senaste taggen tidigare än den incheckningen, följt av antalet incheckningar sedan den taggen, följt av en del av SHA-1-värdet för den incheckningen (föregånget av bokstaven g som betyder Git):

+
+
+
+
$ git describe master
+v1.6.2-rc1-20-g8c5b85c
+
+
+
+

På det här sättet kan du få en sträng som är meningsfull för människor att använda som versionsnummer. +Om du bygger Git från källkoden som är klonad från Git-arkivet ger git --version dig något som ser ut så här. +Om du beskriver en incheckning som du direkt har taggat ger den dig helt enkelt taggnamnet.

+
+
+

git describe-kommandot kräver annoterade taggar som standard (taggar som skapats med flaggorna -a eller -s); om du vill dra nytta av lättviktiga (icke-annoterade) taggar också, lägg till --tags-flaggan till kommandot. +Du kan också använda den här strängen som mål för ett git checkout- eller git show-kommando, även om det förlitar sig på det förkortade SHA-1-värdet i slutet, så det kanske inte är giltigt för evigt. +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 namn ogiltigförklarades.

+
+
+
+

Förbereda ett släpp

+
+

+Nu vill du släppa en ny version. +En av de saker du vill göra är att skapa ett arkiv av den senaste ögonblicksbilden av din kod för de arma själar som inte använder Git. +Kommandot för att göra detta är git archive:

+
+
+
+
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
+$ ls *.tar.gz
+v1.6.2-rc1-20-g8c5b85c.tar.gz
+
+
+
+

Om någon öppnar det arkivet får de den senaste ögonblicksbilden av ditt projekt i en projektkatalog. +Du kan också skapa ett zip-arkiv ungefär på samma sätt men genom att ange --format=zip-flaggan till git archive:

+
+
+
+
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
+
+
+
+

Nu har du en snyggt arkiv och en zipkatalog av ditt projekts släpp som du kan ladda upp till din webbplats eller mejla till folk.

+
+
+
+

Shortlog

+
+

+Det är dags att mejla till din mejllista med personer som vill veta vad som händer i ditt projekt. +Ett trevligt sätt att snabbt få en slags ändringslogg över vad som har lagts till i ditt projekt sedan ditt senaste släpp eller mejl är att använda kommandot git shortlog. +Det sammanfattar alla incheckningar i det intervall du ger det; till exempel ger följande en sammanfattning av alla incheckningar sedan ditt senaste släpp, om ditt senaste släpp hette v1.0.1:

+
+
+
+
$ git shortlog --no-merges master --not v1.0.1
+Chris Wanstrath (6):
+      Add support for annotated tags to Grit::Tag
+      Add packed-refs annotated tag support.
+      Add Grit::Commit#to_patch
+      Update version and History.txt
+      Remove stray `puts`
+      Make ls_tree ignore nils
+
+Tom Preston-Werner (4):
+      fix dates in history
+      dynamic version method
+      Version bump to 1.0.2
+      Regenerated gemspec for version 1.0.2
+
+
+
+

Du får en enhetlig sammanfattning av samtliga incheckningar sedan v1.0.1, grupperade efter författare, som du kan skicka till din mejllista.

+
+
+ \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Distributed-Git-Contributing-to-a-Project.html b/external/book/content/book/sv/v2/Distributed-Git-Contributing-to-a-Project.html deleted file mode 100644 index 820108efed..0000000000 --- a/external/book/content/book/sv/v2/Distributed-Git-Contributing-to-a-Project.html +++ /dev/null @@ -1,965 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -category: book -section: documentation -subsection: book -sidebar: book -book: - language_code: sv - chapter: - title: Distributed Git - number: 5 - section: - title: Contributing to a Project - number: 2 - cs_number: '5.2' - previous: book/sv/v2/Distributed-Git-Distributed-Workflows - next: book/sv/v2/Distributed-Git-Maintaining-a-Project -title: Git - Contributing to a Project ---- -

Contributing to a Project

-
-

-The main difficulty with describing how to contribute to a project are the numerous variations on how to do that. -Because Git is very flexible, people can and do work together in many ways, and it’s problematic to describe how you should contribute — every project is a bit different. -Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method.

-
-
-

The first variable is active contributor count — how many users are actively contributing code to this project, and how often? -In many instances, you’ll have two or three developers with a few commits a day, or possibly less for somewhat dormant projects. -For larger companies or projects, the number of developers could be in the thousands, with hundreds or thousands of commits coming in each day. -This is important because with more and more developers, you run into more issues with making sure your code applies cleanly or can be easily merged. -Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied. -How can you keep your code consistently up to date and your commits valid?

-
-
-

The next variable is the workflow in use for the project. -Is it centralized, with each developer having equal write access to the main codeline? -Does the project have a maintainer or integration manager who checks all the patches? -Are all the patches peer-reviewed and approved? -Are you involved in that process? -Is a lieutenant system in place, and do you have to submit your work to them first?

-
-
-

The next variable is your commit access. -The workflow required in order to contribute to a project is much different if you have write access to the project than if you don’t. -If you don’t have write access, how does the project prefer to accept contributed work? -Does it even have a policy? -How much work are you contributing at a time? -How often do you contribute?

-
-
-

All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. -We’ll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples.

-
-
-

Commit Guidelines

-
-

Before we start looking at the specific use cases, here’s a quick note about commit messages. -Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. -The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches — you can read it in the Git source code in the Documentation/SubmittingPatches file.

-
-
-

-First, your submissions should not contain any whitespace errors. -Git provides an easy way to check for this — before you commit, run git diff --check, which identifies possible whitespace errors and lists them for you.

-
-
-
-}}" alt="Output of `git diff --check`."> -
-
Figur 57. Output of git diff --check.
-
-
-

If you run that command before committing, you can tell if you’re about to commit whitespace issues that may annoy other developers.

-
-
-

Next, try to make each commit a logically separate changeset. -If you can, try to make your changes digestible — don’t code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. -Even if you don’t commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. -If some of the changes modify the same file, try to use git add --patch to partially stage files (covered in detail in }}">Interactive Staging). -The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes.

-
-
-

This approach also makes it easier to pull out or revert one of the changesets if you need to later. -}}">Rewriting History describes a number of useful Git tricks for rewriting history and interactively staging files — use these tools to help craft a clean and understandable history before sending the work to someone else.

-
-
-

The last thing to keep in mind is the commit message. -Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. -As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. -The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. -It’s also a good idea to use the imperative present tense in these messages. -In other words, use commands. -Instead of “I added tests for” or “Adding tests for,” use “Add tests for.” -Here is a template originally written by Tim Pope:

-
-
-
-
Short (50 chars or less) summary of changes
-
-More detailed explanatory text, if necessary.  Wrap it to
-about 72 characters or so.  In some contexts, the first
-line is treated as the subject of an email and the rest of
-the text as the body.  The blank line separating the
-summary from the body is critical (unless you omit the body
-entirely); tools like rebase can get confused if you run
-the two together.
-
-Further paragraphs come after blank lines.
-
-  - Bullet points are okay, too
-
-  - Typically a hyphen or asterisk is used for the bullet,
-    preceded by a single space, with blank lines in
-    between, but conventions vary here
-
-
-
-

If all your commit messages follow this model, things will be much easier for you and the developers with whom you collaborate. -The Git project has well-formatted commit messages — try running git log --no-merges there to see what a nicely-formatted project-commit history looks like.

-
-
- - - - - -
-
Notera
-		 -
Do as we say, not as we do.
-
-

For the sake of brevity, many of the examples in this book don’t have nicely-formatted commit messages like this; instead, we simply use the -m option to git commit.

-
-
-

In short, do as we say, not as we do.

-
-
-
-
-
-

Private Small Team

-
-

-The simplest setup you’re likely to encounter is a private project with one or two other developers. -“Private,” in this context, means closed-source — not accessible to the outside world. -You and the other developers all have push access to the repository.

-
-
-

In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. -You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time. -Let’s see what it might look like when two developers start to work together with a shared repository. -The first developer, John, clones the repository, makes a change, and commits locally. -(The protocol messages have been replaced with ... in these examples to shorten them somewhat.)

-
-
-
-
# John's Machine
-$ git clone john@githost:simplegit.git
-Cloning into 'simplegit'...
-...
-$ cd simplegit/
-$ vim lib/simplegit.rb
-$ git commit -am 'remove invalid default value'
-[master 738ee87] remove invalid default value
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-
-
-

The second developer, Jessica, does the same thing — clones the repository and commits a change:

-
-
-
-
# Jessica's Machine
-$ git clone jessica@githost:simplegit.git
-Cloning into 'simplegit'...
-...
-$ cd simplegit/
-$ vim TODO
-$ git commit -am 'add reset task'
-[master fbff5bc] add reset task
- 1 files changed, 1 insertions(+), 0 deletions(-)
-
-
-
-

Now, Jessica pushes her work to the server, which works just fine:

-
-
-
-
# Jessica's Machine
-$ git push origin master
-...
-To jessica@githost:simplegit.git
-   1edee6b..fbff5bc  master -> master
-
-
-
-

The last line of the output above shows a useful return message from the push operation. -The basic format is <oldref>..<newref> fromref -> toref, where oldref means the old reference, newref means the new reference, fromref is the name of the local reference being pushed, and toref is the name of the remote reference being updated. -You’ll see similar output like this below in the discussions, so having a basic idea of the meaning will help in understanding the various states of the repositories. -More details are available in the documentation for git-push.

-
-
-

Continuing with this example, shortly afterwards, John makes some changes, commits them to his local repository, and tries to push them to the same server:

-
-
-
-
# John's Machine
-$ git push origin master
-To john@githost:simplegit.git
- ! [rejected]        master -> master (non-fast forward)
-error: failed to push some refs to 'john@githost:simplegit.git'
-
-
-
-

In this case, John’s push fails because of Jessica’s earlier push of her changes. -This is especially important to understand if you’re used to Subversion, because you’ll notice that the two developers didn’t edit the same file. -Although Subversion automatically does such a merge on the server if different files are edited, with Git, you must first merge the commits locally. -In other words, John must first fetch Jessica’s upstream changes and merge them into his local repository before he will be allowed to push.

-
-
-

As a first step, John fetches Jessica’s work (this only fetches Jessica’s upstream work, it does not yet merge it into John’s work):

-
-
-
-
$ git fetch origin
-...
-From john@githost:simplegit
- + 049d078...fbff5bc master     -> origin/master
-
-
-
-

At this point, John’s local repository looks something like this:

-
-
-
-}}" alt="John’s divergent history."> -
-
Figur 58. John’s divergent history.
-
-
-

Now John can merge Jessica’s work that he fetched into his own local work:

-
-
-
-
$ git merge origin/master
-Merge made by the 'recursive' strategy.
- TODO |    1 +
- 1 files changed, 1 insertions(+), 0 deletions(-)
-
-
-
-

As long as that local merge goes smoothly, John’s updated history will now look like this:

-
-
-
-}}" alt="John’s repository after merging `origin/master`."> -
-
Figur 59. John’s repository after merging origin/master.
-
-
-

At this point, John might want to test this new code to make sure none of Jessica’s work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server:

-
-
-
-
$ git push origin master
-...
-To john@githost:simplegit.git
-   fbff5bc..72bbc59  master -> master
-
-
-
-

In the end, John’s commit history will look like this:

-
-
-
-}}" alt="John’s history after pushing to the `origin` server."> -
-
Figur 60. John’s history after pushing to the origin server.
-
-
-

In the meantime, Jessica has created a new topic branch called issue54, and made three commits to that branch. -She hasn’t fetched John’s changes yet, so her commit history looks like this:

-
-
-
-}}" alt="Jessica’s topic branch."> -
-
Figur 61. Jessica’s topic branch.
-
-
-

Suddenly, Jessica learns that John has pushed some new work to the server and she wants to take a look at it, so she can fetch all new content from the server that she does not yet have with:

-
-
-
-
# Jessica's Machine
-$ git fetch origin
-...
-From jessica@githost:simplegit
-   fbff5bc..72bbc59  master     -> origin/master
-
-
-
-

That pulls down the work John has pushed up in the meantime. -Jessica’s history now looks like this:

-
-
-
-}}" alt="Jessica’s history after fetching John’s changes."> -
-
Figur 62. Jessica’s history after fetching John’s changes.
-
-
-

Jessica thinks her topic branch is ready, but she wants to know what part of John’s fetched work she has to merge into her work so that she can push. -She runs git log to find out:

-
-
-
-
$ git log --no-merges issue54..origin/master
-commit 738ee872852dfaa9d6634e0dea7a324040193016
-Author: John Smith <jsmith@example.com>
-Date:   Fri May 29 16:01:27 2009 -0700
-
-   remove invalid default value
-
-
-
-

The issue54..origin/master syntax is a log filter that asks Git to display only those commits that are on the latter branch (in this case origin/master) that are not on the first branch (in this case issue54). -We’ll go over this syntax in detail in }}">Commit Ranges.

-
-
-

From the above output, we can see that there is a single commit that John has made that Jessica has not merged into her local work. -If she merges origin/master, that is the single commit that will modify her local work.

-
-
-

Now, Jessica can merge her topic work into her master branch, merge John’s work (origin/master) into her master branch, and then push back to the server again.

-
-
-

First (having committed all of the work on her issue54 topic branch), Jessica switches back to her master branch in preparation for integrating all this work:

-
-
-
-
$ git checkout master
-Switched to branch 'master'
-Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
-
-
-
-

Jessica can merge either origin/master or issue54 first — they’re both upstream, so the order doesn’t matter. -The end snapshot should be identical no matter which order she chooses; only the history will be different. -She chooses to merge the issue54 branch first:

-
-
-
-
$ git merge issue54
-Updating fbff5bc..4af4298
-Fast forward
- README           |    1 +
- lib/simplegit.rb |    6 +++++-
- 2 files changed, 6 insertions(+), 1 deletions(-)
-
-
-
-

No problems occur; as you can see it was a simple fast-forward merge. -Jessica now completes the local merging process by merging John’s earlier fetched work that is sitting in the origin/master branch:

-
-
-
-
$ git merge origin/master
-Auto-merging lib/simplegit.rb
-Merge made by the 'recursive' strategy.
- lib/simplegit.rb |    2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-
-
-

Everything merges cleanly, and Jessica’s history now looks like this:

-
-
-
-}}" alt="Jessica’s history after merging John’s changes."> -
-
Figur 63. Jessica’s history after merging John’s changes.
-
-
-

Now origin/master is reachable from Jessica’s master branch, so she should be able to successfully push (assuming John hasn’t pushed even more changes in the meantime):

-
-
-
-
$ git push origin master
-...
-To jessica@githost:simplegit.git
-   72bbc59..8059c15  master -> master
-
-
-
-

Each developer has committed a few times and merged each other’s work successfully.

-
-
-
-}}" alt="Jessica’s history after pushing all changes back to the server."> -
-
Figur 64. Jessica’s history after pushing all changes back to the server.
-
-
-

That is one of the simplest workflows. -You work for a while (generally in a topic branch), and merge that work into your master branch when it’s ready to be integrated. -When you want to share that work, you fetch and merge your master from origin/master if it has changed, and finally push to the master branch on the server. -The general sequence is something like this:

-
-
-
-}}" alt="General sequence of events for a simple multiple-developer Git workflow."> -
-
Figur 65. General sequence of events for a simple multiple-developer Git workflow.
-
-
-
-

Private Managed Team

-
-

-In this next scenario, you’ll look at contributor roles in a larger private group. -You’ll learn how to work in an environment where small groups collaborate on features, after which those team-based contributions are integrated by another party.

-
-
-

Let’s say that John and Jessica are working together on one feature (call this “featureA”), while Jessica and a third developer, Josie, are working on a second (say, “featureB”). -In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the master branch of the main repo can be updated only by those engineers. -In this scenario, all work is done in team-based branches and pulled together by the integrators later.

-
-
-

Let’s follow Jessica’s workflow as she works on her two features, collaborating in parallel with two different developers in this environment. -Assuming she already has her repository cloned, she decides to work on featureA first. -She creates a new branch for the feature and does some work on it there:

-
-
-
-
# Jessica's Machine
-$ git checkout -b featureA
-Switched to a new branch 'featureA'
-$ vim lib/simplegit.rb
-$ git commit -am 'add limit to log function'
-[featureA 3300904] add limit to log function
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-
-
-

At this point, she needs to share her work with John, so she pushes her featureA branch commits up to the server. -Jessica doesn’t have push access to the master branch — only the integrators do — so she has to push to another branch in order to collaborate with John:

-
-
-
-
$ git push -u origin featureA
-...
-To jessica@githost:simplegit.git
- * [new branch]      featureA -> featureA
-
-
-
-

Jessica emails John to tell him that she’s pushed some work into a branch named featureA and he can look at it now. -While she waits for feedback from John, Jessica decides to start working on featureB with Josie. -To begin, she starts a new feature branch, basing it off the server’s master branch:

-
-
-
-
# Jessica's Machine
-$ git fetch origin
-$ git checkout -b featureB origin/master
-Switched to a new branch 'featureB'
-
-
-
-

Now, Jessica makes a couple of commits on the featureB branch:

-
-
-
-
$ vim lib/simplegit.rb
-$ git commit -am 'made the ls-tree function recursive'
-[featureB e5b0fdc] made the ls-tree function recursive
- 1 files changed, 1 insertions(+), 1 deletions(-)
-$ vim lib/simplegit.rb
-$ git commit -am 'add ls-files'
-[featureB 8512791] add ls-files
- 1 files changed, 5 insertions(+), 0 deletions(-)
-
-
-
-

Jessica’s repository now looks like this:

-
-
-
-}}" alt="Jessica’s initial commit history."> -
-
Figur 66. Jessica’s initial commit history.
-
-
-

She’s ready to push her work, but gets an email from Josie that a branch with some initial “featureB” work on it was already pushed to the server as the featureBee branch. -Jessica needs to merge those changes with her own before she can push her work to the server. -Jessica first fetches Josie’s changes with git fetch:

-
-
-
-
$ git fetch origin
-...
-From jessica@githost:simplegit
- * [new branch]      featureBee -> origin/featureBee
-
-
-
-

Assuming Jessica is still on her checked-out featureB branch, she can now merge Josie’s work into that branch with git merge:

-
-
-
-
$ git merge origin/featureBee
-Auto-merging lib/simplegit.rb
-Merge made by the 'recursive' strategy.
- lib/simplegit.rb |    4 ++++
- 1 files changed, 4 insertions(+), 0 deletions(-)
-
-
-
-

At this point, Jessica wants to push all of this merged “featureB” work back to the server, but she doesn’t want to simply push her own featureB branch. -Rather, since Josie has already started an upstream featureBee branch, Jessica wants to push to that branch, which she does with:

-
-
-
-
$ git push -u origin featureB:featureBee
-...
-To jessica@githost:simplegit.git
-   fba9af8..cd685d1  featureB -> featureBee
-
-
-
-

This is called a refspec. -See }}">The Refspec for a more detailed discussion of Git refspecs and different things you can do with them. -Also notice the -u flag; this is short for --set-upstream, which configures the branches for easier pushing and pulling later.

-
-
-

Suddenly, Jessica gets email from John, who tells her he’s pushed some changes to the featureA branch on which they are collaborating, and he asks Jessica to take a look at them. -Again, Jessica runs a simple git fetch to fetch all new content from the server, including (of course) John’s latest work:

-
-
-
-
$ git fetch origin
-...
-From jessica@githost:simplegit
-   3300904..aad881d  featureA   -> origin/featureA
-
-
-
-

Jessica can display the log of John’s new work by comparing the content of the newly-fetched featureA branch with her local copy of the same branch:

-
-
-
-
$ git log featureA..origin/featureA
-commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
-Author: John Smith <jsmith@example.com>
-Date:   Fri May 29 19:57:33 2009 -0700
-
-    changed log output to 30 from 25
-
-
-
-

If Jessica likes what she sees, she can merge John’s new work into her local featureA branch with:

-
-
-
-
$ git checkout featureA
-Switched to branch 'featureA'
-$ git merge origin/featureA
-Updating 3300904..aad881d
-Fast forward
- lib/simplegit.rb |   10 +++++++++-
-1 files changed, 9 insertions(+), 1 deletions(-)
-
-
-
-

Finally, Jessica might want to make a couple minor changes to all that merged content, so she is free to make those changes, commit them to her local featureA branch, and push the end result back to the server.

-
-
-
-
$ git commit -am 'small tweak'
-[featureA 774b3ed] small tweak
- 1 files changed, 1 insertions(+), 1 deletions(-)
-$ git push
-...
-To jessica@githost:simplegit.git
-   3300904..774b3ed  featureA -> featureA
-
-
-
-

Jessica’s commit history now looks something like this:

-
-
-
-}}" alt="Jessica’s history after committing on a feature branch."> -
-
Figur 67. Jessica’s history after committing on a feature branch.
-
-
-

At some point, Jessica, Josie, and John inform the integrators that the featureA and featureBee branches on the server are ready for integration into the mainline. -After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this:

-
-
-
-}}" alt="Jessica’s history after merging both her topic branches."> -
-
Figur 68. Jessica’s history after merging both her topic branches.
-
-
-

Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. -The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. -The sequence for the workflow you saw here is something like this:

-
-
-
-}}" alt="Basic sequence of this managed-team workflow."> -
-
Figur 69. Basic sequence of this managed-team workflow.
-
-
-
-

Forked Public Project

-
-

-Contributing to public projects is a bit different. -Because you don’t have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. -This first example describes contributing via forking on Git hosts that support easy forking. -Many hosting sites support this (including GitHub, BitBucket, repo.or.cz, and others), and many project maintainers expect this style of contribution. -The next section deals with projects that prefer to accept contributed patches via email.

-
-
-

First, you’ll probably want to clone the main repository, create a topic branch for the patch or patch series you’re planning to contribute, and do your work there. -The sequence looks basically like this:

-
-
-
-
$ git clone <url>
-$ cd project
-$ git checkout -b featureA
-  ... work ...
-$ git commit
-  ... work ...
-$ git commit
-
-
-
- - - - - -
-
Notera
-		 -
-

You may want to use rebase -i to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review — see }}">Rewriting History for more information about interactive rebasing.

-
-
-
-
-

When your branch work is finished and you’re ready to contribute it back to the maintainers, go to the original project page and click the “Fork” button, creating your own writable fork of the project. -You then need to add this repository URL as a new remote of your local repository; in this example, let’s call it myfork:

-
-
-
-
$ git remote add myfork <url>
-
-
-
-

You then need to push your new work to this repository. -It’s easiest to push the topic branch you’re working on to your forked repository, rather than merging that work into your master branch and pushing that. -The reason is that if your work isn’t accepted or is cherry-picked, you don’t have to rewind your master branch (the Git cherry-pick operation is covered in more detail in }}">Rebasing and Cherry-Picking Workflows). -If the maintainers merge, rebase, or cherry-pick your work, you’ll eventually get it back via pulling from their repository anyhow.

-
-
-

In any event, you can push your work with:

-
-
-
-
$ git push -u myfork featureA
-
-
-
-

-Once your work has been pushed to your fork of the repository, you need to notify the maintainers of the original project that you have work you’d like them to merge. -This is often called a pull request, and you typically generate such a request either via the website — GitHub has its own “Pull Request” mechanism that we’ll go over in }}">GitHub — or you can run the git request-pull command and email the subsequent output to the project maintainer manually.

-
-
-

The git request-pull command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and produces a summary of all the changes you’re asking to be pulled. -For instance, if Jessica wants to send John a pull request, and she’s done two commits on the topic branch she just pushed, she can run this:

-
-
-
-
$ git request-pull origin/master myfork
-The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
-Jessica Smith (1):
-        added a new function
-
-are available in the git repository at:
-
-  git://githost/simplegit.git featureA
-
-Jessica Smith (2):
-      add limit to log function
-      change log output to 30 from 25
-
- lib/simplegit.rb |   10 +++++++++-
- 1 files changed, 9 insertions(+), 1 deletions(-)
-
-
-
-

This output can be sent to the maintainer — it tells them where the work was branched from, summarizes the commits, and identifies from where the new work is to be pulled.

-
-
-

On a project for which you’re not the maintainer, it’s generally easier to have a branch like master always track origin/master and to do your work in topic branches that you can easily discard if they’re rejected. -Having work themes isolated into topic branches also makes it easier for you to rebase your work if the tip of the main repository has moved in the meantime and your commits no longer apply cleanly. -For example, if you want to submit a second topic of work to the project, don’t continue working on the topic branch you just pushed up — start over from the main repository’s master branch:

-
-
-
-
$ git checkout -b featureB origin/master
-  ... work ...
-$ git commit
-$ git push myfork featureB
-$ git request-pull origin/master myfork
-  ... email generated request pull to maintainer ...
-$ git fetch origin
-
-
-
-

Now, each of your topics is contained within a silo — similar to a patch queue — that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so:

-
-
-
-}}" alt="Initial commit history with `featureB` work."> -
-
Figur 70. Initial commit history with featureB work.
-
-
-

Let’s say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. -In this case, you can try to rebase that branch on top of origin/master, resolve the conflicts for the maintainer, and then resubmit your changes:

-
-
-
-
$ git checkout featureA
-$ git rebase origin/master
-$ git push -f myfork featureA
-
-
-
-

This rewrites your history to now look like }}">Commit history after featureA work..

-
-
-
-}}" alt="Commit history after `featureA` work."> -
-
Figur 71. Commit history after featureA work.
-
-
-

Because you rebased the branch, you have to specify the -f to your push command in order to be able to replace the featureA branch on the server with a commit that isn’t a descendant of it. -An alternative would be to push this new work to a different branch on the server (perhaps called featureAv2).

-
-
-

Let’s look at one more possible scenario: the maintainer has looked at work in your second branch and likes the concept but would like you to change an implementation detail. -You’ll also take this opportunity to move the work to be based off the project’s current master branch. -You start a new branch based off the current origin/master branch, squash the featureB changes there, resolve any conflicts, make the implementation change, and then push that as a new branch:

-
-
-

-
-
-
-
$ git checkout -b featureBv2 origin/master
-$ git merge --squash featureB
-  ... change implementation ...
-$ git commit
-$ git push myfork featureBv2
-
-
-
-

The --squash option takes all the work on the merged branch and squashes it into one changeset producing the repository state as if a real merge happened, without actually making a merge commit. -This means your future commit will have one parent only and allows you to introduce all the changes from another branch and then make more changes before recording the new commit. -Also the --no-commit option can be useful to delay the merge commit in case of the default merge process.

-
-
-

At this point, you can notify the maintainer that you’ve made the requested changes, and that they can find those changes in your featureBv2 branch.

-
-
-
-}}" alt="Commit history after `featureBv2` work."> -
-
Figur 72. Commit history after featureBv2 work.
-
-
-
-

Public Project over Email

-
-

-Many projects have established procedures for accepting patches — you’ll need to check the specific rules for each project, because they will differ. -Since there are several older, larger projects which accept patches via a developer mailing list, we’ll go over an example of that now.

-
-
-

The workflow is similar to the previous use case — you create topic branches for each patch series you work on. -The difference is how you submit them to the project. -Instead of forking the project and pushing to your own writable version, you generate email versions of each commit series and email them to the developer mailing list:

-
-
-
-
$ git checkout -b topicA
-  ... work ...
-$ git commit
-  ... work ...
-$ git commit
-
-
-
-

-Now you have two commits that you want to send to the mailing list. -You use git format-patch to generate the mbox-formatted files that you can email to the list — it turns each commit into an email message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. -The nice thing about this is that applying a patch from an email generated with format-patch preserves all the commit information properly.

-
-
-
-
$ git format-patch -M origin/master
-0001-add-limit-to-log-function.patch
-0002-changed-log-output-to-30-from-25.patch
-
-
-
-

The format-patch command prints out the names of the patch files it creates. -The -M switch tells Git to look for renames. -The files end up looking like this:

-
-
-
-
$ cat 0001-add-limit-to-log-function.patch
-From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
-From: Jessica Smith <jessica@example.com>
-Date: Sun, 6 Apr 2008 10:17:23 -0700
-Subject: [PATCH 1/2] add limit to log function
-
-Limit log functionality to the first 20
-
----
- lib/simplegit.rb |    2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-diff --git a/lib/simplegit.rb b/lib/simplegit.rb
-index 76f47bc..f9815f1 100644
---- a/lib/simplegit.rb
-+++ b/lib/simplegit.rb
-@@ -14,7 +14,7 @@ class SimpleGit
-   end
-
-   def log(treeish = 'master')
--    command("git log #{treeish}")
-+    command("git log -n 20 #{treeish}")
-   end
-
-   def ls_tree(treeish = 'master')
---
-2.1.0
-
-
-
-

You can also edit these patch files to add more information for the email list that you don’t want to show up in the commit message. -If you add text between the --- line and the beginning of the patch (the diff --git line), the developers can read it, but that content is ignored by the patching process.

-
-
-

To email this to a mailing list, you can either paste the file into your email program or send it via a command-line program. -Pasting the text often causes formatting issues, especially with “smarter” clients that don’t preserve newlines and other whitespace appropriately. -Luckily, Git provides a tool to help you send properly formatted patches via IMAP, which may be easier for you. -We’ll demonstrate how to send a patch via Gmail, which happens to be the email agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned Documentation/SubmittingPatches file in the Git source code.

-
-
-

-First, you need to set up the imap section in your ~/.gitconfig file. -You can set each value separately with a series of git config commands, or you can add them manually, but in the end your config file should look something like this:

-
-
-
-
[imap]
-  folder = "[Gmail]/Drafts"
-  host = imaps://imap.gmail.com
-  user = user@gmail.com
-  pass = YX]8g76G_2^sFbd
-  port = 993
-  sslverify = false
-
-
-
-

If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be imap:// instead of imaps://. -When that is set up, you can use git imap-send to place the patch series in the Drafts folder of the specified IMAP server:

-
-
-
-
$ cat *.patch |git imap-send
-Resolving imap.gmail.com... ok
-Connecting to [74.125.142.109]:993... ok
-Logging in...
-sending 2 messages
-100% (2/2) done
-
-
-
-

At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.

-
-
-

You can also send the patches through an SMTP server. -As before, you can set each value separately with a series of git config commands, or you can add them manually in the sendemail section in your ~/.gitconfig file:

-
-
-
-
[sendemail]
-  smtpencryption = tls
-  smtpserver = smtp.gmail.com
-  smtpuser = user@gmail.com
-  smtpserverport = 587
-
-
-
-

After this is done, you can use git send-email to send your patches:

-
-
-
-
$ git send-email *.patch
-0001-added-limit-to-log-function.patch
-0002-changed-log-output-to-30-from-25.patch
-Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
-Emails will be sent from: Jessica Smith <jessica@example.com>
-Who should the emails be sent to? jessica@example.com
-Message-ID to be used as In-Reply-To for the first email? y
-
-
-
-

Then, Git spits out a bunch of log information looking something like this for each patch you’re sending:

-
-
-
-
(mbox) Adding cc: Jessica Smith <jessica@example.com> from
-  \line 'From: Jessica Smith <jessica@example.com>'
-OK. Log says:
-Sendmail: /usr/sbin/sendmail -i jessica@example.com
-From: Jessica Smith <jessica@example.com>
-To: jessica@example.com
-Subject: [PATCH 1/2] added limit to log function
-Date: Sat, 30 May 2009 13:29:15 -0700
-Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
-X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
-In-Reply-To: <y>
-References: <y>
-
-Result: OK
-
-
-
-
-

Summary

-
-

This section has covered a number of common workflows for dealing with several very different types of Git projects you’re likely to encounter, and introduced a couple of new tools to help you manage this process. -Next, you’ll see how to work the other side of the coin: maintaining a Git project. -You’ll learn how to be a benevolent dictator or integration manager.

-
-
- \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Distributed-Git-Distributed-Workflows.html b/external/book/content/book/sv/v2/Distributed-Git-Distributed-Workflows.html deleted file mode 100644 index 813a74c63e..0000000000 --- a/external/book/content/book/sv/v2/Distributed-Git-Distributed-Workflows.html +++ /dev/null @@ -1,160 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -category: book -section: documentation -subsection: book -sidebar: book -book: - language_code: sv - chapter: - title: Distributed Git - number: 5 - section: - title: Distributed Workflows - number: 1 - cs_number: '5.1' - previous: book/sv/v2/Git-på-servern-Sammanfattning - next: book/sv/v2/Distributed-Git-Contributing-to-a-Project -title: Git - Distributed Workflows ---- -

-Now that you have a remote Git repository set up as a focal point for all the developers to share their code, and you’re familiar with basic Git commands in a local workflow, you’ll look at how to utilize some of the distributed workflows that Git affords you.

In this chapter, you’ll see how to work with Git in a distributed environment as a contributor and an integrator. -That is, you’ll learn how to contribute code successfully to a project and make it as easy on you and the project maintainer as possible, and also how to maintain a project successfully with a number of developers contributing.

-

Distributed Workflows

-
-

-In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. -In centralized systems, every developer is a node working more or less equally with a central hub. -In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. -This presents a vast range of workflow possibilities for your project and/or your team, so we’ll cover a few common paradigms that take advantage of this flexibility. -We’ll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.

-
-
-

Centralized Workflow

-
-

-In centralized systems, there is generally a single collaboration model — the centralized workflow. -One central hub, or repository, can accept code, and everyone synchronizes their work with it. -A number of developers are nodes — consumers of that hub — and synchronize with that centralized location.

-
-
-
-}}" alt="Centralized workflow."> -
-
Figur 54. Centralized workflow.
-
-
-

This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. -The second developer must merge in the first one’s work before pushing changes up, so as not to overwrite the first developer’s changes. -This concept is as true in Git as it is in Subversion (or any CVCS), and this model works perfectly well in Git.

-
-
-

If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. -Simply set up a single repository, and give everyone on your team push access; Git won’t let users overwrite each other.

-
-
-

Say John and Jessica both start working at the same time. -John finishes his change and pushes it to the server. -Then Jessica tries to push her changes, but the server rejects them. -She is told that she’s trying to push non-fast-forward changes and that she won’t be able to do so until she fetches and merges. -This workflow is attractive to a lot of people because it’s a paradigm that many are familiar and comfortable with.

-
-
-

This is also not limited to small teams. -With Git’s branching model, it’s possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously.

-
-
-
-

Integration-Manager Workflow

-
-

-Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. -This scenario often includes a canonical repository that represents the “official” project. -To contribute to that project, you create your own public clone of the project and push your changes to it. -Then, you can send a request to the maintainer of the main project to pull in your changes. -The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. -The process works as follows (see }}">Integration-manager workflow.):

-
-
-
    -
  1. -

    The project maintainer pushes to their public repository.

    -
    2. -
  2. -

    A contributor clones that repository and makes changes.

    -
    3. -
  3. -

    The contributor pushes to their own public copy.

    -
    4. -
  4. -

    The contributor sends the maintainer an email asking them to pull changes.

    -
    5. -
  5. -

    The maintainer adds the contributor’s repository as a remote and merges locally.

    -
    6. -
  6. -

    The maintainer pushes merged changes to the main repository.

    -
    7. -
-
-
-
-}}" alt="Integration-manager workflow."> -
-
Figur 55. Integration-manager workflow.
-
-
-

-This is a very common workflow with hub-based tools like GitHub or GitLab, where it’s easy to fork a project and push your changes into your fork for everyone to see. -One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time. -Contributors don’t have to wait for the project to incorporate their changes — each party can work at their own pace.

-
-
-
-

Dictator and Lieutenants Workflow

-
-

-This is a variant of a multiple-repository workflow. -It’s generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. -Various integration managers are in charge of certain parts of the repository; they’re called lieutenants. -All the lieutenants have one integration manager known as the benevolent dictator. -The benevolent dictator pushes from his directory to a reference repository from which all the collaborators need to pull. -The process works like this (see }}">Benevolent dictator workflow.):

-
-
-
    -
  1. -

    Regular developers work on their topic branch and rebase their work on top of master. -The master branch is that of the reference repository to which the dictator pushes.

    -
    2. -
  2. -

    Lieutenants merge the developers' topic branches into their master branch.

    -
    3. -
  3. -

    The dictator merges the lieutenants' master branches into the dictator’s master branch.

    -
    4. -
  4. -

    Finally, the dictator pushes that master branch to the reference repository so the other developers can rebase on it.

    -
    5. -
-
-
-
-}}" alt="Benevolent dictator workflow."> -
-
Figur 56. Benevolent dictator workflow.
-
-
-

This kind of workflow isn’t common, but can be useful in very big projects, or in highly hierarchical environments. -It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.

-
-
-
-

Workflows Summary

-
-

These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. -Now that you can (hopefully) determine which workflow combination may work for you, we’ll cover some more specific examples of how to accomplish the main roles that make up the different flows. -In the next section, you’ll learn about a few common patterns for contributing to a project.

-
-
- \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Distributed-Git-Maintaining-a-Project.html b/external/book/content/book/sv/v2/Distributed-Git-Maintaining-a-Project.html deleted file mode 100644 index 25862f0f13..0000000000 --- a/external/book/content/book/sv/v2/Distributed-Git-Maintaining-a-Project.html +++ /dev/null @@ -1,675 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -category: book -section: documentation -subsection: book -sidebar: book -book: - language_code: sv - chapter: - title: Distributed Git - number: 5 - section: - title: Maintaining a Project - number: 3 - cs_number: '5.3' - previous: book/sv/v2/Distributed-Git-Contributing-to-a-Project - next: book/sv/v2/Distributed-Git-Summary -title: Git - Maintaining a Project ---- -

Maintaining a Project

-
-

-In addition to knowing how to contribute effectively to a project, you’ll likely need to know how to maintain one. -This can consist of accepting and applying patches generated via format-patch and emailed to you, or integrating changes in remote branches for repositories you’ve added as remotes to your project. -Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run.

-
-
-

Working in Topic Branches

-
-

-When you’re thinking of integrating new work, it’s generally a good idea to try it out in a topic branch — a temporary branch specifically made to try out that new work. -This way, it’s easy to tweak a patch individually and leave it if it’s not working until you have time to come back to it. -If you create a simple branch name based on the theme of the work you’re going to try, such as ruby_client or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. -The maintainer of the Git project tends to namespace these branches as well — such as sc/ruby_client, where sc is short for the person who contributed the work. -As you’ll remember, you can create the branch based off your master branch like this:

-
-
-
-
$ git branch sc/ruby_client master
-
-
-
-

Or, if you want to also switch to it immediately, you can use the checkout -b option:

-
-
-
-
$ git checkout -b sc/ruby_client master
-
-
-
-

Now you’re ready to add the contributed work that you received into this topic branch and determine if you want to merge it into your longer-term branches.

-
-
-
-

Applying Patches from Email

-
-

-If you receive a patch over email that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. -There are two ways to apply an emailed patch: with git apply or with git am.

-
-
-

Applying a Patch with apply

-
-

-If you received the patch from someone who generated it with git diff or some variation of the Unix diff command (which is not recommended; see the next section), you can apply it with the git apply command. -Assuming you saved the patch at /tmp/patch-ruby-client.patch, you can apply the patch like this:

-
-
-
-
$ git apply /tmp/patch-ruby-client.patch
-
-
-
-

This modifies the files in your working directory. -It’s almost identical to running a patch -p1 command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches than patch. -It also handles file adds, deletes, and renames if they’re described in the git diff format, which patch won’t do. -Finally, git apply is an “apply all or abort all” model where either everything is applied or nothing is, whereas patch can partially apply patchfiles, leaving your working directory in a weird state. -git apply is overall much more conservative than patch. -It won’t create a commit for you — after running it, you must stage and commit the changes introduced manually.

-
-
-

You can also use git apply to see if a patch applies cleanly before you try actually applying it — you can run git apply --check with the patch:

-
-
-
-
$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
-error: patch failed: ticgit.gemspec:1
-error: ticgit.gemspec: patch does not apply
-
-
-
-

If there is no output, then the patch should apply cleanly. -This command also exits with a non-zero status if the check fails, so you can use it in scripts if you want.

-
-
-
-

Applying a Patch with am -

-
-

-If the contributor is a Git user and was good enough to use the format-patch command to generate their patch, then your job is easier because the patch contains author information and a commit message for you. -If you can, encourage your contributors to use format-patch instead of diff to generate patches for you. -You should only have to use git apply for legacy patches and things like that.

-
-
-

To apply a patch generated by format-patch, you use git am (the command is named am as it is used to "apply a series of patches from a mailbox"). -Technically, git am is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file. -It looks something like this:

-
-
-
-
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
-From: Jessica Smith <jessica@example.com>
-Date: Sun, 6 Apr 2008 10:17:23 -0700
-Subject: [PATCH 1/2] add limit to log function
-
-Limit log functionality to the first 20
-
-
-
-

This is the beginning of the output of the git format-patch command that you saw in the previous section; it also represents a valid mbox email format. -If someone has emailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. -If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.

-
-
-

However, if someone uploaded a patch file generated via git format-patch to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to git am to apply it:

-
-
-
-
$ git am 0001-limit-log-function.patch
-Applying: add limit to log function
-
-
-
-

You can see that it applied cleanly and automatically created the new commit for you. -The author information is taken from the email’s From and Date headers, and the message of the commit is taken from the Subject and body (before the patch) of the email. -For example, if this patch was applied from the mbox example above, the commit generated would look something like this:

-
-
-
-
$ git log --pretty=fuller -1
-commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
-Author:     Jessica Smith <jessica@example.com>
-AuthorDate: Sun Apr 6 10:17:23 2008 -0700
-Commit:     Scott Chacon <schacon@gmail.com>
-CommitDate: Thu Apr 9 09:19:06 2009 -0700
-
-   add limit to log function
-
-   Limit log functionality to the first 20
-
-
-
-

The Commit information indicates the person who applied the patch and the time it was applied. -The Author information is the individual who originally created the patch and when it was originally created.

-
-
-

But it’s possible that the patch won’t apply cleanly. -Perhaps your main branch has diverged too far from the branch the patch was built from, or the patch depends on another patch you haven’t applied yet. -In that case, the git am process will fail and ask you what you want to do:

-
-
-
-
$ git am 0001-seeing-if-this-helps-the-gem.patch
-Applying: seeing if this helps the gem
-error: patch failed: ticgit.gemspec:1
-error: ticgit.gemspec: patch does not apply
-Patch failed at 0001.
-When you have resolved this problem run "git am --resolved".
-If you would prefer to skip this patch, instead run "git am --skip".
-To restore the original branch and stop patching run "git am --abort".
-
-
-
-

This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation. -You solve this issue much the same way — edit the file to resolve the conflict, stage the new file, and then run git am --resolved to continue to the next patch:

-
-
-
-
$ (fix the file)
-$ git add ticgit.gemspec
-$ git am --resolved
-Applying: seeing if this helps the gem
-
-
-
-

If you want Git to try a bit more intelligently to resolve the conflict, you can pass a -3 option to it, which makes Git attempt a three-way merge. -This option isn’t on by default because it doesn’t work if the commit the patch says it was based on isn’t in your repository. -If you do have that commit — if the patch was based on a public commit — then the -3 option is generally much smarter about applying a conflicting patch:

-
-
-
-
$ git am -3 0001-seeing-if-this-helps-the-gem.patch
-Applying: seeing if this helps the gem
-error: patch failed: ticgit.gemspec:1
-error: ticgit.gemspec: patch does not apply
-Using index info to reconstruct a base tree...
-Falling back to patching base and 3-way merge...
-No changes -- Patch already applied.
-
-
-
-

In this case, without the -3 option the patch would have been considered as a conflict. -Since the -3 option was used the patch applied cleanly.

-
-
-

If you’re applying a number of patches from an mbox, you can also run the am command in interactive mode, which stops at each patch it finds and asks if you want to apply it:

-
-
-
-
$ git am -3 -i mbox
-Commit Body is:
---------------------------
-seeing if this helps the gem
---------------------------
-Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
-
-
-
-

This is nice if you have a number of patches saved, because you can view the patch first if you don’t remember what it is, or not apply the patch if you’ve already done so.

-
-
-

When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a longer-running branch.

-
-
-
-
-

Checking Out Remote Branches

-
-

-If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally.

-
-
-

For instance, if Jessica sends you an email saying that she has a great new feature in the ruby-client branch of her repository, you can test it by adding the remote and checking out that branch locally:

-
-
-
-
$ git remote add jessica git://github.com/jessica/myproject.git
-$ git fetch jessica
-$ git checkout -b rubyclient jessica/ruby-client
-
-
-
-

If she emails you again later with another branch containing another great feature, you could directly fetch and checkout because you already have the remote setup.

-
-
-

This is most useful if you’re working with a person consistently. -If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches. -You’re also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two. -However, scripts and hosted services may make this easier — it depends largely on how you develop and how your contributors develop.

-
-
-

The other advantage of this approach is that you get the history of the commits as well. -Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a -3 and hope the patch was generated off a public commit to which you have access.

-
-
-

If you aren’t working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the git pull command. -This does a one-time pull and doesn’t save the URL as a remote reference:

-
-
-
-
$ git pull https://github.com/onetimeguy/project
-From https://github.com/onetimeguy/project
- * branch            HEAD       -> FETCH_HEAD
-Merge made by the 'recursive' strategy.
-
-
-
-
-

Determining What Is Introduced

-
-

-Now you have a topic branch that contains contributed work. -At this point, you can determine what you’d like to do with it. -This section revisits a couple of commands so you can see how you can use them to review exactly what you’ll be introducing if you merge this into your main branch.

-
-
-

It’s often helpful to get a review of all the commits that are in this branch but that aren’t in your master branch. -You can exclude commits in the master branch by adding the --not option before the branch name. -This does the same thing as the master..contrib format that we used earlier. -For example, if your contributor sends you two patches and you create a branch called contrib and applied those patches there, you can run this:

-
-
-
-
$ git log contrib --not master
-commit 5b6235bd297351589efc4d73316f0a68d484f118
-Author: Scott Chacon <schacon@gmail.com>
-Date:   Fri Oct 24 09:53:59 2008 -0700
-
-    seeing if this helps the gem
-
-commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
-Author: Scott Chacon <schacon@gmail.com>
-Date:   Mon Oct 22 19:38:36 2008 -0700
-
-    updated the gemspec to hopefully work better
-
-
-
-

To see what changes each commit introduces, remember that you can pass the -p option to git log and it will append the diff introduced to each commit.

-
-
-

To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results. -You may think to run this:

-
-
-
-
$ git diff master
-
-
-
-

This command gives you a diff, but it may be misleading. -If your master branch has moved forward since you created the topic branch from it, then you’ll get seemingly strange results. -This happens because Git directly compares the snapshots of the last commit of the topic branch you’re on and the snapshot of the last commit on the master branch. -For example, if you’ve added a line in a file on the master branch, a direct comparison of the snapshots will look like the topic branch is going to remove that line.

-
-
-

If master is a direct ancestor of your topic branch, this isn’t a problem; but if the two histories have diverged, the diff will look like you’re adding all the new stuff in your topic branch and removing everything unique to the master branch.

-
-
-

What you really want to see are the changes added to the topic branch — the work you’ll introduce if you merge this branch with master. -You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch.

-
-
-

Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it:

-
-
-
-
$ git merge-base contrib master
-36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
-$ git diff 36c7db
-
-
-
-

or, more concisely:

-
-
-
-
$ git diff $(git merge-base contrib master)
-
-
-
-

However, neither of those is particularly convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. -In the context of the git diff command, you can put three periods after another branch to do a diff between the last commit of the branch you’re on and its common ancestor with another branch:

-
-
-
-
$ git diff master...contrib
-
-
-
-

This command shows you only the work your current topic branch has introduced since its common ancestor with master. -That is a very useful syntax to remember.

-
-
-
-

Integrating Contributed Work

-
-

-When all the work in your topic branch is ready to be integrated into a more mainline branch, the question is how to do it. -Furthermore, what overall workflow do you want to use to maintain your project? -You have a number of choices, so we’ll cover a few of them.

-
-
-

Merging Workflows

-
-

-One basic workflow is to simply merge all that work directly into your master branch. -In this scenario, you have a master branch that contains basically stable code. -When you have work in a topic branch that you think you’ve completed, or work that someone else has contributed and you’ve verified, you merge it into your master branch, delete that just-merged topic branch, and repeat.

-
-
-

For instance, if we have a repository with work in two branches named ruby_client and php_client that looks like }}">History with several topic branches., and we merge ruby_client followed by php_client, your history will end up looking like }}">After a topic branch merge..

-
-
-
-}}" alt="History with several topic branches."> -
-
Figur 73. History with several topic branches.
-
-
-
-}}" alt="After a topic branch merge."> -
-
Figur 74. After a topic branch merge.
-
-
-

That is probably the simplest workflow, but it can possibly be problematic if you’re dealing with larger or more stable projects where you want to be really careful about what you introduce.

-
-
-

If you have a more important project, you might want to use a two-phase merge cycle. -In this scenario, you have two long-running branches, master and develop, in which you determine that master is updated only when a very stable release is cut and all new code is integrated into the develop branch. -You regularly push both of these branches to the public repository. -Each time you have a new topic branch to merge in (}}">Before a topic branch merge.), you merge it into develop (}}">After a topic branch merge.); then, when you tag a release, you fast-forward master to wherever the now-stable develop branch is (}}">After a project release.).

-
-
-
-}}" alt="Before a topic branch merge."> -
-
Figur 75. Before a topic branch merge.
-
-
-
-}}" alt="After a topic branch merge."> -
-
Figur 76. After a topic branch merge.
-
-
-
-}}" alt="After a topic branch release."> -
-
Figur 77. After a project release.
-
-
-

This way, when people clone your project’s repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge content. -You can also extend this concept by having an integrate branch where all the work is merged together. -Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch.

-
-
-
-

Large-Merging Workflows

-
-

-The Git project has four long-running branches: master, next, and pu (proposed updates) for new work, and maint for maintenance backports. -When new work is introduced by contributors, it’s collected into topic branches in the maintainer’s repository in a manner similar to what we’ve described (see }}">Managing a complex series of parallel contributed topic branches.). -At this point, the topics are evaluated to determine whether they’re safe and ready for consumption or whether they need more work. -If they’re safe, they’re merged into next, and that branch is pushed up so everyone can try the topics integrated together.

-
-
-
-}}" alt="Managing a complex series of parallel contributed topic branches."> -
-
Figur 78. Managing a complex series of parallel contributed topic branches.
-
-
-

If the topics still need work, they’re merged into pu instead. -When it’s determined that they’re totally stable, the topics are re-merged into master. -The next and pu branches are then rebuilt from the master. -This means master almost always moves forward, next is rebased occasionally, and pu is rebased even more often:

-
-
-
-}}" alt="Merging contributed topic branches into long-term integration branches."> -
-
Figur 79. Merging contributed topic branches into long-term integration branches.
-
-
-

When a topic branch has finally been merged into master, it’s removed from the repository. -The Git project also has a maint branch that is forked off from the last release to provide backported patches in case a maintenance release is required. -Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions. -The Git project’s workflow is specialized. To clearly understand this you could check out the Git Maintainer’s guide.

-
-
-
-

Rebasing and Cherry-Picking Workflows

-
-

-Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. -When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or develop, and so on) branch. -If that works well, you can fast-forward your master branch, and you’ll end up with a linear project history.

-
-
-

-The other way to move introduced work from one branch to another is to cherry-pick it. -A cherry-pick in Git is like a rebase for a single commit. -It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. -This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. -For example, suppose you have a project that looks like this:

-
-
-
-}}" alt="Example history before a cherry-pick."> -
-
Figur 80. Example history before a cherry-pick.
-
-
-

If you want to pull commit e43a6 into your master branch, you can run

-
-
-
-
$ git cherry-pick e43a6
-Finished one cherry-pick.
-[master]: created a0a41a9: "More friendly message when locking the index fails."
- 3 files changed, 17 insertions(+), 3 deletions(-)
-
-
-
-

This pulls the same change introduced in e43a6, but you get a new commit SHA-1 value, because the date applied is different. -Now your history looks like this:

-
-
-
-}}" alt="History after cherry-picking a commit on a topic branch."> -
-
Figur 81. History after cherry-picking a commit on a topic branch.
-
-
-

Now you can remove your topic branch and drop the commits you didn’t want to pull in.

-
-
-
-

Rerere

-
-

-If you’re doing lots of merging and rebasing, or you’re maintaining a long-lived topic branch, Git has a feature called “rerere” that can help.

-
-
-

Rerere stands for “reuse recorded resolution” — it’s a way of shortcutting manual conflict resolution. -When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there’s a conflict that looks exactly like one you’ve already fixed, it’ll just use the fix from last time, without bothering you with it.

-
-
-

This feature comes in two parts: a configuration setting and a command. -The configuration setting is rerere.enabled, and it’s handy enough to put in your global config:

-
-
-
-
$ git config --global rerere.enabled true
-
-
-
-

Now, whenever you do a merge that resolves conflicts, the resolution will be recorded in the cache in case you need it in the future.

-
-
-

If you need to, you can interact with the rerere cache using the git rerere command. -When it’s invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if rerere.enabled is set to true). -There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache. -We will cover rerere in more detail in }}">Rerere.

-
-
-
-
-

Tagging Your Releases

-
-

-When you’ve decided to cut a release, you’ll probably want to assign a tag so you can re-create that release at any point going forward. -You can create a new tag as discussed in }}">Grunder i Git. -If you decide to sign the tag as the maintainer, the tagging may look something like this:

-
-
-
-
$ git tag -s v1.5 -m 'my signed 1.5 tag'
-You need a passphrase to unlock the secret key for
-user: "Scott Chacon <schacon@gmail.com>"
-1024-bit DSA key, ID F721C45A, created 2009-02-09
-
-
-
-

If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. -The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. -To do this, you can figure out which key you want by running gpg --list-keys:

-
-
-
-
$ gpg --list-keys
-/Users/schacon/.gnupg/pubring.gpg
----------------------------------
-pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
-uid                  Scott Chacon <schacon@gmail.com>
-sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
-
-
-
-

Then, you can directly import the key into the Git database by exporting it and piping that through git hash-object, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob:

-
-
-
-
$ gpg -a --export F721C45A | git hash-object -w --stdin
-659ef797d181633c87ec71ac3f9ba29fe5775b92
-
-
-
-

Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the hash-object command gave you:

-
-
-
-
$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
-
-
-
-

If you run git push --tags, the maintainer-pgp-pub tag will be shared with everyone. -If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG:

-
-
-
-
$ git show maintainer-pgp-pub | gpg --import
-
-
-
-

They can use that key to verify all your signed tags. -Also, if you include instructions in the tag message, running git show <tag> will let you give the end user more specific instructions about tag verification.

-
-
-
-

Generating a Build Number

-
-

-Because Git doesn’t have monotonically increasing numbers like v123 or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run git describe on that commit. -In response, Git generates a string consisting of the name of the most recent tag earlier than that commit, followed by the number of commits since that tag, followed finally by a partial SHA-1 value of the commit being described (prefixed with the letter "g" meaning Git):

-
-
-
-
$ git describe master
-v1.6.2-rc1-20-g8c5b85c
-
-
-
-

This way, you can export a snapshot or build and name it something understandable to people. -In fact, if you build Git from source code cloned from the Git repository, git --version gives you something that looks like this. -If you’re describing a commit that you have directly tagged, it gives you simply the tag name.

-
-
-

By default, the git describe command requires annotated tags (tags created with the -a or -s flag); if you want to take advantage of lightweight (non-annotated) tags as well, add the --tags option to the command. -You can also use this string as the target of a git checkout or git show command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever. -For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older git describe output names were invalidated.

-
-
-
-

Preparing a Release

-
-

-Now you want to release a build. -One of the things you’ll want to do is create an archive of the latest snapshot of your code for those poor souls who don’t use Git. -The command to do this is git archive:

-
-
-
-
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
-$ ls *.tar.gz
-v1.6.2-rc1-20-g8c5b85c.tar.gz
-
-
-
-

If someone opens that tarball, they get the latest snapshot of your project under a project directory. -You can also create a zip archive in much the same way, but by passing the --format=zip option to git archive:

-
-
-
-
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
-
-
-
-

You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people.

-
-
-
-

The Shortlog

-
-

-It’s time to email your mailing list of people who want to know what’s happening in your project. -A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or email is to use the git shortlog command. -It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1:

-
-
-
-
$ git shortlog --no-merges master --not v1.0.1
-Chris Wanstrath (6):
-      Add support for annotated tags to Grit::Tag
-      Add packed-refs annotated tag support.
-      Add Grit::Commit#to_patch
-      Update version and History.txt
-      Remove stray `puts`
-      Make ls_tree ignore nils
-
-Tom Preston-Werner (4):
-      fix dates in history
-      dynamic version method
-      Version bump to 1.0.2
-      Regenerated gemspec for version 1.0.2
-
-
-
-

You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list.

-
-
- \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Distributed-Git-Summary.html b/external/book/content/book/sv/v2/Distributed-Git-Summary.html deleted file mode 100644 index 30f8166ea3..0000000000 --- a/external/book/content/book/sv/v2/Distributed-Git-Summary.html +++ /dev/null @@ -1,26 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -category: book -section: documentation -subsection: book -sidebar: book -book: - language_code: sv - chapter: - title: Distributed Git - number: 5 - section: - title: Summary - number: 4 - cs_number: '5.4' - previous: book/sv/v2/Distributed-Git-Maintaining-a-Project - next: book/sv/v2/GitHub-Account-Setup-and-Configuration -title: Git - Summary ---- -

Summary

-
-

You should feel fairly comfortable contributing to a project in Git as well as maintaining your own project or integrating other users' contributions. -Congratulations on being an effective Git developer! -In the next chapter, you’ll learn about how to use the largest and most popular Git hosting service, GitHub.

-
- \ No newline at end of file diff --git a/external/book/content/book/sv/v2/Git-Internals-Summary.html b/external/book/content/book/sv/v2/Git-Internals-Summary.html index f72ea12595..370c5fe486 100644 --- a/external/book/content/book/sv/v2/Git-Internals-Summary.html +++ b/external/book/content/book/sv/v2/Git-Internals-Summary.html @@ -17,7 +17,7 @@ next: book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces title: Git - Summary --- -

Summary

+

Summary

At this point, you should have a pretty good understanding of what Git does in the background and, to some degree, how it’s implemented. This chapter has covered a number of plumbing commands — commands that are lower level and simpler than the porcelain commands you’ve learned about in the rest of the book. diff --git a/external/book/content/book/sv/v2/Git-Tools-Reset-Demystified.html b/external/book/content/book/sv/v2/Git-Tools-Reset-Demystified.html index 3e8550165c..fc7abb27cf 100644 --- a/external/book/content/book/sv/v2/Git-Tools-Reset-Demystified.html +++ b/external/book/content/book/sv/v2/Git-Tools-Reset-Demystified.html @@ -470,7 +470,7 @@

With Paths

-

Summary

+

Summary

Hopefully now you understand and feel more comfortable with the reset command, but are probably still a little confused about how exactly it differs from checkout and could not possibly remember all the rules of the different invocations.

diff --git a/external/book/content/book/sv/v2/Git-Tools-Summary.html b/external/book/content/book/sv/v2/Git-Tools-Summary.html index a749c943d9..0904fc8ae9 100644 --- a/external/book/content/book/sv/v2/Git-Tools-Summary.html +++ b/external/book/content/book/sv/v2/Git-Tools-Summary.html @@ -17,7 +17,7 @@ next: book/sv/v2/Customizing-Git-Git-Configuration title: Git - Summary --- -

Summary

+

Summary

You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. diff --git a/external/book/content/book/sv/v2/Git-and-Other-Systems-Git-as-a-Client.html b/external/book/content/book/sv/v2/Git-and-Other-Systems-Git-as-a-Client.html index 53d387a73c..7354e01cfd 100644 --- a/external/book/content/book/sv/v2/Git-and-Other-Systems-Git-as-a-Client.html +++ b/external/book/content/book/sv/v2/Git-and-Other-Systems-Git-as-a-Client.html @@ -1213,7 +1213,7 @@

Caveats

-

Summary

+

Summary

Since Git’s and Bazaar’s models are similar, there isn’t a lot of resistance when working across the boundary. As long as you watch out for the limitations, and are always aware that the remote repository isn’t natively Git, you’ll be fine.

diff --git a/external/book/content/book/sv/v2/Git-and-Other-Systems-Summary.html b/external/book/content/book/sv/v2/Git-and-Other-Systems-Summary.html index eaa60af3c0..8a231e09e8 100644 --- a/external/book/content/book/sv/v2/Git-and-Other-Systems-Summary.html +++ b/external/book/content/book/sv/v2/Git-and-Other-Systems-Summary.html @@ -17,7 +17,7 @@ next: book/sv/v2/Git-Internals-Plumbing-and-Porcelain title: Git - Summary --- -

Summary

+

Summary

You should feel comfortable using Git as a client for other version-control systems, or importing nearly any existing repository into Git without losing data. In the next chapter, we’ll cover the raw internals of Git so you can craft every single byte, if need be.

diff --git "a/external/book/content/book/sv/v2/Git-f\303\266rgreningar-Arbetsfl\303\266de-med-grenar.html" "b/external/book/content/book/sv/v2/Git-f\303\266rgreningar-Arbetsfl\303\266de-med-grenar.html" index aa9fc4bea8..9c7b3ad21f 100644 --- "a/external/book/content/book/sv/v2/Git-f\303\266rgreningar-Arbetsfl\303\266de-med-grenar.html" +++ "b/external/book/content/book/sv/v2/Git-f\303\266rgreningar-Arbetsfl\303\266de-med-grenar.html" @@ -99,7 +99,7 @@

Ämnesgrenar

-

Vi kommer gå in i mer detalj gällande olika möjliga arbetsflödena för dit Gitprojekt i }}">Distributed Git, innan du bestämmer dig för vilken förgreningsmodell som ditt nästa projekt skall ha, så glöm inte det kapitlet.

+

Vi kommer gå in i mer detalj gällande olika möjliga arbetsflödena för dit Gitprojekt i }}">Distribuerade Git, innan du bestämmer dig för vilken förgreningsmodell som ditt nästa projekt skall ha, så glöm inte det kapitlet.

Det är viktigt att komma ihåg att när du gör allt detta, att grenarna är lokala. När du grenar ut och slår ihop grenar görs allt i dit lokala förvar — ingen kommunikation sker med servern.

diff --git "a/external/book/content/book/sv/v2/Git-p\303\245-servern-Sammanfattning.html" "b/external/book/content/book/sv/v2/Git-p\303\245-servern-Sammanfattning.html" index 4d02732566..0414281a87 100644 --- "a/external/book/content/book/sv/v2/Git-p\303\245-servern-Sammanfattning.html" +++ "b/external/book/content/book/sv/v2/Git-p\303\245-servern-Sammanfattning.html" @@ -14,7 +14,7 @@ number: 10 cs_number: '4.10' previous: book/sv/v2/Git-på-servern-Alternativ-tillhandahållna-av-tredje-part - next: book/sv/v2/Distributed-Git-Distributed-Workflows + next: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden title: Git - Sammanfattning url: "/book/sv/v2/Git-på-servern-Sammanfattning.html" --- diff --git a/external/book/content/book/sv/v2/GitHub-Account-Setup-and-Configuration.html b/external/book/content/book/sv/v2/GitHub-Account-Setup-and-Configuration.html index 6db7df251b..187bfb90e0 100644 --- a/external/book/content/book/sv/v2/GitHub-Account-Setup-and-Configuration.html +++ b/external/book/content/book/sv/v2/GitHub-Account-Setup-and-Configuration.html @@ -13,7 +13,7 @@ title: Account Setup and Configuration number: 1 cs_number: '6.1' - previous: book/sv/v2/Distributed-Git-Summary + previous: book/sv/v2/Distribuerade-Git-Sammanfattning next: book/sv/v2/GitHub-Contributing-to-a-Project title: Git - Account Setup and Configuration --- diff --git a/external/book/content/book/sv/v2/GitHub-Contributing-to-a-Project.html b/external/book/content/book/sv/v2/GitHub-Contributing-to-a-Project.html index 013fc53c78..d9fa349d68 100644 --- a/external/book/content/book/sv/v2/GitHub-Contributing-to-a-Project.html +++ b/external/book/content/book/sv/v2/GitHub-Contributing-to-a-Project.html @@ -98,7 +98,7 @@

The GitHub Flow

-

This is basically the Integration Manager workflow covered in }}">Integration-Manager Workflow, but instead of using email to communicate and review changes, teams use GitHub’s web based tools.

+

This is basically the Integration Manager workflow covered in }}">Integrationsstyrd arbetsprocess, but instead of using email to communicate and review changes, teams use GitHub’s web based tools.

Let’s walk through an example of proposing a change to an open source project hosted on GitHub using this flow.

@@ -238,7 +238,7 @@

Iterating on a Pull Request

At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let’s say that he likes the idea, but would prefer a slightly longer time for the light to be off than on.

-

Where this conversation may take place over email in the workflows presented in }}">Distributed Git, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines.

+

Where this conversation may take place over email in the workflows presented in }}">Distribuerade Git, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines.

@@ -280,7 +280,7 @@

Iterating on a Pull Request

Figur 96. Pull Request final
-

An interesting thing to notice is that if you click on the “Files Changed” tab on this Pull Request, you’ll get the “unified” diff — that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. In git diff terms, it basically automatically shows you git diff master...<branch> for the branch this Pull Request is based on. See }}">Determining What Is Introduced for more about this type of diff.

+

An interesting thing to notice is that if you click on the “Files Changed” tab on this Pull Request, you’ll get the “unified” diff — that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. In git diff terms, it basically automatically shows you git diff master...<branch> for the branch this Pull Request is based on. See }}">Avgöra vad som ska integreras for more about this type of diff.

The other thing you’ll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. This button only shows up if you have write access to the repository and a trivial merge is possible. If you click it GitHub will perform a “non-fast-forward” merge, meaning that even if the merge could be a fast-forward, it will still create a merge commit.

diff --git a/external/book/content/book/sv/v2/GitHub-Maintaining-a-Project.html b/external/book/content/book/sv/v2/GitHub-Maintaining-a-Project.html index 2a5b020d5c..725cbd712e 100644 --- a/external/book/content/book/sv/v2/GitHub-Maintaining-a-Project.html +++ b/external/book/content/book/sv/v2/GitHub-Maintaining-a-Project.html @@ -139,7 +139,7 @@

Email Notifications

If you notice the line that says git pull <url> patch-1, this is a simple way to merge in a remote branch without having to add a remote. -We went over this quickly in }}">Checking Out Remote Branches. +We went over this quickly in }}">Checka ut fjärrgrenar. If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes.

diff --git a/external/book/content/book/sv/v2/GitHub-Summary.html b/external/book/content/book/sv/v2/GitHub-Summary.html index d91ecd6e27..e6b900823c 100644 --- a/external/book/content/book/sv/v2/GitHub-Summary.html +++ b/external/book/content/book/sv/v2/GitHub-Summary.html @@ -17,7 +17,7 @@ next: book/sv/v2/Git-Tools-Revision-Selection title: Git - Summary --- -

Summary

+

Summary

Now you’re a GitHub user. You know how to create an account, manage an organization, create and push to repositories, contribute to other people’s projects and accept contributions from others. diff --git a/external/book/content/book/sv/v2/Grunder-i-Git-Visa-historiken.html b/external/book/content/book/sv/v2/Grunder-i-Git-Visa-historiken.html index 5b37c12ee6..b0bc0e89a7 100644 --- a/external/book/content/book/sv/v2/Grunder-i-Git-Visa-historiken.html +++ b/external/book/content/book/sv/v2/Grunder-i-Git-Visa-historiken.html @@ -264,7 +264,7 @@

Visa historiken

Du kanske undrar vad som är skillnaden mellan author och committer. Det förra är författare, det vill säga den som ursprungligen gjorde arbetet, medan den senare är den som sparade versionen. Om du skickare en patch till ett projekt och någon projektmedlem använder din patch, kommer båda ni att anses bidragande till ändringen. — Du som författare, och projhektmedlemmen som den som sparade versionen. -Vi kommer att gå igenom distinktionen lite mer i }}">Distributed Git.

+Vi kommer att gå igenom distinktionen lite mer i }}">Distribuerade Git.

Valen oneline och format är särskilt användbara tillsammans med ett annat val till log, nämligen --graph. diff --git a/external/book/content/book/sv/v2/_index.html b/external/book/content/book/sv/v2/_index.html index 41a580911f..c859534fab 100644 --- a/external/book/content/book/sv/v2/_index.html +++ b/external/book/content/book/sv/v2/_index.html @@ -8,7 +8,7 @@ language_code: sv front_page: true repository_url: https://github.com/progit2-sv/progit2 - sha: fe2c9c6d56deaa0c3f40b66da094c6d287c7eef8 + sha: 70b2db57c83dff9df34f6587e0d59f10ace85a77 page_title: Git - Book url: "/book/sv/v2.html" aliases: diff --git a/external/book/content/book/sv/v2/ch00/_applicera_en_mejlad_patch_med_apply.html b/external/book/content/book/sv/v2/ch00/_applicera_en_mejlad_patch_med_apply.html new file mode 100644 index 0000000000..a164331128 --- /dev/null +++ b/external/book/content/book/sv/v2/ch00/_applicera_en_mejlad_patch_med_apply.html @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_applicera_en_mejlad_patch_med_apply +--- diff --git a/external/book/content/book/sv/v2/ch00/_applying_a_patch_with_apply.html b/external/book/content/book/sv/v2/ch00/_applying_a_patch_with_apply.html deleted file mode 100644 index d0f1616d80..0000000000 --- a/external/book/content/book/sv/v2/ch00/_applying_a_patch_with_apply.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_applying_a_patch_with_apply ---- diff --git "a/external/book/content/book/sv/v2/ch00/_arbeta_i_\303\244mnesgrenar.html" "b/external/book/content/book/sv/v2/ch00/_arbeta_i_\303\244mnesgrenar.html" new file mode 100644 index 0000000000..1ac5d76ddc --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_arbeta_i_\303\244mnesgrenar.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_arbeta_i_ämnesgrenar +--- diff --git "a/external/book/content/book/sv/v2/ch00/_arbetsfl\303\266de_med_stora_sammanslagningar.html" "b/external/book/content/book/sv/v2/ch00/_arbetsfl\303\266de_med_stora_sammanslagningar.html" new file mode 100644 index 0000000000..c0c71692ce --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_arbetsfl\303\266de_med_stora_sammanslagningar.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_arbetsflöde_med_stora_sammanslagningar +--- diff --git "a/external/book/content/book/sv/v2/ch00/_arbetsfl\303\266den_med_sammanslagning.html" "b/external/book/content/book/sv/v2/ch00/_arbetsfl\303\266den_med_sammanslagning.html" new file mode 100644 index 0000000000..92e72f033f --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_arbetsfl\303\266den_med_sammanslagning.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_arbetsflöden_med_sammanslagning +--- diff --git a/external/book/content/book/sv/v2/ch00/_build_number.html b/external/book/content/book/sv/v2/ch00/_build_number.html index 9b1877aec6..14c6d0ae28 100644 --- a/external/book/content/book/sv/v2/ch00/_build_number.html +++ b/external/book/content/book/sv/v2/ch00/_build_number.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_build_number +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_build_number --- diff --git a/external/book/content/book/sv/v2/ch00/_centraliserad_arbetsprocess.html b/external/book/content/book/sv/v2/ch00/_centraliserad_arbetsprocess.html new file mode 100644 index 0000000000..b410755308 --- /dev/null +++ b/external/book/content/book/sv/v2/ch00/_centraliserad_arbetsprocess.html @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#_centraliserad_arbetsprocess +--- diff --git a/external/book/content/book/sv/v2/ch00/_centralized_workflow.html b/external/book/content/book/sv/v2/ch00/_centralized_workflow.html deleted file mode 100644 index 3d8cc8929a..0000000000 --- a/external/book/content/book/sv/v2/ch00/_centralized_workflow.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#_centralized_workflow ---- diff --git a/external/book/content/book/sv/v2/ch00/_checking_out_remotes.html b/external/book/content/book/sv/v2/ch00/_checking_out_remotes.html index 8ace35accf..a370e3b863 100644 --- a/external/book/content/book/sv/v2/ch00/_checking_out_remotes.html +++ b/external/book/content/book/sv/v2/ch00/_checking_out_remotes.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_checking_out_remotes +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_checking_out_remotes --- diff --git a/external/book/content/book/sv/v2/ch00/_commit_guidelines.html b/external/book/content/book/sv/v2/ch00/_commit_guidelines.html index a7806fe586..c6e3f7e54d 100644 --- a/external/book/content/book/sv/v2/ch00/_commit_guidelines.html +++ b/external/book/content/book/sv/v2/ch00/_commit_guidelines.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_commit_guidelines --- diff --git a/external/book/content/book/sv/v2/ch00/_contributing_project.html b/external/book/content/book/sv/v2/ch00/_contributing_project.html index 8ad31056ab..2c3c24ca1c 100644 --- a/external/book/content/book/sv/v2/ch00/_contributing_project.html +++ b/external/book/content/book/sv/v2/ch00/_contributing_project.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_contributing_project +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_contributing_project --- diff --git a/external/book/content/book/sv/v2/ch00/_dictator_and_lieutenants_workflow.html b/external/book/content/book/sv/v2/ch00/_dictator_and_lieutenants_workflow.html deleted file mode 100644 index 57f6369e03..0000000000 --- a/external/book/content/book/sv/v2/ch00/_dictator_and_lieutenants_workflow.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow ---- diff --git "a/external/book/content/book/sv/v2/ch00/_diktatorns_och_l\303\266jtnanternas_arbetsfl\303\266de.html" "b/external/book/content/book/sv/v2/ch00/_diktatorns_och_l\303\266jtnanternas_arbetsfl\303\266de.html" new file mode 100644 index 0000000000..d281f625a2 --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_diktatorns_och_l\303\266jtnanternas_arbetsfl\303\266de.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#_diktatorns_och_löjtnanternas_arbetsflöde +--- diff --git "a/external/book/content/book/sv/v2/ch00/_distribuerade_arbetsfl\303\266den.html" "b/external/book/content/book/sv/v2/ch00/_distribuerade_arbetsfl\303\266den.html" new file mode 100644 index 0000000000..37f7669ebe --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_distribuerade_arbetsfl\303\266den.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#_distribuerade_arbetsflöden +--- diff --git a/external/book/content/book/sv/v2/ch00/_distributed_workflows.html b/external/book/content/book/sv/v2/ch00/_distributed_workflows.html deleted file mode 100644 index dfceaa3336..0000000000 --- a/external/book/content/book/sv/v2/ch00/_distributed_workflows.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#_distributed_workflows ---- diff --git a/external/book/content/book/sv/v2/ch00/_git_am.html b/external/book/content/book/sv/v2/ch00/_git_am.html index 29f19483a0..985b7f74c2 100644 --- a/external/book/content/book/sv/v2/ch00/_git_am.html +++ b/external/book/content/book/sv/v2/ch00/_git_am.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_git_am +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_git_am --- diff --git a/external/book/content/book/sv/v2/ch00/_integrating_contributed_work.html b/external/book/content/book/sv/v2/ch00/_integrating_contributed_work.html deleted file mode 100644 index 50c1082687..0000000000 --- a/external/book/content/book/sv/v2/ch00/_integrating_contributed_work.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_integrating_contributed_work ---- diff --git a/external/book/content/book/sv/v2/ch00/_integration_manager.html b/external/book/content/book/sv/v2/ch00/_integration_manager.html index b22794e393..62a9aa36b4 100644 --- a/external/book/content/book/sv/v2/ch00/_integration_manager.html +++ b/external/book/content/book/sv/v2/ch00/_integration_manager.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#_integration_manager +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#_integration_manager --- diff --git "a/external/book/content/book/sv/v2/ch00/_integrera_kod_fr\303\245n_bidragsl\303\244mnare.html" "b/external/book/content/book/sv/v2/ch00/_integrera_kod_fr\303\245n_bidragsl\303\244mnare.html" new file mode 100644 index 0000000000..f0111996d5 --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_integrera_kod_fr\303\245n_bidragsl\303\244mnare.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_integrera_kod_från_bidragslämnare +--- diff --git a/external/book/content/book/sv/v2/ch00/_large_merging_workflows.html b/external/book/content/book/sv/v2/ch00/_large_merging_workflows.html deleted file mode 100644 index 269b9dfbb5..0000000000 --- a/external/book/content/book/sv/v2/ch00/_large_merging_workflows.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_large_merging_workflows ---- diff --git a/external/book/content/book/sv/v2/ch00/_maintaining_a_project.html b/external/book/content/book/sv/v2/ch00/_maintaining_a_project.html deleted file mode 100644 index cd2a151997..0000000000 --- a/external/book/content/book/sv/v2/ch00/_maintaining_a_project.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_maintaining_a_project ---- diff --git a/external/book/content/book/sv/v2/ch00/_merging_workflows.html b/external/book/content/book/sv/v2/ch00/_merging_workflows.html deleted file mode 100644 index e553c629db..0000000000 --- a/external/book/content/book/sv/v2/ch00/_merging_workflows.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_merging_workflows ---- diff --git a/external/book/content/book/sv/v2/ch00/_patches_from_email.html b/external/book/content/book/sv/v2/ch00/_patches_from_email.html index 65c8a582cb..da630d7be0 100644 --- a/external/book/content/book/sv/v2/ch00/_patches_from_email.html +++ b/external/book/content/book/sv/v2/ch00/_patches_from_email.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_patches_from_email +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_patches_from_email --- diff --git a/external/book/content/book/sv/v2/ch00/_preparing_release.html b/external/book/content/book/sv/v2/ch00/_preparing_release.html index 9a7a747c98..d317a34fc5 100644 --- a/external/book/content/book/sv/v2/ch00/_preparing_release.html +++ b/external/book/content/book/sv/v2/ch00/_preparing_release.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_preparing_release +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_preparing_release --- diff --git "a/external/book/content/book/sv/v2/ch00/_privat_st\303\266rre_team.html" "b/external/book/content/book/sv/v2/ch00/_privat_st\303\266rre_team.html" new file mode 100644 index 0000000000..006e955f78 --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_privat_st\303\266rre_team.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_privat_större_team +--- diff --git a/external/book/content/book/sv/v2/ch00/_private_managed_team.html b/external/book/content/book/sv/v2/ch00/_private_managed_team.html deleted file mode 100644 index 97823f5f09..0000000000 --- a/external/book/content/book/sv/v2/ch00/_private_managed_team.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_private_managed_team ---- diff --git a/external/book/content/book/sv/v2/ch00/_private_team.html b/external/book/content/book/sv/v2/ch00/_private_team.html index 059a2cadc5..de99cb1332 100644 --- a/external/book/content/book/sv/v2/ch00/_private_team.html +++ b/external/book/content/book/sv/v2/ch00/_private_team.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_private_team +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_private_team --- diff --git a/external/book/content/book/sv/v2/ch00/_project_over_email.html b/external/book/content/book/sv/v2/ch00/_project_over_email.html index 7e4ae4afac..72d13bceab 100644 --- a/external/book/content/book/sv/v2/ch00/_project_over_email.html +++ b/external/book/content/book/sv/v2/ch00/_project_over_email.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_project_over_email +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_project_over_email --- diff --git a/external/book/content/book/sv/v2/ch00/_public_project.html b/external/book/content/book/sv/v2/ch00/_public_project.html index 2927205aab..f16337662d 100644 --- a/external/book/content/book/sv/v2/ch00/_public_project.html +++ b/external/book/content/book/sv/v2/ch00/_public_project.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_public_project +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_public_project --- diff --git a/external/book/content/book/sv/v2/ch00/_rebase_cherry_pick.html b/external/book/content/book/sv/v2/ch00/_rebase_cherry_pick.html index f6f629a65f..607e691a11 100644 --- a/external/book/content/book/sv/v2/ch00/_rebase_cherry_pick.html +++ b/external/book/content/book/sv/v2/ch00/_rebase_cherry_pick.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_rebase_cherry_pick +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_rebase_cherry_pick --- diff --git a/external/book/content/book/sv/v2/ch00/_rerere.html b/external/book/content/book/sv/v2/ch00/_rerere.html index b55f221f1e..448c6453f0 100644 --- a/external/book/content/book/sv/v2/ch00/_rerere.html +++ b/external/book/content/book/sv/v2/ch00/_rerere.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_rerere +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_rerere --- diff --git a/external/book/content/book/sv/v2/ch00/_sammanfattning_5.html b/external/book/content/book/sv/v2/ch00/_sammanfattning_5.html new file mode 100644 index 0000000000..62fa6de3fc --- /dev/null +++ b/external/book/content/book/sv/v2/ch00/_sammanfattning_5.html @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#_sammanfattning_5 +--- diff --git a/external/book/content/book/sv/v2/ch00/_sammanfattning_6.html b/external/book/content/book/sv/v2/ch00/_sammanfattning_6.html new file mode 100644 index 0000000000..11a20c7191 --- /dev/null +++ b/external/book/content/book/sv/v2/ch00/_sammanfattning_6.html @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Sammanfattning#_sammanfattning_6 +--- diff --git "a/external/book/content/book/sv/v2/ch00/_sammanfattning_av_arbetsfl\303\266den.html" "b/external/book/content/book/sv/v2/ch00/_sammanfattning_av_arbetsfl\303\266den.html" new file mode 100644 index 0000000000..f7e61c91ef --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_sammanfattning_av_arbetsfl\303\266den.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#_sammanfattning_av_arbetsflöden +--- diff --git a/external/book/content/book/sv/v2/ch00/_summary.html b/external/book/content/book/sv/v2/ch00/_summary.html index eacf46ed04..e98500d6fe 100644 --- a/external/book/content/book/sv/v2/ch00/_summary.html +++ b/external/book/content/book/sv/v2/ch00/_summary.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#_summary +redirect_to: book/sv/v2/GitHub-Summary#_summary --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_10.html b/external/book/content/book/sv/v2/ch00/_summary_10.html deleted file mode 100644 index 3d4b3b4b81..0000000000 --- a/external/book/content/book/sv/v2/ch00/_summary_10.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces#_summary_10 ---- diff --git a/external/book/content/book/sv/v2/ch00/_summary_11.html b/external/book/content/book/sv/v2/ch00/_summary_11.html deleted file mode 100644 index d51bf513c3..0000000000 --- a/external/book/content/book/sv/v2/ch00/_summary_11.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary#_summary_11 ---- diff --git a/external/book/content/book/sv/v2/ch00/_summary_2.html b/external/book/content/book/sv/v2/ch00/_summary_2.html index 09f9f31d87..3b7ec1c2b8 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_2.html +++ b/external/book/content/book/sv/v2/ch00/_summary_2.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Summary#_summary_2 +redirect_to: book/sv/v2/Git-Tools-Reset-Demystified#_summary_2 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_3.html b/external/book/content/book/sv/v2/ch00/_summary_3.html index 311c94e91e..8411596cc5 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_3.html +++ b/external/book/content/book/sv/v2/ch00/_summary_3.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/GitHub-Summary#_summary_3 +redirect_to: book/sv/v2/Git-Tools-Summary#_summary_3 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_4.html b/external/book/content/book/sv/v2/ch00/_summary_4.html index a8e5fe3da0..3df89d859b 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_4.html +++ b/external/book/content/book/sv/v2/ch00/_summary_4.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Git-Tools-Reset-Demystified#_summary_4 +redirect_to: book/sv/v2/Customizing-Git-Summary#_summary_4 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_5.html b/external/book/content/book/sv/v2/ch00/_summary_5.html index c44158f66c..31f3649845 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_5.html +++ b/external/book/content/book/sv/v2/ch00/_summary_5.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Git-Tools-Summary#_summary_5 +redirect_to: book/sv/v2/Git-and-Other-Systems-Git-as-a-Client#_summary_5 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_6.html b/external/book/content/book/sv/v2/ch00/_summary_6.html index 8a5eef53fd..7ce8b3f295 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_6.html +++ b/external/book/content/book/sv/v2/ch00/_summary_6.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Customizing-Git-Summary#_summary_6 +redirect_to: book/sv/v2/Git-and-Other-Systems-Summary#_summary_6 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_7.html b/external/book/content/book/sv/v2/ch00/_summary_7.html index d61dc7e3fa..4f6fa92e3c 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_7.html +++ b/external/book/content/book/sv/v2/ch00/_summary_7.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Git-and-Other-Systems-Git-as-a-Client#_summary_7 +redirect_to: book/sv/v2/Git-Internals-Summary#_summary_7 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_8.html b/external/book/content/book/sv/v2/ch00/_summary_8.html index 81773a6e4e..e7ba7ddd94 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_8.html +++ b/external/book/content/book/sv/v2/ch00/_summary_8.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Git-and-Other-Systems-Summary#_summary_8 +redirect_to: book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces#_summary_8 --- diff --git a/external/book/content/book/sv/v2/ch00/_summary_9.html b/external/book/content/book/sv/v2/ch00/_summary_9.html index 94f8387e44..bcf3b8b003 100644 --- a/external/book/content/book/sv/v2/ch00/_summary_9.html +++ b/external/book/content/book/sv/v2/ch00/_summary_9.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Git-Internals-Summary#_summary_9 +redirect_to: book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary#_summary_9 --- diff --git a/external/book/content/book/sv/v2/ch00/_tagging_releases.html b/external/book/content/book/sv/v2/ch00/_tagging_releases.html index 5d92a5e56f..b46134c0b9 100644 --- a/external/book/content/book/sv/v2/ch00/_tagging_releases.html +++ b/external/book/content/book/sv/v2/ch00/_tagging_releases.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_tagging_releases +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_tagging_releases --- diff --git a/external/book/content/book/sv/v2/ch00/_the_shortlog.html b/external/book/content/book/sv/v2/ch00/_the_shortlog.html index ab20cbf8a1..3cd9113057 100644 --- a/external/book/content/book/sv/v2/ch00/_the_shortlog.html +++ b/external/book/content/book/sv/v2/ch00/_the_shortlog.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_the_shortlog +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_the_shortlog --- diff --git "a/external/book/content/book/sv/v2/ch00/_underh\303\245lla_ett_projekt.html" "b/external/book/content/book/sv/v2/ch00/_underh\303\245lla_ett_projekt.html" new file mode 100644 index 0000000000..5b7dd20d32 --- /dev/null +++ "b/external/book/content/book/sv/v2/ch00/_underh\303\245lla_ett_projekt.html" @@ -0,0 +1,4 @@ +--- +### DO NOT EDIT! Generated by script/update-book2.rb +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_underhålla_ett_projekt +--- diff --git a/external/book/content/book/sv/v2/ch00/_what_is_introduced.html b/external/book/content/book/sv/v2/ch00/_what_is_introduced.html index ece6832a94..4a75aa85b2 100644 --- a/external/book/content/book/sv/v2/ch00/_what_is_introduced.html +++ b/external/book/content/book/sv/v2/ch00/_what_is_introduced.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_what_is_introduced +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#_what_is_introduced --- diff --git a/external/book/content/book/sv/v2/ch00/_workflows_summary.html b/external/book/content/book/sv/v2/ch00/_workflows_summary.html deleted file mode 100644 index a78c9faa67..0000000000 --- a/external/book/content/book/sv/v2/ch00/_workflows_summary.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#_workflows_summary ---- diff --git a/external/book/content/book/sv/v2/ch00/_working_in_topic_branches.html b/external/book/content/book/sv/v2/ch00/_working_in_topic_branches.html deleted file mode 100644 index 43305e2487..0000000000 --- a/external/book/content/book/sv/v2/ch00/_working_in_topic_branches.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#_working_in_topic_branches ---- diff --git a/external/book/content/book/sv/v2/ch00/ch05-distributed-git.html b/external/book/content/book/sv/v2/ch00/ch05-distributed-git.html index 89a83c2799..fe000a5f6f 100644 --- a/external/book/content/book/sv/v2/ch00/ch05-distributed-git.html +++ b/external/book/content/book/sv/v2/ch00/ch05-distributed-git.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#ch05-distributed-git +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#ch05-distributed-git --- diff --git a/external/book/content/book/sv/v2/ch00/merwf_a.html b/external/book/content/book/sv/v2/ch00/merwf_a.html index a1886f9cca..d2cebaf567 100644 --- a/external/book/content/book/sv/v2/ch00/merwf_a.html +++ b/external/book/content/book/sv/v2/ch00/merwf_a.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#merwf_a +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#merwf_a --- diff --git a/external/book/content/book/sv/v2/ch00/merwf_b.html b/external/book/content/book/sv/v2/ch00/merwf_b.html index d7e4a939e5..006cc15356 100644 --- a/external/book/content/book/sv/v2/ch00/merwf_b.html +++ b/external/book/content/book/sv/v2/ch00/merwf_b.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#merwf_b +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#merwf_b --- diff --git a/external/book/content/book/sv/v2/ch00/merwf_c.html b/external/book/content/book/sv/v2/ch00/merwf_c.html index 5a8f1b7acc..fbcb70f898 100644 --- a/external/book/content/book/sv/v2/ch00/merwf_c.html +++ b/external/book/content/book/sv/v2/ch00/merwf_c.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#merwf_c +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#merwf_c --- diff --git a/external/book/content/book/sv/v2/ch00/merwf_d.html b/external/book/content/book/sv/v2/ch00/merwf_d.html index 25b813be6e..c5e0811265 100644 --- a/external/book/content/book/sv/v2/ch00/merwf_d.html +++ b/external/book/content/book/sv/v2/ch00/merwf_d.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#merwf_d +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#merwf_d --- diff --git a/external/book/content/book/sv/v2/ch00/merwf_e.html b/external/book/content/book/sv/v2/ch00/merwf_e.html index 34f48fb028..5b23ce2a12 100644 --- a/external/book/content/book/sv/v2/ch00/merwf_e.html +++ b/external/book/content/book/sv/v2/ch00/merwf_e.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#merwf_e +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#merwf_e --- diff --git a/external/book/content/book/sv/v2/ch00/merwf_f.html b/external/book/content/book/sv/v2/ch00/merwf_f.html index 5a2256a7a2..dc04c86b51 100644 --- a/external/book/content/book/sv/v2/ch00/merwf_f.html +++ b/external/book/content/book/sv/v2/ch00/merwf_f.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Maintaining-a-Project#merwf_f +redirect_to: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt#merwf_f --- diff --git a/external/book/content/book/sv/v2/ch00/psp_b.html b/external/book/content/book/sv/v2/ch00/psp_b.html index ff0d5f2117..7d46368b9e 100644 --- a/external/book/content/book/sv/v2/ch00/psp_b.html +++ b/external/book/content/book/sv/v2/ch00/psp_b.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Contributing-to-a-Project#psp_b +redirect_to: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt#psp_b --- diff --git a/external/book/content/book/sv/v2/ch00/wfdiag_b.html b/external/book/content/book/sv/v2/ch00/wfdiag_b.html index 17c38d43c6..365cbfe201 100644 --- a/external/book/content/book/sv/v2/ch00/wfdiag_b.html +++ b/external/book/content/book/sv/v2/ch00/wfdiag_b.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#wfdiag_b +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#wfdiag_b --- diff --git a/external/book/content/book/sv/v2/ch00/wfdiag_c.html b/external/book/content/book/sv/v2/ch00/wfdiag_c.html index bf6d59854d..f6981d09b1 100644 --- a/external/book/content/book/sv/v2/ch00/wfdiag_c.html +++ b/external/book/content/book/sv/v2/ch00/wfdiag_c.html @@ -1,4 +1,4 @@ --- ### DO NOT EDIT! Generated by script/update-book2.rb -redirect_to: book/sv/v2/Distributed-Git-Distributed-Workflows#wfdiag_c +redirect_to: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden#wfdiag_c --- diff --git a/external/book/data/book/sv.yml b/external/book/data/book/sv.yml index 102a982882..c2efd173e8 100644 --- a/external/book/data/book/sv.yml +++ b/external/book/data/book/sv.yml @@ -115,20 +115,20 @@ chapters: title: Sammanfattning url: book/sv/v2/Git-på-servern-Sammanfattning - cs_number: '5' - title: Distributed Git + title: Distribuerade Git sections: - cs_number: '5.1' - title: Distributed Workflows - url: book/sv/v2/Distributed-Git-Distributed-Workflows + title: Distribuerade arbetsflöden + url: book/sv/v2/Distribuerade-Git-Distribuerade-arbetsflöden - cs_number: '5.2' - title: Contributing to a Project - url: book/sv/v2/Distributed-Git-Contributing-to-a-Project + title: Medverka i ett projekt + url: book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt - cs_number: '5.3' - title: Maintaining a Project - url: book/sv/v2/Distributed-Git-Maintaining-a-Project + title: Underhålla ett projekt + url: book/sv/v2/Distribuerade-Git-Underhålla-ett-projekt - cs_number: '5.4' - title: Summary - url: book/sv/v2/Distributed-Git-Summary + title: Sammanfattning + url: book/sv/v2/Distribuerade-Git-Sammanfattning - cs_number: '6' title: GitHub sections: diff --git a/external/book/sync/book-sv.sha b/external/book/sync/book-sv.sha index 1e79cd8485..f5d1a4293a 100644 --- a/external/book/sync/book-sv.sha +++ b/external/book/sync/book-sv.sha @@ -1 +1 @@ -fe2c9c6d56deaa0c3f40b66da094c6d287c7eef8 +70b2db57c83dff9df34f6587e0d59f10ace85a77