ru/basic.txt

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