Merge remote branch 'CupIvan/master'

ru/02-git-basics/01-chapter2.markdown

@@ -1156,33 +1156,33 @@ If you want to remove a reference for some reason — you’ve moved the server
 	$ git remote
 	origin
 
-## Tagging ##
+## Создание тегов (tags) ##
 
-Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on). In this section, you’ll learn how to list the available tags, how to create new tags, and what the different types of tags are.
+Как и большинство систем контроля версий, Git имеет возможность помечать конкретные моменты в истории как важные. Как правило, люди используют эту функциональность, чтобы отметить релизы (v1.0, и так далее). В этом разделе вы узнаете, как получить список доступных тегов, как создать новые, а также узнаете какие бывают типы тегов и их отличия друг от друга.
 
-### Listing Your Tags ###
+### Просмотр ваших тегов ###
 
-Listing the available tags in Git is straightforward. Just type `git tag`:
+Для получения списка тегов достаточно просто набрать команду `git tag`:
 
 	$ git tag
 	v0.1
 	v1.3
 
-This command lists the tags in alphabetical order; the order in which they appear has no real importance.
+Эта команда выводит список тегов в алфавитном порядке; порядок, в котором они назначаются не имеет никакого значения.
 
-You can also search for tags with a particular pattern. The Git source repo, for instance, contains more than 240 tags. If you’re only interested in looking at the 1.4.2 series, you can run this:
+Вы также можете вывести теги по шаблону. Репозиторий Git, к примеру, содержит более 240 тегов. Если вас интересуют теги только релиза 1.4.2, вы можете просмотреть их следующим образом:
 
 	$ git tag -l 'v1.4.2.*'
 	v1.4.2.1
 	v1.4.2.2
 	v1.4.2.3
 	v1.4.2.4
 
-### Creating Tags ###
+### Создание тегов ###
 
-Git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It’s generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don’t want to keep the other information, lightweight tags are available too.
+Git использует два основных типа тегов: легковесные и аннотированные. Легковесные теги очень похож на ветку (branch), который не изменяется - это просто указатель на конкретный коммит. Аннотированные теги, однако, хранятся как стандартные объекты в базе данных Git. Они имеют контрольную сумму, имеют автора, адрес его электронной почты, а также дату; имеют сообщение коммита, и могут быть подписаны и проверены с GNU Privacy Guard (GPG). Обычно рекомендуется создать аннотированные теги, чтобы вы могли иметь всю эту информацию, но если вы хотите создать временный тег или по какой-то причине не хотите сохранять другую информацию, вам необходимо использовать легковесные теги.
 
-### Annotated Tags ###
+### Аннотированные теги ###
 
 Creating an annotated tag in Git is simple. The easiest way is to specify `-a` when you run the `tag` command:
 
