ru/basic.txt

   1 == Базовые операции ==
   2
   3 Прежде чем погружаться в дебри многочисленных команд Git, попробуйте воспользоваться приведёнными ниже простыми примерами, чтобы немного освоиться. Несмотря на свою простоту, каждый из них является полезным.
   4
   5 В самом деле, первые месяцы использования Git я не выходил за рамки материала, изложенного в этой главе.
   6
   7 === Сохранение состояния ===
   8
   9 Выполняете опасную операцию? Прежде чем сделать это, создайте снимок всех файлов в текущей директории с помощью команд:
  10
  11  $ git init
  12  $ git add .
  13  $ git commit -m "Мой первый бекап"
  14
  15 Теперь, если ваши новые правки всё испортили, запустите:
  16
  17  $ git reset --hard
  18
  19 чтобы вернуться к исходному состоянию. Чтобы вновь сохраниться, выполните:
  20
  21  $ git commit -a -m "Другой бекап"
  22
  23 ==== Добавление, удаление, переименование ====
  24
  25 Приведенный выше пример будет отслеживать файлы, которые вы добавили, когда впервые запустили *git add*. Если вы хотите добавить новые файлы или поддиректории, вам придётся сказать Git:
  26
  27  $ git add НОВЫЕ_ФАЙЛЫ...
  28
  29 Аналогично, если вы хотите, чтобы Git забыл о некоторых файлах, например, потому что вы удалили их:
  30
  31  $ git rm СТАРЫЕ_ФАЙЛЫ...
  32
  33 Переименование файла — это то же, что и удаление старого имени и добавления нового. Для этого есть *git mv*, который имеет тот же синтаксис, что и команда *mv*. Например:
  34
  35  $ git mv OLDFILE NEWFILE
  36
  37 === Расширенная отмена/Восстановление ===
  38
  39 Иногда вы просто хотите вернуться к определенной точке и забыть все изменения, потому что все они были неправильными. В таком случае:
  40
  41  $ git log
  42
  43 покажет вам список последних изменений (коммитов, прим. пер.) и их SHA1 хеши. Далее введите:
  44
  45  $ git reset --hard SHA1_HASH
  46
  47 для восстановления состояния до указанного коммита и удаления всех последующих коммитов безвозвратно.
  48
  49 Возможно, в другой раз вы захотите быстро вернуться к старому состоянию. В этом случае наберите:
  50
  51  $ git checkout SHA1_HASH
  52
  53 Это перенесет вас назад во времени, до тех пор пока вы не сделаете новые коммиты. Как и в фантастических фильмах о путешествиях во времени, если вы редактируете и коммитите код, вы будете находиться в альтернативной реальности, потому что ваши действия отличаются от тех, что вы делали до этого.
  54
  55 Эта альтернативная реальность называется «ветвь» (branch, прим. пер.), и
  56 <<branch,чуть позже мы поговорим об этом>>. А сейчас просто запомните:
  57
  58  $ git checkout master
  59
  60 вернёт вас обратно в настоящее. Кроме того, чтобы не получать предупреждений от Git, всегда делайте коммит или сброс ваших изменений до запуска checkout.
  61
  62 Ещё раз воспользуемся терминологией компьютерных игр:
  63
  64 - *`git reset --hard`*: загружает ранее сохраненную игру и удаляет все версии, сохраненные после только что загруженной.
  65
  66 - *`git checkout`*: загружает старую игру, но если вы продолжаете играть, состояние игры будет отличаться от более новых сохранений, которые вы сделали в первый раз. Любая игра, которую вы теперь сохраняете, попадает в отдельную ветвь, представляющую альтенативную реальность, в которую вы вошли.
  67 <<branch,Как мы договорились, о бранчах поговорим позже>>.
  68
  69 Вы можете выбрать для восстановления только определенные файлы и поддиректории путём перечисления их имён после команды:
  70
  71  $ git checkout SHA1_HASH some.file another.file
  72
  73 Будьте внимательны: такая форма *checkout* может незаметно перезаписать файлы. Чтобы избежать неприятных неожиданностей, выполняйте коммит до запуска checkout, особенно если вы только осваиваетесь с Git. Вообще, если вы не уверены в какой-либо операции, будь то команда Git или нет, сперва выполните *git commit -a*.
  74
  75 Не любите копировать и вставлять хеши? Используйте:
  76
  77  $ git checkout :/"Мой первый б"
  78
  79 для перехода на коммит, который начинается с приведенной строки.
  80
  81 Можно также запросить 5-ое с конца сохраненное состояние:
  82
  83  $ git checkout master~5
  84
  85 ==== Возвраты ====
  86
  87 В зале суда в протокол могут вноситься изменения прямо во время слушания. Подобным образом и вы можете выбирать коммиты для возврата.
  88
  89  $ git commit -a
  90  $ git revert SHA1_HASH
  91
  92 отменит коммит с выбранным хешем. Запущенный *git log* показывает, что изменение записано в качестве нового коммита.
  93
  94 === Создание списка изменений ===
  95
  96 Некоторым проектам требуется http://en.wikipedia.org/wiki/Changelog[список изменений] (changelog, прим. пер.).
  97 Создать такой список вы можете, просто направив вывод *git log* в файл:
  98
  99  $ git log > ChangeLog
 100
 101 === Скачивание файлов ===
 102
 103 Получить копию проекта под управлением Git можно, набрав:
 104
 105  $ git clone git://server/path/to/files
 106
 107 Например, чтобы получить все файлы, я создавал такой сайт:
 108
 109  $ git clone git://git.or.cz/gitmagic.git
 110
 111 Мы поговорим больше о команде *clone* позже.
 112
 113 === На острие ножа ===
 114
 115 Если вы уже загрузили копию проекта с помощью *git clone*, вы можете обновить его до последней версии, используя:
 116
 117  $ git pull
 118
 119 === Публичный доступ ===
 120
 121 Предположим, вы написали скрипт, которым хотите поделиться с другими. Можно просто позволить всем загружать его с вашего компьютера, но, если они будут делать это в то время, как вы дорабатываете его или добавляете экспериментальную функциональность, у них могут возникнуть проблемы. Конечно, это одна из причин существования цикла разработки. Разработчики могут долго работать над проектом, но открывать доступ к коду следует только после того, как код приведен в приличный вид.
 122
 123 Чтобы сделать это с помощью Git, выполните в директории, где лежит ваш скрипт:
 124
 125  $ git init
 126  $ git add .
 127  $ git commit -m "Первый релиз"
 128
 129 Затем скажите вашим пользователям запустить:
 130
 131  $ git clone ваш.компьютер:/path/to/script
 132
 133 для того чтобы загрузить ваш скрипт. Это подразумевает что у вас есть доступ по ssh. Если нет, запустите *git daemon* и скажите остальным использовать для запуска:
 134
 135  $ git clone git://ваш.компьютер/path/to/script
 136
 137 Теперь, всякий раз когда ваш скрипт готов к релизу, выполняйте:
 138
 139  $ git commit -a -m "Следующий релиз"
 140
 141 и ваши пользователи смогут обновить свои версии, перейдя в директорию, содержащую ваш скрипт, и, набрав:
 142
 143  $ git pull
 144
 145 ваши пользователи никогда не попадут на версии скрипта, доступ к которым вы скрываете. Безусловно, этот трюк работает для всего, а не только в случаях со скриптами.
 146
 147 === Что я наделал? ===
 148
 149 Выясните, какие изменения вы сделали со времени последнего коммита:
 150
 151  $ git diff
 152
 153 Или со вчерашнего дня:
 154
 155  $ git diff "@{yesterday}"
 156
 157 Или между определенной версией и версией, сделанной 2 коммита назад:
 158
 159  $ git diff SHA1_HASH "master~2"
 160
 161 В каждом случае на выходе будет патч, который может быть применён с помощью *git apply*.
 162
 163 Попробуйте также:
 164
 165  $ git whatchanged --since="2 weeks ago"
 166
 167 Часто я смотрю историю при помощи http://sourceforge.net/projects/qgit[qgit] вместо стандартного способа,
 168 из-за приятного интерфейса, или с помощью http://jonas.nitro.dk/tig[tig] с текстовым интерфейсом,
 169 который хорошо работает при медленном соединении. В качестве альтернативы, можно запустить веб-сервер,
 170 введя *git instaweb*, и запустить любой веб-браузер.
 171
 172 === Упражнение ===
 173
 174 Пусть A, B, C, D четыре успешных коммита, где В — то же, что и A, но с несколькими удаленными файлами. Мы хотим вернуть файлы в D, но не в B. Как это можно сделать?
 175
 176 Существует как минимум три решения. Предположим, что мы находимся на D.
 177
 178   1. Разница между A и B — удаление файлов.
 179   Мы можем создать патч, отражающий эти изменения, и применить его:
 180
 181    $ git diff B A | git apply
 182
 183   2. Поскольку в коммите A мы сохранили файлы, мы можем получить их обратно:
 184
 185    $ git checkout A FILES...
 186
 187   3. Мы можем рассматривать переход от A до B в качестве изменений, которые мы хотим отменить:
 188
 189    $ git revert B
 190
 191 Какой способ лучший?
 192 Тот, который вам больше нравится. С Git легко сделать все, что вы хотите, причём часто существует много разных способов сделать одно и то-же.
 193