Merge pull request #204 from sanail/master

Fix incorrect usage of "в отличие"

Author: sadfuzzy

book/07-git-tools/sections/advanced-merging.asc

@@ -3,7 +3,7 @@
 
 Обычно выполнять слияния в Git довольно легко. Git упрощает повторные слияния с одной и той же веткой, таким образом, позволяя вам иметь очень долго живущую ветку, и вы можете сохранять ее всё это время в актуальном состоянии, часто разрешая маленькие конфликты, а не доводить дело до одного большого конфликта по завершению всех изменений.
 
-Однако, иногда все же будут возникать сложные конфликты. В отличии от других систем управления версиями, Git не пытается быть слишком умным при разрешении конфликтов слияния. Философия Git заключается в том, чтобы быть умным, когда слияние разрешается однозначно, но если возникает конфликт, он не пытается сумничать и разрешить его автоматически. Поэтому, если вы слишком долго откладываете слияние двух быстрорастущих веток, вы можете столкнуться с некоторыми проблемами.
+Однако, иногда все же будут возникать сложные конфликты. В отличие от других систем управления версиями, Git не пытается быть слишком умным при разрешении конфликтов слияния. Философия Git заключается в том, чтобы быть умным, когда слияние разрешается однозначно, но если возникает конфликт, он не пытается сумничать и разрешить его автоматически. Поэтому, если вы слишком долго откладываете слияние двух быстрорастущих веток, вы можете столкнуться с некоторыми проблемами.
 
 В этом разделе мы рассмотрим некоторые из возможных проблем и инструменты, которые предоставляет Git, чтобы помочь вам справиться с этими более сложными ситуациями. Мы также рассмотрим некоторые другие нестандартные типы слияний, которые вы можете выполнять, и вы узнаете как можно откатить уже выполненные слияния.
 

book/07-git-tools/sections/bundling.asc

@@ -67,7 +67,7 @@ c99cf5b fourth commit - second repo
 b1ec324 first commit
 ----
 
-Во-первых, нам нужно определить диапазон коммитов, которые мы хотим включить в пакет. В отличии от сетевых протоколов, которые сами выясняют минимальный набор данных, который нужно передать по сети, в данном случае мы должны сделать это сами вручную. В данном примере вы можете сделать, как раньше и упаковать полностью весь репозиторий, но будет лучше упаковать только изменения – три коммита, сделанные локально.
+Во-первых, нам нужно определить диапазон коммитов, которые мы хотим включить в пакет. В отличие от сетевых протоколов, которые сами выясняют минимальный набор данных, который нужно передать по сети, в данном случае мы должны сделать это сами вручную. В данном примере вы можете сделать, как раньше и упаковать полностью весь репозиторий, но будет лучше упаковать только изменения – три коммита, сделанные локально.
 
 Для того, чтобы сделать это, вы должны вычислить различия. Как мы рассказывали в <<r_commit_ranges>>, вы можете указать диапазон коммитов несколькими способами. Для того, чтобы получить три коммита из нашей основной ветки, которые отсутствовали в изначально склонированной ветке, мы можем использовать запись вида `origin/master..master` или `master ^origin/master`. Вы можете проверить ее с помощью команды `log`.
 

book/07-git-tools/sections/reset.asc

@@ -264,7 +264,7 @@ image::images/reset-squash-r3.png[]
 
 Команда `git checkout [branch]` очень похожа на `git reset --hard [branch]`, в процессе их выполнения все три дерева изменяются так, чтобы выглядеть как `[branch]`. Но между этими командами есть два важных отличия.
 
-Во-первых, в отличии от `reset --hard`, команда `checkout` бережно относится к рабочему каталогу, и проверяет, что она не трогает файлы, в которых есть изменения. 
+Во-первых, в отличие от `reset --hard`, команда `checkout` бережно относится к рабочему каталогу, и проверяет, что она не трогает файлы, в которых есть изменения.
 В действительности, эта команда поступает немного умнее – она пытается выполнить в Рабочем Каталоге простые слияния так, чтобы все файлы, которые вы _не_ изменяли, были обновлены.
 С другой стороны, команда `reset --hard` просто заменяет всё целиком, не выполняя проверок.
 

book/07-git-tools/sections/submodules.asc

@@ -843,6 +843,6 @@ Switched to branch 'master'
 
 Когда в дальнейшем вы переключитесь обратно, то по некоторой причине получите пустую директорию `CryptoLibrary` и команда `git submodule update` не сможет этого исправить. Вам может потребоваться перейти в директорию подмодуля и выполнить `git checkout .`, чтобы вернуть все ваши файлы. Для того, чтобы запустить эту команду для нескольких подмодулей, вы можете выполнять ее, используя `submodule foreach`.
 
-Важно отметить, что подмодули в данный момент сохраняют все служебные данные в директории `.git` основного проекта, поэтому в отличии от более старых версии Git, удаление директории подмодуля не приведет к потери каких-либо коммитов или веток, которые у вас были.
+Важно отметить, что подмодули в данный момент сохраняют все служебные данные в директории `.git` основного проекта, поэтому в отличие от более старых версии Git, удаление директории подмодуля не приведет к потери каких-либо коммитов или веток, которые у вас были.
 
 Все эти инструменты делают подмодули довольно простым и эффективным методом работы одновременно над несколькими связанными, но пока разделенными проектами.

ch03-git-branching.asc

@@ -10,7 +10,7 @@
 Некоторые люди, говоря о модели ветвления Git, называют ее ``киллер-фича'', что выгодно выделяет Git на фоне остальных СКВ.
 Что в ней такого особенного?
 Ветвление Git очень легковесно. Операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро.
-В отличии от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день.
+В отличие от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день.
 Понимание и владение этой функциональностью дает Вам уникальный и мощный инструмент, который может полностью изменить привычный Вам процесс разработки.
 
 include::book/03-git-branching/sections/nutshell.asc[]