Merge pull request #201 from Menelion/fix-01-02

Правка раздела 2 главы 1

Author: sadfuzzy

book/01-introduction/sections/basics.asc

@@ -1,22 +1,22 @@
 === Основы Git
 
 Что же такое Git, если говорить коротко?
-Очень важно понять эту часть материала, потому что если вы поймёте что такое Git и основы того, как он работает, тогда, возможно, вам будет гораздо проще его использовать.
-Пока вы изучаете Git, попробуйте забыть всё, что вы знаете о других СКВ, таких как Subversion и Perforce; это позволит вам избежать определённых проблем при использовании утилиты.
+Очень важно понять эту часть материала, потому что если вы поймёте, что такое Git и основы того, как он работает, тогда, возможно, вам будет гораздо проще его использовать.
+Пока вы изучаете Git, попробуйте забыть всё, что вы знаете о других СКВ, таких как Subversion и Perforce. Это позволит вам избежать определённых проблем при использовании инструмента.
 Git хранит и использует информацию совсем иначе по сравнению с другими системами, даже несмотря на то, что интерфейс пользователя достаточно похож, и понимание этих различий поможет вам избежать путаницы во время использования.(((Subversion)))(((Perforce)))
 
 ==== Снимки, а не различия
 
-Основное отличие Git'а от любой другой СКВ (Subversion и её собратья включительно), это подход Git'а к работе со своими данными.
+Основное отличие Git’а от любой другой СКВ (включая Subversion и её собратьев) — это подход Git’а к работе со своими данными.
 Концептуально, большинство других систем хранят информацию в виде списка изменений в файлах.
-Эти системы (CVS, Subversion, Perforce, Bazaar и т.д.) представляют информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени.
+Эти системы (CVS, Subversion, Perforce, Bazaar и т.д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, _основанным на различиях_).
 
 .Хранение данных как набора изменений относительно первоначальной версии каждого из файлов.
 image::images/deltas.png[Хранение данных как набора изменений относительно первоначальной версии каждого из файлов.]
 
 Git не хранит и не обрабатывает данные таким способом.
-Вместо этого, подход Git'а к хранению данных больше похож на набор снимков миниатюрной файловой системы.
-Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git'е, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок.
+Вместо этого, подход Git’а к хранению данных больше похож на набор снимков миниатюрной файловой системы.
+Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git’е, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок.
 Для увеличения эффективности, если файлы не были изменены, Git не запоминает эти файлы вновь, а только создаёт ссылку на предыдущую версию идентичного файла, который уже сохранён.
 Git представляет свои данные как, скажем, *поток снимков*.
 
@@ -31,23 +31,23 @@ Git переосмысливает практически все аспекты
 ==== Почти все операции выполняются локально
 
 Для работы большинства операций в Git достаточно локальных файлов и ресурсов — в основном, системе не нужна никакая информация с других компьютеров в вашей сети.
-Если вы привыкли к ЦСКВ, где большинство операций имеют задержку из-за работы с сетью, то этот аспект Git'а заставит вас думать, что боги скорости наделили Git несказанной мощью.
+Если вы привыкли к ЦСКВ, где большинство операций страдают от задержек из-за работы с сетью, то этот аспект Git’а заставит вас думать, что боги скорости наделили Git несказанной мощью.
 Так как вся история проекта хранится прямо на вашем локальном диске, большинство операций кажутся чуть ли не мгновенными.
 
-Для примера, чтобы посмотреть историю проекта, Git'у не нужно соединяться с сервером для её получения и отображения — система просто считывает данные напрямую из локальной базы данных.
+Для примера, чтобы посмотреть историю проекта, Git’у не нужно соединяться с сервером для её получения и отображения — система просто считывает данные напрямую из локальной базы данных.
 Это означает, что вы увидите историю проекта практически моментально.
 Если вам необходимо посмотреть изменения, сделанные между текущей версией файла и версией, созданной месяц назад, Git может найти файл месячной давности и локально вычислить изменения, вместо того, чтобы запрашивать удалённый сервер выполнить эту операцию, либо вместо получения старой версии файла с сервера и выполнения операции локально.
 
 Это также означает, что есть лишь небольшое количество действий, которые вы не сможете выполнить, если вы находитесь оффлайн или не имеете доступа к VPN в данный момент.
-Если вы в самолёте или в поезде и хотите немного поработать, вы сможете создавать коммиты без каких-либо проблем: когда будет возможность подключиться к сети, все изменения можно будет синхронизировать.
+Если вы в самолёте или в поезде и хотите немного поработать, вы сможете создавать коммиты без каких-либо проблем (в вашу _локальную_ копию, помните?): когда будет возможность подключиться к сети, все изменения можно будет синхронизировать.
 Если вы ушли домой и не можете подключиться через VPN, вы всё равно сможете работать.
 Добиться такого же поведения во многих других системах либо очень сложно, либо вовсе невозможно.
 В Perforce, для примера, если вы не подключены к серверу, вам не удастся сделать многого; в Subversion и CVS вы можете редактировать файлы, но вы не сможете сохранить изменения в базу данных (потому что вы не подключены к БД).
 Всё это может показаться не таким уж и значимым, но вы удивитесь, какое большое значение это может иметь.
 
 ==== Целостность Git
 
