From 8c4cc4ad3d4be79fda6cb3109956d33bf984ca94 Mon Sep 17 00:00:00 2001 From: Dimitar Bonev Date: Thu, 28 Feb 2013 00:33:41 +0200 Subject: [PATCH 01/37] highlight the existence of git 'tree' object type to distinguish it (e.g. from file system tree) --- en/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown index 6dc212b55..a1ed3993f 100644 --- a/en/03-git-branching/01-chapter3.markdown +++ b/en/03-git-branching/01-chapter3.markdown @@ -15,7 +15,7 @@ To visualize this, let’s assume that you have a directory containing three fil $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' -When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed. +Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed. Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1. From 9e0a6b9baa526b6db1ff140cd99766ac11f1b433 Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Tue, 11 Jun 2013 00:08:49 +0400 Subject: [PATCH 02/37] Extend/improve "Diffing Binary Files" section v2 v2: * grammar fixes * description of img2txt is dropped --- en/07-customizing-git/01-chapter7.markdown | 35 +++++++++++----------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index 9e7b40423..27911ed02 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -307,11 +307,15 @@ Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute o #### Diffing Binary Files #### -In Git, you can use the attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff. +In Git, you can use the attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff. But the question is how do you convert *binary* data to a text? The best solution is to find some tool that does conversion for your binary format to a text representation. Unfortunately, very few binary formats can be represented as human readable text (imagine trying to convert audio data to a text). If this is the case and you failed to get a text presentation of your file's contents, it's often relatively easy to get a human readable description of that content, or metadata. Metadata won't give you a full representation of your file's content, but in any case it's better than nothing. + +We'll make use of the both described approaches to get usable diffs for some widely used binary formats. + +Side note: There are different kinds of binary formats with a text content, which are hard to find usable converter for. In such a case you could try to extract a text from your file with the `strings` program. Some of these files may use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats. ##### MS Word files ##### -Because this is a pretty cool and not widely known feature, I’ll go over a few examples. First, you’ll use this technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this: +First, you’ll use the described technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this: $ git diff diff --git a/chapter1.doc b/chapter1.doc @@ -322,18 +326,16 @@ You can’t directly compare two versions unless you check them out and scan the *.doc diff=word -This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `strings` program to convert Word documents into readable text files, which it will then diff properly: +This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `catdoc` program, which was written specifically for extracting text from a binary MS Word documents (you can get it from `http://www.wagner.pp.ru/~vitus/software/catdoc/`), to convert Word documents into readable text files, which it will then diff properly: - $ git config diff.word.textconv strings + $ git config diff.word.textconv catdoc This command adds a section to your `.git/config` that looks like this: [diff "word"] - textconv = strings - -Side note: There are different kinds of `.doc` files. Some use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. + textconv = catdoc -Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `strings` program. This effectively makes nice text-based versions of your Word files before attempting to diff them. +Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `catdoc` program. This effectively makes nice text-based versions of your Word files before attempting to diff them. Here’s an example. I put Chapter 1 of this book into Git, added some text to a paragraph, and saved the document. Then, I ran `git diff` to see what changed: @@ -342,15 +344,14 @@ Here’s an example. I put Chapter 1 of this book into Git, added some text to a index c1c8a0a..b93c9e4 100644 --- a/chapter1.doc +++ b/chapter1.doc - @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics - re going to cover how to get it and set it up for the first time if you don - t already have it on your system. - In Chapter Two we will go over basic Git usage - how to use Git for the 80% - -s going on, modify stuff and contribute changes. If the book spontaneously - +s going on, modify stuff and contribute changes. If the book spontaneously - +Let's see if this works. - -Git successfully and succinctly tells me that I added the string "Let’s see if this works", which is correct. It’s not perfect — it adds a bunch of random stuff at the end — but it certainly works. If you can find or write a Word-to-plain-text converter that works well enough, that solution will likely be incredibly effective. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats. + @@ -128,7 +128,7 @@ and data size) + Since its birth in 2005, Git has evolved and matured to be easy to use + and yet retain these initial qualities. It’s incredibly fast, it’s + very efficient with large projects, and it has an incredible branching + -system for non-linear development (See Chapter 3). + +system for non-linear development. + +Git successfully and succinctly tells me that I added the string "(See Chapter 3)", which is correct. Works perfectly! ##### OpenDocument Text files ##### From 5a43161e8900d758819a23f07e692ee9428fb37b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jukka=20Hyyti=C3=A4l=C3=A4?= Date: Sun, 28 Jul 2013 15:16:47 +0300 Subject: [PATCH 03/37] [fi] Completed Chapter 2.2 --- fi/02-git-basics/01-chapter2.markdown | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown index af9a9243c..b58c8fea0 100644 --- a/fi/02-git-basics/01-chapter2.markdown +++ b/fi/02-git-basics/01-chapter2.markdown @@ -389,15 +389,15 @@ Huomaa kenoviiva (`\`) `*`-merkin edessä. Windowsin järjestelmäkonsolissa ken Tämä komento poistaa kaikki tiedostot, jotka loppuvat `~`-merkkiin. -### Moving Files ### +### Tiedostojen siirtäminen ### -Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later. +Toisin kuin monet muut VCS-järjestelmät, Git ei jäljitä suoranaisesti tiedostojen siirtämistä. Jos nimeät tiedoston uudelleen Gitissä, Gitiin ei tallenneta metadataa, joka kertoo, että nimesit tiedoston uudelleen. Git on kuitenkin melko älykäs selvittämään sen myöhemmin — käsittelemme tiedostojen siirtämisen havaitsemista hieman myöhemmin. -Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like +Siksi on hieman sekavaa, että Gitissä on `mv`-komento. Jos haluat nimetä tiedoston uudelleen Gitissä, voit ajaa jotakuinkin seuraavasti - $ git mv file_from file_to + $ git mv lähdetiedosto kohdetiedosto -and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file: +ja se toimii hienosti. Itse asiassa, jos ajat jotakuinkin tällä tavalla ja katsot tilaa, näet Gitin pitävän sitä uudelleennimettynä tiedostona: $ git mv README.txt README $ git status @@ -410,13 +410,13 @@ and it works fine. In fact, if you run something like this and look at the statu # renamed: README.txt -> README # -However, this is equivalent to running something like this: +Tämä on kuitenkin sama, kuin ajaisit seuraavasti: $ mv README.txt README $ git rm README.txt $ git add README -Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +Git ymmärtää sen olevan uudelleennimeäminen epäsuorasti, joten ei ole väliä, nimeätkö tiedoston uudelleen tällä tavalla vai `mv`-komennolla. Ainoa todellinen ero on, että `mv` on yksi komento kolmen sijaan — se on helppokäyttötoiminto. Tärkeämpää, voit käyttää tiedoston uudelleennimeämiseen mitä työkalua haluat ja käsitellä add/rm myöhemmin, ennen kuin teet pysyvän muutoksen. ## Viewing the Commit History ## From 0e25baf3462dbfd2e09737207ee21c6e3ca55012 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 30 Jul 2013 22:50:29 +0200 Subject: [PATCH 04/37] Fail on REXML exceptions Maruku uses REXML internally to parse the xml/html snippets. But if the parsing fails, no error are generated and the task does not fail. Let the REXML exceptions appear when processing a file so as to validate html snippets also. --- Rakefile | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/Rakefile b/Rakefile index cdb55a1fa..03c0bb9e7 100644 --- a/Rakefile +++ b/Rakefile @@ -159,6 +159,15 @@ namespace :pdf do end end +class StderrDecorator + def <<(x) + $stderr<< "#{x}" + if x.match /REXML/ + raise "" + end + end +end + namespace :ci do desc "Continuous Integration" @@ -219,7 +228,7 @@ namespace :ci do end end begin - code = Maruku.new(mark, :on_error => :raise) + code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new) print "OK\n" rescue print "KO\n" From 0ac353d81d3440e7bfcf78da01231cf981f66db7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jukka=20Hyyti=C3=A4l=C3=A4?= Date: Thu, 1 Aug 2013 20:24:52 +0300 Subject: [PATCH 05/37] [fi] Translated Chapter 2.3 --- fi/02-git-basics/01-chapter2.markdown | 134 +++++++++++++------------- 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown index b58c8fea0..82bb71458 100644 --- a/fi/02-git-basics/01-chapter2.markdown +++ b/fi/02-git-basics/01-chapter2.markdown @@ -418,15 +418,15 @@ Tämä on kuitenkin sama, kuin ajaisit seuraavasti: Git ymmärtää sen olevan uudelleennimeäminen epäsuorasti, joten ei ole väliä, nimeätkö tiedoston uudelleen tällä tavalla vai `mv`-komennolla. Ainoa todellinen ero on, että `mv` on yksi komento kolmen sijaan — se on helppokäyttötoiminto. Tärkeämpää, voit käyttää tiedoston uudelleennimeämiseen mitä työkalua haluat ja käsitellä add/rm myöhemmin, ennen kuin teet pysyvän muutoksen. -## Viewing the Commit History ## +## Pysyvien muutosten historian tarkasteleminen ## -After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command. +Kun olet luonut useita pysyviä muutoksia tai kloonannut tietovaraston, jonka historiassa on pysyviä muutoksia, haluat todennäköisesti katsoa taaksepäin nähdäksesi, mitä on tapahtunut. Yksinkertaisin ja tehokkain työkalu tähän on `git log` -komento. -These examples use a very simple project called `simplegit` that I often use for demonstrations. To get the project, run +Nämä esimerkit käyttävät erittäin yksinkertaista projektia nimeltä `simplegit`, jota käytän useasti havainnollistamisessa. Saadaksesi projektin, aja git clone git://github.com/schacon/simplegit-progit.git -When you run `git log` in this project, you should get output that looks something like this: +Kun ajat `git log` tässä projektissa, sinun tulisi saada vastaavanlainen tuloste: $ git log commit ca82a6dff817ec66f44342007202690a93763949 @@ -447,11 +447,11 @@ When you run `git log` in this project, you should get output that looks somethi first commit -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and e-mail, the date written, and the commit message. +Oletuksena, ilman argumentteja, `git log` listaa tietovarastoon tehdyt pysyvät muutokset käänteisessä aikajärjestyksessä. Se tarkoittaa, että uusin pysyvä muutos tulee ensimmäiseksi. Kuten voit nähdä, tämä komento listaa kustakin pysyvästä muutoksesta sen SHA-1-tarkisteen, tekijän nimen ja sähköpostin, luontipäiväyksen sekä viestin. -A huge number and variety of options to the `git log` command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most-used options. +`Git log` -komennolle on saatavilla valtava määrä ja lajitelma optioita näyttääkseen sinulle tarkalleen etsimäsi. Näytämme tässä sinulle joitakin käytetyimpiä optioita. -One of the more helpful options is `-p`, which shows the diff introduced in each commit. You can also use `-2`, which limits the output to only the last two entries: +Yksi hyödyllisimmistä optioista on `-p`, joka näyttää kunkin pysyvän muutoksen eroavaisuuden. Voit myös käyttää `-2`, joka rajaa tulosteen ainoastaan kahteen viimeisimpään kirjaukseen: $ git log -p -2 commit ca82a6dff817ec66f44342007202690a93763949 @@ -493,9 +493,9 @@ One of the more helpful options is `-p`, which shows the diff introduced in each -end \ No newline at end of file -This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. +Tämä optio näyttää saman informaation, mutta jokaista kirjausta seuraavalla eroavaisuudella. Tämä on erittäin hyödyllinen koodin katselmoinnissa tai nopeasti tarkistettaessa, mitä tapahtui pysyvien muutosten sarjassa, jonka työtoveri on lisännyt. -Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example: +Joskus on helpompaa katselmoida muutoksia sanatasolla kuin rivitasolla. Gitissä on saatavilla `--word-diff`-optio, jonka voit lisätä `git log -p` -komentoon saadaksesi sanatason eroavaisuuden normaalin rivitasoisen eroavaisuuden sijaan. Sanatason eroavaisuuden formaatti on melko hyödytön käytettäessä sitä lähdekoodiin, mutta siitä tulee kätevä käytettäessä sitä isoihin tekstitiedostoihin, kuten kirjoihin tai väitöskirjaasi. Tässä on esimerkki: $ git log -U1 --word-diff commit ca82a6dff817ec66f44342007202690a93763949 @@ -513,9 +513,9 @@ Sometimes it's easier to review changes on the word level rather than on the lin s.version = [-"0.1.0"-]{+"0.1.1"+} s.author = "Scott Chacon" -As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above. +Kuten voit nähdä, tässä tulosteessa ei ole lisättyjä ja poistettuja rivejä, kuten normaalissa eroavaisuudessa. Muutokset esitetään sen sijaan rivin sisällä. Voit nähdä lisätyn sanan ympäröitynä `{+ +}` -merkeillä ja poistetun ympäröitynä `[- -]` -merkeillä. Voit myös haluta vähentää tavallisen kolmen rivin kontekstin eroavaisuustulosteessa vain yhden rivin kontekstiksi, koska asiayhteys on nyt sanatasolla ei rivitasolla. Voit tehdä tämän `-U1`-optiolla, kuten teimme esimerkissä yläpuolella. -You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +Voit myös käyttää yhteenveto-optioiden sarjaa `git log`in kanssa. Esimerkiksi, jos haluat nähdä hieman lyhennettyjä tilastoja kustakin pysyvästä muutoksesta, voit käyttää `--stat`-optiota: $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 @@ -547,48 +547,48 @@ You can also use a series of summarizing options with `git log`. For example, if lib/simplegit.rb | 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 0 deletions(-) -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end. -Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +Kuten voit nähdä, `--stat`-optio tulostaa kunkin pysyvän muutoksen alapuolelle listan muokatuista tiedostoista, kuinka montaa tiedostoa muutettiin ja kuinka monta riviä lisättiin ja poistettiin näissä tiedostoissa. Se esittää myös lopuksi yhteenvedon tiedoista. +Toinen todella hyödyllinen optio on `--pretty`. Tämä optio muuttaa lokitulosteen oletuksesta poikkeaviin muotoihin. Saatavilla on muutama esikäännetty optio käytettäväksesi. `Oneline`-optio tulostaa kunkin pysyvän muutoksen yhdelle riville, mikä on hyödyllistä, jos katselet monia pysyviä muutoksia. Lisäksi `short`-, `full`- ja `fuller`-optiot näyttävät tulosteen karkeasti ottaen alkuperäisessä muodossa, mutta vastaavasti vähemmillä tai enemmillä tiedoilla: $ git log --pretty=oneline ca82a6dff817ec66f44342007202690a93763949 changed the version number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code a11bef06a3f659402fe7563abf99ad00de2209e6 first commit -The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git: +Kiinnostavin optio on `format`, joka antaa sinun määritellä oman formaatin lokitulosteelle. Tämä on hyödyllinen varsinkin, kun luot tulostetta koneellista parsimista varten — koska sinä määrittelet formaatin eksplisiittisesti, tiedät, ettei se muutu Gitin päivitysten myötä: $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 11 months ago : changed the version number 085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code a11bef0 - Scott Chacon, 11 months ago : first commit -Table 2-1 lists some of the more useful options that format takes. +Taulukko 2-1 listaa joitakin hyödyllisempiä optioita, joita format hyväksyy. - Option Description of Output - %H Commit hash - %h Abbreviated commit hash - %T Tree hash - %t Abbreviated tree hash - %P Parent hashes - %p Abbreviated parent hashes - %an Author name - %ae Author e-mail - %ad Author date (format respects the --date= option) - %ar Author date, relative - %cn Committer name - %ce Committer email - %cd Committer date - %cr Committer date, relative - %s Subject - -You may be wondering what the difference is between _author_ and _committer_. The _author_ is the person who originally wrote the patch, whereas the _committer_ is the person who last applied the patch. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in *Chapter 5*. - -The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see in our copy of the Grit project repository: + Optio Tulosteen kuvaus + %H Pysyvän muutoksen tarkiste + %h Lyhennetty pysyvän muutoksen tarkiste + %T Puun tarkiste + %t Lyhennetty puun tarkiste + %P Vanhempien tarkisteet + %p Lyhennetyt vanhempien tarkisteet + %an Tekijän nimi + %ae Tekijän sähköpostiosoite + %ad Tekijän päiväys (muoto riippuu --date=-optiosta) + %ar Tekijän päiväys, suhteellinen + %cn Hyväksyjän nimi + %ce Hyväksyjän sähköpostiosoite + %cd Hyväksyjän päiväys + %cr Hyväksyjän päiväys, suhteellinen + %s Aihe + +Saatat ihmetellä, mitä eroa on _tekijällä_ ja _hyväksyjällä_. _Tekijä_ on henkilö, joka alunperin kirjoitti muutoksen, kun taas _hyväksyjä_ on henkilö, joka lopulta otti muutoksen käyttöön. Joten, jos sinä lähetät muutoksen projektiin ja joku ydinjäsenistä ottaa muutoksen käyttöön, te saatte molemmat kunniaa — sinä tekijänä ja ydinjäsen hyväksyjänä. Käsittelemme tätä eroa enemmän *Luvussa 5*. + +`Oneline`- ja `format`-optiot ovat erityisen hyödyllisiä yhdessä toisen `--graph`-nimisen `log`-komennon option kanssa. Tämä optio lisää kivan pienen ASCII-kaavion esittämään haarasi ja yhdistämisten historiaa, jonka voimme nähdä Grit-projektin tietovaraston kopiossamme: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap @@ -602,55 +602,55 @@ The `oneline` and `format` options are particularly useful with another `log` op * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local -Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the `log` command. +Ne ovat vain joitakin yksinkertaisia tulosteenmuotoiluoptioita `git log`ille — monia muitakin on olemassa. Taulukko 2-2 listaa optiot, jotka olemme käsitelleet tähän mennessä sekä joitakin muita yleisiä muotoiluoptioita, jotka voivat olla hyödyllisiä, yhdessä sen kanssa, miten ne muuttavat `log`-komennon tulostetta. - Option Description - -p Show the patch introduced with each commit. - --word-diff Show the patch in a word diff format. - --stat Show statistics for files modified in each commit. - --shortstat Display only the changed/insertions/deletions line from the --stat command. - --name-only Show the list of files modified after the commit information. - --name-status Show the list of files affected with added/modified/deleted information as well. - --abbrev-commit Show only the first few characters of the SHA-1 checksum instead of all 40. - --relative-date Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format. - --graph Display an ASCII graph of the branch and merge history beside the log output. - --pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). - --oneline A convenience option short for `--pretty=oneline --abbrev-commit`. + Optio Kuvaus + -p Näyttää tehdyt muutokset kunkin pysyvän muutoksen yhteydessä. + --word-diff Näyttää tehdyt muutokset sanatason eroavaisuuksina. + --stat Näyttää kussakin pysyvässä muutoksessa muutetuista tiedostoista tilaston. + --shortstat Näyttää vain muuttuneet/lisätyt/poistetut-rivin –stat-komennosta. + --name-only Näyttää muutettujen tiedostojen listan pysyvän muutoksen tietojen jälkeen. + --name-status Näyttää lisäksi listan vaikutetuista tiedostoista lisätty/muokattu/poistettu-tiedon kera. + --abbrev-commit Näyttää vain muutaman ensimmäisen merkin SHA-1-tarkistesummasta kaikkien 40 merkin sijaan. + --relative-date Näyttää päiväykset suhteellisessa muodossa (esimerkiksi, ”2 viikkoa sitten”) täyden päiväysmuotoilun käyttämisen sijaan. + --graph Näyttää ASCII-kaavion haarasi ja yhdistämisten historiasta lokitulosteen vieressä. + --pretty Näyttää pysyvät muutokset vaihtoehtoisessa muodossa. Vaihtoehtoihin kuuluu oneline, short, full, fuller ja format (jossa voit määritellä oman muotoilusi). + --oneline Helppokäyttöoptio `--pretty=oneline –abbrev-commit`ille. -### Limiting Log Output ### +### Tulosteen rajaaminen ### -In addition to output-formatting options, `git log` takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which shows only the last two commits. In fact, you can do `-`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +Lisäyksenä tulosteen muotoiluoptioihin, `git log` hyväksyy useita hyödyllisiä rajaamisoptioita — optioita, jotka antavat sinun näyttää vain osajoukon pysyvistä muutoksista. Olet nähnyt yhden sellaisen option ennestään — `-2`-option, joka näyttää vain kaksi viimeisintä pysyvää muutosta. Itse asiassa, voit käyttää `-`:tä, jossa `n` on mikä tahansa kokonaisluku näyttääksesi viimeiset `n` pysyvää muutosta. Todellisuudessa käytät sitä epätodennäköisesti usein, koska oletuksena Git putkittaa kaiken tulosteen sivuttajan läpi, joten näet vain yhden sivun lokitulosteesta kerralla. -However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks: +Aikarajausoptiot, kuten `--since` ja `--until`, ovat kuitenkin erittäin hyödyllisiä. Esimerkiksi tämä komento hakee listan pysyvistä muutoksista, jotka on tehty kahden viimeisen viikon aikana. $ git log --since=2.weeks -This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”. +Tämä komento toimii useilla muodoilla — voit määritellä tietyn päivämäärän (”15. 1. 2008”) tai suhteellisen päiväyksen, kuten ”2 vuotta 1 päivä ja 3 minuuttia sitten”. -You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.) +Voit myös suodattaa listan pysyviin muutoksiin, joihin sopii jokin hakukriteeri. `--author`-optio antaa sinun suodattaa tietyllä tekijällä ja `--grep`-optio etsiä avainsanoja pysyvän muutoksen viestistä (Huomaa, että jos haluat määritellä sekä tekijä- että grep-optiot, täytyy sinun lisätä `--all-match` tai komento sopii pysyviin muutoksiin, jotka täyttävät vain toisen ehdon.) -The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +Viimeinen todella hyödyllinen `git log`ille suodattimena annettava optio on hakemistopolku (path). Jos määrittelet hakemiston tai tiedoston nimen, voit rajata lokitulosteen pysyviin muutoksiin, jotka esittelivät muutokset niihin tiedostoihin. Tämä on aina viimeinen optio ja yleensä varustettu kahden viivan (`--`) etuliitteellä, jotta hakemistopolut erotettaisiin optioista. -In Table 2-3 we’ll list these and a few other common options for your reference. +Taulukossa 2-3 listaamme nämä ja muutaman muun yleisen option referenssiksesi. - Option Description - -(n) Show only the last n commits - --since, --after Limit the commits to those made after the specified date. - --until, --before Limit the commits to those made before the specified date. - --author Only show commits in which the author entry matches the specified string. - --committer Only show commits in which the committer entry matches the specified string. + Optio Kuvaus + -(n) Näyttää vain viimeisimmät n pysyvää muutosta + --since, --after Rajaa pysyvät muutokset tietyn päivämäärän jälkeen tehtyihin. + --until, --before Rajaa pysyvät muutokset tiettyä päivämäärää ennen tehtyihin. + --author Näyttää vain pysyvät muutokset, joiden tekijämerkintä sopii tiettyyn merkkijonoon. + --committer Näyttää vain pysyvät muutokset, joiden hyväksyjämerkintä sopii tiettyyn merkkijonoon. -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and were not merges, you can run something like this: +Esimerkiksi, jos haluat nähdä, mitkä testitiedostoja muokanneet pysyvät muutokset Gitin lähdekoodihistoriassa Junio Hamano teki lokakuussa 2008, joita ei ole yhdistetty, voit ajaa jotakuinkin seuraavasti: $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ @@ -661,16 +661,16 @@ For example, if you want to see which commits modifying test files in the Git so 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur -Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria. +Tämä komento näyttää melkein 20 000 pysyvän muutoksen Gitin lähdekoodihistoriasta 6 näihin ehtoihin sopivaa pysyvää muutosta. -### Using a GUI to Visualize History ### +### GUI:n käyttäminen historian visualisointiin ### -If you like to use a more graphical tool to visualize your commit history, you may want to take a look at a Tcl/Tk program called `gitk` that is distributed with Git. Gitk is basically a visual `git log` tool, and it accepts nearly all the filtering options that `git log` does. If you type `gitk` on the command line in your project, you should see something like Figure 2-2. +Jos haluat käyttää graafisempaa työkalua visualisoidaksesi pysyvien muutosten historiaasi, voit haluta katsoa `gitk`:ksi kutsuttua Tcl/Tk-ohjelmaa, jota levitetään Gitin kanssa. Gitk on periaatteessa visuaalinen `git log` -työkalu ja se hyväksyy lähes kaikki suodatusoptiot, joita `git log`kin hyväksyy. Jos kirjoitat projektissasi komentoriville `gitk`, sinun pitäisi saada Kuvaa 2-2 vastaava tulos. Insert 18333fig0202.png -Figure 2-2. The gitk history visualizer. +Kuva 2-2. Gitk -historian visualisoija. -You can see the commit history in the top half of the window along with a nice ancestry graph. The diff viewer in the bottom half of the window shows you the changes introduced at any commit you click. +Voit nähdä pysyvien muutosten historian ikkunan ylemmässä puoliskossa yhdessä kivan syntyperäkaavion kanssa. Vertailuohjelma ikkunan alemmassa puoliskossa näyttää sinulle napsauttamassasi pysyvässä muutoksessa esitellyt muutokset. ## Undoing Things ## From 904900603903245188af3b943d64ffc86ef13113 Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Sun, 4 Aug 2013 12:49:17 +0400 Subject: [PATCH 06/37] [ru] chapter 4: Improve wording in "Git Daemon" section --- ru/04-git-server/01-chapter4.markdown | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown index f79fbbdd3..4d4cf4ee1 100644 --- a/ru/04-git-server/01-chapter4.markdown +++ b/ru/04-git-server/01-chapter4.markdown @@ -649,17 +649,17 @@ Gitolite позволяет указывать репозитории с пом ## Git-демон ## -Для публичного неаутентифицированного доступа на чтение к вашим проектам вы можете захотеть продвинуться дальше, чем протокол HTTP, и начать использовать Git-протокол. Главная причина — скорость. Git-протокол гораздо эффективнее и поэтому быстрее чем HTTP, поэтому, используя его, вы можете сэкономить вашим пользователям время. +Для предоставления публичного неаутентифицируемого доступа на чтение к своим проектам стоит продвинуться дальше, чем протокол HTTP, и начать использовать Git-протокол. Основное его преимущество — скорость. Git-протокол гораздо эффективнее и следовательно быстрее чем HTTP, поэтому, используя его, вы можете сэкономить своим пользователям время. -Повторимся, это для доступа только на чтение без аутентификации. Если вы запустите его на сервере не за сетевым экраном, он должен использоваться только для проектов, которые публично видны внешнему миру. Если сервер, на котором вы его запускаете, находится за вашим сетевым экраном, вы можете использовать его для проектов, к которым большое число людей или компьютеров (серверов непрерывной интеграции или сборки) должно иметь доступ только на чтение, и если вы не хотите для каждого из них заводить SSH-ключ. +Напомним, что он годится только для доступа на чтение без аутентификации. Если вы запустили его на сервере не загороженном сетевым экраном, то он должен использоваться только для проектов, которые публично видны внешнему миру. Если сервер, на котором вы его запускаете, находится за сетевым экраном, тогда его вполне можно использовать для проектов, к которым нужно иметь доступ только на чтение для большого числа людей или компьютеров (серверов непрерывной интеграции или сборки), если вы не хотите для каждого из них заводить свой SSH-ключ. -В любом случае, Git-протокол относительно просто настроить. Упрощённо, вам нужно запустить следующую команду в демонизированной форме: +В любом случае, Git-протокол относительно просто настроить. По сути, вам нужно запустить следующую команду в демонизированной форме: git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ -`--reuseaddr` позволит серверу перезапуститься без ожидания истечения старых подключений, `--base-path` позволит людям не указывать полный путь, чтобы склонировать проект, а путь на конце говорит Git-демону, где искать экспортируемые репозитории. Если у вас запущен сетевой экран, вы должны проколоть в нём дырочку, открыв порт 9418 на машине, на которой это всё запущено. +Опция `--reuseaddr` позволит серверу перезапускаться без ожидания окончания старых соединений, `--base-path` позволит людям не указывать полный путь при клонировании проекта, а путь в конце говорит Git-демону, где искать экспортируемые репозитории. Если у вас запущен сетевой экран, то ещё необходимо проделать в нём дырочку, открыв порт 9418 на машине, на которой это всё запущено. -Вы можете демонизировать этот процесс несколькими путями, в зависимости от операционной системы. На машине с Ubuntu используйте Upstart-сценарий. Итак, в этом файле +Вы можете демонизировать этот процесс несколькими путями, в зависимости от операционной системы. На машине с Ubuntu используйте Upstart-сценарий. Итак, в этот файл /etc/event.d/local-git-daemon @@ -674,27 +674,27 @@ Gitolite позволяет указывать репозитории с пом /opt/git/ respawn -По соображениям безопасности крайне приветствуется, если вы будете запускать этого демона как пользователя с правами только на чтение на репозитории — вы легко можете сделать это, создав пользователя 'git-ro' и запустив этого демона из-под него. Для простоты мы запустим его от того же пользователя 'git', от которого запущен Gitosis. +По соображениям безопасности крайне желательно, чтобы вы запускали этот демон от пользователя с правами только на чтение на репозитории — вы легко можете сделать это, создав пользователя 'git-ro' и запустив этот демон из-под него. Для простоты мы запустим его от того же пользователя 'git', от которого запущен Gitosis. Когда вы перезапустите машину, Git-демон запустится автоматически, и возродится, если вдруг завершится. Чтобы запустить его без перезагрузки машины, выполните следующее: initctl start local-git-daemon -На других системах вы можете использовать `xinetd`, сценарий вашей системы `sysvinit`, или что-то другое — главное, чтобы вы могли эту команду как-либо демонизировать и перезапускать в случае завершения. +На других системах вы можете использовать `xinetd`, сценарий для системы `sysvinit`, или что-то другое — главное, чтобы вы могли эту команду как-либо демонизировать и перезапускать в случае завершения. -Затем, вы должны указать Gitosis-серверу, к каким репозиториям предоставить неаутентифицированный доступ через Git-сервер. Если вы добавили по секции для каждого репозитория, вы можете указать, из каких из них Git-демону позволено читать. Если вы хотите предоставить доступ через Git-протокол к `iphone_project`, добавьте это в конец вашего файла `gitosis.conf`: +Затем, вы должны указать Gitosis-серверу, к каким репозиториям предоставить неаутентифицируемый доступ через Git-сервер. Если вы добавили по секции для каждого репозитория, вы можете указать, из каких из них Git-демону позволено читать. Если вы хотите предоставить доступ по Git-протоколу к `iphone_project`, добавьте следующее в конец своего файла `gitosis.conf`: [repo iphone_project] daemon = yes Когда это зафиксировано и отправлено, ваш запущенный демон должен начать обслуживать запросы к проекту от всех, у кого есть доступ к порту 9418 на вашем сервере. -Если вы решили не использовать Gitosis, но хотите установить Git-демон, вы должны выполнить следующее в каждом проекте, который должен обслуживаться Git-демоном: +Если вы решили не использовать Gitosis, но хотите установить Git-демон, вам необходимо выполнить следующее в каждом проекте, который должен обслуживаться Git-демоном: $ cd /path/to/project.git $ touch git-daemon-export-ok -Наличие этого файла скажет Git'у, что можно обслуживать этот проект без аутентификации. +Наличие этого файла скажет Git'у, что этот проект можно обслуживать без аутентификации. Gitosis также может контролировать, какие проекты будет показывать GitWeb. Вам нужно добавить что-то вроде этого в файл `/etc/gitweb.conf`: @@ -703,7 +703,7 @@ Gitosis также может контролировать, какие прое $export_ok = "git-daemon-export-ok"; @git_base_url_list = ('git://gitserver'); -Вы можете контролировать, какие проекты GitWeb будет позволять просматривать пользователям, добавляя или удаляя пункт настройки `gitweb` в конфигурационном файле Gitosis'а. Например, если вы хотите, чтобы `iphone_project` просматривался в GitWeb, сделайте, чтобы секция настроек `repo` выглядела следующим образом: +Вы можете контролировать, какие проекты GitWeb будет позволять просматривать пользователям, добавляя или удаляя пункт настройки `gitweb` в конфигурационном файле Gitosis'а. Например, если вы хотите, чтобы `iphone_project` просматривался в GitWeb, сделайте так, чтобы секция настроек `repo` выглядела следующим образом: [repo iphone_project] daemon = yes From 51e009b90a6718ba6dc1d927ea06ec2cab056071 Mon Sep 17 00:00:00 2001 From: sekai Date: Fri, 9 Aug 2013 21:25:53 +0900 Subject: [PATCH 07/37] =?UTF-8?q?update=20typo=20=E6=B3=A8=E6=84=8F?= =?UTF-8?q?=E3=81=97=E3=81=AA=E3=81=91=E3=82=8C=E3=81=B0=E3=81=AA=E3=82=89?= =?UTF-8?q?=E3=81=84=E3=81=AE=E3=81=AF=20->=E6=B3=A8=E6=84=8F=E7=82=B9?= =?UTF-8?q?=E3=81=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ja/02-git-basics/01-chapter2.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown index 1940d48d6..80c7407d5 100755 --- a/ja/02-git-basics/01-chapter2.markdown +++ b/ja/02-git-basics/01-chapter2.markdown @@ -672,7 +672,7 @@ Insert 18333fig0202.png ## 作業のやり直し ## -どんな場面であっても、何かをやり直したくなることはあります。ここでは、行った変更を取り消すための基本的なツールについて説明します。注意しなければならいのは、ここで扱う内容の中には「やり直しの取り消し」ができないものもあるということです。Git で何か間違えたときに作業内容を失ってしまう数少ない例がここにあります。 +どんな場面であっても、何かをやり直したくなることはあります。ここでは、行った変更を取り消すための基本的なツールについて説明します。注意点は、ここで扱う内容の中には「やり直しの取り消し」ができないものもあるということです。Git で何か間違えたときに作業内容を失ってしまう数少ない例がここにあります。 ### 直近のコミットの変更 ### From e6a412e990fc9cf6296e122d2e09af6198a3b4d1 Mon Sep 17 00:00:00 2001 From: sekai Date: Fri, 9 Aug 2013 21:32:55 +0900 Subject: [PATCH 08/37] =?UTF-8?q?update=20typo=20=E8=AA=B0=E3=81=8B?= =?UTF-8?q?=E3=81=A8=E3=81=8B=E3=81=AE=E4=BA=BA=20->=20=E8=AA=B0=E3=81=8B?= =?UTF-8?q?=E3=81=BB=E3=81=8B=E3=81=AE=E4=BA=BA?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ja/03-git-branching/01-chapter3.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown index 69a657541..f61f7a2d1 100644 --- a/ja/03-git-branching/01-chapter3.markdown +++ b/ja/03-git-branching/01-chapter3.markdown @@ -379,7 +379,7 @@ Insert 18333fig0321.png リモートブランチは、リモートリポジトリ上のブランチの状態を指すものです。ネットワーク越しの操作をしたときに自動的に移動します。リモートブランチは、前回リモートリポジトリに接続したときにブランチがどの場所を指していたかを示すブックマークのようなものです。 -ブランチ名は `(remote)/(branch)` のようになります。たとえば、`origin` サーバーに最後に接続したときの `master` ブランチの状態を知りたければ `origin/master` ブランチをチェックします。誰かとかの人と共同で問題に対応しており、相手が `iss53` ブランチにプッシュしたとしましょう。あなたの手元にはローカルの `iss53` ブランチがあります。しかし、サーバー側のブランチは `origin/iss53` のコミットを指しています。 +ブランチ名は `(remote)/(branch)` のようになります。たとえば、`origin` サーバーに最後に接続したときの `master` ブランチの状態を知りたければ `origin/master` ブランチをチェックします。誰かほかの人と共同で問題に対応しており、相手が `iss53` ブランチにプッシュしたとしましょう。あなたの手元にはローカルの `iss53` ブランチがあります。しかし、サーバー側のブランチは `origin/iss53` のコミットを指しています。 ……ちょっと混乱してきましたか? では、具体例で考えてみましょう。ネットワーク上の `git.ourcompany.com` に Git サーバーがあるとします。これをクローンすると、Git はそれに `origin` という名前をつけ、すべてのデータを引き出し、`master` ブランチを指すポインタを作成し、そのポインタにローカルで `origin/master` という名前をつけます。それを自分で移動させることはできません。Ｇit はまた、`master` というブランチも作成します。これは origin の `master` ブランチと同じ場所を指しており、ここから何らかの作業を始めます (図 3-22 を参照ください)。 From 93983e6113d418f35ad6f59ec906d42255f28ad0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jukka=20Hyyti=C3=A4l=C3=A4?= Date: Sat, 10 Aug 2013 13:07:30 +0300 Subject: [PATCH 09/37] [fi] Translated Chapter 2.4 --- fi/02-git-basics/01-chapter2.markdown | 36 +++++++++++++-------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown index 63b21a760..7a19a5f8d 100644 --- a/fi/02-git-basics/01-chapter2.markdown +++ b/fi/02-git-basics/01-chapter2.markdown @@ -672,31 +672,31 @@ Kuva 2-2. Gitk -historian visualisoija. Voit nähdä pysyvien muutosten historian ikkunan ylemmässä puoliskossa yhdessä kivan syntyperäkaavion kanssa. Vertailuohjelma ikkunan alemmassa puoliskossa näyttää sinulle napsauttamassasi pysyvässä muutoksessa esitellyt muutokset. -## Undoing Things ## +## Asioiden kumoaminen ## -At any stage, you may want to undo something. Here, we’ll review a few basic tools for undoing changes that you’ve made. Be careful, because you can’t always revert some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong. +Saatat haluta kumota jotain missä tahansa työvaiheessa. Esittelemme tässä muutaman perustyökalun tekemiesi muutosten kumoamiseen. Ole huolellinen, koska et voi aina peruuttaa joitakin näistä kumoamisista. Tämä on yksi muutamasta alueesta Gitissä, joissa voit menettää jonkin verran työtä, jos teet sen väärin. -### Changing Your Last Commit ### +### Viimeisimmän pysyvän muutoksen muuttaminen ### -One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the `--amend` option: +Yksi yleinen kumoaminen tapahtuu, kun teet pysyvän muutoksen liian aikaisin ja mahdollisesti unohdat lisätä joitakin tiedostoja tai sähläät pysyvän muutoksen viestin kanssa. Jos haluat yrittää pysyvää muutosta uudestaan, voit tehdä pysyvän muutoksen `--amend`-optiolla: $ git commit --amend -This command takes your staging area and uses it for the commit. If you’ve made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same and all you’ll change is your commit message. +Tämä komento ottaa lavastusalueesi ja käyttää sitä pysyvään muutokseen. Jos et ole tehnyt muutoksia viimeisimmän pysyvän muutoksesi jälkeen (esimerkiksi, jos ajat tämän komennon heti edellisen pysyvän muutoksesi jälkeen), tilannekuvasi näyttää tarkalleen samalta ja kaikki, mitä muutat, on pysyvän muutoksesi viesti. -The same commit-message editor fires up, but it already contains the message of your previous commit. You can edit the message the same as always, but it overwrites your previous commit. +Sama pysyvän muutoksen viestin editori aktivoituu, mutta se sisältää jo viestin edellisestä pysyvästä muutoksesta. Voit muokata viestiä samoin kuin aina, mutta se korvaa edellisen pysyvän muutoksesi. -As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: +Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi lavastaa muutokset tiedostossa, jonka haluat lisätä tähän pysyvään muutokseen, voit tehdä jotakuinkin seuraavasti: $ git commit -m 'initial commit' - $ git add forgotten_file + $ git add unohtunut_tiedosto $ git commit --amend -After these three commands, you end up with a single commit — the second commit replaces the results of the first. +Näiden kolmen komennon jälkeen päädyt yhteen pysyvään muutokseen — toinen pysyvä muutos korvaa ensimmäisen. -### Unstaging a Staged File ### +### Lavastetun tiedoston lavastuksen purkaminen ### -The next two sections demonstrate how to wrangle your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let’s say you’ve changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. How can you unstage one of the two? The `git status` command reminds you: +Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia lavastusalueellasi ja työskentelyhakemistossasi. Mukava osa on, että komento, jota käytät selvittääksesi näiden kahden alueen tilan, muistuttaa sinua myös, kuinka peruuttaa muutokset niihin. Sanokaamme, esimerkiksi, että olet muuttanut kahta tiedostoa ja haluat tehdä niistä kaksi erillistä pysyvää muutosta, mutta kirjoitit vahingossa `git add *` ja lavastit ne molemmat. Kuinka voit purkaa toisen lavastuksen? `Git status` -komento muistuttaa sinua: $ git add . $ git status @@ -708,7 +708,7 @@ The next two sections demonstrate how to wrangle your staging area and working d # modified: benchmarks.rb # -Right below the “Changes to be committed” text, it says "use `git reset HEAD ...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file: +Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD ...` to unstage". Joten, käyttäkäämme tätä neuvoa purkaaksemme `benchmarks.rb`-tiedoston lavastuksen: $ git reset HEAD benchmarks.rb benchmarks.rb: locally modified @@ -726,11 +726,11 @@ Right below the “Changes to be committed” text, it says "use `git reset HEAD # modified: benchmarks.rb # -The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged. +Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muokattu mutta lavastamaton jälleen. -### Unmodifying a Modified File ### +### Muutetun tiedoston muutosten kumoaminen ### -What if you realize that you don’t want to keep your changes to the `benchmarks.rb` file? How can you easily unmodify it — revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, `git status` tells you how to do that, too. In the last example output, the unstaged area looks like this: +Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Jälkimmäisessä esimerkkitulosteessa lavastamaton alue näyttää tältä: # Changes not staged for commit: # (use "git add ..." to update what will be committed) @@ -739,7 +739,7 @@ What if you realize that you don’t want to keep your changes to the `benchmark # modified: benchmarks.rb # -It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do this — if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says: +Se kertoo sinulle melko selvästi, kuinka hylätä tekemäsi muutokset (ainakin Gitin uudemmat versiot, 1.6.1 ja uudemmat, tekevät tämän — jos sinulla on vanhempi versio, suosittelemme lämpimästi sen päivittämistä saadaksesi joitakin näistä mukavammista käytettävyysominaisuuksista). Tehkäämme kuten se sanoo: $ git checkout -- benchmarks.rb $ git status @@ -750,9 +750,9 @@ It tells you pretty explicitly how to discard the changes you’ve made (at leas # modified: README.txt # -You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go. +Voit nähdä, että muutokset on peruutettu. Sinun tulisi myös ymmärtää, että tämä on vaarallinen komento: kaikki tähän tiedostoon tekemäsi muutokset ovat mennyttä — kopioit juuri toisen tiedoston sen päälle. Älä koskaan käytä tätä komentoa ellet ehdottomasti tiedä, ettet halua säilyttää tiedostoa. Jos sinun täytyy ainoastaan saada se pois tieltä, käymme läpi kätkemisen ja haarautumisen seuraavassa luvussa; ne ovat usein parempia tapoja toimia. -Remember, anything that is committed in Git can almost always be recovered. Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see *Chapter 9* for data recovery). However, anything you lose that was never committed is likely never to be seen again. +Muista, että kaikki, mistä on tehty pysyvä muutos Gitiin, voidaan melkein aina palauttaa. Jopa poistetuissa haaroissa olleet tai `--amend`-optiolla ylikirjoitetut pysyvät muutokset voidaan palauttaa (katso *Luku 9* datan palauttamiseksi). Kuitenkin, mitään, minkä hävität ja mistä ei ole tehty pysyvää muutosta, ei nähdä todennäköisesti koskaan uudelleen. ## Working with Remotes ## From 9c11655aee54b6428678ae9c37f056b2e6bfadc5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jukka=20Hyyti=C3=A4l=C3=A4?= Date: Sat, 10 Aug 2013 16:19:29 +0300 Subject: [PATCH 10/37] [fi] Made some improvements in Chapter 2.4 --- fi/02-git-basics/01-chapter2.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown index 7a19a5f8d..f5c7f1ab0 100644 --- a/fi/02-git-basics/01-chapter2.markdown +++ b/fi/02-git-basics/01-chapter2.markdown @@ -678,7 +678,7 @@ Saatat haluta kumota jotain missä tahansa työvaiheessa. Esittelemme tässä mu ### Viimeisimmän pysyvän muutoksen muuttaminen ### -Yksi yleinen kumoaminen tapahtuu, kun teet pysyvän muutoksen liian aikaisin ja mahdollisesti unohdat lisätä joitakin tiedostoja tai sähläät pysyvän muutoksen viestin kanssa. Jos haluat yrittää pysyvää muutosta uudestaan, voit tehdä pysyvän muutoksen `--amend`-optiolla: +Yksi yleinen kumoaminen tapahtuu, kun teet pysyvän muutoksen liian aikaisin ja mahdollisesti unohdat lisätä joitakin tiedostoja tai sähläät pysyvän muutoksen viestin kanssa. Jos haluat yrittää tehdä pysyvää muutosta uudestaan, voit tehdä sen `--amend`-optiolla: $ git commit --amend @@ -730,7 +730,7 @@ Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muok ### Muutetun tiedoston muutosten kumoaminen ### -Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Jälkimmäisessä esimerkkitulosteessa lavastamaton alue näyttää tältä: +Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Edellisessä esimerkkitulosteessa lavastamaton alue näyttää tältä: # Changes not staged for commit: # (use "git add ..." to update what will be committed) From 1f7e5dc77abfc7c3f7caf140412fa7a244b117bc Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 13 Aug 2013 14:34:33 +0200 Subject: [PATCH 11/37] makeebooks with translation of "Figure" for cs --- makeebooks | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/makeebooks b/makeebooks index 7f73b5969..4c15b8be1 100755 --- a/makeebooks +++ b/makeebooks @@ -4,7 +4,7 @@ # formats supported with calibre (http://calibre-ebook.com) # # Samples: -# +# # Build e-book for amazon kindle for english and russian languages # $ ruby makeebooks en ru # or @@ -78,7 +78,11 @@ ARGV.each do |lang| elsif lang == 'pl' figure_title = 'Rysunek' book_title = 'Pro Git — profesjonalna kontrola wersji' - comments = 'udostępnione na licencji Creative Commons Attribution-Non Commercial-Share Alike 3.0 license' + comments = 'udostępnione na licencji Creative Commons Attribution-Non Commercial-Share Alike 3.0 license' + elsif lang == 'cs' + figure_title = 'Obrázek' + book_title = 'Pro Git — profesionální správa verzí' + comments = 'Licence: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license' end book_content = %(#{book_title}) From 0caa5da50e98271eb40c525a4ea7b121cacef7a9 Mon Sep 17 00:00:00 2001 From: Petr Prikryl Date: Tue, 13 Aug 2013 14:46:22 +0200 Subject: [PATCH 12/37] =?UTF-8?q?[cs]=20"Figure"=20before=20the=20fig.=20n?= =?UTF-8?q?umbers=20replaced=20by=20the=20localized=20"Obr=C3=A1zek"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- cs/01-introduction/01-chapter1.markdown | 14 ++-- cs/02-git-basics/01-chapter2.markdown | 4 +- cs/03-git-branching/01-chapter3.markdown | 78 +++++++++++----------- cs/04-git-server/01-chapter4.markdown | 30 ++++----- cs/05-distributed-git/01-chapter5.markdown | 54 +++++++-------- cs/06-git-tools/01-chapter6.markdown | 2 +- cs/07-customizing-git/01-chapter7.markdown | 6 +- cs/09-git-internals/01-chapter9.markdown | 8 +-- 8 files changed, 98 insertions(+), 98 deletions(-) diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown index c02e6b3e1..44fdd2521 100644 --- a/cs/01-introduction/01-chapter1.markdown +++ b/cs/01-introduction/01-chapter1.markdown @@ -15,7 +15,7 @@ Uživatelé často provádějí správu verzí tím způsobem, že zkopírují s Aby se uživatelé tomuto riziku vyhnuli, vyvinuli programátoři už před dlouhou dobou lokální systémy VCS s jednoduchou databází, která uchovávala všechny změny souborů s nastavenou správou revizí (viz obrázek 1-1). Insert 18333fig0101.png -Figure 1-1. Diagram lokální správy verzí +Obrázek 1-1. Diagram lokální správy verzí Jedním z velmi oblíbených nástrojů VCS byl systém s názvem rcs, který je ještě dnes distribuován s mnoha počítači. Dokonce i populární operační systém Mac OS X obsahuje po nainstalování vývojářských nástrojů (Developer Tools) příkaz rcs. Tento nástroj pracuje na tom principu, že na disku uchovává ve speciálním formátu seznam změn mezi jednotlivými verzemi. Systém později může díky porovnání těchto změn vrátit jakýkoli soubor do podoby, v níž byl v libovolném okamžiku. @@ -24,7 +24,7 @@ Jedním z velmi oblíbených nástrojů VCS byl systém s názvem rcs, který je Dalším velkým problémem, s nímž se uživatelé potýkají, je potřeba spolupráce s dalšími pracovníky týmu. Řešení tohoto problému nabízejí tzv. centralizované systémy správy verzí (CVCS z angl. Centralized Version Control System). Tyto systémy, jmenovitě např. CVS, Subversion či Perforce, obsahují serverovou část, která uchovává všechny verzované soubory. Z tohoto centrálního úložiště si potom soubory stahují jednotliví klienti. Tento koncept byl dlouhá léta standardem pro správu verzí (viz obrázek 1-2). Insert 18333fig0102.png -Figure 1-2. Diagram centralizované správy verzí +Obrázek 1-2. Diagram centralizované správy verzí Nabízí ostatně mnoho výhod, zejména v porovnání s lokálními systémy VCS. Každý například — do určité míry — ví, co dělají ostatní účastníci projektu a administrátoři mají přesnou kontrolu nad jednotlivými právy. Kromě toho je podstatně jednodušší spravovat CVCS, než pracovat s lokálními databázemi na jednotlivých klientech. @@ -35,7 +35,7 @@ Avšak i tato koncepce má závažné nedostatky. Tímto nejkřiklavějším je V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verzí (DVCS z angl. Distributed Version Control System). V systémech DVCS (např. Git, Mercurial, Bazaar nebo Darcs) uživatelé pouze nestahují nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale uchovávají kompletní kopii repozitáře (repository). Pokud v takové situaci dojde ke kolapsu serveru, lze jej obnovit zkopírováním repozitáře od libovolného uživatele. Každá lokální kopie (checkout) je plnohodnotnou zálohou všech dat (viz obrázek 1-3). Insert 18333fig0103.png -Figure 1-3. Diagram distribuované správy verzí +Obrázek 1-3. Diagram distribuované správy verzí Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, a vy tak můžete v rámci jednoho projektu spolupracovat na různých úrovních s rozdílnými skupinami lidí. Díky tomu si můžete vytvořit několik typů pracovních postupů, což není v centralizovaných systémech (např. v hierarchických modelech) možné. @@ -62,12 +62,12 @@ Jak bychom tedy mohli Git charakterizovat? Odpověď na tuto otázku je velmi d Hlavním rozdílem mezi systémem Git a všemi ostatními systémy VCS (včetně Subversion a jemu podobných) je způsob, jakým Git zpracovává data. Většina ostatních systémů ukládá informace jako seznamy změn jednotlivých souborů. Tyto systémy (CVS, Perforce, Bazaar atd.) chápou uložené informace jako sadu souborů a seznamů změn těchto souborů v čase — viz obrázek 1-4. Insert 18333fig0104.png -Figure 1-4. Ostatní systémy ukládají data jako změny v základní verzi každého souboru. +Obrázek 1-4. Ostatní systémy ukládají data jako změny v základní verzi každého souboru. Git zpracovává data jinak. Chápe je spíše jako sadu snímků (snapshots) vlastního malého systému souborů. Pokaždé, když v systému zapíšete (uložíte) stav projektu, Git v podstatě „vyfotí“, jak vypadají všechny vaše soubory v daném okamžiku, a uloží reference na tento snímek. Pokud v souborech nebyly provedeny žádné změny, Git v zájmu zefektivnění práce neukládá znovu celý soubor, ale pouze odkaz na předchozí identický soubor, který už byl uložen. Zpracování dat v systému Git ilustruje obrázek 1-5. Insert 18333fig0105.png -Figure 1-5. Git ukládá data jako snímky projektu proměnlivé v čase. +Obrázek 1-5. Git ukládá data jako snímky projektu proměnlivé v čase. Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git je tak z obyčejného VCS spíše povýšen na vlastní systém správy souborů s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3. @@ -102,7 +102,7 @@ A nyní pozor. Pokud chcete dále hladce pokračovat ve studiu Git, budou pro v Z toho vyplývá, že projekt je v systému Git rozdělen do tří hlavních částí: adresář systému Git (Git directory), pracovní adresář (working directory) a oblast připravených změn (staging area). Insert 18333fig0106.png -Figure 1-6. Pracovní adresář, oblast připravených změn a adresář Git +Obrázek 1-6. Pracovní adresář, oblast připravených změn a adresář Git V adresáři Git ukládá systém databázi metadat a objektů k projektu. Je to nejdůležitější část systému Git a zároveň adresář, který se zkopíruje, když klonujete repozitář z jiného počítače. @@ -166,7 +166,7 @@ Existují dva jednoduché způsoby, jak nainstalovat Git v systému Mac. Tím ne http://code.google.com/p/git-osx-installer Insert 18333fig0107.png -Figure 1-7. Instalátor Git pro OS X +Obrázek 1-7. Instalátor Git pro OS X Jiným obvyklým způsobem je instalace systému Git prostřednictvím systému MacPorts (`http://www.macports.org`). Máte-li systém MacPorts nainstalován, nainstalujte Git příkazem: diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown index 4285112c1..82ffcc030 100644 --- a/cs/02-git-basics/01-chapter2.markdown +++ b/cs/02-git-basics/01-chapter2.markdown @@ -47,7 +47,7 @@ Nezapomeňte, že každý soubor ve vašem pracovním adresáři může být ve Jakmile začnete soubory upravovat, Git je bude považovat za „změněné“, protože jste v nich od poslední revize provedli změny. Poté všechny tyto změněné soubory připravíte k zapsání a následně všechny připravené změny zapíšete. Cyklus může začít od začátku. Pracovní cyklus je znázorněn na obrázku 2-1. Insert 18333fig0201.png -Figure 2-1. Cyklus stavů vašich souborů +Obrázek 2-1. Cyklus stavů vašich souborů ### Kontrola stavu souborů ### @@ -625,7 +625,7 @@ Z téměř 20 000 revizí v historii zdrojového kódu Git zobrazí tento přík Chcete-li použít graficky výrazněji zpracovaný nástroj k procházení historie revizí, možná oceníte Tcl/Tk program nazvaný `gitk`, který je distribuován spolu se systémem Git. Gitk je v zásadě grafická verze příkazu `git log` a umožňuje téměř všechny možnosti filtrování jako `git log`. Pokud do příkazového řádku ve svém projektu zadáte příkaz `gitk`, otevře se okno podobné jako na obrázku 2-2. Insert 18333fig0202.png -Figure 2-2. Graficky zpracovaná historie v nástroji „gitk“ +Obrázek 2-2. Graficky zpracovaná historie v nástroji „gitk“ V horní polovině okna vidíte historii revizí, doplněnou názorným hierarchickým grafem. Prohlížeč rozdílů v dolní polovině okna zobrazuje změny provedené v každé revizi, na niž kliknete. diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown index 4989901a4..8d5275ffe 100644 --- a/cs/03-git-branching/01-chapter3.markdown +++ b/cs/03-git-branching/01-chapter3.markdown @@ -20,17 +20,17 @@ Vytvoříte-li revizi příkazem `git commit`, provede Git kontrolní součet ka Váš repozitář Git nyní obsahuje pět objektů: jeden blob pro obsah každého ze tří vašich souborů, jeden strom, který zaznamenává obsah adresáře a udává, které názvy souborů jsou uloženy jako který blob, a jednu revizi s ukazatelem na kořenový strom a se všemi metadaty revize. Data ve vašem repozitáři Git se dají schematicky znázornit jako na obrázku 3-1. Insert 18333fig0301.png -Figure 3-1. Repozitář s daty jedné revize +Obrázek 3-1. Repozitář s daty jedné revize Jestliže v souborech provedete změny a zapíšete je, další revize uloží ukazatel na revizi, jež jí bezprostředně předcházela. Po dalších dvou revizích bude vaše historie vypadat jako na obrázku 3-2. Insert 18333fig0302.png -Figure 3-2. Data objektů Git pro několik revizí +Obrázek 3-2. Data objektů Git pro několik revizí Větev je v systému Git jen snadno přemístitelným ukazatelem na jednu z těchto revizí. Výchozím názvem větve v systému Git je `master` (hlavní větev). Při prvním zapisování revizí dostanete hlavní větev, jež bude ukazovat na poslední revizi, kterou jste zapsali. Pokaždé, když zapíšete novou revizi, větev se automaticky posune vpřed. Insert 18333fig0303.png -Figure 3-3. Větev ukazující do historie dat revizí +Obrázek 3-3. Větev ukazující do historie dat revizí Co se stane, když vytvoříte novou větev? Ano, nová větev znamená vytvoření nového ukazatele, s nímž můžete pohybovat. Řekněme, že vytvoříte novou větev a nazvete ji testing. Učiníte tak příkazem `git branch`: @@ -39,12 +39,12 @@ Co se stane, když vytvoříte novou větev? Ano, nová větev znamená vytvoře Tento příkaz vytvoří nový ukazatel na stejné revizi, na níž se právě nacházíte (viz obrázek 3-4). Insert 18333fig0304.png -Figure 3-4. Několik větví ukazujících do historie dat revizí +Obrázek 3-4. Několik větví ukazujících do historie dat revizí Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem git branch jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5). Insert 18333fig0305.png -Figure 3-5. Soubor HEAD ukazující na větev, na níž se nacházíte. +Obrázek 3-5. Soubor HEAD ukazující na větev, na níž se nacházíte. Chcete-li přepnout na existující větev, spusťte příkaz `git checkout`. My můžeme přepnout na novou větev testing: @@ -53,7 +53,7 @@ Chcete-li přepnout na existující větev, spusťte příkaz `git checkout`. My Tímto příkazem přesunete ukazatel HEAD tak, že ukazuje na větev testing (viz obrázek 3-6). Insert 18333fig0306.png -Figure 3-6. Soubor HEAD ukazuje po přepnutí na jinou větev. +Obrázek 3-6. Soubor HEAD ukazuje po přepnutí na jinou větev. A jaký to má smysl? Dobře, proveďme další revizi: @@ -63,7 +63,7 @@ A jaký to má smysl? Dobře, proveďme další revizi: Obrázek 3-7 ukazuje výsledek. Insert 18333fig0307.png -Figure 3-7. Větev, na niž ukazuje soubor HEAD, se posouvá vpřed s každou revizí. +Obrázek 3-7. Větev, na niž ukazuje soubor HEAD, se posouvá vpřed s každou revizí. Výsledek je zajímavý z toho důvodu, že se větev `testing` posunula vpřed, zatímco větev `master` stále ukazuje na revizi, na níž jste se nacházeli v okamžiku, kdy jste spustili příkaz `git checkout` a přepnuli tím větve. Přepněme zpět na větev `master`. @@ -72,7 +72,7 @@ Výsledek je zajímavý z toho důvodu, že se větev `testing` posunula vpřed, Výsledek ukazuje obrázek 3-8. Insert 18333fig0308.png -Figure 3-8. Ukazatel HEAD se po příkazu git checkout přesune na jinou větev. +Obrázek 3-8. Ukazatel HEAD se po příkazu git checkout přesune na jinou větev. Tento příkaz provedl dvě věci. Přemístil ukazatel `HEAD` zpět, takže nyní ukazuje na větev `master`, a vrátil soubory ve vašem pracovním adresáři zpět ke snímku, na nějž větev `master` ukazuje. To také znamená, že změny, které od teď provedete, se odštěpí od starší verze projektu. V podstatě dočasně vrátíte všechny změny, které jste provedli ve větvi testing, a vydáte se jiným směrem. @@ -84,7 +84,7 @@ Proveďme pár změn a zapišme další revizi: Nyní se historie vašeho projektu rozdělila (viz obrázek 3-9). Vytvořili jste novou větev, přepnuli jste na ni, provedli jste v ní změny a poté jste přepnuli zpět na hlavní větev, v níž jste rovněž provedli změny. Oboje tyto změny jsou oddělené na samostatných větvích. Můžete mezi nimi přepínat tam a zpět, a až uznáte za vhodné, můžete je sloučit. To vše jste provedli pomocí jednoduchých příkazů `branch` a `checkout`. Insert 18333fig0309.png -Figure 3-9. Historie větví se rozdělila. +Obrázek 3-9. Historie větví se rozdělila. Vzhledem k tomu, že větev v systému Git tvoří jeden jednoduchý soubor, obsahující 40 znaků kontrolního součtu SHA-1 revize, na niž ukazuje, je snadné větve vytvářet i odstraňovat. Vytvořit novou větev je právě tak snadné a rychlé jako zapsat 41 bytů do souboru (40 znaků a jeden nový řádek). @@ -112,7 +112,7 @@ V tomto okamžiku vám zavolají, že se vyskytla jiná kritická chyba, která Řekněme, že pracujete na projektu a už jste vytvořili několik revizí (viz obrázek 3-10). Insert 18333fig0310.png -Figure 3-10. Krátká a jednoduchá historie revizí +Obrázek 3-10. Krátká a jednoduchá historie revizí Rozhodli jste se, že budete pracovat na chybě č. 53, ať už vaše společnost používá jakýkoli systém sledování chyb. Přesněji řečeno, Git není začleněn do žádného konkrétního systému sledování chyb, ale protože je chyba č. 53 významná a chcete na ní pracovat, vytvoříte si pro ni novou větev. Abyste vytvořili novou větev a rovnou na ni přepnuli, můžete spustit příkaz `git checkout` s přepínačem `-b`: @@ -127,7 +127,7 @@ Tímto způsobem jste spojili dva příkazy: Obrázek 3-11 ukazuje výsledek. Insert 18333fig0311.png -Figure 3-11. Vytvoření nového ukazatele na větev +Obrázek 3-11. Vytvoření nového ukazatele na větev Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že jste na ni přepnuli a ukazuje na ni soubor HEAD – viz obrázek 3-12): @@ -135,7 +135,7 @@ Pracujete na webových stránkách a zapíšete několik revizí. S každou novo $ git commit -a -m 'added a new footer [issue 53]' Insert 18333fig0312.png -Figure 3-12. Větev iss53 se s vaší prací posouvá vpřed. +Obrázek 3-12. Větev iss53 se s vaší prací posouvá vpřed. V tomto okamžiku vám zavolají, že se na webových stránkách vyskytl problém, který musíte okamžitě vyřešit. Jelikož pracujete v systému Git, nemusíte svou opravu vytvářet uprostřed změn, které jste provedli v části `iss53`, ani nemusíte dělat zbytečnou práci, abyste všechny tyto změny vrátili, než budete moci začít pracovat na opravě produkční verze stránek. Jediné, co teď musíte udělat, je přepnout zpět na hlavní větev. @@ -156,7 +156,7 @@ Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme p 1 files changed, 0 insertions(+), 1 deletions(-) Insert 18333fig0313.png -Figure 3-13. Větev „hotfix“ začleněná zpět v místě hlavní větve +Obrázek 3-13. Větev „hotfix“ začleněná zpět v místě hlavní větve Můžete provádět testování, ujistit se, že hotfix splňuje všechny požadavky, a pak můžete větev začlenit (merge) zpět do hlavní větve, aby byla připravena do produkce. Učiníte tak příkazem `git merge`: @@ -172,7 +172,7 @@ Při sloučení jste si možná všimli spojení „Fast forward“ (rychle vpř Vaše změna je nyní obsažena ve snímku revize, na niž ukazuje hlavní větev `master`, a vy můžete pokračovat v provádění změn (viz obrázek 3-14). Insert 18333fig0314.png -Figure 3-14. Hlavní větev ukazuje po sloučení na stejné místo jako větev „hotfix“. +Obrázek 3-14. Hlavní větev ukazuje po sloučení na stejné místo jako větev „hotfix“. Poté, co jste dokončili práci na bezodkladné opravě, můžete přepnout zpět na práci, jíž jste se věnovali před telefonátem. Nejprve však smažete větev `hotfix`, kterou teď už nebudete potřebovat – větev `master` ukazuje na totéž místo. Větev smažete přidáním parametru `-d` k příkazu `git branch`: @@ -189,7 +189,7 @@ Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na c 1 files changed, 1 insertions(+), 0 deletions(-) Insert 18333fig0315.png -Figure 3-15. Větev iss53 může nezávisle postupovat vpřed. +Obrázek 3-15. Větev iss53 může nezávisle postupovat vpřed. Za zmínku stojí, že práce, kterou jste udělali ve větvi `hotfix`, není obsažena v souborech ve větvi `iss53`. Pokud potřebujete tyto změny do větve natáhnout, můžete začlenit větev `master` do větve `iss53` – použijte příkaz `git merge master`. Druhou možností je s integrací změn vyčkat a provést ji až ve chvíli, kdy budete chtít větev `iss53` natáhnout zpět do větve `master`. @@ -206,14 +206,14 @@ Předpokládejme, že jste dokončili práci na chybě č. 53 a nyní byste ji r Toto už se trochu liší od začlenění větve `hotfix`, které jste prováděli před chvílí. V tomto případě se historie vývoje od určitého bodu v minulosti rozbíhala. Vzhledem k tomu, že revize na větvi, na níž se nacházíte, není přímým předkem větve, kterou chcete začlenit, Git bude muset podniknout určité kroky. Git v tomto případě provádí jednoduché třícestné sloučení: vychází ze dvou snímků, na které ukazují větve, a jejich společného předka. Obrázek 3-16 označuje ony tři snímky, které Git v tomto případě použije ke sloučení. Insert 18333fig0316.png -Figure 3-16. Git automaticky identifikuje nejvhodnějšího společného předka jako základnu pro sloučení větví. +Obrázek 3-16. Git automaticky identifikuje nejvhodnějšího společného předka jako základnu pro sloučení větví. Git tentokrát neposune ukazatel větve vpřed, ale vytvoří nový snímek jako výsledek tohoto třícestného sloučení a automaticky vytvoří novou revizi, která bude na snímek ukazovat (viz obrázek 3-17). Takové revizi se říká revize sloučením (merge commit) a její zvláštností je to, že má více než jednoho rodiče. Na tomto místě bych chtěl zopakovat, že Git určuje nejvhodnějšího společného předka, který bude použit jako základna pro sloučení, automaticky. Liší se tím od systému CVS i Subversion (před verzí 1.5), kde musí vývojář při slučování najít nejvhodnější základnu pro sloučení sám. Slučování větví je tak v systému Git o poznání jednodušší než v těchto ostatních systémech. Insert 18333fig0317.png -Figure 3-17. Git automaticky vytvoří nový objekt revize, který obsahuje sloučenou práci. +Obrázek 3-17. Git automaticky vytvoří nový objekt revize, který obsahuje sloučenou práci. Nyní, když jste svou práci sloučili, větev `iss53` už nebudete potřebovat. Můžete ji smazat a poté ručně zavřít tiket v systému sledování tiketů: @@ -349,12 +349,12 @@ Mnoho vývojářů systému Git používá pracovní postup, při němž je tato Ve skutečnosti hovoříme o ukazatelích pohybujících se vzhůru po linii revizí, které zapisujete. Stabilní větve leží v linii historie revizí níže a nové, neověřené větve se nacházejí nad nimi (viz obrázek 3-18). Insert 18333fig0318.png -Figure 3-18. Stabilnější větve většinou leží v historii revizí níže. +Obrázek 3-18. Stabilnější větve většinou leží v historii revizí níže. Snáze si je můžeme představit jako pracovní zásobníky, v nichž se sada revizí dostává do stabilnějšího zásobníku, když úspěšně absolvovala testování (viz obrázek 3-19). Insert 18333fig0319.png -Figure 3-19. Větve si můžeme představit jako zásobníky +Obrázek 3-19. Větve si můžeme představit jako zásobníky Tento postup lze použít hned pro několik úrovní stability. Některé větší projekty mají také větev `proposed` nebo `pu` (proposed updates, návrh aktualizací) s integrovanými větvemi, které nemusí být nutně způsobilé k začlenění do větve `next` nebo `master`. Idea je taková, že se větve nacházejí na různé úrovni stability. Jakmile dosáhnou stability o stupeň vyšší, jsou začleněny do větve nad nimi. Není nutné používat při práci několik dlouhých větví, ale často to může být užitečné, zejména pokud pracujete ve velmi velkých nebo komplexních projektech. @@ -368,12 +368,12 @@ Viděli jste to v předchozí části, kdy jste si vytvořili větve `iss53` a ` Uvažujme nyní následující situaci: pracujete na projektu v hlavní větvi (`master`), odbočíte z ní k vyřešení jednoho problému (`iss91`), chvíli na něm pracujete, ale vytvoříte ještě další větev, abyste zkusili jiné řešení stejné chyby (`iss91v2`). Pak se vrátíte zpět na hlavní větev, kde pokračujete v práci, než dostanete nápad, který by se možná mohl osvědčit, a tak pro něj vytvoříte další větev (`dumbidea`). Historie revizí bude vypadat zhruba jako na obrázku 3-20. Insert 18333fig0320.png -Figure 3-20. Historie revizí s několika tematickými větvemi +Obrázek 3-20. Historie revizí s několika tematickými větvemi Řekněme, že se nyní rozhodnete, že druhé řešení vašeho problému bude vhodnější (`iss91v2`). Dále jste také ukázali svůj nápad ve větvi `dumbidea` kolegům a ti ho považují za geniální. Původní větev `iss91` tak nyní můžete zahodit (s ní i revize C5 a C6) a začlenit zbylé dvě větve. Vaši historii v tomto stavu znázorňuje obrázek 3-21. Insert 18333fig0321.png -Figure 3-21. Vaše historie po začlenění větví „dumbidea“ a „iss91v2“ +Obrázek 3-21. Vaše historie po začlenění větví „dumbidea“ a „iss91v2“ Při tom všem, co nyní děláte, je důležité mít na paměti, že všechny tyto větve jsou čistě lokální. Veškeré větvení a slučování se odehrává pouze v repozitáři Git, neprobíhá žádná komunikace se serverem. @@ -386,27 +386,27 @@ Vzdálené větve mají podobu `(vzdálený repozitář)/(větev)`. Například: Mohlo by to být trochu matoucí, takže si uveďme příklad. Řekněme, že máte v síti server Git označený `git.ourcompany.com`. Pokud provedete klonování z tohoto serveru, Git ho automaticky pojmenuje `origin`, stáhne z něj všechna data, vytvoří ukazatel, který bude označovat jeho větev `master`, a lokálně ji pojmenuje `origin/master`. Tuto větev nemůžete přesouvat. Git vám rovněž vytvoří vaši vlastní větev `master`, která bude začínat ve stejném místě jako větev `master` serveru `origin`. Máte tak definován výchozí bod pro svoji práci (viz obrázek 3-22). Insert 18333fig0322.png -Figure 3-22. Příkaz git clone vám vytvoří vlastní hlavní větev a větev origin/master, ukazující na hlavní větev serveru origin. +Obrázek 3-22. Příkaz git clone vám vytvoří vlastní hlavní větev a větev origin/master, ukazující na hlavní větev serveru origin. Pokud nyní budete pracovat na své lokální hlavní větvi a někdo z kolegů mezitím pošle svou práci na server `git.ourcompany.com` a aktualizuje jeho hlavní větev, budou se vaše historie vyvíjet odlišně. A dokud zůstanete od serveru origin odpojeni, váš ukazatel `origin/master` se nemůže přemístit (viz obrázek 3-23). Insert 18333fig0323.png -Figure 3-23. Pokud pracujete lokálně a někdo jiný odešle svou práci na vzdálený server, obě historie se rozejdou. +Obrázek 3-23. Pokud pracujete lokálně a někdo jiný odešle svou práci na vzdálený server, obě historie se rozejdou. K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je „origin“ (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24). Insert 18333fig0324.png -Figure 3-24. Příkaz git fetch aktualizuje vaše reference na vzdálený server. +Obrázek 3-24. Příkaz git fetch aktualizuje vaše reference na vzdálený server. Abychom si mohli ukázat, jak se pracuje s několika vzdálenými servery a jak vypadají vzdálené větve takových vzdálených projektů, předpokládejme, že máte ještě další interní server Git, který při vývoji používá pouze jeden z vašich sprint teamů. Tento server se nachází na `git.team1.ourcompany.com`. Můžete ho přidat jako novou vzdálenou referenci k projektu, na němž právě pracujete – spusťte příkaz `git remote add` (viz kapitola 2). Pojmenujte tento vzdálený server jako `teamone`, což bude zkrácený název pro celou URL adresu (viz obrázek 3-25). Insert 18333fig0325.png -Figure 3-25. Přidání dalšího vzdáleného serveru. +Obrázek 3-25. Přidání dalšího vzdáleného serveru. Nyní můžete spustit příkaz `git fetch teamone`, který ze vzdáleného serveru `teamone` vyzvedne vše, co ještě nemáte. Protože je tento server podmnožinou dat, která jsou právě na serveru `origin`, Git nevyzvedne žádná data, ale nastaví vzdálenou větev nazvanou `teamone/master` tak, aby ukazovala na revizi, kterou má server `teamone` nastavenou jako větev `master` (viz obrázek 3-26). Insert 18333fig0326.png -Figure 3-26. Lokálně získáte referenci na pozici hlavní větve serveru teamone. +Obrázek 3-26. Lokálně získáte referenci na pozici hlavní větve serveru teamone. ### Odesílání ### @@ -481,12 +481,12 @@ V systému Git existují dvě základní možnosti, jak integrovat změny z jedn Pokud se vrátíme k našemu dřívějšímu příkladu z části o slučování větví (viz obrázek 3-27), vidíme, že jsme svoji práci rozdělili a vytvářeli revize ve dvou různých větvích. Insert 18333fig0327.png -Figure 3-27. Vaše původně rozdělená historie revizí +Obrázek 3-27. Vaše původně rozdělená historie revizí Víme, že nejjednodušším způsobem, jak integrovat větve, je příkaz `merge`. Ten provede třícestné sloučení mezi dvěma posledními snímky (C3 a C4) a jejich nejmladším společným předkem (C2), přičemž vytvoří nový snímek (a novou revizi) – viz obrázek 3-28. Insert 18333fig0328.png -Figure 3-28. Integrace rozdělené historie sloučením větví +Obrázek 3-28. Integrace rozdělené historie sloučením větví Existuje však ještě jiný způsob. Můžete vzít záplatu se změnou, kterou jste provedli revizí C3, a aplikovat ji na vrcholu revize C4. V systému Git se tato metoda nazývá přeskládání (rebasing). Příkazem `rebase` vezmete všechny změny, které byly zapsány na jedné větvi, a necháte je znovu provést na jiné větvi. @@ -500,12 +500,12 @@ V našem případě tedy provedete následující: Přeskládání funguje takto: systém najde společného předka obou větví (větve, na níž se nacházíte, a větve, na kterou přeskládáváte), provede příkaz diff pro všechny revize větve, na níž se nacházíte, uloží zjištěné rozdíly do dočasných souborů, vrátí aktuální větev na stejnou revizi jako větev, na kterou přeskládáváte, a nakonec po jedné aplikuje všechny změny. Tento proces je naznačen na obrázku 3-29. Insert 18333fig0329.png -Figure 3-29. Přeskládání změny provedené v revizi C3 na revizi C4 +Obrázek 3-29. Přeskládání změny provedené v revizi C3 na revizi C4 Nyní můžete přejít zpět na hlavní větev a provést sloučení „rychle vpřed“ (viz obrázek 3-30). Insert 18333fig0330.png -Figure 3-30. „Rychle vpřed“ po hlavní větvi +Obrázek 3-30. „Rychle vpřed“ po hlavní větvi Snímek, na který nyní ukazuje revize C3, je zcela totožný se snímkem, na který v příkladu v části o slučování ukazovala C5. V koncových produktech integrace není žádný rozdíl, výsledkem přeskládání je však čistší historie. Pokud si prohlížíte log přeskládané větve, vypadá jako lineární historie – zdá se, jako by veškerá práce probíhala v jedné linii, ačkoli původně byla paralelní. @@ -518,7 +518,7 @@ Ještě jednou bychom chtěli upozornit, že snímek, na který ukazuje závěre Opětovné provedení změn pomocí příkazu rebase můžete využít i jiným účelům než jen k přeskládání větve. Vezměme například historii na obrázku 3-31. Vytvořili jste novou tematickou větev (`server`), pomocí níž chcete do svého projektu přidat funkci na straně serveru, a zapsali jste revizi. Poté jste tuto větev opustili a začali pracovat na změnách na straně klienta (`client`). I tady jste zapsali několik revizí. Nakonec jste se vrátili na větev `server` a zapsali tu další revize. Insert 18333fig0331.png -Figure 3-31. Historie s tematickou větví obsahující další tematickou větev. +Obrázek 3-31. Historie s tematickou větví obsahující další tematickou větev. Předpokládejme, že nyní chcete začlenit změny provedené na straně klienta do své hlavní linie k vydání, ale prozatím chcete počkat se změnami na straně serveru, dokud nebudou pečlivě otestovány. Můžete vzít změny na větvi client, které nejsou na větvi server (C8 a C9), a nechat je znovu provést na hlavní větvi. Použijte k tomu příkaz `git rebase` v kombinaci s parametrem `--onto`: @@ -527,7 +527,7 @@ Předpokládejme, že nyní chcete začlenit změny provedené na straně klient Tím v podstatě říkáte: „Proveď checkout větve `client`, zjisti záplaty ze společného předka větví `client` a `server` a znovu je aplikuj na hlavní větev `master`.“ Postup je možná trochu složitý, ale výsledek, znázorněný na obrázku 3-32, stojí opravdu za to. Insert 18333fig0332.png -Figure 3-32. Přeskládání tematické větve, která byla součástí jiné tematické větve 72. +Obrázek 3-32. Přeskládání tematické větve, která byla součástí jiné tematické větve 72. Nyní můžete posunout hlavní větev „rychle vpřed“ (viz obrázek 3-33): @@ -535,7 +535,7 @@ Nyní můžete posunout hlavní větev „rychle vpřed“ (viz obrázek 3-33): $ git merge client Insert 18333fig0333.png -Figure 3-33. Posun hlavní větve rychle vpřed na konec změn přeskládaných z větve client +Obrázek 3-33. Posun hlavní větve rychle vpřed na konec změn přeskládaných z větve client Řekněme, že se později rozhodnete natáhnout i větev server. Větev server můžete přeskládat na hlavní větev příkazem `git rebase [základna] [tematická větev]`. Příkaz provede checkout tematické větve (v tomto případě větve `server`) a přeskládá její změny na základnu (angl. base branch, v tomto případě `master`): @@ -544,7 +544,7 @@ Figure 3-33. Posun hlavní větve rychle vpřed na konec změn přeskládaných Příkaz provede změny obsažené ve větvi `server` ještě jednou na vrcholu větve `master`, jak je znázorněno na obrázku 3-34. Insert 18333fig0334.png -Figure 3-34. Přeskládání větve server na vrcholu hlavní větve. +Obrázek 3-34. Přeskládání větve server na vrcholu hlavní větve. Poté se můžete přesunout „rychle vpřed“ po základně (větev `master`): @@ -557,7 +557,7 @@ Poté můžete větev `client` i `server` smazat, protože všechna práce z nic $ git branch -d server Insert 18333fig0335.png -Figure 3-35. Konečná historie revizí +Obrázek 3-35. Konečná historie revizí ### Rizika spojená s přeskládáním ### @@ -572,22 +572,22 @@ Při přeskládání dat zahodíte existující revize a vytvoříte nové, kter Podívejme se na malý příklad, jaké problémy může přeskládání již zveřejněných dat způsobit. Představme si situaci, kdy jste naklonovali repozitář z centrálního serveru a provedli jste v něm několik změn. Vaše historie revizí bude vypadat jako na obrázku 3-36. Insert 18333fig0336.png -Figure 3-36. Naklonovali jste repozitář a provedli v něm změny. +Obrázek 3-36. Naklonovali jste repozitář a provedli v něm změny. Někdo jiný teď provede jiné úpravy, jejichž součástí bude i začlenění, a odešle svou práci na centrální server. Vy tyto změny vyzvednete a začleníte novou vzdálenou větev do své práce – vaše historie teď vypadá jako na obrázku 3-37. Insert 18333fig0337.png -Figure 3-37. Vyzvedli jste další revize a začlenili je do své práce. +Obrázek 3-37. Vyzvedli jste další revize a začlenili je do své práce. Jenže osoba, která odeslala a začlenila své změny, se rozhodne vrátit a svou práci raději přeskládat. Provede příkaz `git push --force` a přepíše historii na serveru. Vy poté znovu vyzvednete data ze serveru a stáhnete nové revize. Insert 18333fig0338.png -Figure 3-38. Kdosi odeslal přeskládané revize a zahodil ty, na nichž jste založili svou práci. +Obrázek 3-38. Kdosi odeslal přeskládané revize a zahodil ty, na nichž jste založili svou práci. V tuto chvíli vám nezbývá, než změny znovu začlenit do své práce, ačkoli už jste je jednou začlenili. Přeskládáním se změnily otisky SHA-1 těchto revizí, a Git je proto považuje za nové revize, přestože změny označené jako C4 už jsou ve skutečnosti ve vaší historii obsaženy (viz obrázek 3-39). Insert 18333fig0339.png -Figure 3-39. Znovu jste začlenili stejnou práci do nové revize sloučením. +Obrázek 3-39. Znovu jste začlenili stejnou práci do nové revize sloučením. Vy musíte tyto změny ve vhodném okamžiku začlenit do své práce, abyste do budoucna neztratili kontakt s ostatními vývojáři. Vaše historie pak bude obsahovat revize C4 i C4’, které mají obě jiný otisk SHA-1, ale představují stejnou práci a nesou i stejnou zprávu k revizi. Pokud s takovouto historií spustíte příkaz `git log`, nastane zmatečná situace, kdy se zobrazí dvě revize se stejným datem autora i stejnou zprávou k revizi. Pokud pak tuto historii odešlete zpět na server, znovu provedete všechny tyto přeskládané revize na centrálním serveru, což bude zmatečné i pro vaše spolupracovníky. diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown index a72692a22..746caa912 100644 --- a/cs/04-git-server/01-chapter4.markdown +++ b/cs/04-git-server/01-chapter4.markdown @@ -319,7 +319,7 @@ Tímto způsobem můžete během pár minut nastavit oprávnění pro čtení za Nyní, když máte ke svému projektu nastavena základní oprávnění pro čtení/zápis a pouze pro čtení, možná budete chtít nastavit jednoduchou online vizualizaci. Git vám nabízí CGI skript s názvem GitWeb, který slouží k tomuto účelu. Jak GitWeb funguje, na to se můžete podívat např. na stránkách `http://git.kernel.org` (viz obrázek 4-1). Insert 18333fig0401.png -Figure 4-1. Online uživatelské rozhraní GitWeb +Obrázek 4-1. Online uživatelské rozhraní GitWeb Pokud vás zajímá, jak by GitWeb vypadal pro váš projekt, nabízí Git příkaz, jímž lze spustit dočasnou instanci. V systému je třeba mít lehký server typu `lighttpd` nebo `webrick`. V počítačích se systémem Linux je často nainstalován `lighttpd`. Spustit ho lze zadáním příkazu `git instaweb` v adresáři vašeho projektu. Pokud používáte OS Mac, v systému Leopard je předinstalován jazyk Ruby, a proto pro vás bude nejlepší variantou zřejmě server `webrick`. Chcete-li spustit `instaweb` s jiným správcem než `lighttpd`, použijte parametr `--httpd`: @@ -741,18 +741,18 @@ GitHub je zároveň komerční společnost, jejíž finanční příjmy plynou z První věcí, kterou budete muset udělat, je vytvoření bezplatného uživatelské účtu. Jestliže na stránce „Pricing and Signup“ (`http://github.com/plans`) kliknete u bezplatného účtu (Free) na tlačítko „Sign Up“ (viz obrázek 4-2), přejdete na registrační stránku. Insert 18333fig0402.png -Figure 4-2. Výběr typu účtu na serveru GitHub +Obrázek 4-2. Výběr typu účtu na serveru GitHub Tady si budete muset zvolit uživatelské jméno, které zatím není v systému obsazeno, a zadat e-mailovou adresu, která bude přiřazena k účtu a heslu (viz obrázek 4-3). Insert 18333fig0403.png -Figure 4-3. Registrační formulář na serveru GitHub +Obrázek 4-3. Registrační formulář na serveru GitHub Po vyplnění osobních údajů nadešel vhodný čas k vložení vašeho veřejného klíče SSH. Jak vygenerovat nový klíč, jsme popsali výše, v části 4.3. Vezměte obsah veřejného klíče z daného páru a vložte ho do textového pole „SSH Public Key“. Kliknutím na odkaz „explain ssh keys“ přejdete na stránku s podrobnými instrukcemi, jak klíč vložit ve všech hlavních operačních systémech. Kliknutím na tlačítko „I agree, sign me up“ přejdete na svůj nový uživatelský ovládací panel (viz obrázek 4-4). Insert 18333fig0404.png -Figure 4-4. Uživatelský ovládací panel na serveru GitHub +Obrázek 4-4. Uživatelský ovládací panel na serveru GitHub Jako další krok následuje vytvoření nového repozitáře. @@ -761,17 +761,17 @@ Jako další krok následuje vytvoření nového repozitáře. Začněte kliknutím na odkaz „create a new one“ (vytvořit nový) vedle nadpisu „Your Repositories“ na ovládacím panelu. Přejdete tím na formulář „Create a New Repository“ (viz obrázek 4-5). Insert 18333fig0405.png -Figure 4-5. Vytvoření nového repozitáře na serveru GitHub +Obrázek 4-5. Vytvoření nového repozitáře na serveru GitHub Vše, co tu bezpodmínečně musíte udělat, je zadat název projektu. Kromě toho můžete přidat i jeho popis. Poté klikněte na tlačítko „Create Repository“ (Vytvořit repozitář). Nyní máte na serveru GitHub vytvořen nový repozitář (viz obrázek 4-6). Insert 18333fig0406.png -Figure 4-6. Záhlaví s informacemi o projektu na serveru GitHub +Obrázek 4-6. Záhlaví s informacemi o projektu na serveru GitHub Protože v něm ještě nemáte uložen žádný kód, GitHub vám nabízí instrukce, jak vytvořit zcela nový projekt, odeslat sem existující projekt Git nebo naimportovat projekt z veřejného repozitáře Subversion (viz obrázek 4-7). Insert 18333fig0407.png -Figure 4-7. Instrukce k novému repozitáři +Obrázek 4-7. Instrukce k novému repozitáři Tyto instrukce jsou podobné těm, které jsme už uváděli. K inicializaci projektu, pokud to ještě není projekt Git, použijte příkaz: @@ -787,7 +787,7 @@ Pokud už máte lokální repozitář Git, přidejte GitHub jako vzdálený serv Nyní je váš projekt hostován na serveru GitHub a vy můžete dát adresu URL komukoli, s kým chcete svůj projekt sdílet. V tomto případě je adresa `http://github.com/testinguser/iphone_project`. V záhlaví na stránce všech vašich projektů si můžete všimnout, že máte dvě adresy URL (viz obrázek 4-8). Insert 18333fig0408.png -Figure 4-8. Záhlaví projektu s veřejnou a soukromou adresou URL +Obrázek 4-8. Záhlaví projektu s veřejnou a soukromou adresou URL „Public Clone URL“ je veřejná adresa Git pouze pro čtení, na níž si může váš projekt kdokoli naklonovat. Nemusíte se bát poskytnout tuto adresu ostatním nebo ji třeba zveřejnit na svých webových stránkách. @@ -798,7 +798,7 @@ Figure 4-8. Záhlaví projektu s veřejnou a soukromou adresou URL Máte-li existující veřejný projekt Subversion, který byste rádi importovali do systému Git, GitHub vám s tím často ochotně pomůže. Dole na stránce s instrukcemi najdete odkaz na import ze systému Subversion. Pokud na něj kliknete, zobrazí se formulář s informacemi o importu a textové pole, kam můžete vložit adresu URL svého veřejného projektu Subversion (viz obrázek 4-9). Insert 18333fig0409.png -Figure 4-9. Rozhraní importu ze systému Subversion +Obrázek 4-9. Rozhraní importu ze systému Subversion Proces nejspíš nebude fungovat, pokud je váš projekt příliš velký, nestandardní nebo soukromý. V kapitole 7 se dostaneme k tomu, jak lze ručně importovat složitější projekty. @@ -809,17 +809,17 @@ Nyní přidáme zbytek vašeho týmu. Pokud si John, Josie i Jessica zaregistruj Kliknutím na tlačítko „edit“ v záhlaví projektu nebo na záložce „Admin“ v horní části projektu se dostanete na stránku správy vašeho projektu na serveru GitHub (viz obrázek 4-10). Insert 18333fig0410.png -Figure 4-10. Stránka správy na serveru GitHub +Obrázek 4-10. Stránka správy na serveru GitHub Chcete-li k svému projektu poskytnout oprávnění pro zápis ještě dalším uživatelům, klikněte na odkaz „Add another collaborator“ (Přidat dalšího spolupracovníka). Zobrazí se nové textové pole, do nějž můžete zadat jméno uživatele. Během psaní se zobrazuje pomocník, který vám navrhuje možná dokončení uživatelského jména. Poté, co najdete správného uživatele, klikněte na tlačítko „Add“. Tím uživatele přidáte jako spolupracovníka na svém projektu (viz obrázek 4-11). Insert 18333fig0411.png -Figure 4-11. Přidání spolupracovníka do projektu +Obrázek 4-11. Přidání spolupracovníka do projektu Po přidání všech spolupracovníků byste měli vidět jejich seznam v poli „Repository Collaborators“ (viz obrázek 4-12). Insert 18333fig0412.png -Figure 4-12. Seznam spolupracovníků na projektu +Obrázek 4-12. Seznam spolupracovníků na projektu Pokud potřebujete oprávnění pro některého z uživatelů zrušit, klikněte na odkaz „revoke“. Tím odstraníte jeho oprávnění k odesílání dat. U budoucích projektů budete také moci zkopírovat skupinu spolupracovníků zkopírováním oprávnění z existujícího projektu. @@ -828,7 +828,7 @@ Pokud potřebujete oprávnění pro některého z uživatelů zrušit, klikněte Po odeslání projektu nebo jeho naimportování ze systému Subversion budete mít hlavní stránku projektu, která bude vypadat přibližně jako na obrázku 4-13. Insert 18333fig0413.png -Figure 4-13. Hlavní stránka projektu na serveru GitHub +Obrázek 4-13. Hlavní stránka projektu na serveru GitHub Navštíví-li váš projekt ostatní uživatelé, tuto stránku uvidí. Obsahuje několik záložek k různým aspektům vašich projektů. Záložka „Commits“ zobrazuje seznam revizí v obráceném chronologickém pořadí, podobně jako výstup příkazu `git log`. Záložka „Network“ zobrazuje všechny uživatele, kteří rozštěpili váš projekt a přispěli do něj. Záložka „Downloads“ umožňuje nahrávat binární soubory k projektu a přidávat odkazy na tarbally a komprimované verze všech míst ve vašem projektu, které jsou označeny značkou (tagem). Záložka „Wiki“ vám nabízí stránku wiki, kam můžete napsat dokumentaci nebo jiné informace ke svému projektu. Záložka „Graphs“ graficky zobrazuje některé příspěvky a statistiky k vašemu projektu. Hlavní záložka „Source“, na níž se stránka otvírá, zobrazuje hlavní adresář vašeho projektu, a máte-li soubor README, automaticky ho zařadí na konec seznamu. Tato záložka obsahuje rovněž pole s informacemi o poslední zapsané revizi. @@ -841,12 +841,12 @@ Díky tomu se projekty nemusí starat o přidávání uživatelů do role spolup Chcete-li projekt rozštěpit, přejděte na stránku projektu (v tomto případě mojombo/chronic) a klikněte na tlačítko „fork“ v záhlaví (viz obrázek 4-14). Insert 18333fig0414.png -Figure 4-14. Zapisovatelnou kopii jakéhokoli repozitáře získáte kliknutím na tlačítko „fork“. +Obrázek 4-14. Zapisovatelnou kopii jakéhokoli repozitáře získáte kliknutím na tlačítko „fork“. Po několika sekundách přejdete na novou stránku svého projektu, která oznamuje, že je tento projekt rozštěpením (fork) jiného projektu (viz obrázek 4-15). Insert 18333fig0415.png -Figure 4-15. Vaše rozštěpení projektu +Obrázek 4-15. Vaše rozštěpení projektu ### Shrnutí k serveru GitHub ### diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown index cdd2f16bc..58cbe5f3e 100644 --- a/cs/05-distributed-git/01-chapter5.markdown +++ b/cs/05-distributed-git/01-chapter5.markdown @@ -13,7 +13,7 @@ Na rozdíl od centralizovaných systémů správy verzí (CVCS) umožňuje distr V centralizovaných systémech je většinou možný pouze jediný model spolupráce, tzv. centralizovaný pracovní postup. Jedno centrální úložiště (hub) nebo repozitář přijímá zdrojový kód a každý podle něj synchronizuje svou práci. Několik vývojářů představuje jednotlivé uzly (nodes) – uživatele centrálního místa – které se podle tohoto místa synchronizují (viz obrázek 5-1). Insert 18333fig0501.png -Figure 5-1. Centralizovaný pracovní postup +Obrázek 5-1. Centralizovaný pracovní postup To znamená, že pokud dva vývojáři klonují z centrálního úložiště a oba provedou změny, jen první z nich, který odešle své změny, to může provést bez komplikací. Druhý vývojář musí před odesláním svých změn začlenit práci prvního vývojáře do své, aby nepřepsal jeho změny. Tento koncept platí jak pro Git, tak pro Subversion (popř. jakýkoli CVCS). I v systému Git funguje bez problémů. @@ -32,7 +32,7 @@ Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze p 6. Správce odešle začleněné změny do hlavního repozitáře. Insert 18333fig0502.png -Figure 5-2. Pracovní postup s integračním manažerem +Obrázek 5-2. Pracovní postup s integračním manažerem Tento pracovní postup je velmi rozšířený na stránkách jako GitHub, kde je snadné rozštěpit projekt a odeslat změny do své odštěpené části, kde jsou pro každého k nahlédnutí. Jednou z hlavních předností tohoto postupu je, že můžete pracovat bez přerušení a správce hlavního repozitáře může natáhnout vaše změny do projektu, kdykoli uzná za vhodné. Přispěvatelé nemusí čekat, až budou jejich změny začleněny do projektu – každá strana může pracovat svým tempem. @@ -46,7 +46,7 @@ Jedná se o variantu pracovního postupu s více repozitáři. Většinou se pou 4. Diktátor odesílá svou hlavní větev do referenčního repozitáře, aby si na jeho základě mohli ostatní vývojáři přeskládat data. Insert 18333fig0503.png -Figure 5-3. Pracovní postup s benevolentním diktátorem +Obrázek 5-3. Pracovní postup s benevolentním diktátorem Tento typ pracovního postupu není sice obvyklý, ale může být užitečný u velmi velkých projektů nebo v silně hierarchizovaných prostředích, neboť umožňuje, aby vedoucí projektu (diktátor) velkou část práce delegoval. Pak sbírá velké kusy kódu, které integruje. @@ -162,7 +162,7 @@ John nyní nesmí odeslat revize, protože mezitím odeslala své změny Jessica V tomto okamžiku vypadá Johnův lokální repozitář jako na obrázku 5-4. Insert 18333fig0504.png -Figure 5-4. Johnův výchozí repozitář +Obrázek 5-4. Johnův výchozí repozitář John má referenci ke změnám, které odeslala Jessica, ale než bude moci sám odeslat svá data, bude muset začlenit její práci: @@ -174,7 +174,7 @@ John má referenci ke změnám, které odeslala Jessica, ale než bude moci sám Sloučení probíhá hladce, Johnova historie revizí teď vypadá jako na obrázku 5-5. Insert 18333fig0505.png -Figure 5-5. Johnův repozitář po začlenění větve origin/master +Obrázek 5-5. Johnův repozitář po začlenění větve origin/master John nyní může otestovat svůj kód, aby se ujistil, že stále pracuje správně, a pak může odeslat svou novou sloučenou práci na server: @@ -186,12 +186,12 @@ John nyní může otestovat svůj kód, aby se ujistil, že stále pracuje sprá Johnova historie revizí bude nakonec vypadat jako na obrázku 5-6. Insert 18333fig0506.png -Figure 5-6. Johnova historie po odeslání revize na server origin +Obrázek 5-6. Johnova historie po odeslání revize na server origin Jessica mezitím pracovala na tematické větvi. Vytvořila tematickou větev s názvem `issue54` a zapsala do ní tři revize. Zatím ještě nevyzvedla Johnovy změny, a proto její historie revizí vypadá jako na obrázku 5-7. Insert 18333fig0507.png -Figure 5-7. Výchozí historie revizí – Jessica +Obrázek 5-7. Výchozí historie revizí – Jessica Jessica chce synchronizovat svou práci s Johnem, a proto vyzvedne jeho data: @@ -204,7 +204,7 @@ Jessica chce synchronizovat svou práci s Johnem, a proto vyzvedne jeho data: Tím stáhne práci, kterou mezitím odeslal John. Historie revizí Jessicy teď vypadá jako na obrázku 5-8. Insert 18333fig0508.png -Figure 5-8. Historie Jessicy po vyzvednutí Johnových změn +Obrázek 5-8. Historie Jessicy po vyzvednutí Johnových změn Jessica považuje svou tematickou větev za dokončenou, ale chce vědět, do čeho má svou práci začlenit, aby mohla změny odeslat. Spustí proto příkaz `git log`: @@ -241,7 +241,7 @@ Tento postup je bezproblémový. Jak vidíte, šlo o jednoduchý posun „rychle Začlenění proběhne čistě a historie Jessicy bude vypadat jako na obrázku 5-9. Insert 18333fig0509.png -Figure 5-9. Historie Jessicy po začlenění Johnových změn +Obrázek 5-9. Historie Jessicy po začlenění Johnových změn Větev `origin/master` teď má Jessica dostupnou ze své větve `master`, takže může svou práci úspěšně odeslat (za předpokladu, že John mezitím neodeslal další revize): @@ -253,12 +253,12 @@ Větev `origin/master` teď má Jessica dostupnou ze své větve `master`, takž Všichni vývojáři zapsali několik revizí a úspěšně začlenili práci ostatních do své – viz obrázek 5-10. Insert 18333fig0510.png -Figure 5-10. Historie Jessicy po odeslání všech změn zpět na server +Obrázek 5-10. Historie Jessicy po odeslání všech změn zpět na server Toto je jeden z nejjednodušších pracovních postupů. Po určitou dobu pracujete, obvykle na nějaké tematické větvi, a když je připravena k integraci, začleníte ji do hlavní větve. Chcete-li tuto práci sdílet, začleníte ji do své hlavní větve. Poté vyzvednete a začleníte větev `origin/master`, jestliže se změnila. Nakonec odešlete všechna data do větve `master` na serveru. Obecná posloupnost kroků je naznačena na obrázku 5-11. Insert 18333fig0511.png -Figure 5-11. Obecná posloupnost kroků u jednoduchého pracovního postupu s více vývojáři v systému Git +Obrázek 5-11. Obecná posloupnost kroků u jednoduchého pracovního postupu s více vývojáři v systému Git ### Soukromý řízený tým ### @@ -304,7 +304,7 @@ Jessica nyní vytvoří několik revizí ve větvi `featureB`: Repozitář Jessicy vypadá jako na obrázku 5-12. Insert 18333fig0512.png -Figure 5-12. Výchozí historie revizí – Jessica +Obrázek 5-12. Výchozí historie revizí – Jessica Jessica je připravena odeslat svou práci, ale dostane e-mail od Josie, že již na server odeslala větev `featureBee`, v níž už je část práce hotová. Než bude Jessica moci odeslat svou práci na server, bude do ní nejprve muset začlenit práci Josie. Změny, které Josie provedla, vyzvedne příkazem `git fetch`: @@ -369,17 +369,17 @@ Jessica by ráda něco vylepšila, a proto vytvoří novou revizi a odešle ji z Historie revizí Jessicy bude nyní vypadat jako na obrázku 5-13. Insert 18333fig0513.png -Figure 5-13. Historie Jessicy po zapsání revizí do větve s úkolem +Obrázek 5-13. Historie Jessicy po zapsání revizí do větve s úkolem Jessica, Josie a John pošlou zprávu zprostředkovatelům integrace, že větve `featureA` a `featureBee` jsou na serveru připraveny k integraci do hlavní linie. Poté, co budou tyto větve do hlavní linie integrovány, vyzvednutím dat bude možné stáhnout nové revize vzniklé začleněním změn a historie revizí bude vypadat jako na obrázku 5-14. Insert 18333fig0514.png -Figure 5-14. Historie Jessicy po začlenění obou jejích tematických větví +Obrázek 5-14. Historie Jessicy po začlenění obou jejích tematických větví Mnoho skupin přechází na systém Git právě kvůli této možnosti paralelní spolupráce několika týmů a následného slučování různých linií práce. Možnost, aby několik menších podskupin jednoho týmu spolupracovalo prostřednictvím vzdálených větví a aby si práce nevyžádala účast celého týmu nebo nebránila ostatním v jiné práci, je velkou devízou systému Git. Posloupnost kroků vypadá v případě pracovního postupu, který jsme si právě ukázali, jako na obrázku 5-15. Insert 18333fig0515.png -Figure 5-15. Základní posloupnost kroků u pracovního postupu v řízeném týmu +Obrázek 5-15. Základní posloupnost kroků u pracovního postupu v řízeném týmu ### Malý veřejný projekt ### @@ -439,7 +439,7 @@ U projektů, u nichž nejste v roli správce, je většinou jednodušší, aby v Nyní mají obě vaše témata samostatný zásobník – podobně jako řada záplat – které můžete přepsat, přeskládat a upravit, aniž by se tím obě témata navzájem ovlivňovala nebo omezovala (viz obrázek 5-16). Insert 18333fig0516.png -Figure 5-16. Výchozí historie revizí s větví featureB +Obrázek 5-16. Výchozí historie revizí s větví featureB Řekněme, že správce projektu natáhl do projektu několik jiných záplat a nyní vyzkoušel vaši první větev, jenže tu už nelze čistě začlenit. V takovém případě můžete zkusit přeskládat tuto větev na vrcholu větve `origin/master`, vyřešit za správce vzniklé konflikty a poté své změny ještě jednou odeslat: @@ -450,7 +450,7 @@ Figure 5-16. Výchozí historie revizí s větví featureB Tím přepíšete svou historii, která teď bude vypadat jako na obrázku 5-17. Insert 18333fig0517.png -Figure 5-17. Historie revizí s větví featureA +Obrázek 5-17. Historie revizí s větví featureA Protože jste větev přeskládali, musíte k příkazu git push přidat parametr `-f`, abyste mohli větev `featureA` na serveru nahradit revizí, která není jejím potomkem. Druhou možností je odeslat tuto novou práci do jiné větve na serveru (nazvané např. `featureAv2`). @@ -467,7 +467,7 @@ Parametr `--squash` (komprimovat) vezme všechnu vaši práci v začleněné vě Nyní můžete správci oznámit, že jste provedli požadované změny a že je najde ve vaší větvi `featureBv2` (viz obrázek 5-18). Insert 18333fig0518.png -Figure 5-18. Historie revizí s větví featureBv2 +Obrázek 5-18. Historie revizí s větví featureBv2 ### Velký veřejný projekt ### @@ -755,23 +755,23 @@ Když už je práce v tematické větvi připravena a může být integrována d Jeden jednoduchý pracovní postup začlení vaší práci do větve `master`. V tomto scénáři obsahuje vaše větev `master` převážně jen stabilní kód. Máte-li v tematické větvi práci, kterou jste vytvořili nebo kterou vám někdo doručil a vy jste ji schválili, začleníte ji do své hlavní větve, smažete tematickou větev a proces může pokračovat. Máme-li repozitář s prací ve dvou větvích pojmenovaných `ruby_client` a `php_client`, který vypadá jako na obrázku 5-19, a začleníme nejprve větev `ruby_client` a poté `php_client`, bude naše historie vypadat jako na obrázku 5-20. Insert 18333fig0519.png -Figure 5-19. Historie s několika tematickými větvemi +Obrázek 5-19. Historie s několika tematickými větvemi Insert 18333fig0520.png -Figure 5-20. Po začlenění tematické větve +Obrázek 5-20. Po začlenění tematické větve Jedná se patrně o nejjednodušší pracovní postup. Je však problematický, pokud ho používáme u velkých repozitářů nebo projektů. Máte-li více vývojářů nebo větší projekt, pravděpodobně budete chtít použít přinejmenším dvoufázový cyklus začlenění. V tomto scénáři máte dvě dlouhodobé větve, hlavní větev `master` a větev `develop`. Určíte, že větev `master` bude aktualizována, pouze když je k dispozici velmi stabilní verze a do větve `develop` je integrován veškerý nový kód. Obě tyto větve pravidelně odesíláte do veřejného repozitáře. Pokaždé, když máte novou tematickou větev k začlenění (obrázek 5-21), začleníte ji do větve `develop` (obrázek 5-22). Když poté označujete vydání, posunete větev `master` rychle vpřed do místa, kde je nyní větev `develop` stabilní (obrázek 5-23). Insert 18333fig0521.png -Figure 5-21. Před začleněním tematické větve +Obrázek 5-21. Před začleněním tematické větve Insert 18333fig0522.png -Figure 5-22. Po začlenění tematické větve +Obrázek 5-22. Po začlenění tematické větve Insert 18333fig0523.png -Figure 5-23. Po vydání tematické větve +Obrázek 5-23. Po vydání tematické větve Pokud někdo při tomto postupu klonuje repozitář vašeho projektu, může provést buď checkout hlavní větve, aby získal nejnovější stabilní verzi a udržoval ji aktuální, nebo checkout větve develop, která může být ještě o něco napřed. Tento koncept můžete dále rozšířit o integrační větev, v níž budete veškerou práci slučovat. Teprve pokud je kód v této větvi stabilní a projde testováním, začleníte ho do větve develop. A až se větev develop ukáže v některém okamžiku jako stabilní, posunete rychle vpřed i svou hlavní větev. @@ -781,12 +781,12 @@ Tento koncept můžete dále rozšířit o integrační větev, v níž budete v Váš projekt Git má čtyři trvalé větve: `master`, `next` a `pu` (proposed updates, tj. návrh aktualizací) pro novou práci a `maint` pro backporty správy. Pokud přispěvatelé vytvoří novou práci, je shromažďována v tematických větvích v repozitáři správce podobným způsobem, jaký už jsem popisoval (viz obrázek 5-24). Nyní budou tematické větve vyhodnoceny, zda jsou bezpečné a mohou být aplikovány, nebo zda potřebují další úpravy. Jsou-li vyhodnoceny jako bezpečné, budou začleněny do větve `next` a ta bude následně odeslána do repozitáře, aby mohli všichni vyzkoušet, jak fungují tematické větve po sloučení. Insert 18333fig0524.png -Figure 5-24. Správa komplexní série současně zpracovávaných příspěvků v tematických větvích +Obrázek 5-24. Správa komplexní série současně zpracovávaných příspěvků v tematických větvích Pokud ale tematické větve vyžadují další úpravy, budou začleněny do větve `pu`. Pokud se ukáže, že jsou tyto tematické větve naprosto stabilní, budou začleněny do větve `master` a poté budou znovu sestaveny z tematických větví, které byly ve větvi `next`, ale ještě se nedostaly do větve `master`. To znamená, že se větev `master` téměř neustále posouvá vpřed, větev `next` je čas od času přeskládána a větev `pu` je přeskládávána ještě o něco častěji (viz obrázek 5-25). Insert 18333fig0525.png -Figure 5-25. Začlenění tematických větví s příspěvky do dlouhodobých integračních větví +Obrázek 5-25. Začlenění tematických větví s příspěvky do dlouhodobých integračních větví Byla-li tematická větev konečně začleněna do větve `master`, může být odstraněna z repozitáře. Projekt Git má kromě toho větev `maint`, která byla odštěpena z posledního vydání a představuje záplaty backportované pro případ, že by bylo třeba vydat opravnou verzi. Pokud tedy klonujete repozitář Git, můžete stáhnout až čtyři větve, a hodnotit tak projekt na čtyřech různých úrovních vývoje. Záleží na vás, do jaké hloubky chcete proniknout nebo jak chcete přispívat. A správce projektu má k dispozici strukturovaný pracovní postup k evaluaci nových příspěvků. @@ -797,7 +797,7 @@ Jiní správci dávají před začleněním práce z příspěvků přednost jej Druhým způsobem, jak přesunout práci z jedné větve do druhé, je tzv. částečné převzetí (angl. cherry picking, tedy něco jako „vyzobání třešniček“). Částečné převzetí lze v systému Git přirovnat k přeskládání jedné revize. Při této operaci vezme systém záplatu, která byla provedena v dané revizi, a pokusí se ji znovu aplikovat na větev, na níž se právě nacházíte. To využijete například v situaci, kdy máte několik revizí v tematické větvi, ale chcete integrovat pouze jednu z nich. Částečné převzetí však můžete použít i místo přeskládání, pokud máte v tematické větvi pouze jednu revizi. Uvažujme tedy projekt, který vypadá jako na obrázku 5-26. Insert 18333fig0526.png -Figure 5-26. Uvažovaná historie před částečným převzetím +Obrázek 5-26. Uvažovaná historie před částečným převzetím Chcete-li do hlavní větve natáhnout revizi `e43a6`, můžete zadat následující příkaz: @@ -809,7 +809,7 @@ Chcete-li do hlavní větve natáhnout revizi `e43a6`, můžete zadat následuj Tímto natáhnete stejnou změnu, která byla provedena revizí `e43a6`, avšak hodnota SHA-1 obou revizí se bude lišit, neboť bude rozdílné datum aplikace. Vaše historie revizí bude nyní vypadat jako na obrázku 5-27. Insert 18333fig0527.png -Figure 5-27. Historie po částečném převzetí revize z tematické větve +Obrázek 5-27. Historie po částečném převzetí revize z tematické větve Nyní můžete tematickou větev odstranit a zahodit revize, které nehodláte natáhnout do jiné větve. diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown index c6c90d5de..55eaa1bd3 100644 --- a/cs/06-git-tools/01-chapter6.markdown +++ b/cs/06-git-tools/01-chapter6.markdown @@ -191,7 +191,7 @@ Nyní, když umíte určit jednotlivé revize, podíváme se, jak lze určovat c Nejčastěji se při označení intervalu používá dvojtečková syntax. Pomocí ní systému Git v podstatě říkáte, aby uvažoval celý interval revizí, které jsou dostupné z jedné revize, ale nejsou dostupné z jiné. Předpokládejme tedy, že máte historii revizí jako na obrázku 6-1. Insert 18333fig0601.png -Figure 6-1. Příklad historie revizí pro výběr intervalu +Obrázek 6-1. Příklad historie revizí pro výběr intervalu Vy chcete vidět, co všechno obsahuje vaše experimentální větev, kterou jste ještě nezačlenili do hlavní větve. Pomocí výrazu `master..experiment` můžete systému Git zadat příkaz, aby vám zobrazil log právě s těmito revizemi, doslova „všemi revizemi dostupnými z větve experiment a nedostupnými z hlavní větve“. V zájmu stručnosti a názornosti použiji v těchto příkladech místo skutečného výstupu logu písmena objektů revizí z diagramu v pořadí, jak by se zobrazily: diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown index 2ec47b7bc..ad1bb57d0 100644 --- a/cs/07-customizing-git/01-chapter7.markdown +++ b/cs/07-customizing-git/01-chapter7.markdown @@ -190,7 +190,7 @@ Až dokončíte celé nastavení, můžete spustit příkaz diff, např.: Výstup příkazu diff se nezobrazí na příkazovém řádku, ale Git spustí program P4Merge v podobě, jak je zachycen na obrázku 7-1. Insert 18333fig0701.png -Figure 7-1. P4Merge +Obrázek 7-1. P4Merge Jestliže se pokusíte sloučit dvě větve a dojde při tom ke konfliktu, můžete spustit příkaz `git mergetool`. Příkaz spustí program P4Merge, v němž budete moci v grafickém uživatelském rozhraní konflikt vyřešit. @@ -454,10 +454,10 @@ Tento výsledek má však omezené použití. Pokud nahradíte klíčové slovo Jak zjistíte, můžete pro substituce v souborech určených k zapsání/checkoutu napsat i vlastní filtry. Jedná se o filtry clean a smudge. V souboru `.gitattributes` můžete určit filtr pro konkrétní umístění a nastavit skripty, jimiž budou zpracovány soubory těsně před jejich zapsáním („clean“ – viz obrázek 7-2) a těsně před checkoutem („smudge“ – viz obrázek 7-3). Tyto filtry lze nastavit k různým šikovným úkonům. Insert 18333fig0702.png -Figure 7-2. Filtr smudge spuštěný při checkoutu – git checkout +Obrázek 7-2. Filtr smudge spuštěný při checkoutu – git checkout Insert 18333fig0703.png -Figure 7-3. Filtr clean spuštěný při přípravě souborů k zapsání – git add +Obrázek 7-3. Filtr clean spuštěný při přípravě souborů k zapsání – git add Původní zpráva k revizi s touto funkcí uvádí jednoduchý příklad, jak můžete před zapsáním prohnat veškeré vaše céčkové zdrojové texty programem `indent`. Tuto možnost lze aplikovat nastavením atributu `filter` v souboru `.gitattributes` tak, aby přefiltroval soubory `*.c` filtrem pro úpravu odsazování: diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown index 97b3dcbfc..81708d2b4 100644 --- a/cs/09-git-internals/01-chapter9.markdown +++ b/cs/09-git-internals/01-chapter9.markdown @@ -117,7 +117,7 @@ Syntaxe `master^{tree}` určuje objekt stromu, na nějž ukazuje poslední reviz Data, která Git ukládá, vypadají v principu jako na obrázku 9-1. Insert 18333fig0901.png -Figure 9-1. Zjednodušený model dat v systému Git +Obrázek 9-1. Zjednodušený model dat v systému Git Můžete si vytvořit i vlastní strom. Git běžně vytváří strom tak, že vezme stav oblasti připravených změn nebo-li indexu a zapíše z nich objekt stromu. Proto chcete-li vytvořit objekt stromu, musíte ze všeho nejdříve připravit soubory k zapsání, a vytvořit tak index. Chcete-li vytvořit index s jediným záznamem – první verzí souboru text.txt – můžete k tomu použít nízkoúrovňový příkaz `update-index`. Tento příkaz lze použít, jestliže chcete uměle přidat starší verzi souboru test.txt do nové oblasti připravených změn. K příkazu je třeba zadat parametr `--add`, neboť tento soubor ve vaší oblasti připravených změn ještě neexistuje (dokonce ještě nemáte ani vytvořenou oblast připravených změn), a parametr `--cacheinfo`, protože soubor, který přidáváte, není ve vašem adresáři, je ale ve vaší databázi. K tomu všemu přidáte režim, SHA-1 a název souboru: @@ -165,7 +165,7 @@ Všimněte si, že tento strom má oba záznamy souborů a že hodnota SHA soubo Pokud byste vytvořili pracovní adresář z nového stromu, který jste právě zapsali, dostali byste dva soubory na nejvyšší úrovni pracovního adresáře a podadresář `bak`, obsahující první verzi souboru test.txt. Data, která Git pro tyto struktury obsahuje, si můžete představit jako ilustraci na obrázku 9-2. Insert 18333fig0902.png -Figure 9-2. Struktura obsahu vašich současných dat Git +Obrázek 9-2. Struktura obsahu vašich současných dat Git ### Objekty revize ### @@ -242,7 +242,7 @@ Všechny tři tyto objekty revizí ukazují na jeden ze tří stromů snímku, k Pokud byste hledali vztahy mezi všemi interními ukazateli, vyšel by vám celý diagram objektů – viz obrázek 9-3. Insert 18333fig0903.png -Figure 9-3. Všechny objekty v adresáři Git +Obrázek 9-3. Všechny objekty v adresáři Git ### Ukládání objektů ### @@ -327,7 +327,7 @@ Vaše větev bude obsahovat pouze práci od této revize níže: Vaše databáze Git bude nyní v principu vypadat tak, jak je znázorněno na obrázku 9-4. Insert 18333fig0904.png -Figure 9-4. Objekty v adresáři Git s referencemi větve „head“ +Obrázek 9-4. Objekty v adresáři Git s referencemi větve „head“ Spouštíte-li příkaz typu `git branch (název větve)`, Git ve skutečnosti spustí příkaz `update-ref` a vloží hodnotu SHA-1 poslední revize větve, na níž se nacházíte, do nové reference, kterou chcete vytvořit. From 52d951fa6f62973818aa65e85cc1769bb89a8351 Mon Sep 17 00:00:00 2001 From: Dwaddle Date: Mon, 2 Sep 2013 16:11:12 +0200 Subject: [PATCH 13/37] [nl] Delete english text Translation was already done --- nl/06-git-tools/01-chapter6.markdown | 1 - 1 file changed, 1 deletion(-) diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown index 463042466..d207fcb00 100644 --- a/nl/06-git-tools/01-chapter6.markdown +++ b/nl/06-git-tools/01-chapter6.markdown @@ -403,7 +403,6 @@ Over het algemeen zul je `y` of `n` typen als je ieder stuk wilt stagen, maar ze De status van het simplegit.rb bestand is interessant. Het laat zien dat een paar regels gestaged zijn, en een paar niet. Je hebt dit bestand deels gestaged. Op dit punt kun je het interactieve toevoeg script verlaten en het `git commit` commando uitvoeren om de gedeeltelijk gestagede bestanden te committen. -Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line. Tot slot hoef je niet in de interactieve toevoeg modus te zijn om het gedeeltelijke bestands-stagen te doen – je kunt hetzelfde script starten door `git add -p` of `git add --patch` op de commando regel te gebruiken. ## Stashen ## From 1ff847d315c87c287067ce7502412697ec9c3044 Mon Sep 17 00:00:00 2001 From: Keenan Brock Date: Sun, 8 Sep 2013 21:36:03 -0400 Subject: [PATCH 14/37] added code to find ebook-convert --- Gemfile | 3 ++- makeebooks | 11 ++++++++++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/Gemfile b/Gemfile index ad5bb37f6..a37722ab6 100644 --- a/Gemfile +++ b/Gemfile @@ -1,4 +1,5 @@ source 'https://rubygems.org' gem 'maruku' -gem 'redcarpet' \ No newline at end of file +gem 'redcarpet' +gem 'rdiscount' diff --git a/makeebooks b/makeebooks index 4c15b8be1..5d2f308e4 100755 --- a/makeebooks +++ b/makeebooks @@ -99,7 +99,16 @@ ARGV.each do |lang| output.write(book_content) end - system('ebook-convert', "progit.#{lang}.html", "progit.#{lang}.#{format}", + $ebook_convert_cmd = ENV['ebook_convert_path'].to_s + if $ebook_convert_cmd.empty? + $ebook_convert_cmd = `which ebook-convert`.chomp + end + if $ebook_convert_cmd.empty? + mac_osx_path = '/Applications/calibre.app/Contents/MacOS/ebook-convert' + $ebook_convert_cmd = mac_osx_path + end + + system($ebook_convert_cmd, "progit.#{lang}.html", "progit.#{lang}.#{format}", '--cover', 'ebooks/cover.png', '--authors', authors, '--comments', comments, From 120cd6b88bb7bfd54e934d6240a343b42903b399 Mon Sep 17 00:00:00 2001 From: harupong Date: Tue, 10 Sep 2013 10:47:43 +0900 Subject: [PATCH 15/37] [ja] Apply b4854ff8dc42db658df66ecdd8fe2162a73ebdb5 Merge pull request #435 from GArik/EN https://github.com/progit/progit/commit/b4854ff8dc42db658df66ecdd8fe2162a73ebdb5 --- ja/07-customizing-git/01-chapter7.markdown | 35 +++++++++++----------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown index 7ad52a8b5..2df4feb59 100644 --- a/ja/07-customizing-git/01-chapter7.markdown +++ b/ja/07-customizing-git/01-chapter7.markdown @@ -307,11 +307,15 @@ Git の属性を使ってできるちょっとした技として、どのファ #### バイナリファイルの差分 #### -Gitでは、バイナリファイルの差分を効果的に扱うためにGitの属性機能を使うことができます。通常のdiff機能を使って比較を行うことができるように、バイナリデータをテキストデータに変換する方法をGitに教えればいいのです。 +Gitでは、バイナリファイルの差分を効果的に扱うためにGitの属性機能を使うことができます。通常のdiff機能を使って比較を行うことができるように、バイナリデータをテキストデータに変換する方法をGitに教えればいいのです。ただし問題があります。*バイナリ*データをどうやってテキストに変換するか？ということです。この場合、一番いい方法はバイナリファイル形式ごとに専用の変換ツールを使うことです。とはいえ、判読可能なテキストに変換可能なバイナリファイル形式はそう多くありません(音声データをテキスト形式に変換？うまくいかなさそうです...)。ただ、仮にそういった事例に出くわしデータをテキスト形式にできなかったとしても、ファイルの内容についての説明、もしくはメタデータを取得することはそれほど難しくないでしょう。もちろん、そのファイルについての全てがメタデータから読み取れるわけではありませんが、何もないよりはよっぽどよいはずです。 +これから、上述の2手法を用い、よく使われてるバイナリファイル形式から有用な差分を取得する方法を説明します。 + +補足： バイナリファイル形式で、かつデータがテキストで記述されているけれど、テキスト形式に変換するためのツールがないケースがよくあります。そういった場合、`strings` プログラムを使ってそのファイルからテキストを抽出できるかどうか、試してみるとよいでしょう。UTF-16 などのエンコーディングで記述されている場合だと、`strings` プログラムではうまくいかないかもしれません。どこまで変換できるかはケースバイケースでしょう。とはいえ、`strings` プログラムは 大半の Mac と Linux で使えるので、バイナリファイル形式を取り扱う最初の一手としては十分でしょう。 + ##### MS Word ファイル ##### -これは素晴らしい機能ですがほとんど知られていないので、少し例をあげてみたいと思います。あなたはまず最初に人類にとっても最も厄介な問題のひとつを解決するためにこのテクニックを使いたいと思うでしょう。そう、Wordで作成した文書のバージョン管理です。奇妙なことに、Wordは最悪のエディタだと全ての人が知っているにも係わらず、全ての人がWordを使っています。Word文書をバージョン管理したいと思ったなら、Gitのリポジトリにそれらを追加して、まとめてcommitすればいいのです。しかし、それでいいのでしょうか？ あなたが'git diff'をいつも通りに実行すると、次のように表示されるだけです。 +あなたはまずこれらのテクニックを使って、人類にとって最も厄介な問題のひとつ、Wordで作成した文書のバージョン管理を解決したいと思うでしょう。奇妙なことに、Wordは最悪のエディタだと全ての人が知っているにも係わらず、皆がWordを使っています。Word文書をバージョン管理したいと思ったなら、Gitのリポジトリにそれらを追加して、まとめてコミットすればいいのです。しかし、それでいいのでしょうか？ あなたが `git diff` をいつも通りに実行すると、次のように表示されるだけです。 $ git diff diff --git a/chapter1.doc b/chapter1.doc @@ -322,18 +326,16 @@ Gitでは、バイナリファイルの差分を効果的に扱うためにGit *.doc diff=word -これは、指定したパターン(.doc)にマッチした全てのファイルに対して、差分を表示する時には"word"というフィルタを使うべきであるとGitに教えているのです。"word"フィルタとは何でしょうか？ それはあなたが用意しなければなりません。Word文書をテキストファイルに変換するプログラムとして `strings` を使うように次のようにGitを設定してみましょう。 +これは、指定したパターン(.doc)にマッチした全てのファイルに対して、差分を表示する時には"word"というフィルタを使うべきであるとGitに教えているのです。"word"フィルタとは何でしょうか？ それはあなたが用意しなければなりません。Word文書をテキストファイルに変換するプログラムとして `catdoc` を使うように次のようにGitを設定してみましょう。なお、`catdoc` とは、差分を正しく表示するために、Word文書からテキストを取り出す専用のツール( `http://www.wagner.pp.ru/~vitus/software/catdoc/` からダウンロードできます。)です。 - $ git config diff.word.textconv strings + $ git config diff.word.textconv catdoc このコマンドは、`.git/config` に次のようなセクションを追加します。 [diff "word"] - textconv = strings - -補足: `.doc` ファイルにもさまざまな種類があります。中には UTF-16 エンコーディングやその他の "コードページ" を使っているものもあり、`strings` では有効な結果を得られないかもしれません。有用性も落ちる可能性があります。 + textconv = catdoc -これで、`.doc`という拡張子をもったファイルはそれぞれのファイルに`strings`というプログラムとして定義された"word"フィルタを通してからdiffを取るべきだということをGitは知っていることになります。こうすることで、Wordファイルに対して直接差分を取るのではなく、より効果的なテキストベースでの差分を取ることができるようになります。 +これで、`.doc` という拡張子をもったファイルはそれぞれのファイルに `catdoc` というプログラムとして定義された"word"フィルタを通してからdiffを取るべきだということをGitは知っていることになります。こうすることで、Wordファイルに対して直接差分を取るのではなく、より効果的なテキストベースでの差分を取ることができるようになります。 例を示しましょう。この本の第1章をGitリポジトリに登録した後、ある段落にいくつかの文章を追加して保存し、それから、変更箇所を確認するために`git diff`を実行しました。 @@ -342,15 +344,14 @@ Gitでは、バイナリファイルの差分を効果的に扱うためにGit index c1c8a0a..b93c9e4 100644 --- a/chapter1.doc +++ b/chapter1.doc - @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics - re going to cover how to get it and set it up for the first time if you don - t already have it on your system. - In Chapter Two we will go over basic Git usage - how to use Git for the 80% - -s going on, modify stuff and contribute changes. If the book spontaneously - +s going on, modify stuff and contribute changes. If the book spontaneously - +Let's see if this works. - -Gitは正しく、追加した"Let’s see if this works"という文字列を首尾よく、かつ、簡潔に知らせてくれました。予想外の差分が表示されているので、完璧といえません。しかし、正しく動作しているとはいえます。あなたがWord文書をテキストファイルに変換するもっと良いプログラムを見付けられれば、よりよい結果を得られるでしょう。とはいえ、`strings`はほとんどのMacとLinuxで動作するので、様々なバイナリフォーマットに試してみるのに、最初の選択肢としては良いと思います。 + @@ -128,7 +128,7 @@ and data size) + Since its birth in 2005, Git has evolved and matured to be easy to use + and yet retain these initial qualities. It’s incredibly fast, it’s + very efficient with large projects, and it has an incredible branching + -system for non-linear development (See Chapter 3). + +system for non-linear development. + +Gitは、追加した"(See Chapter 3)"という文字列を首尾よく、かつ、簡潔に知らせてくれました。正確で、申し分のない動作です！ ##### OpenDocument Text ファイル ##### From b1782e390ce0255b546b71037d0daebc912f780d Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Sun, 8 Sep 2013 01:07:15 +0400 Subject: [PATCH 16/37] Fix wrong arrow direction on Dia-version of figure 7.3 --- figures-dia/fig0703.dia | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/figures-dia/fig0703.dia b/figures-dia/fig0703.dia index 78c7b16ed..1d9cfddfc 100644 --- a/figures-dia/fig0703.dia +++ b/figures-dia/fig0703.dia @@ -529,7 +529,7 @@ - + @@ -541,13 +541,13 @@ - + - + - + @@ -655,7 +655,7 @@ - + From d444abc53197a647f1063aee427c0c36cc961b03 Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Tue, 10 Sep 2013 22:01:34 +0400 Subject: [PATCH 17/37] Reverse diff in the example with .doc files to match it with the description --- en/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown index 27911ed02..7029378e5 100644 --- a/en/07-customizing-git/01-chapter7.markdown +++ b/en/07-customizing-git/01-chapter7.markdown @@ -348,8 +348,8 @@ Here’s an example. I put Chapter 1 of this book into Git, added some text to a Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching - -system for non-linear development (See Chapter 3). - +system for non-linear development. + -system for non-linear development. + +system for non-linear development (See Chapter 3). Git successfully and succinctly tells me that I added the string "(See Chapter 3)", which is correct. Works perfectly! From cf2c75cdaad6990b79bade53a2121ebbfc6baf2d Mon Sep 17 00:00:00 2001 From: hex636b Date: Wed, 11 Sep 2013 20:25:06 +0800 Subject: [PATCH 18/37] modify a chinese character in 01-chapter7.markdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 石 --> 是 --- zh/07-customizing-git/01-chapter7.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown index 15bbbf8d3..d922e284f 100644 --- a/zh/07-customizing-git/01-chapter7.markdown +++ b/zh/07-customizing-git/01-chapter7.markdown @@ -687,7 +687,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为 check_directory_perms -以上的大部分内容应该都比较容易理解。通过 `git rev-list` 获取推送到服务器内容的提交列表。然后，针对其中每一项，找出它试图修改的文件然后确保执行推送的用户对这些文件具有权限。一个不太容易理解的 Ruby 技巧石 `path.index(access_path) ==0` 这句，它的返回真值如果路径以 `access_path` 开头——这是为了确保 `access_path ` 并不是只在允许的路径之一，而是所有准许全选的目录都在该目录之下。 +以上的大部分内容应该都比较容易理解。通过 `git rev-list` 获取推送到服务器内容的提交列表。然后，针对其中每一项，找出它试图修改的文件然后确保执行推送的用户对这些文件具有权限。一个不太容易理解的 Ruby 技巧是 `path.index(access_path) ==0` 这句，它的返回真值如果路径以 `access_path` 开头——这是为了确保 `access_path ` 并不是只在允许的路径之一，而是所有准许全选的目录都在该目录之下。 现在你的用户没法推送带有不正确的提交信息的内容，也不能在准许他们访问范围之外的位置做出修改。 From d351ce0427d1c31fb2d522bf820f94b829f1203c Mon Sep 17 00:00:00 2001 From: AngleMortSociety Date: Wed, 11 Sep 2013 19:27:51 +0200 Subject: [PATCH 19/37] Update 01-chapter5.markdown "e" manquant. --- fr/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/05-distributed-git/01-chapter5.markdown b/fr/05-distributed-git/01-chapter5.markdown index 1c064fd3d..a9a74bf2b 100644 --- a/fr/05-distributed-git/01-chapter5.markdown +++ b/fr/05-distributed-git/01-chapter5.markdown @@ -148,7 +148,7 @@ Le dernier point à soigner est le message de validation. S'habituer à écrire des messages de validation de qualité facilite grandement l'emploi et la collaboration avec Git. En règle générale, les messages doivent débuter par une ligne unique d'au plus 50 caractères décrivant concisément la modification, suivie d'une ligne vide, suivie d'une explication plus détaillée. Le projet Git exige que l'explication détaillée inclue la motivation de la modification en contrastant le nouveau comportement par rapport à l'ancien — c'est une bonne règle de rédaction. -Un bonne règle consiste aussi à utiliser le présent de l'impératif ou des verbes substantivés dans le message. +Une bonne règle consiste aussi à utiliser le présent de l'impératif ou des verbes substantivés dans le message. En d'autres termes, utilisez des ordres. Au lieu d'écrire « J'ai ajouté des tests pour » ou « En train d'ajouter des tests pour », utilisez juste « Ajoute des tests pour » ou « Ajout de tests pour ». From 8a103a8e06460ba227e30b62672d6ef90178ef3f Mon Sep 17 00:00:00 2001 From: Tomasz Jakub Skrynnyk Date: Wed, 11 Sep 2013 22:19:17 +0200 Subject: [PATCH 20/37] [pl] Spelling/typo fixes. --- pl/03-git-branching/01-chapter3.markdown | 10 +++---- pl/04-git-server/01-chapter4.markdown | 26 +++++++++---------- pl/06-git-tools/01-chapter6.markdown | 2 +- pl/07-customizing-git/01-chapter7.markdown | 18 ++++++------- pl/08-git-and-other-scms/01-chapter8.markdown | 6 ++--- 5 files changed, 31 insertions(+), 31 deletions(-) diff --git a/pl/03-git-branching/01-chapter3.markdown b/pl/03-git-branching/01-chapter3.markdown index 003851d46..d0538f3aa 100644 --- a/pl/03-git-branching/01-chapter3.markdown +++ b/pl/03-git-branching/01-chapter3.markdown @@ -268,7 +268,7 @@ Jeśli chcesz do rozwiązania tych problemów użyć narzędzia graficznego, mo {remote}: modified Hit return to start merge resolution tool (opendiff): -Jeśli chcesz użyć narzędzia innego niż domyślne (Git w tym przypadku wybrał dla mnie `opendiff`, ponieważ pracuję na Maku), możesz zobaczyć wszystkie wspierane narzędzia wymienione na samej górze, zaraz za „merge tool candidates”. Wpisz nazwę narzędzia, którego wolałbyś użyć. W Rozdziale 7 dowiemy się, jak zmienić domyślną wartość dla Twojego środowiska pracy. +Jeśli chcesz użyć narzędzia innego niż domyślne (Git w tym przypadku wybrał dla mnie `opendiff`, ponieważ pracuję na Maku), możesz zobaczyć wszystkie wspierane narzędzia wymienione na samej górze, zaraz za „merge tool candidates”. Wpisz nazwę narzędzia, którego wolałbyś użyć. W Rozdziale 7 dowiemy się, jak zmienić domyślną wartość dla twojego środowiska pracy. Po opuszczeniu narzędzia do scalania, Git zapyta, czy wszystko przebiegło pomyślnie. Jeśli odpowiesz skryptowi, że tak właśnie było, plik zostanie umieszczony w poczekalni, by konflikt oznaczyć jako rozwiązany. @@ -328,7 +328,7 @@ Aby zobaczyć wszystkie gałęzie zawierające zmiany, których jeszcze nie scal $ git branch --no-merged testing -Pokazuje to Twoją drugą gałąź. Ponieważ zawiera ona zmiany, które nie zostały jeszcze scalona, próba usunięcia jej poleceniem `git branch -d` nie powiedzie się: +Pokazuje to Twoją drugą gałąź. Ponieważ zawiera ona zmiany, które nie zostały jeszcze scalone, próba usunięcia jej poleceniem `git branch -d` nie powiedzie się: $ git branch -d testing error: The branch 'testing' is not an ancestor of your current HEAD. @@ -356,7 +356,7 @@ Ogólnie łatwiej jest myśleć o nich jak o silosach na zmiany, gdzie grupy zmi Insert 18333fig0319.png Figure 3-19. Może być ci łatwiej myśleć o swoich gałęziach jak o silosach. -Możesz powielić ten schemat na kilka poziomów stabilności. Niektóre większe projekty posiadają dodatkowo gałąź `proposed` albo `pu` („proposed updates” — proponowane zmiany), scalającą gałęzie, które nie są jeszcze gotowe trafić do gałęzi `next` czy `master`. Zamysł jest taki, że Twoje gałęzie reprezentują różne poziomy stabilności; kiedy osiągają wyższy stopień stabilności, są scalane do gałęzi powyżej. +Możesz powielić ten schemat na kilka poziomów stabilności. Niektóre większe projekty posiadają dodatkowo gałąź `proposed` albo `pu` („proposed updates” — proponowane zmiany), scalającą gałęzie, które nie są jeszcze gotowe trafić do gałęzi `next` czy `master`. Zamysł jest taki, że twoje gałęzie reprezentują różne poziomy stabilności; kiedy osiągają wyższy stopień stabilności, są scalane do gałęzi powyżej. Podobnie jak poprzednio, posiadanie takich długodystansowych gałęzi nie jest konieczne, ale często bardzo pomocne, zwłaszcza jeśli pracujesz przy dużych, złożonych projektach. ### Gałęzie tematyczne ### @@ -410,7 +410,7 @@ Figure 3-26. Dostajesz lokalny odnośnik do gałęzi master w repozytorium teamo ### Wypychanie zmian ### -Jeśli chcesz podzielić się swoją gałęzią ze światem, musisz wypchnąć zmiany na zdalny serwer, na którym posiadasz prawa zapisu. Twoje lokalne gałęzie nie są automatycznie synchronizowane z serwerem, na którym zapisujesz - musisz jawnie określić gałęzie, których zmianami chcesz się podzielić. W ten sposób możesz używać prywatnych gałęzi do pracy, której nie chcesz dzielić, i wypychać jedynie gałęzie tematyczne, w ramach których współpracujesz. +Jeśli chcesz podzielić się swoją gałęzią ze światem, musisz wypchnąć zmiany na zdalny serwer, na którym posiadasz prawa zapisu. twoje lokalne gałęzie nie są automatycznie synchronizowane z serwerem, na którym zapisujesz - musisz jawnie określić gałęzie, których zmianami chcesz się podzielić. W ten sposób możesz używać prywatnych gałęzi do pracy, której nie chcesz dzielić, i wypychać jedynie gałęzie tematyczne, w ramach których współpracujesz. Jeśli posiadasz gałąź o nazwie `serverfix`, w której chcesz współpracować z innymi, możesz wypchnąć swoje zmiany w taki sam sposób jak wypychałeś je w przypadku pierwszej gałęzi. Uruchom `git push (nazwa zdalnego repozytorium) (nazwa gałęzi)`: @@ -470,7 +470,7 @@ Załóżmy, że skończyłeś pracę ze zdalną gałęzią - powiedzmy, że ty i To git@github.com:schacon/simplegit.git - [deleted] serverfix -Bum. Nie ma już na serwerze tej gałęzi. Jeśli chcesz, zaznacz sobie tą stronę ponieważ będziesz potrzebował tego polecenia, a najprawdopodobniej zapomnisz jego składni. Polecenie to można spróbować zapamiętać przypominając sobie składnię `git push [nazwa zdalnego repozytorium] [gałąź lokalna]:[gałąź zdalna]`, którą omówiliśmy odrobinę wcześniej. Pozbywając się części [gałąź lokalna], mówisz mniej więcej "Weź nic z mojej strony i zrób z tego [gałąź zdalną]". +Bum. Nie ma już na serwerze tej gałęzi. Jeśli chcesz, zaznacz sobie tę stronę, ponieważ będziesz potrzebował tego polecenia, a najprawdopodobniej zapomnisz jego składni. Polecenie to można spróbować zapamiętać przypominając sobie składnię `git push [nazwa zdalnego repozytorium] [gałąź lokalna]:[gałąź zdalna]`, którą omówiliśmy odrobinę wcześniej. Pozbywając się części [gałąź lokalna], mówisz mniej więcej "Weź nic z mojej strony i zrób z tego [gałąź zdalną]". ## Zmiana bazy ## diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown index 632a3521f..0c2d4227c 100644 --- a/pl/04-git-server/01-chapter4.markdown +++ b/pl/04-git-server/01-chapter4.markdown @@ -10,7 +10,7 @@ Zdalne repozytorium to nic innego jak samo repozytorium bez kopii roboczej (ang. ## Protokoły ## -Git potrafi korzystać z czterech podstawowych protokołów sieciowych do przesyłu danych: lokalnego, Secure Shell (SSH), Git, oraz HTTP. Poniżej opiszemy czym się charakteryzują i w jakich sytuacjach wartko korzystać (lub wręcz przeciwnie) z jednego z nich. +Git potrafi korzystać z czterech podstawowych protokołów sieciowych do przesyłu danych: lokalnego, Secure Shell (SSH), Git, oraz HTTP. Poniżej opiszemy czym się charakteryzują i w jakich sytuacjach warto korzystać (lub wręcz przeciwnie) z jednego z nich. Istotne jest, że z wyjątkiem protokołu HTTP, wszystkie pozostałe wymagają by na serwerze został zainstalowany Git. @@ -119,7 +119,7 @@ Aby sklonować repozytorium jako nowe, czyste repozytorium, należy uruchomić p $ git clone --bare my_project my_project.git Initialized empty Git repository in /opt/projects/my_project.git/ -Informacje wyświetlane przez to polecenia mogą być mylące. Ponieważ `clone` to tak naprawdę `git init` + `git fetch`, można zobaczyć informacje wyświetlane przez część związaną z `git init`, która powoduje utworzenie pustego katalogu. Ma miejsce rzeczywiste kopiowanie obiektów, ale nie powoduje to wyświetlenia jakiejkolwiek informacji. Teraz powinieneś mieć kopię katalogu Git w katalogu `my_project.git`. +Informacje wyświetlane przez to polecenie mogą być mylące. Ponieważ `clone` to tak naprawdę `git init` + `git fetch`, można zobaczyć informacje wyświetlane przez część związaną z `git init`, która powoduje utworzenie pustego katalogu. Ma miejsce rzeczywiste kopiowanie obiektów, ale nie powoduje to wyświetlenia jakiejkolwiek informacji. Teraz powinieneś mieć kopię katalogu Git w katalogu `my_project.git`. Ogólnie rzecz biorąc odpowiada to następującemu poleceniu: @@ -147,7 +147,7 @@ Widać zatem, że bardzo prosto jest wziąć repozytorium Git, utworzyć jego cz Warto zaznaczyć, że to właściwie wszystko czego potrzeba, aby utworzyć działający serwer Git, do którego dostęp ma kilka osób - wystarczy utworzyć dla nich konta SSH i wstawić czyste repozytorium gdzieś, gdzie osoby te mają dostęp i uprawnienia do zapisu i odczytu. Więcej nie trzeba - można działać. -W następnych sekcjach zobaczysz jak przeprowadzić bardziej zaawansowaną konfigurację. Sprawdzimy jak uniknąć konieczności tworzenia kont użytkowników dla każdej osoby, jak dodać publiczny dostęp tylko do odczytu, jak skonfigurować interfejs WWW, jak wykorzystać narzędzie Gitosis i inne. Miej jednak na uwadzę, że do pracy nad prywatnym projektem w kilka osób, _wszystko_, czego potrzeba to serwer z dostępem SSH i czyste repozytorium. +W następnych sekcjach zobaczysz jak przeprowadzić bardziej zaawansowaną konfigurację. Sprawdzimy jak uniknąć konieczności tworzenia kont użytkowników dla każdej osoby, jak dodać publiczny dostęp tylko do odczytu, jak skonfigurować interfejs WWW, jak wykorzystać narzędzie Gitosis i inne. Miej jednak na uwadze, że do pracy nad prywatnym projektem w kilka osób, _wszystko_, czego potrzeba to serwer z dostępem SSH i czyste repozytorium. ### Prosta konfiguracja ### @@ -233,7 +233,7 @@ Od tego momentu możesz ustawić puste repozytorium poprzez komendę 'git init' $ cd project.git $ git --bare init -Teraz John, Josie lub Jessica ma możliwość wykonania komendy push (wysłania) pierwszej wersji projektu do repozytorium poprzez dodanie go (projektu) jako zdalny (remote) oraz wysłanie całej gałęzi projektu. Aby tego dokonać należy połączyć sie poprzez shell z maszyną i utworzyć nowe repozytorium za każdym razem kiedy chcemy dodać projekt. Użyjmy `gitserver` jako nazwę serwera, na którym ustawisz użytkownika `git` oraz repozytorium. Jeżeli odpalasz je lokalnie i ustawiasz DNS jako `gitserver` do połączenia z tym serwerem, wtedy będziesz mógł użyć poniższych komend: +Teraz John, Josie lub Jessica ma możliwość wykonania komendy push (wysłania) pierwszej wersji projektu do repozytorium poprzez dodanie go (projektu) jako zdalny (remote) oraz wysłanie całej gałęzi projektu. Aby tego dokonać należy połączyć się poprzez shell z maszyną i utworzyć nowe repozytorium za każdym razem kiedy chcemy dodać projekt. Użyjmy `gitserver` jako nazwę serwera, na którym ustawisz użytkownika `git` oraz repozytorium. Jeżeli odpalasz je lokalnie i ustawiasz DNS jako `gitserver` do połączenia z tym serwerem, wtedy będziesz mógł użyć poniższych komend: # on Johns computer $ cd myproject @@ -290,7 +290,7 @@ Co robi to podpięcie `post-update`? Generalnie wygląda ono tak: #!/bin/sh exec git-update-server-info -To oznacza ze kiedy wysyłasz do serwera przez SSH, Git uruchomi tę komendę, aby uaktualnić pliki potrzebne do ściągania przez HTTP. +To oznacza, że kiedy wysyłasz do serwera przez SSH, Git uruchomi tę komendę, aby uaktualnić pliki potrzebne do ściągania przez HTTP. Następnie do ustawień swojego serwera Apache musisz dodać pozycję VirtualHost z głównym dokumentem jako główny katalog twoich projektów Git. Tutaj zakładamy, ze masz ustawiony wildcard DNS do wysyłania `*.gitserver` do jakiegokolwiek pudła, którego używasz do uruchamiania tego wszystkiego: @@ -657,7 +657,7 @@ Wiele wymiany kodu w świecie gita zdarza się jako żądania pobrania zmian "pl Takie podejście spowodowałoby takie samo zamieszanie z gałęziami jak w scentralizowanych systemach VCS, dodatkowo ustawianie uprawnień jest harówką dla administratora. -Gitolite pozwala nam na zdefiniowanie prefiksów "osobistych" lub "scratch" przestrzeni nazw dla każdego developera (na przykład `refs/personal//*`); zobacz sekcje "osobiste gałęzie" w `doc/3-faq-tips-etc.mkd`. +Gitolite pozwala nam na zdefiniowanie prefiksów "osobistych" lub "scratch" przestrzeni nazw dla każdego developera (na przykład `refs/personal//*`); zobacz sekcję "osobiste gałęzie" w `doc/3-faq-tips-etc.mkd`. ### Repozytoria "Wildcard" ### @@ -737,7 +737,7 @@ Jeśli zdecydujesz się nie używać Gitosis, ale chcesz ustawić Git demona, mu $ cd /path/to/project.git $ touch git-daemon-export-ok -Obecność tego pliku mówi Git'owi, że można serwować ten projekt bez autoryzacji. +Obecność tego pliku mówi Gitowi, że można serwować ten projekt bez autoryzacji. Gitosis może także kontrolować, który projekt GitWeb ma pokazywać. Najpierw, musisz dodać coś takiego do pliku `/etc/gitweb.conf`: @@ -788,7 +788,7 @@ Jeśli jest to możliwe to jest to dobry moment aby dodać swój publiczny klucz Kliknięcie "I agree, sign me up" powoduje przeniesienie do nowego panelu użytkownika (patrz rysunek 4-4). Insert 18333fig0404.png -Figure 4-4. Panel użytkowinia GitHub. +Figure 4-4. Panel użytkownika GitHub. Następnie możesz utworzyć nowe repozytorium. @@ -866,13 +866,13 @@ Po tym jak wyślesz swój projekt lub zaimportujesz z Subversion, będziesz mia Insert 18333fig0413.png Figure 4-13. Strona główna projektu GitHub. -Kiedy ludzie będą odwiedzali Twój projekt, zobaczą tą stronę. Zawiera ona kilka kart. Karta zatwierdzeń pokazuje zatwierdzenia w odwrotnej kolejności, tak samo jak w przypadku polecenia `git log`. Karta połączeń pokazuje wszystkich którzy zrobili rozwidlenie Twojego projektu i uzupełniają go. Karta ściągnięć pozwala Tobie załadować pliki binarne do projektu oraz linki do paczek z kodami i spakowane wersje wszystkich zaznaczonych punktów w projekcie. Karta Wiki pozwala na dodawanie dokumentacji oraz informacji do projektu. Karta Grafów pokazuje w graficzny sposób statystyki użytkowania projektu. Głowna karta z plikami źródłowymi, które lądują w projekcie pokazuje listę katalogów w projekcie i automatycznie renderuje plik README poniżej jeśli taki znajduje się w głównym katalogu projektu. Ta karta pokazuje również okno z zatwierdzeniami. +Kiedy ludzie będą odwiedzali Twój projekt, zobaczą tę stronę. Zawiera ona kilka kart. Karta zatwierdzeń pokazuje zatwierdzenia w odwrotnej kolejności, tak samo jak w przypadku polecenia `git log`. Karta połączeń pokazuje wszystkich którzy zrobili rozwidlenie Twojego projektu i uzupełniają go. Karta ściągnięć pozwala ci załadować pliki binarne do projektu oraz linki do paczek z kodami i spakowane wersje wszystkich zaznaczonych punktów w projekcie. Karta Wiki pozwala na dodawanie dokumentacji oraz informacji do projektu. Karta Grafów pokazuje w graficzny sposób statystyki użytkowania projektu. Głowna karta z plikami źródłowymi, które lądują w projekcie pokazuje listę katalogów w projekcie i automatycznie renderuje plik README poniżej jeśli taki znajduje się w głównym katalogu projektu. Ta karta pokazuje również okno z zatwierdzeniami. ### Rozwidlanie projektu ### Jeśli chcesz przyczynić się do rozwoju istniejącego projektu, w którym nie masz możliwości wysyłania, GitHub zachęca do rozwidlania projektu. Kiedy znajdziesz się na stronie która wydaje się interesująca i chcesz pogrzebać w niej trochę, możesz nacisnąć przycisk "fork" w nagłówku projektu aby GitHub skopiował projekt do Twojego użytkownika tak abyś mógł do niego wprowadzać zmiany. -W tego typu projektach nie musimy martwić się o dodawanie współpracowników aby nadać im prawo do wysyłania. Ludzie moga rozwidlić projekt i swobodnie wysyłać do niego, a głowny opiekun projektu może pobrać te zmiany dodając gałąź jako zdalną i połączyć go z głównym projektem. +W tego typu projektach nie musimy martwić się o dodawanie współpracowników aby nadać im prawo do wysyłania. Ludzie mogą rozwidlić projekt i swobodnie wysyłać do niego, a główny opiekun projektu może pobrać te zmiany dodając gałąź jako zdalną i połączyć go z głównym projektem. Aby rozwidlić projekt, odwiedź stronę projektu (w tym przykładzie, mojombo/chronic) i naciśnij przycisk "fork" w nagłówku (zobacz Rysunek 4-14). @@ -886,12 +886,12 @@ Figure 4-15. Twoje rozwidlenie projektu. ### Podsumowanie GitHub ### -To już wszystko o GitHub, ale ważne jest aby zaznaczyć jak szybko można to wszystko zrobić. Możesz stworzyć konto, dodać nowy projekt i wysłać go w kilka minut. Jeśli Twój projekt jest typu open source, dodatkowo zyskujesz ogromną społeczność programistów, którzy mają teraz wgląd do Twojego projektu i mogą pomóc jego rozwoju tworząc rozwidlenie. W ostateczności, może to być sposób na zaznajomienie się i szybkie wypróbowanie Git'a. +To już wszystko o GitHub, ale ważne jest aby zaznaczyć jak szybko można to wszystko zrobić. Możesz stworzyć konto, dodać nowy projekt i wysłać go w kilka minut. Jeśli Twój projekt jest typu open source, dodatkowo zyskujesz ogromną społeczność programistów, którzy mają teraz wgląd do twojego projektu i mogą pomóc w jego rozwoju tworząc rozwidlenie. W ostateczności, może to być sposób na zaznajomienie się i szybkie wypróbowanie Gita. ## Podsumowanie ## -Istnieje kilka sposobów na stworzenie repozytorium Git'a, w celu kooperacji z innymi lub dzielenia się swoją pracą. +Istnieje kilka sposobów na stworzenie repozytorium Gita, w celu kooperacji z innymi lub dzielenia się swoją pracą. -Postawienie własnego serwera daje Ci sporą kontrolę i umożliwia działanie serwera za własnym firewall'em, ale taki serwer na ogół wymaga sporo czasu na stworzenie i utrzymanie. Jeśli umieścisz swoje dane na gotowym hostingu, to jest to łatwe do skonfigurowania i utrzymania, ale musisz być w stanie utrzymać swój kod na cudzych serwerach, a niektóre organizacje na to nie pozwalają. +Postawienie własnego serwera daje Ci sporą kontrolę i umożliwia działanie serwera za własnym firewallem, ale taki serwer na ogół wymaga sporo czasu na stworzenie i utrzymanie. Jeśli umieścisz swoje dane na gotowym hostingu, to jest to łatwe do skonfigurowania i utrzymania, ale musisz być w stanie utrzymać swój kod na cudzych serwerach, a niektóre organizacje na to nie pozwalają. Określenie, które rozwiązanie lub połączenie rozwiązań jest odpowiednie dla Ciebie i Twojej organizacji powinno być dość proste. diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown index 8357fc007..5225365a1 100644 --- a/pl/06-git-tools/01-chapter6.markdown +++ b/pl/06-git-tools/01-chapter6.markdown @@ -1096,7 +1096,7 @@ Git zobaczył, że 12 zmian było wprowadzonych między commitem który uznałe Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing -Teraz jest na innym commicie, w połowie drogi między tym który właśnie przetestowałeś, a tym oznaczonym jako zły. Uruchamiasz swój test ponownie i widisz, że obecna wersja zawiera błąd, więc wskazujesz to Gitowi za pomocą `git bisect bad`: +Teraz jest na innym commicie, w połowie drogi między tym który właśnie przetestowałeś, a tym oznaczonym jako zły. Uruchamiasz swój test ponownie i widzisz, że obecna wersja zawiera błąd, więc wskazujesz to Gitowi za pomocą `git bisect bad`: diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown index c8c89bb8c..c23b185a8 100644 --- a/pl/07-customizing-git/01-chapter7.markdown +++ b/pl/07-customizing-git/01-chapter7.markdown @@ -30,7 +30,7 @@ Następnym miejscem w które Git zajrzy jest plik `~/.gitconfig`, wskazujący na -Na końcu, Git szuka ustawień w pliku konfiguracyjnym znajdującym się z katalogu Git (`.git/config`) w każdym repozytorium którego obecnie uzywasz. Ustawienia te są specyficzne dla tego konkretnego repozytorium. Każdy z poziomów nadpisuje ustawienia poprzedniegi poziomy, więc na przykład ustawienia w `.git/config` napisują te z `/etc/gitconfig`. Możesz również ustawiać wartości ręcznie poprzez edycję i wprowadzenie danych w poprawnym formacie, ale generalnie dużo ławiej jest użyć komendy `git config`. +Na końcu, Git szuka ustawień w pliku konfiguracyjnym znajdującym się z katalogu Git (`.git/config`) w każdym repozytorium którego obecnie używasz. Ustawienia te są specyficzne dla tego konkretnego repozytorium. Każdy z poziomów nadpisuje ustawienia poprzedniego poziomu, więc na przykład ustawienia w `.git/config` nadpisują te z `/etc/gitconfig`. Możesz również ustawiać wartości ręcznie poprzez edycję i wprowadzenie danych w poprawnym formacie, ale generalnie dużo łatwiej jest użyć komendy `git config`. @@ -38,7 +38,7 @@ Na końcu, Git szuka ustawień w pliku konfiguracyjnym znajdującym się z katal -Opcje konfiguracyjne rozpoznawane przez Gita dzielą się na dwie kategorie: opcje klienta i serwera. Większość opcji dotyczy konfiguracji klienta - ustawień Twoich własnych preferencji. Chociaż jest dostępnych mnóstwo opcji, opiszę tylko kilka te z nich, którę są albo często używane lub mogą w znaczący sposób wpłynąć na Twoją pracę. Duża ilość opcji jest użyteczna tylko w specyficznych sytuacjach, których nie opiszę tutaj. Jeżeli chcesz zobaczyć listę wszystkich opcji konfiguracyjnych które Twoja wersja Gita rozpoznaje, uruchom +Opcje konfiguracyjne rozpoznawane przez Gita dzielą się na dwie kategorie: opcje klienta i serwera. Większość opcji dotyczy konfiguracji klienta - ustawień Twoich własnych preferencji. Chociaż jest dostępnych mnóstwo opcji, opiszę tylko kilka te z nich, które są albo często używane lub mogą w znaczący sposób wpłynąć na Twoją pracę. Duża ilość opcji jest użyteczna tylko w specyficznych sytuacjach, których nie opiszę tutaj. Jeżeli chcesz zobaczyć listę wszystkich opcji konfiguracyjnych które Twoja wersja Gita rozpoznaje, uruchom @@ -100,13 +100,13 @@ Potem, Twój edytor będzie ustawiał coś takiego jako domyślną treść komen ~ ".git/COMMIT_EDITMSG" 14L, 297C -Jeżeli masz specjalną politykę tworzenia treści komentarzy, to ustawienie takiego szablonu i skonfigurowanie Gita aby go używał zwiekszy szanse na to, że będzie ona regularnie przestrzegana. +Jeżeli masz specjalną politykę tworzenia treści komentarzy, to ustawienie takiego szablonu i skonfigurowanie Gita aby go używał zwiększy szanse na to, że będzie ona regularnie przestrzegana. #### core.pager #### -Wartość core.pager określa jaki program do stronnicowania jest używany przez Gita podczas pokazywania wyników komend `log` i `diff`. Możesz ustawić je na `more` lub inny ulubiony (domyślnie jest to `less`), lub możesz zupełnie je wyłączyć przez ustawienie pustej wartości: +Wartość core.pager określa jaki program do stronicowania jest używany przez Gita podczas pokazywania wyników komend `log` i `diff`. Możesz ustawić je na `more` lub inny ulubiony (domyślnie jest to `less`), lub możesz zupełnie je wyłączyć przez ustawienie pustej wartości: @@ -170,7 +170,7 @@ Gdy ta wartość jest ustawiona, Git będzie pokazywał w kolorze wyniki swojego -Bardzo rzadko będziesz potrzebował `color.ui = always`. Najczęściej, jeżeli będziesz chciał kolory w wynik działania Gita, użyjesz opcji `--color` do komendy Gita, aby wymisić na nim użycie kolorów. Ustawienie `color.ui = true` jest najczęściej tym, które będziesz chciał użyć. +Bardzo rzadko będziesz potrzebował `color.ui = always`. Najczęściej, jeżeli będziesz chciał kolory w wynik działania Gita, użyjesz opcji `--color` do komendy Gita, aby wymusić na nim użycie kolorów. Ustawienie `color.ui = true` jest najczęściej tym, które będziesz chciał użyć. @@ -203,11 +203,11 @@ Zobacz podręcznik systemowy do komendy `git config`, aby poznać wszystkie usta -Chociaż Git posiada wbudowaną obsługę narzedzia diff, którego dotychczas używałeś, możesz ustawić inny zewnętrzny program zamiast niego. Możesz również ustawić graficzny program pozwalający na łączenie zmian i rozwiązywanie konfliktów, bez konieczności robienia tego ręcznie. Zaprezentuję na przykładzie Perforce Visual Merge Tool (P4Merge) w jaki sposób ustawić do obsługi łączenia i pokazywania różnic zewnętrzny program, ponieważ ma on prosty graficzny interfejs i jest darmowy. +Chociaż Git posiada wbudowaną obsługę narzędzia diff, którego dotychczas używałeś, możesz ustawić inny zewnętrzny program zamiast niego. Możesz również ustawić graficzny program pozwalający na łączenie zmian i rozwiązywanie konfliktów, bez konieczności robienia tego ręcznie. Zaprezentuję na przykładzie Perforce Visual Merge Tool (P4Merge) w jaki sposób ustawić do obsługi łączenia i pokazywania różnic zewnętrzny program, ponieważ ma on prosty graficzny interfejs i jest darmowy. -Jeżeli chcesz tego również spróbować, P4Merge działa na wszystkich głównych platformach, więc prawdopodobnie będziesz mogł to zrobić. Będę używał nazw ścieżek w przykładach które działają na systemach Mac i Linux; dla systemu Windows bedziesz musiał zmienić `/usr/local/bin` na odpowiednią ścieżkę w Twoim środowisku. +Jeżeli chcesz tego również spróbować, P4Merge działa na wszystkich głównych platformach, więc prawdopodobnie będziesz mógł to zrobić. Będę używał nazw ścieżek w przykładach które działają na systemach Mac i Linux; dla systemu Windows będziesz musiał zmienić `/usr/local/bin` na odpowiednią ścieżkę w Twoim środowisku. @@ -217,7 +217,7 @@ Możesz pobrać P4Merge stąd: http://www.perforce.com/perforce/downloads/component.html -Na początek, ustawimy zewnętrzny skrypt do uruchamiania komend. Użyję ścieżki z systemu Mac wskazującej na program; w innych systemach, będzie ona musiała wskazywać na miejscej w którym program `p4merge` został zainstalowany. Stwórz skrypt o nazwie `extMerge`, który bedzie przyjmował wszystkie podane parametry i uruchamiał program: +Na początek, ustawimy zewnętrzny skrypt do uruchamiania komend. Użyję ścieżki z systemu Mac wskazującej na program; w innych systemach, będzie ona musiała wskazywać na miejsce w którym program `p4merge` został zainstalowany. Stwórz skrypt o nazwie `extMerge`, który będzie przyjmował wszystkie podane parametry i uruchamiał program: @@ -226,7 +226,7 @@ Na początek, ustawimy zewnętrzny skrypt do uruchamiania komend. Użyję ście /Applications/p4merge.app/Contents/MacOS/p4merge $* -Skrypt do obsługi diff sprawdza czy zostało podanych 7 argumentów i przekazuje dwa z nicg do skryptu obsłiugującego merge. Domyślnie, Git przekazuje te argumenty do programu obsługującego pokazywanie różnic: +Skrypt do obsługi diff sprawdza czy zostało podanych 7 argumentów i przekazuje dwa z nich do skryptu obsługującego merge. Domyślnie, Git przekazuje te argumenty do programu obsługującego pokazywanie różnic: diff --git a/pl/08-git-and-other-scms/01-chapter8.markdown b/pl/08-git-and-other-scms/01-chapter8.markdown index 46fb4a52f..c7c5762a8 100644 --- a/pl/08-git-and-other-scms/01-chapter8.markdown +++ b/pl/08-git-and-other-scms/01-chapter8.markdown @@ -208,7 +208,7 @@ Widać również, że suma SHA która oryginalnie rozpoczynała się od `97031e5 -Jeżeli współpracujesz z innymi programistami, a jeden z Was w pewnym momencie wypchnie jakieś zmiany, drugi może napotkać konflikt podczas próby wypchnęcia swoich zmian. Ta zmiana będzie odrzucona, do czasu włączenia tamtych. W `git svn`, wygląda to tak: +Jeżeli współpracujesz z innymi programistami, a jeden z Was w pewnym momencie wypchnie jakieś zmiany, drugi może napotkać konflikt podczas próby wypchnięcia swoich zmian. Ta zmiana będzie odrzucona, do czasu włączenia tamtych. W `git svn`, wygląda to tak: @@ -283,7 +283,7 @@ Uruchamianie `git svn rebase` co jakiś czas, pozwoli Ci upewnić się, że masz -Jak już przyzwyczaisz się do pracy z Gitem, z pewnością będziesz tworzył gałęzie tematyczne, pracował na nich, a następnie włączał je. Jeżeli wypychasz zmiany do serwera Subversion za pomocą komendy `git svn`, możesz chcieć wykonać "rebase" na wszystkich swoich zmianach włączając je do jednej gałęzi, zamiast łączyć gałezie razem. Powodem takiego sposobu działania jest to, że Subversion ma liniową historię i nie obsługuje łączenia zmian w taki sposób jak Git, więc `git svn` będzie podążał tylko za pierwszym rodzicem podczas konwertowania migawki do commitu Subversion. +Jak już przyzwyczaisz się do pracy z Gitem, z pewnością będziesz tworzył gałęzie tematyczne, pracował na nich, a następnie włączał je. Jeżeli wypychasz zmiany do serwera Subversion za pomocą komendy `git svn`, możesz chcieć wykonać "rebase" na wszystkich swoich zmianach włączając je do jednej gałęzi, zamiast łączyć gałęzie razem. Powodem takiego sposobu działania jest to, że Subversion ma liniową historię i nie obsługuje łączenia zmian w taki sposób jak Git, więc `git svn` będzie podążał tylko za pierwszym rodzicem podczas konwertowania migawki do commitu Subversion. @@ -488,7 +488,7 @@ Narzędzia dostarczane przez `git svn` są przydatne, jeżeli musisz używać se * Keep a linear Git history that doesn’t contain merge commits made by `git merge`. Rebase any work you do outside of your mainline branch back onto it; don’t merge it in. * Don’t set up and collaborate on a separate Git server. Possibly have one to speed up clones for new developers, but don’t push anything to it that doesn’t have a `git-svn-id` entry. You may even want to add a `pre-receive` hook that checks each commit message for a `git-svn-id` and rejects pushes that contain commits without it. --> -Jeżeli będziesz postępował zgodnie z tymi wskazówkami, praca z repozytoriami Subersion będzie bardziej znośna. Jednak, jeżeli możliwe jest przeniesienie się na prawdziwy serwer Gita, powinieneś to zrobić, a cały zespół jeszcze więcej na tym skorzysta. +Jeżeli będziesz postępował zgodnie z tymi wskazówkami, praca z repozytoriami Subversion będzie bardziej znośna. Jednak, jeżeli możliwe jest przeniesienie się na prawdziwy serwer Gita, powinieneś to zrobić, a cały zespół jeszcze więcej na tym skorzysta. From fb4d788817b175b0ca035ff02065bddef5310764 Mon Sep 17 00:00:00 2001 From: chenhui Date: Fri, 13 Sep 2013 17:48:29 +0800 Subject: [PATCH 21/37] fix a minor problem --- zh/09-git-internals/01-chapter9.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown index b549612db..2f1b11229 100644 --- a/zh/09-git-internals/01-chapter9.markdown +++ b/zh/09-git-internals/01-chapter9.markdown @@ -225,7 +225,7 @@ commit 对象有格式很简单：指明了该时间点项目快照的顶层树 test.txt | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -真棒。你刚刚通过使用低级操作而不是那些普通命令创建了一个 Git 历史。这基本上就是运行　`git add` 和 `git commit` 命令时 Git 进行的工作　──保存修改了的文件的 blob，更新索引，创建 tree 对象，最后创建 commit 对象，这些 commit 对象指向了顶层 tree 对象以及先前的 commit 对象。这三类 Git 对象 ── blob，tree 以及 tree ── 都各自以文件的方式保存在 `.git/objects` 目录下。以下所列是目前为止样例中的所有对象，每个对象后面的注释里标明了它们保存的内容： +真棒。你刚刚通过使用低级操作而不是那些普通命令创建了一个 Git 历史。这基本上就是运行　`git add` 和 `git commit` 命令时 Git 进行的工作　──保存修改了的文件的 blob，更新索引，创建 tree 对象，最后创建 commit 对象，这些 commit 对象指向了顶层 tree 对象以及先前的 commit 对象。这三类 Git 对象 ── blob，tree 以及 commit ── 都各自以文件的方式保存在 `.git/objects` 目录下。以下所列是目前为止样例中的所有对象，每个对象后面的注释里标明了它们保存的内容： $ find .git/objects -type f .git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2 From 7a51dcdc456f27dbfe24688b8f706588a0f188ca Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Sun, 15 Sep 2013 03:01:23 +0400 Subject: [PATCH 22/37] Fix a bunch of typos on Dia figures in chapter 3 --- figures-dia/fig0323.dia | 2 +- figures-dia/fig0325.dia | 6 +++--- figures-dia/fig0326.dia | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/figures-dia/fig0323.dia b/figures-dia/fig0323.dia index 771326ba6..b7a5e05b2 100644 --- a/figures-dia/fig0323.dia +++ b/figures-dia/fig0323.dia @@ -270,7 +270,7 @@ - #31b8c# + #31b8e# diff --git a/figures-dia/fig0325.dia b/figures-dia/fig0325.dia index 5436e3e4f..79de145d9 100644 --- a/figures-dia/fig0325.dia +++ b/figures-dia/fig0325.dia @@ -758,7 +758,7 @@ - #a38de# + #31b8e# @@ -1150,7 +1150,7 @@ - #a38de# + #31b8e# @@ -1349,7 +1349,7 @@ - #a38de# + #31b8e# diff --git a/figures-dia/fig0326.dia b/figures-dia/fig0326.dia index b881207fb..9537a82bf 100644 --- a/figures-dia/fig0326.dia +++ b/figures-dia/fig0326.dia @@ -725,7 +725,7 @@ - #a38de# + #31b8e# @@ -1117,7 +1117,7 @@ - #a38de# + #31b8e# @@ -1316,7 +1316,7 @@ - #a38de# + #31b8e# From 5da0901ab72541ac4d91adee0c5471c8f2b12847 Mon Sep 17 00:00:00 2001 From: AngleMortSociety Date: Sun, 15 Sep 2013 18:52:38 +0200 Subject: [PATCH 23/37] 'e' missing --- fr/05-distributed-git/01-chapter5.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/05-distributed-git/01-chapter5.markdown b/fr/05-distributed-git/01-chapter5.markdown index a9a74bf2b..8457ee105 100644 --- a/fr/05-distributed-git/01-chapter5.markdown +++ b/fr/05-distributed-git/01-chapter5.markdown @@ -723,7 +723,7 @@ Que vous mainteniez le dépôt de référence ou que vous souhaitiez aider en v ### Travail dans des branches thématiques ### -Quand vous vous apprêtez à intégrer des contributions, un bonne idée consiste à les essayer d'abord dans une branche thématique, une branche temporaire spécifiquement créée pour essayer cette nouveauté. +Quand vous vous apprêtez à intégrer des contributions, une bonne idée consiste à les essayer d'abord dans une branche thématique, une branche temporaire spécifiquement créée pour essayer cette nouveauté. De cette manière, il est plus facile de rectifier un patch à part et de le laisser s'il ne fonctionne pas jusqu'à ce que vous disposiez de temps pour y travailler. Si vous créez une simple branche nommée d'après le thème de la modification que vous allez essayer, telle que `ruby_client` ou quelque chose d'aussi descriptif, vous pouvez vous en souvenir simplement plus tard. Le mainteneur du projet Git a l'habitude d'utiliser des espaces de nommage pour ses branches, tels que `sc/ruby_client`, où `sc` représente les initiales de la personne qui a contribué les modifications. From 74a739511c6c4afe426361f7f4c01fbb776d9974 Mon Sep 17 00:00:00 2001 From: harupong Date: Tue, 17 Sep 2013 10:30:11 +0900 Subject: [PATCH 24/37] [ja] Fix incorrect example in "diffing binary files" section --- ja/07-customizing-git/01-chapter7.markdown | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown index 2df4feb59..860824fbe 100644 --- a/ja/07-customizing-git/01-chapter7.markdown +++ b/ja/07-customizing-git/01-chapter7.markdown @@ -348,8 +348,8 @@ Gitでは、バイナリファイルの差分を効果的に扱うためにGit Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching - -system for non-linear development (See Chapter 3). - +system for non-linear development. + -system for non-linear development. + +system for non-linear development (See Chapter 3). Gitは、追加した"(See Chapter 3)"という文字列を首尾よく、かつ、簡潔に知らせてくれました。正確で、申し分のない動作です！ From bcadb05ae922cb3cbbcb6f7683ed0f77069936fa Mon Sep 17 00:00:00 2001 From: AngleMortSociety Date: Tue, 17 Sep 2013 17:23:25 +0200 Subject: [PATCH 25/37] Word correction (comm => comment) --- fr/06-git-tools/01-chapter6.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown index 1f362431e..ba662065c 100644 --- a/fr/06-git-tools/01-chapter6.markdown +++ b/fr/06-git-tools/01-chapter6.markdown @@ -1278,7 +1278,7 @@ La fusion de la pieuvre peut gérer plusieurs branches mais elle est plus pruden Cependant, il existe d'autres stratégies que vous pouvez tout aussi bien choisir. L'une d'elles est la fusion de sous-arborescence que vous pouvez utiliser pour gérer la problématique du sous-projet. -Nous allons donc voir comme gérer l'inclusion de `rack` comme dans la section précédente, mais en utilisant cette fois-ci les fusions de sous-arborescence. +Nous allons donc voir comment gérer l'inclusion de `rack` comme dans la section précédente, mais en utilisant cette fois-ci les fusions de sous-arborescence. La fusion de sous-arborescence suppose que vous ayez deux projets et que l'un s'identifie à un sous-répertoire de l'autre. Lorsque vous spécifiez une fusion de sous-arborescence, Git est assez intelligent pour deviner lequel est un sous-répertoire de l'autre et fusionne en conséquence — c'est assez bluffant. From a6841eb3f6d685c569e8d0572aea3a1853b54642 Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Tue, 11 Jun 2013 01:59:06 +0400 Subject: [PATCH 26/37] [ru] chapter 7: Extend/improve "Diffing Binary Files" section --- ru/07-customizing-git/01-chapter7.markdown | 35 +++++++++++----------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/ru/07-customizing-git/01-chapter7.markdown b/ru/07-customizing-git/01-chapter7.markdown index 6fc378d11..3b501e569 100644 --- a/ru/07-customizing-git/01-chapter7.markdown +++ b/ru/07-customizing-git/01-chapter7.markdown @@ -307,11 +307,15 @@ Git будет выявлять эти проблемы при запуске к #### Получение дельты для бинарных файлов #### -В Git'е функциональность атрибутов может быть использована для эффективного получения дельт для бинарных файлов. Чтобы сделать это, нужно объяснить Git'у, как сконвертировать ваши бинарные данные в текстовый формат, для которого можно выполнить сравнение с помощью обычного diff. +Функциональность атрибутов Git'а может быть использована для эффективного получения дельт бинарных файлов. Сделать это можно, объяснив Git'у, как сконвертировать ваши бинарные данные в текстовый формат, для которого можно выполнить сравнение с помощью обычного diff. Осталось только понять, как получить текстовое представление для *бинарных* данных. Идеальный вариант — найти подходящую утилиту для конвертирования нужного формата в текстовый вид. Но, к сожалению, получить хорошее текстовое представление можно только для весьма ограниченного набора бинарных форматов. Для большинства же бинарных форматов, например, для графических или аудио данных, получить читаемый текстовый вид не представляется возможным. Но если мы не можем получить текстовое представление содержимого, мы зачастую можем получить читаемое описание содержимого или метаданные. Метаданные не дают полное представление о содержимом файле, но, во всяком случае, это лучше чем ничего. + +Далее мы рассмотрим оба подхода на примерах популярных бинарных форматов. + +Замечание: Существуют разные виды бинарных файлов с текстовым содержимым, для которых вам, может быть, не удастся найти подходящий конвёртер. В данном случае вы можете попробовать вытащить текст с помощью утилиты `strings`. Некоторые из таких файлов могут использовать кодировку UTF-16 или могут быть написаны не в латинице, в таких файлах `strings` не найдёт ничего хорошего. Полезность `strings` может сильно варьироваться. Тем не менее, `strings` доступен на большинстве Mac- и Linux-систем, так что он может быть хорошим первым вариантом для того, чтобы сделать подобное со многими бинарными форматами. ##### Документы MS Word ##### -Так как эта довольно клёвая функция не особо широко известна, мы рассмотрим несколько примеров её использования. Для начала мы используем этот подход, чтобы решить одну из самых раздражающих проблем, известных человечеству: версионный контроль документов Word. Всем известно, что Word — это самый ужасающий из всех существующих редакторов, но, как ни странно, все им пользуются. Если вы хотите поместить документы Word под версионный контроль, вы можете запихнуть их в Git-репозиторий и время от времени делать коммиты. Но что в этом хорошего? Если вы запустите `git diff` как обычно, то увидите только что-то наподобие этого: +Для начала мы используем описанный подход, чтобы решить одну из самых раздражающих проблем, известных человечеству: версионный контроль документов Word. Всем известно, что Word — это самый ужасающий из всех существующих редакторов, но, как ни странно, все им пользуются. Если вы хотите поместить документы Word под версионный контроль, вы можете запихнуть их в Git-репозиторий и время от времени делать коммиты. Но что в этом хорошего? Если вы запустите `git diff` как обычно, то увидите только что-то наподобие этого: $ git diff diff --git a/chapter1.doc b/chapter1.doc @@ -322,18 +326,16 @@ Git будет выявлять эти проблемы при запуске к *.doc diff=word -Она говорит Git'у, что все файлы, соответствующие указанному шаблону (.doc) должны использовать фильтр "word" при попытке посмотреть дельту с изменениями. Что такое фильтр "word"? Нам нужно его изготовить. Сейчас мы настроим Git на использование программы `strings` для конвертирования документов Word в читаемые текстовые файлы, которые Git затем правильно сравнит: +Она говорит Git'у, что все файлы, соответствующие указанному шаблону (.doc) должны использовать фильтр "word" при попытке посмотреть дельту с изменениями. Что такое фильтр "word"? Нам нужно его изготовить. Сейчас мы настроим Git на использование программы `catdoc`, специально написанной для того, чтобы вытаскивать текстовую информацию из бинарных документов MS Word (скачать её можно по адресу `http://www.45.free.net/~vitus/software/catdoc/`), для конвертирования документов Word в читаемые текстовые файлы, которые Git затем правильно сравнит: - $ git config diff.word.textconv strings + $ git config diff.word.textconv catdoc Этой командой в свой `.git/config` вы добавите следующую секцию: [diff "word"] - textconv = strings - -Замечание: Существуют разные виды `.doc` файлов. Некоторые из них могут использовать кодировку UTF-16 или могут быть написаны не в латинице, в таких файлах `strings` не найдёт ничего хорошего. Полезность `strings` может сильно варьироваться. + textconv = catdoc -Теперь Git знает, что если ему надо найти дельту между двумя снимками состояния, и какие-то их файлы заканчиваются на `.doc`, он должен прогнать эти файлы через фильтр "word", который определён как программа `strings`. Так вы фактически сделаете текстовые версии своих Word-файлов перед тем, как получить для них дельту. +Теперь Git знает, что если ему надо найти дельту между двумя снимками состояния, и какие-то их файлы заканчиваются на `.doc`, он должен прогнать эти файлы через фильтр "word", который определён как программа `catdoc`. Так вы фактически сделаете текстовые версии своих Word-файлов перед тем, как получить для них дельту. Рассмотрим пример. Я поместил главу 1 настоящей книги в Git, добавил немного текста в один параграф и сохранил документ. Затем я выполнил `git diff`, чтобы увидеть, что изменилось: @@ -342,15 +344,14 @@ Git будет выявлять эти проблемы при запуске к index c1c8a0a..b93c9e4 100644 --- a/chapter1.doc +++ b/chapter1.doc - @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics - re going to cover how to get it and set it up for the first time if you don - t already have it on your system. - In Chapter Two we will go over basic Git usage - how to use Git for the 80% - -s going on, modify stuff and contribute changes. If the book spontaneously - +s going on, modify stuff and contribute changes. If the book spontaneously - +Let's see if this works. + @@ -128,7 +128,7 @@ and data size) + Since its birth in 2005, Git has evolved and matured to be easy to use + and yet retain these initial qualities. It’s incredibly fast, it’s + very efficient with large projects, and it has an incredible branching + -system for non-linear development. + +system for non-linear development (See Chapter 3). -Git коротко и ясно дал мне знать, что я добавил строку "Let’s see if this works", так оно и есть. Работает не идеально, так как добавляет немного лишнего в конце, но определённо работает. Если вы сможете найти или написать хорошо работающую программу для конвертации документов Word в обычный текст, то такое решение, скорее всего, будет невероятно эффективно. Тем не менее, `strings` доступен на большинстве Mac- и Linux-систем, так что он может быть хорошим первым вариантом для того, чтобы сделать подобное со многими бинарными форматами. +Git коротко и ясно дал мне знать, что я добавил строку "(See Chapter 3)", так оно и есть. Работает идеально. ##### Текстовые файлы в формате OpenDocument ##### @@ -366,7 +367,7 @@ Git коротко и ясно дал мне знать, что я добави binary = true textconv = /usr/local/bin/odt-to-txt -Файлы в формате OpenDocument на самом деле являются запакованными zip'ом каталогами с множеством файлов (содержимое в XML-формате, таблицы стилей, изображения и т.д.). Мы напишем сценарий для извлечения содержимого и вывода его в виде обычного текста. Создайте файл `/usr/local/bin/odt-to-txt` (можете создать его в любом другом каталоге) со следующим содержимым: +Файлы в формате OpenDocument на самом деле являются запакованными zip'ом каталогами с множеством файлов (содержимое в XML-формате, таблицы стилей, изображения и т.д.). Мы напишем свой сценарий для извлечения содержимого и вывода его в виде обычного текста. Создайте файл `/usr/local/bin/odt-to-txt` (можете создать его в любом другом каталоге) со следующим содержимым: #! /usr/bin/env perl # Сценарий для конвертации OpenDocument Text (.odt) в обычный текст. From 2be2edae39951dceda41d48693c937a93c3d5734 Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Sun, 8 Sep 2013 01:08:48 +0400 Subject: [PATCH 27/37] [ru] chapter 7: Translate figures. --- ru/figures-dia/fig0702.dia | 851 +++++++++++++++++++++++++++++++++++++ ru/figures-dia/fig0703.dia | 851 +++++++++++++++++++++++++++++++++++++ 2 files changed, 1702 insertions(+) create mode 100644 ru/figures-dia/fig0702.dia create mode 100644 ru/figures-dia/fig0703.dia diff --git a/ru/figures-dia/fig0702.dia b/ru/figures-dia/fig0702.dia new file mode 100644 index 000000000..a287eb2bf --- /dev/null +++ b/ru/figures-dia/fig0702.dia @@ -0,0 +1,851 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileA.txt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileB.txt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileC.rb# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileC.rb# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileA.txt'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileB.txt'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #smudge# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #clean# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Фильтры для *.txt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Рабочий каталог# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Индекс# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git checkout# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0703.dia b/ru/figures-dia/fig0703.dia new file mode 100644 index 000000000..7535d3ef7 --- /dev/null +++ b/ru/figures-dia/fig0703.dia @@ -0,0 +1,851 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileA.txt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileB.txt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileC.rb# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileC.rb# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileA.txt'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #fileB.txt'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #smudge# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #clean# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Фильтры для *.txt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Рабочий каталог# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Индекс# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git add# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From ac59c20b6db3cc63a66c0ade7cba1ddad2b6472e Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Sun, 15 Sep 2013 03:09:03 +0400 Subject: [PATCH 28/37] [ru] chapter 3: Translate some figures. --- ru/figures-dia/fig0322.dia | 1182 ++++++++++++++++++++ ru/figures-dia/fig0323.dia | 1457 +++++++++++++++++++++++++ ru/figures-dia/fig0324.dia | 1698 +++++++++++++++++++++++++++++ ru/figures-dia/fig0325.dia | 2101 +++++++++++++++++++++++++++++++++++ ru/figures-dia/fig0326.dia | 2111 ++++++++++++++++++++++++++++++++++++ ru/figures-dia/fig0336.dia | 786 ++++++++++++++ ru/figures-dia/fig0337.dia | 1546 ++++++++++++++++++++++++++ ru/figures-dia/fig0338.dia | 1755 ++++++++++++++++++++++++++++++ ru/figures-dia/fig0339.dia | 1882 ++++++++++++++++++++++++++++++++ 9 files changed, 14518 insertions(+) create mode 100644 ru/figures-dia/fig0322.dia create mode 100644 ru/figures-dia/fig0323.dia create mode 100644 ru/figures-dia/fig0324.dia create mode 100644 ru/figures-dia/fig0325.dia create mode 100644 ru/figures-dia/fig0326.dia create mode 100644 ru/figures-dia/fig0336.dia create mode 100644 ru/figures-dia/fig0337.dia create mode 100644 ru/figures-dia/fig0338.dia create mode 100644 ru/figures-dia/fig0339.dia diff --git a/ru/figures-dia/fig0322.dia b/ru/figures-dia/fig0322.dia new file mode 100644 index 000000000..7d796d442 --- /dev/null +++ b/ru/figures-dia/fig0322.dia @@ -0,0 +1,1182 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git clone schacon@git.ourcompany.com:project.git# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Удалённая ветка# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальная ветка# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0323.dia b/ru/figures-dia/fig0323.dia new file mode 100644 index 000000000..2534b9d48 --- /dev/null +++ b/ru/figures-dia/fig0323.dia @@ -0,0 +1,1457 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a38de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #893cf# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Отправил кто-то другой# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0324.dia b/ru/figures-dia/fig0324.dia new file mode 100644 index 000000000..3f6f6452c --- /dev/null +++ b/ru/figures-dia/fig0324.dia @@ -0,0 +1,1698 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git fetch origin# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a38de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #893cf# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0325.dia b/ru/figures-dia/fig0325.dia new file mode 100644 index 000000000..abec97190 --- /dev/null +++ b/ru/figures-dia/fig0325.dia @@ -0,0 +1,2101 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git remote add# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a38de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #893cf# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git://git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0326.dia b/ru/figures-dia/fig0326.dia new file mode 100644 index 000000000..db235dc83 --- /dev/null +++ b/ru/figures-dia/fig0326.dia @@ -0,0 +1,2111 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #0b743# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a6b4c# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #190a3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #f42c5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #31b8e# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #origin# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #a38de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #893cf# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git fetch teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git fetch teamone# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0336.dia b/ru/figures-dia/fig0336.dia new file mode 100644 index 000000000..41db8c085 --- /dev/null +++ b/ru/figures-dia/fig0336.dia @@ -0,0 +1,786 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C2# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0337.dia b/ru/figures-dia/fig0337.dia new file mode 100644 index 000000000..385c5f1e3 --- /dev/null +++ b/ru/figures-dia/fig0337.dia @@ -0,0 +1,1546 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C6# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C6# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C2# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C7# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0338.dia b/ru/figures-dia/fig0338.dia new file mode 100644 index 000000000..7f52b2c20 --- /dev/null +++ b/ru/figures-dia/fig0338.dia @@ -0,0 +1,1755 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C6# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C6# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C2# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C7# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/ru/figures-dia/fig0339.dia b/ru/figures-dia/fig0339.dia new file mode 100644 index 000000000..7a9285e76 --- /dev/null +++ b/ru/figures-dia/fig0339.dia @@ -0,0 +1,1882 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #git.team1.ourcompany.com# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Локальный компьютер# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #teamone/master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #master# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C6# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C5# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C6# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C2# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C7# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C4'# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #C8# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 41772b6601108f4941c7c9271956bd0c9a8ccdb2 Mon Sep 17 00:00:00 2001 From: AngleMortSociety Date: Thu, 19 Sep 2013 19:37:14 +0200 Subject: [PATCH 29/37] [fr] Fix some mistakes. --- fr/07-customizing-git/01-chapter7.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fr/07-customizing-git/01-chapter7.markdown b/fr/07-customizing-git/01-chapter7.markdown index 88e55a428..e7248a28a 100644 --- a/fr/07-customizing-git/01-chapter7.markdown +++ b/fr/07-customizing-git/01-chapter7.markdown @@ -142,7 +142,7 @@ Ce réglage a été ajouté dans Git 1.5.5. Si vous avez une version antérieure, vous devrez spécifier les règles de colorisation individuellement. `color.ui = always` est rarement utile. -Dans les plupart des cas, si vous tenez vraiment à coloriser vos sorties redirigées, vous pourrez passer le drapeau `--color` à la commande Git pour la forcer à utiliser les codes de couleur. +Dans la plupart des cas, si vous tenez vraiment à coloriser vos sorties redirigées, vous pourrez passer le drapeau `--color` à la commande Git pour la forcer à utiliser les codes de couleur. Le réglage `color.ui = true` est donc le plus utilisé. #### `color.*` #### @@ -163,7 +163,7 @@ Par exemple, pour régler les couleurs de méta-informations du diff avec une é La couleur peut prendre les valeurs suivantes : *normal*, *black*, *red*, *green*, *yellow*, *blue*, *magenta*, *cyan* ou *white*. Si vous souhaitez ajouter un attribut de casse, les valeurs disponibles sont *bold* (gras), *dim* (léger), *ul* (*underlined*, souligné), *blink* (clignotant) et *reverse* (inversé). -Référez-vous à la page de manuel de `git config` pour tous les sous-réglages disponibles. +Référez-vous à la page du manuel de `git config` pour tous les sous-réglages disponibles. ### Outils externes de fusion et de différence ### @@ -294,7 +294,7 @@ Les deux autres qui sont désactivées par défaut mais peuvent être activées Vous pouvez indiquer à Git quelle correction vous voulez activer en fixant `core.whitespace` avec les valeurs que vous voulez ou non, séparées par des virgules. Vous pouvez désactiver des réglages en les éliminant de la chaîne de paramétrage ou en les préfixant avec un `-`. -Par exemple, si vous souhaiter activer tout sauf `cr-at-eol`, vous pouvez lancer ceci : +Par exemple, si vous souhaitez activer tout sauf `cr-at-eol`, vous pouvez lancer ceci : $ git config --global core.whitespace \ trailing-space,space-before-tab,indent-with-non-tab @@ -749,7 +749,7 @@ Vous ne pouvez plus arrêter le processus de validation avec ce script. #### Autres crochets côté client #### -Le crochet `pre-rebase` est invoqueé avant que vous ne rebasiez et peut interrompre le processus s'il sort avec un code d'erreur non nul. +Le crochet `pre-rebase` est invoqué avant que vous ne rebasiez et peut interrompre le processus s'il sort avec un code d'erreur non nul. Vous pouvez utiliser ce crochet pour empêcher de rebaser tout *commit* qui a déjà été poussé. C'est ce que fait le crochet d'exemple `pre-rebase` que Git installe, même s'il considère que la branche cible de publication s'appelle `next`. Il est très probable que vous ayez à changer ce nom pour celui que vous utilisez réellement en branche publique stable. @@ -760,7 +760,7 @@ Cela peut signifier y déplacer des gros fichiers binaires que vous ne souhaitez Enfin, le crochet `post-merge` s'exécute à la suite d'une commande `merge` réussie. Vous pouvez l'utiliser pour restaurer certaines données non gérées par Git dans le copie de travail telles que les informations de permission. -Ce crochet permet de même de valider la présence de fichiers externes au contrôle de Git que vous souhaitez voir recopiés lorsque la copie de travail change. +Ce crochet permet même de valider la présence de fichiers externes au contrôle de Git que vous souhaitez voir recopiés lorsque la copie de travail change. ### Crochets côté serveur ### From 2394fa4a88971c82be9a24548c323846403e6668 Mon Sep 17 00:00:00 2001 From: Hiroaki ENDOH Date: Sat, 21 Sep 2013 12:20:47 +0900 Subject: [PATCH 30/37] [ja] Fix typo Chapter 1.3 Nearly Every Operation Is Local MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 修正前) もし、飛行機もしくは "列車にに" 乗って 修正後) もし、飛行機もしくは "列車に" 乗って --- ja/01-introduction/01-chapter1.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown index 4388e9de4..692487aee 100644 --- a/ja/01-introduction/01-chapter1.markdown +++ b/ja/01-introduction/01-chapter1.markdown @@ -79,7 +79,7 @@ Gitのほとんどの操作は、ローカル・ファイルと操作する資 例えば、プロジェクトの履歴を閲覧するために、Gitはサーバーに履歴を取得しに行って表示する必要がありません。直接にローカル・データベースからそれを読むだけです。これは、プロジェクトの履歴をほとんど即座に知るということです。もし、あるファイルの現在のバージョンと、そのファイルの1ヶ月前の間に導入された変更点を知りたいのであれば、Gitは、遠隔のサーバーに差分を計算するように問い合わせたり、ローカルで差分を計算するために遠隔サーバーからファイルの古いバージョンを持ってくる代わりに、1か月前のファイルを調べてローカルで差分の計算を行なえます。 -これはまた、オフラインであるか、VPNから切り離されていたとしても、出来ない事は非常に少ないことを意味します。もし、飛行機もしくは列車にに乗ってちょっとした仕事をしたいとしても、アップロードするためにネットワーク接続し始めるまで、楽しくコミットできます。もし、帰宅してVPNクライアントを適切に作動させられないとしても、さらに作業ができます。多くの他のシステムでは、それらを行なう事は、不可能であるか苦痛です。例えばPerforceにおいては、サーバーに接続できないときは、多くの事が行なえません。SubversionとCVSにおいては、ファイルの編集はできますが、データベースに変更をコミットできません（なぜならば、データベースがオフラインだからです）。このことは巨大な問題に思えないでしょうが、実に大きな違いを生じうることに驚くでしょう。 +これはまた、オフラインであるか、VPNから切り離されていたとしても、出来ない事は非常に少ないことを意味します。もし、飛行機もしくは列車に乗ってちょっとした仕事をしたいとしても、アップロードするためにネットワーク接続し始めるまで、楽しくコミットできます。もし、帰宅してVPNクライアントを適切に作動させられないとしても、さらに作業ができます。多くの他のシステムでは、それらを行なう事は、不可能であるか苦痛です。例えばPerforceにおいては、サーバーに接続できないときは、多くの事が行なえません。SubversionとCVSにおいては、ファイルの編集はできますが、データベースに変更をコミットできません（なぜならば、データベースがオフラインだからです）。このことは巨大な問題に思えないでしょうが、実に大きな違いを生じうることに驚くでしょう。 ### Gitは完全性を持つ ### From c4df8034cf8e6e73fb981c0cdc419366df03d810 Mon Sep 17 00:00:00 2001 From: AngleMortSociety Date: Tue, 24 Sep 2013 17:01:07 +0200 Subject: [PATCH 31/37] [fr] Fix some mistakes with a text. --- fr/08-git-and-other-scms/01-chapter8.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fr/08-git-and-other-scms/01-chapter8.markdown b/fr/08-git-and-other-scms/01-chapter8.markdown index 26c5ca0e5..19e6caffb 100644 --- a/fr/08-git-and-other-scms/01-chapter8.markdown +++ b/fr/08-git-and-other-scms/01-chapter8.markdown @@ -374,7 +374,7 @@ Le résultat ressemble à ceci : Ici aussi, tous les *commits* locaux dans Git ou ceux poussé sur Subversion dans l'intervalle n'apparaissent pas. -#### L'information sur la serveur SVN #### +#### L'information sur le serveur SVN #### Vous pouvez aussi obtenir le même genre d'information que celle fournie par `svn info` en lançant `git svn info` : @@ -479,7 +479,7 @@ les *commits* ressemblent à ceci : fixed install - go to trunk -Non seulement le champ auteur a meilleure mine, mais de plus le champ `git-svn-id` a disparu. +Non seulement le champ auteur a meilleure mine, mais de plus, le champ `git-svn-id` a disparu. Il est encore nécessaire de faire un peu de ménage `post-import`. Déjà, vous devriez nettoyer les références bizarres que `git svn` crée. Premièrement, déplacez les étiquettes pour qu'elles soient de vraies étiquettes plutôt que des branches distantes étranges, ensuite déplacez le reste des branches pour qu'elles deviennent locales. @@ -500,7 +500,7 @@ Ensuite, déplacez le reste des références sous `refs/remotes` en branches loc À présent, toutes les vieilles branches sont des vraies branches Git et toutes les vieilles étiquettes sont de vraies étiquettes Git. La dernière activité consiste à ajouter votre nouveau serveur Git comme serveur distant et à y pousser votre projet transformé. -Pour pousser tout, y compris branches et étiquettes, lancez : +Pour pousser le tout, y compris branches et étiquettes, lancez : $ git push origin --tags @@ -516,7 +516,7 @@ Dans ce dernier cas, pour le lancer, il vous faut récupérer le code source de $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/contrib/fast-import -Dans ce répertoire `fast-import`, vous devriez trouver une script exécutable Python appelé `git-p4`. +Dans ce répertoire `fast-import`, vous devriez trouver un script exécutable Python appelé `git-p4`. Python et l'outil `p4` doivent être installés sur votre machine pour que cet import fonctionne. Par exemple, nous importerons le projet Jam depuis le Perforce Public Depot. Pour installer votre client, vous devez exporter la variable d'environnement `P4PORT` qui pointe sur le dépôt Perforce : @@ -556,7 +556,7 @@ Si vous vous rendez dans le répertoire `/opt/p4import` et lancez la commande ` Vous pouvez visualiser l'identifiant `git-p4` de chaque *commit*. Il n'y a pas de problème à garder cet identifiant ici, au cas où vous auriez besoin de référencer dans l'avenir le numéro de modification Perforce. Cependant, si vous souhaitez supprimer l'identifiant, c'est le bon moment, avant de commencer à travailler avec le nouveau dépôt. -Vous pouvez utiliser `git filter-branch` pour faire une retrait en masse des chaînes d'identifiant : +Vous pouvez utiliser `git filter-branch` pour faire un retrait en masse des chaînes d'identifiant : $ git filter-branch --msg-filter ' sed -e "/^\[git-p4:/d" From 18ef2f47453978f4a3bc335db79c295801447381 Mon Sep 17 00:00:00 2001 From: AngleMortSociety Date: Thu, 26 Sep 2013 17:29:55 +0200 Subject: [PATCH 32/37] [fr] Fix some mistakes with a text. --- fr/09-git-internals/01-chapter9.markdown | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/fr/09-git-internals/01-chapter9.markdown b/fr/09-git-internals/01-chapter9.markdown index 975730f80..ccf9eb886 100644 --- a/fr/09-git-internals/01-chapter9.markdown +++ b/fr/09-git-internals/01-chapter9.markdown @@ -19,7 +19,7 @@ Ensuite, vous apprendrez les mécanismes de transport/transmission/communication ## Plomberie et porcelaine ## Ce livre couvre l'utilisation de Git avec une trentaine de verbes comme `checkout`, `branch`, `remote`... -Mais, puisque Git était initialement une boîte à outils (*toolkit*) pour VCS, plutôt qu'un VCS complet et conviviale, il dispose de tout un ensemble d'actions pour les tâches bas niveau qui étaient conçues pour être liées dans le style UNIX ou appelées depuis des scripts. +Mais, puisque Git était initialement une boîte à outils (*toolkit*) pour VCS, plutôt qu'un VCS complet et convivial, il dispose de tout un ensemble d'actions pour les tâches bas niveau qui étaient conçues pour être liées dans le style UNIX ou appelées depuis des scripts. Ces commandes sont dites commandes de « plomberie » (*plumbing*) et les autres, plus conviviales sont appelées « porcelaines » (*porcelain*). Les huit premiers chapitres du livre concernent presque exclusivement les commandes porcelaine. @@ -349,7 +349,7 @@ Vous devez inclure la bibliothèque et exécuter `Zlib::Deflate.deflate()` sur l => "x\234K\312\311OR04c(\317H,Q\310,V(-\320QH\311O\266\a\000_\034\a\235" Finalement, vous enregistrerez le contenu compressé dans un objet sur le disque. -Vous déterminerez le chemin de l'objet que vous voulez enregistrer (les deux premiers caractères de l'empreinte SHA-1 formeront le nom du sous-répertoires et les 38 derniers formeront le nom du fichier dans ce répertoire). +Vous déterminerez le chemin de l'objet que vous voulez enregistrer (les deux premiers caractères de l'empreinte SHA-1 formeront le nom du sous-répertoire et les 38 derniers formeront le nom du fichier dans ce répertoire). En Ruby, on peut utiliser la fonction `FileUtils.mkdir_p()` pour créer un sous-répertoire s'il n'existe pas. Ensuite, ouvrez le fichier avec `File.open()` et enregistrez le contenu compressé en appelant la fonction `write()` sur la référence du fichier : @@ -725,7 +725,7 @@ S'il existe une équipe qualité (QA) qui publie une série de branches et que l fetch = +refs/heads/master:refs/remotes/origin/master fetch = +refs/heads/qa/*:refs/remotes/origin/qa/* -Si vous utilisez des processus complexes impliquant une équipe qualité, des développeurs et des intégrateurs qui publient des branches et qui collaborent sur des branches distantes, vous pouvez facilement utiliser des espaces des noms de cette façon. +Si vous utilisez des processus complexes impliquant une équipe qualité, des développeurs et des intégrateurs qui publient des branches et qui collaborent sur des branches distantes, vous pouvez facilement utiliser des espaces de noms, de cette façon. ### Publier une référence spécifique ### @@ -1084,12 +1084,12 @@ Si vous l'exécutez avec l'option `--full`, il vous montre tous les objets qui n dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293 Dans ce cas, vous pouvez voir votre *commit* manquant après « dangling commit ». -Vous pouvez le restaurez de la même manière que précédemment, en créant une branche qui référence cette empreinte SHA. +Vous pouvez le restaurer de la même manière que précédemment, en créant une branche qui référence cette empreinte SHA. ### Suppression d'objets ### Il y a beaucoup de choses dans Git qui sont géniales, mais une fonctionnalité qui peut poser problème est le fait que `git clone` télécharge l'historique entier du projet, incluant chaque version de chaque fichier. -C'est très bien lorsque le tout est du code source, parce Git est hautement optimisé pour compresser les données efficacement. +C'est très bien lorsque le tout est du code source, parce que Git est hautement optimisé pour compresser les données efficacement. Cependant, si quelqu'un à un moment donné de l'historique de votre projet a ajouté un énorme fichier, chaque clone sera forcé de télécharger cet énorme fichier, même s'il a été supprimé du projet dans le *commit* suivant. Puisqu'il est accessible depuis l'historique, il sera toujours là. @@ -1131,7 +1131,7 @@ Maintenant, faites un `gc` sur votre base de données, pour voir combien d'espac Writing objects: 100% (21/21), done. Total 21 (delta 3), reused 15 (delta 1) -Vous pouvez exécutez la commande `count-objects` pour voir rapidement combien d'espace disque vous utilisez : +Vous pouvez exécuter la commande `count-objects` pour voir rapidement combien d'espace disque vous utilisez : $ git count-objects -v count: 4 @@ -1142,7 +1142,7 @@ Vous pouvez exécutez la commande `count-objects` pour voir rapidement combien d prune-packable: 0 garbage: 0 -L'entrée `size-pack` est la taille de vos fichiers groupés en kilooctets, vous utilisez donc 2 Mio. +L'entrée `size-pack` est la taille de vos fichiers groupés en kilo-octet, vous utilisez donc 2 Mio. Avant votre dernier *commit*, vous utilisiez environ 2 Kio, clairement, supprimer le fichier avec le *commit* précédent ne l'a pas enlevé de votre historique. À chaque fois que quelqu'un clonera votre dépôt, il aura à cloner les 2 Mio pour récupérer votre tout petit projet, parce que vous avez accidentellement rajouté un gros fichier. Débarrassons-nous en. @@ -1160,7 +1160,7 @@ Vous pouvez également le faire suivre à la commande `tail` car vous ne vous in Le gros objet est à la fin : 2 Mio. Pour trouver quel fichier c'est, vous allez utiliser la commande `rev-list`, que vous avez utilisée brièvement dans le chapitre 7. -Si vous mettez l'option `--objects` à `rev-list`, elle listera tous les SHA des *commits* et des blobs avec le chemin du fichier associés. +Si vous mettez l'option `--objects` à `rev-list`, elle listera tous les SHA des *commits* et des blobs avec le chemin du fichier associé. Vous pouvez utilisez cette commande pour trouver le nom de votre blob : $ git rev-list --objects --all | grep 7a9eb2fb From cf27e5f743d28987ba051ac4b8d4ea97aa440f1f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlos=20Pe=C3=B1a?= Date: Tue, 1 Oct 2013 02:08:57 +0300 Subject: [PATCH 33/37] Fixing typo for "entesijos" [sic] According to the RAE the correct spelling is "entresijos" : cosa oculta. --- es/09-git-internals/01-chapter9.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/09-git-internals/01-chapter9.markdown b/es/09-git-internals/01-chapter9.markdown index b0455af06..85c789327 100755 --- a/es/09-git-internals/01-chapter9.markdown +++ b/es/09-git-internals/01-chapter9.markdown @@ -1,4 +1,4 @@ -# Los entesijos internos de Git # +# Los entresijos internos de Git # Puedes que hayas llegado a este capítulo saltando desde alguno previo o puede que hayas llegado tras leer todo el resto del libro. --En uno u otro caso, aquí es donde aprenderás acerca del funcionamiento interno y la implementación de Git--. Me parece que esta información es realmente importante para entender cúan util y potente es Git. Pero algunas personas opinan que puede ser confuso e innecesariamente complejo para novatos. Por ello, lo he puesto al final del libro; de tal forma que puedas leerlo antes o después, en cualquier momento, a lo largo de tu proceso de aprendizaje. Lo dejo en tus manos. From 90c92ceb9ba2034ef9f9489f0fae46ec1e2b33f3 Mon Sep 17 00:00:00 2001 From: Jay Taggart Date: Thu, 3 Oct 2013 10:55:24 -0500 Subject: [PATCH 34/37] Fixed the command for git svn clone, removed erroneous hyphen --- en/08-git-and-other-scms/01-chapter8.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown index 908773998..37ac490e4 100644 --- a/en/08-git-and-other-scms/01-chapter8.markdown +++ b/en/08-git-and-other-scms/01-chapter8.markdown @@ -369,7 +369,7 @@ That gives you the log output in XML format — you can look for the authors, cr You can provide this file to `git svn` to help it map the author data more accurately. You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command. This makes your `import` command look like this: - $ git-svn clone http://my-project.googlecode.com/svn/ \ + $ git svn clone http://my-project.googlecode.com/svn/ \ --authors-file=users.txt --no-metadata -s my_project Now you should have a nicer Subversion import in your `my_project` directory. Instead of commits that look like this From 068e68d1182e576a8d5b6121e559e6fff676d824 Mon Sep 17 00:00:00 2001 From: Igor Murzov Date: Sat, 5 Oct 2013 00:44:58 +0400 Subject: [PATCH 35/37] [ru] chapter 8: Incorporate changes from 90c92ceb9 "Fixed the command for git svn clone, removed erroneous hyphen" --- ru/08-git-and-other-scms/01-chapter8.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ru/08-git-and-other-scms/01-chapter8.markdown b/ru/08-git-and-other-scms/01-chapter8.markdown index d839fedc0..dd6b71084 100644 --- a/ru/08-git-and-other-scms/01-chapter8.markdown +++ b/ru/08-git-and-other-scms/01-chapter8.markdown @@ -369,7 +369,7 @@ Git определяет ветку, в которую он отправит в Вы можете передать этот файл как параметр команде `git svn` для более точного преобразования данных об авторах. Кроме того, можно дать указание `git svn` не включать метаданные, обычно импортируемые Subversion, передав параметр `--no-metadata` команде `clone` или `init`. Таким образом, команда для импортирования будет выглядеть так: - $ git-svn clone http://my-project.googlecode.com/svn/ \ + $ git svn clone http://my-project.googlecode.com/svn/ \ --authors-file=users.txt --no-metadata -s my_project Теперь в вашем каталоге `my_project` будут находиться более приятно выглядящие данные после импортирования. Вместо коммитов, которые выглядят так: From fcec80365a191bf5a715cf89c595beefa3dfc37a Mon Sep 17 00:00:00 2001 From: Patrik Wehrli Date: Tue, 8 Oct 2013 09:07:32 +0200 Subject: [PATCH 36/37] [de] (08) minor spelling fix --- de/08-git-and-other-scms/01-chapter8.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/de/08-git-and-other-scms/01-chapter8.markdown b/de/08-git-and-other-scms/01-chapter8.markdown index dee1fbfdb..8f6fd6b41 100644 --- a/de/08-git-and-other-scms/01-chapter8.markdown +++ b/de/08-git-and-other-scms/01-chapter8.markdown @@ -29,7 +29,7 @@ Das Haupt-Kommando in Git für alle Kommandos der Subversion Bridge ist `git svn -Es ist wichtig, dass Du im Hinterkopf behältst, dass Du mit dem `git svn` Befehl mit Subversion interagierst, eine System, dass nicht ganz so fortschrittlich ist wie Git. Obwohl Du auch dort ganz einfach Branches erstellen und wieder zusammenführen kannst, ist es üblicherweise am einfachsten, wenn Du die History so geradlinig wie möglich gestaltest, indem Du ein rebase für Deine Arbeit durchfürst und es vermeidest, zum Beispiel mit einem entfernten Git-Repository zu interagieren. +Es ist wichtig, dass Du im Hinterkopf behältst, dass Du mit dem `git svn` Befehl mit Subversion interagierst, einem System, das nicht ganz so fortschrittlich ist wie Git. Obwohl Du auch dort ganz einfach Branches erstellen und wieder zusammenführen kannst, ist es üblicherweise am einfachsten, wenn Du die History so geradlinig wie möglich gestaltest, indem Du ein rebase für Deine Arbeit durchfürst und es vermeidest, zum Beispiel mit einem entfernten Git-Repository zu interagieren. From 199e37d5e6d206404749ac2b3381f4cfde9f8ae7 Mon Sep 17 00:00:00 2001 From: Jean-Noel Avila Date: Tue, 8 Oct 2013 10:00:55 +0200 Subject: [PATCH 37/37] Revert maruku to 0.6.1 maruku 0.7.0 has a bug where code blocks starting with a star are interpreted as lists. --- Gemfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Gemfile b/Gemfile index a37722ab6..79f6c3029 100644 --- a/Gemfile +++ b/Gemfile @@ -1,5 +1,5 @@ source 'https://rubygems.org' -gem 'maruku' +gem 'maruku', '0.6.1' gem 'redcarpet' gem 'rdiscount'