Merge https://github.com/mifistor/gitmagic-ru

conf

@@ -0,0 +1,2 @@
+[specialsections]
+^Предисловие $=sect-preface

ru/basic.txt

@@ -0,0 +1,193 @@
+== Базовые операции ==
+
+Прежде чем погружаться в дебри многочисленных команд Git, попробуйте воспользоваться приведёнными ниже простыми примерами, чтобы немного освоиться. Несмотря на свою простоту, каждый из них является полезным.
+
+В самом деле, первые месяцы использования Git я не выходил за рамки материала, изложенного в этой главе.
+
+=== Сохранение состояния ===
+
+Выполняете опасную операцию? Прежде чем сделать это, создайте снимок всех файлов в текущей директории с помощью команд:
+
+ $ git init
+ $ git add .
+ $ git commit -m "Мой первый бекап"
+
+Теперь, если ваши новые правки всё испортили, запустите:
+
+ $ git reset --hard
+
+чтобы вернуться к исходному состоянию. Чтобы вновь сохраниться, выполните:
+
+ $ git commit -a -m "Другой бекап"
+
+==== Добавление, удаление, переименование ====
+
+Приведенный выше пример будет отслеживать файлы, которые вы добавили, когда впервые запустили *git add*. Если вы хотите добавить новые файлы или поддиректории, вам придётся сказать Git:
+
+ $ git add НОВЫЕ_ФАЙЛЫ...
+
+Аналогично, если вы хотите, чтобы Git забыл о некоторых файлах, например, потому что вы удалили их:
+
+ $ git rm СТАРЫЕ_ФАЙЛЫ...
+
+Переименование файла — это то же, что и удаление старого имени и добавления нового. Для этого есть *git mv*, который имеет тот же синтаксис, что и команда *mv*. Например:
+
+ $ git mv OLDFILE NEWFILE
+
+=== Расширенная отмена/Восстановление ===
+
+Иногда вы просто хотите вернуться к определенной точке и забыть все изменения, потому что все они были неправильными. В таком случае:
+
+ $ git log
+
+покажет вам список последних изменений (коммитов, прим. пер.) и их SHA1 хеши. Далее введите:
+
+ $ git reset --hard SHA1_HASH
+
+для восстановления состояния до указанного коммита и удаления всех последующих коммитов безвозвратно.
+
+Возможно, в другой раз вы захотите быстро вернуться к старому состоянию. В этом случае наберите:
+
+ $ git checkout SHA1_HASH
+
+Это перенесет вас назад во времени, до тех пор пока вы не сделаете новые коммиты. Как и в фантастических фильмах о путешествиях во времени, если вы редактируете и коммитите код, вы будете находиться в альтернативной реальности, потому что ваши действия отличаются от тех, что вы делали до этого.
+
+Эта альтернативная реальность называется «ветвь» (branch, прим. пер.), и
+<<branch,чуть позже мы поговорим об этом>>. А сейчас просто запомните:
+
+ $ git checkout master
+
+вернёт вас обратно в настоящее. Кроме того, чтобы не получать предупреждений от Git, всегда делайте коммит или сброс ваших изменений до запуска checkout.
+
+Ещё раз воспользуемся терминологией компьютерных игр:
+
+- *`git reset --hard`*: загружает ранее сохраненную игру и удаляет все версии, сохраненные после только что загруженной.
+
+- *`git checkout`*: загружает старую игру, но если вы продолжаете играть, состояние игры будет отличаться от более новых сохранений, которые вы сделали в первый раз. Любая игра, которую вы теперь сохраняете, попадает в отдельную ветвь, представляющую альтенативную реальность, в которую вы вошли.
+<<branch,Как мы договорились, о бранчах поговорим позже>>.
+
+Вы можете выбрать для восстановления только определенные файлы и поддиректории путём перечисления их имён после команды:
+
+ $ git checkout SHA1_HASH some.file another.file
+
+Будьте внимательны: такая форма *checkout* может незаметно перезаписать файлы. Чтобы избежать неприятных неожиданностей, выполняйте коммит до запуска checkout, особенно если вы только осваиваетесь с Git. Вообще, если вы не уверены в какой-либо операции, будь то команда Git или нет, сперва выполните *git commit -a*.
+
+Не любите копировать и вставлять хеши? Используйте:
+
+ $ git checkout :/"Мой первый б"
+
+для перехода на коммит, который начинается с приведенной строки.
+
+Можно также запросить 5-ое с конца сохраненное состояние:
+
+ $ git checkout master~5
+
+==== Возвраты ====
+
+В зале суда в протокол могут вноситься изменения прямо во время слушания. Подобным образом и вы можете выбирать коммиты для возврата.
+
+ $ git commit -a
+ $ git revert SHA1_HASH
+
+отменит коммит с выбранным хешем. Запущенный *git log* показывает, что изменение записано в качестве нового коммита.
+
+=== Создание списка изменений ===
+
+Некоторым проектам требуется http://en.wikipedia.org/wiki/Changelog[список изменений] (changelog, прим. пер.).
+Создать такой список вы можете, просто направив вывод *git log* в файл:
+
+ $ git log > ChangeLog
+
+=== Скачивание файлов ===
+
+Получить копию проекта под управлением Git можно, набрав:
+
+ $ git clone git://server/path/to/files
+
+Например, чтобы получить все файлы, я создавал такой сайт:
+
+ $ git clone git://git.or.cz/gitmagic.git
+
+Мы поговорим больше о команде *clone* позже.
+
+=== На острие ножа ===
+
+Если вы уже загрузили копию проекта с помощью *git clone*, вы можете обновить его до последней версии, используя:
+
+ $ git pull
+
+=== Публичный доступ ===
+
+Предположим, вы написали скрипт, которым хотите поделиться с другими. Можно просто позволить всем загружать его с вашего компьютера, но, если они будут делать это в то время, как вы дорабатываете его или добавляете экспериментальную функциональность, у них могут возникнуть проблемы. Конечно, это одна из причин существования цикла разработки. Разработчики могут долго работать над проектом, но открывать доступ к коду следует только после того, как код приведен в приличный вид.
+
+Чтобы сделать это с помощью Git, выполните в директории, где лежит ваш скрипт:
+
+ $ git init
+ $ git add .
+ $ git commit -m "Первый релиз"
+
+Затем скажите вашим пользователям запустить:
+
+ $ git clone ваш.компьютер:/path/to/script
+
+для того чтобы загрузить ваш скрипт. Это подразумевает что у вас есть доступ по ssh. Если нет, запустите *git daemon* и скажите остальным использовать для запуска:
+
+ $ git clone git://ваш.компьютер/path/to/script
+
+Теперь, всякий раз когда ваш скрипт готов к релизу, выполняйте:
+
+ $ git commit -a -m "Следующий релиз"
+
+и ваши пользователи смогут обновить свои версии, перейдя в директорию, содержащую ваш скрипт, и, набрав:
+
+ $ git pull
+
+ваши пользователи никогда не попадут на версии скрипта, доступ к которым вы скрываете. Безусловно, этот трюк работает для всего, а не только в случаях со скриптами.
+
+=== Что я наделал? ===
+
+Выясните, какие изменения вы сделали со времени последнего коммита:
+
+ $ git diff
+
+Или со вчерашнего дня:
+
+ $ git diff "@{yesterday}"
+
+Или между определенной версией и версией, сделанной 2 коммита назад:
+
+ $ git diff SHA1_HASH "master~2"
+
+В каждом случае на выходе будет патч, который может быть применён с помощью *git apply*.
+
+Попробуйте также:
+
+ $ git whatchanged --since="2 weeks ago"
+
+Часто я смотрю историю при помощи http://sourceforge.net/projects/qgit[qgit] вместо стандартного способа,
+из-за приятного интерфейса, или с помощью http://jonas.nitro.dk/tig[tig] с текстовым интерфейсом,
+который хорошо работает при медленном соединении. В качестве альтернативы, можно запустить веб-сервер,
+введя *git instaweb*, и запустить любой веб-браузер.
+
+=== Упражнение ===
+
+Пусть A, B, C, D четыре успешных коммита, где В — то же, что и A, но с несколькими удаленными файлами. Мы хотим вернуть файлы в D, но не в B. Как это можно сделать?
+
+Существует как минимум три решения. Предположим, что мы находимся на D.
+
+  1. Разница между A и B — удаление файлов.
+  Мы можем создать патч, отражающий эти изменения, и применить его:
+
+   $ git diff B A | git apply
+
+  2. Поскольку в коммите A мы сохранили файлы, мы можем получить их обратно:
+
+   $ git checkout A FILES...
+
+  3. Мы можем рассматривать переход от A до B в качестве изменений, которые мы хотим отменить:
+
+   $ git revert B
+
+Какой способ лучший?
+Тот, который вам больше нравится. С Git легко сделать все, что вы хотите, причём часто существует много разных способов сделать одно и то-же.
+