-В Git'е для всего вычисляется хеш-сумма, и только потом происходит сохранение. В дальнейшем обращение к сохранённым объектам происходит по этой хеш-сумме.
+В Git’е для всего вычисляется хеш-сумма, и только потом происходит сохранение. В дальнейшем обращение к сохранённым объектам происходит по этой хеш-сумме.
 Это значит, что невозможно изменить содержимое файла или директории так, чтобы Git не узнал об этом.
 Данная функциональность встроена в Git на низком уровне и является неотъемлемой частью его философии.
 Вы не потеряете информацию во время её передачи и не получите повреждённый файл без ведома Git.
@@ -61,14 +61,14 @@ SHA-1 хеш выглядит примерно так:
 24b9da6552252987aa493b52f8696cd6d3b00373
 ----
 
-Вы будете постоянно встречать хеши в Git'е, потому что он использует их повсеместно.
+Вы будете постоянно встречать хеши в Git’е, потому что он использует их повсеместно.
 На самом деле, Git сохраняет все объекты в свою базу данных не по имени, а по хеш-сумме содержимого объекта.
 
-==== Git только добавляет данные
+==== Git обычно только добавляет данные
 
-Когда вы производите какие-либо действия в Git, практически все из них только добавляют новые данные в базу Git.
+Когда вы производите какие-либо действия в Git, практически все из них только _добавляют_ новые данные в базу Git.
 Очень сложно заставить систему удалить данные либо сделать что-то, что нельзя впоследствии отменить.
-Как и в любой другой СКВ, вы можете потерять или испортить свои изменения, пока они не закоммичены, но после того, как вы закоммитите снимок в Git, будет очень сложно что-либо потерять, особенно, если вы регулярно синхронизируете свою базу с другим репозиторием.
+Как и в любой другой СКВ, вы можете потерять или испортить свои изменения, пока они не зафиксированы, но после того, как вы зафиксируете снимок в Git, будет очень сложно что-либо потерять, особенно, если вы регулярно синхронизируете свою базу с другим репозиторием.
 
 Всё это превращает использование Git в одно удовольствие, потому что мы знаем, что можем экспериментировать, не боясь серьёзных проблем.
 Для более глубокого понимания того, как Git хранит свои данные и как вы можете восстановить данные, которые кажутся утерянными, см. <<ch02-git-basics#r_undoing>>.
@@ -77,10 +77,10 @@ SHA-1 хеш выглядит примерно так:
 
 Теперь слушайте внимательно.
 Это самая важная вещь, которую нужно запомнить о Git, если вы хотите, чтобы остаток процесса обучения прошёл гладко.
-Git имеет три основных состояния, в которых могут находиться ваши файлы: зафиксированном (committed), изменённом (modified) и подготовленном (staged).
-``Зафиксированный'' значит, что файл уже сохранён в вашей локальной базе. 
-К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. 
-Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.
+У Git’а есть три основных состояния, в которых могут находиться ваши файлы: _зафиксированное_ (committed), _изменённое_ (modified) и _подготовленное_ (staged).
+* Зафиксированный значит, что файл уже сохранён в вашей локальной базе. 
+* К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. 
+* Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.
 
 Мы подошли к трём основным секциям проекта Git: Git-директория (Git directory), рабочая директория (working directory) и область подготовленных файлов (staging area).
 
@@ -93,16 +93,16 @@ Git-директория — это то место, где Git хранит м
 Рабочая директория является снимком версии проекта.
 Файлы распаковываются из сжатой базы данных в Git-директории и располагаются на диске, для того чтобы их можно было изменять и использовать.
 
-Область подготовленных файлов — это файл, располагающийся в вашей Git-директории, в нём содержится информация о том, какие изменения попадут в следующий коммит.
+Область подготовленных файлов — это файл, обычно располагающийся в вашей Git-директории, в нём содержится информация о том, какие изменения попадут в следующий коммит.
 Эту область ещё называют ``индекс'', однако называть её stage-область также общепринято.
 
 Базовый подход в работе с Git выглядит так:
 
 1. Вы изменяете файлы в вашей рабочей директории.
-2. Вы добавляете файлы в индекс, добавляя тем самым их снимки в область подготовленных файлов.
-3. Когда вы делаете коммит, используются файлы из индекса как есть, и этот снимок сохраняется в вашу Git директорию.
+2. Вы выборочно добавляете в индекс только те изменения, которые должны попасть в следующий коммит, добавляя тем самым снимки _только_ этих изменений в область подготовленных файлов.
+3. Когда вы делаете коммит, используются файлы из индекса как есть, и этот снимок сохраняется в вашу Git-директорию.
 
-Если определённая версия файла есть в Git-директории, эта версия закоммичена.
-Если файл изменён и добавлен в индекс, значит, он будет добавлен в следующий коммит.
-И если файл был изменён с момента последнего распаковывания из репозитория, но не был добавлен в индекс, он считается изменённым.
-В главе <<ch02-git-basics#ch02-git-basics>> вы узнаете больше об этих состояниях и какую пользу вы можете извлечь из них, либо как полностью пропустить часть с индексом.
+Если определённая версия файла есть в Git-директории, эта версия считается _зафиксированной_.
+Если версия файла изменена и добавлена в индекс, значит, она _подготовлена_.
+И если файл был изменён с момента последнего распаковывания из репозитория, но не был добавлен в индекс, он считается _изменённым_.
+В главе <<ch02-git-basics#ch02-git-basics>> вы узнаете больше об этих состояниях и какую пользу вы можете извлечь из них или как полностью пропустить часть с индексом.