@@ -1211,7 +1211,7 @@ You can see the tag data along with the commit that was tagged by using the `git
 
 That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information.
 
-### Signed Tags ###
+### Подписывание тегов ###
 
 You can also sign your tags with GPG, assuming you have a private key. All you have to do is use `-s` instead of `-a`:
 
@@ -1244,9 +1244,9 @@ If you run `git show` on that tag, you can see your GPG signature attached to it
 
 A bit later, you’ll learn how to verify signed tags.
 
-### Lightweight Tags ###
+### Легковесные теги ###
 
-Another way to tag commits is with a lightweight tag. This is basically the commit checksum stored in a file — no other information is kept. To create a lightweight tag, don’t supply the `-a`, `-s`, or `-m` option:
+Другой способ пометить коммит — использовать легковесный тег. Сохраняется только имя тега и указатель на коммит, никакая другая информация не сохраняется. Чтобы создать легковесный тег, не пишите ключи -a, -s, или -m:
 
 	$ git tag v1.4-lw
 	$ git tag
@@ -1256,7 +1256,7 @@ Another way to tag commits is with a lightweight tag. This is basically the comm
 	v1.4-lw
 	v1.5
 
-This time, if you run `git show` on the tag, you don’t see the extra tag information. The command just shows the commit:
+На этот раз, если вы запустите `git show имя_тега`, вы не увидите дополнительную информацию. Команда только выведет коммит:
 
 	$ git show v1.4-lw
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
@@ -1266,7 +1266,7 @@ This time, if you run `git show` on the tag, you don’t see the extra tag infor
 
 	    Merge branch 'experiment'
 
-### Verifying Tags ###
+### Проверка тегов ###
 
 To verify a signed tag, you use `git tag -v [tag-name]`. This command uses GPG to verify the signature. You need the signer’s public key in your keyring for this to work properly:
 

ru/06-git-tools/01-chapter6.markdown

@@ -10,15 +10,13 @@ By now, you’ve learned most of the day-to-day commands and workflows that you
 Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point.
 
 ## Выбор ревизии ##
-
 ## Revision Selection ##
 
 Git позволяет вам указывать конкретные коммиты или их последовательности несколькими способами. Они не всегда очевидны, но иногда их полезно знать.
 
 Git allows you to specify specific commits or a range of commits in several ways. They aren’t necessarily obvious but are helpful to know.
 
 ### Одиночные ревизии ###
-
 ### Single Revisions ###
 
 Вы можете просто сослаться на коммит по его SHA-1 хэшу, но также существуют более дружественные для человека способы ссылаться на коммиты. В этой секции обозреваются различные способы, которыми вы можете сослаться на одиночный коммит.
@@ -73,12 +71,11 @@ Git can figure out a short, unique abbreviation for your SHA-1 values. If you pa
 	085bb3b removed unnecessary test code
 	a11bef0 first commit
 
-В общем случае, от восемь-десять символов более чем достаточно для уникальности внутри проекта. В одном из самых больших проектов на Git, ядре Linux только начинает появляться необходимость использовать 12 символов из 40 возможных для сохранения однозначности.
+В общем случае, восемь-десять символов более чем достаточно для уникальности внутри проекта. В одном из самых больших проектов на Git, ядре Linux только начинает появляться необходимость использовать 12 символов из 40 возможных для сохранения однозначности.
 
 Generally, eight to ten characters are more than enough to be unique within a project. One of the largest Git projects, the Linux kernel, is beginning to need 12 characters out of the possible 40 to stay unique.
 
 ### Небольшое замечание о SHA-1###
-
 ### A SHORT NOTE ABOUT SHA-1 ###
 
 Многие люди интересуются что произойдет, если они в какой-то момент, по некоторой случайности, получат два объекта в репозитории, которые будут иметь два одинаковых значения SHA-1 хэша. Что тогда?
@@ -132,7 +129,7 @@ Every time your branch tip is updated for any reason, Git stores that informatio
 
 	$ git show HEAD@{5}
 
-Вы также можете использовать эту команду, чтобы увидетль ветку, которая была в прошлом. Например, чтобы увидеть состояние вашей `master`-ветки вчера, наберите команду
+Вы также можете использовать эту команду, чтобы увидеть ветку, которая была в прошлом. Например, чтобы увидеть состояние вашей `master`-ветки вчера, наберите команду
 You can also use this syntax to see where a branch was some specific amount of time ago. For instance, to see where your `master` branch was yesterday, you can type
 
 	$ git show master@{yesterday}
@@ -735,14 +732,17 @@ The `--tree-filter` option runs the specified command after each checkout of the
 
 You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `--all` to the command.
 
+#### Создание новой корневой поддириктории ####
 #### Making a Subdirectory the New Root ####
 
+Предположим, вы импортировали репозиторий из другой системы контроля версий и в нем есть бессмысленные каталоги (trunk, tags, и др.). Если вы захотите сделать `trunk` новым корнем проекта, команда `filter-branch` тоже может помочь вам это сделать:
 Suppose you’ve done an import from another source control system and have subdirectories that make no sense (trunk, tags, and so on). If you want to make the `trunk` subdirectory be the new project root for every commit, `filter-branch` can help you do that, too:
 
 	$ git filter-branch --subdirectory-filter trunk HEAD
 	Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
 	Ref 'refs/heads/master' was rewritten
 
+Теперь корневая директория будет в папке `trunk`. Git также автоматом удалит все коммиты, которые не затронули эту папку.
 Now your new project root is what was in the `trunk` subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory. 
 
 #### Changing E-Mail Addresses Globally ####