ru/branch.txt

   1 == Чудеса ветвления ==
   2 Возможности мгновенного разветвления и слияния - самые уникальные особенности Git.
   3
   4 *Задача*: какие-то причины требуют  переключения процессов. В новой версии внезапно возникает серьезная ошибка. Срок завершения работы над определенным свойством близится к концу. Разработчик, помощь которого очень нужна Вам в работе над ключевым разделом, собирается в отпуск. Итак, Вам нужно срочно бросить все, над чем Вы трудитесь в настоящий момент, и переключиться на совершенно другие дела.
   5
   6 Переключение внимания с одного на другое может серьезно снизить эффективность работы, и чем сложнее переход между процессами, тем больше будет потеря. При централизованном управлении версиями необходимо скачивать вновь разработанную рабочую копию с центрального сервера. Распределенная система предоставляет лучшие возможности, так как позволяет клонировать нужную версию в локальное рабочее место.
   7
   8 Однако клонирование все же предполагает копирование всей рабочей директории, а, значит, всей истории изменений до настоящего момента. Даже при том, что Git позволяет сэкономить средства за счет возможности совместного использования файлов и жестких ссылок, все файлы проекта придется полностью воссоздать в новой рабочей директории.
   9
  10 *Решение*: у Git есть более удобный инструмент для этих целей, который, в отличие от клонирования, сэкономит и время, и дисковое пространство - это *git branch*.
  11
  12 С этой волшебной командой файлы в вашей директории мгновенно изменяются с одной версии на другую. Это изменение позволяет сделать намного больше, чем просто вернуться назад или продвинуться вперед в истории. Ваши файлы могут изменится с последней версии на экспериментальную, с экспериментальной - на опытную, с  опытной - на версию вашего друга и так далее.
  13
  14 === Кнопка босса ===
  15
  16 Наверняка, вы играли в одну из тех игр, где при нажатии определеной клавиши ("кнопка босса"), игра быстро сворачивается и на экране отображается рабочая таблица или что-нибудь другое? То есть, если в офис зашел начальник, а вы играете в игру, вы должны уметь быстро ее скрыть.
  17
  18 В какой-нибудь директории:
  19
  20  $ echo "Я хитрее моего босса" > myfile.txt
  21  $ git init
  22  $ git add .
  23  $ git commit -m "Начальный коммит"
  24
  25 Мы создали Git-репозиторий который содержит один текстовый файл с определенным сообщением. Теперь выполните:
  26
  27  $ git checkout -b boss # вероятно, это последнее изменение
  28  $ echo "Мой босс меня умнее" > myfile.txt
  29  $ git commit -a -m "Другой коммит"
  30
  31 Похоже на то, как будто мы перезаписали файл и сделали коммит. Но это иллюзия. Наберите:
  32
  33  $ git checkout master # переключиться на оригинальную версию файла
  34
  35 Вуаля! Текстовый файл восстановлен. И если босс будет рядом, запустите
  36
  37  $ git checkout boss # перейти на специальную версию для босса
  38
  39 Вы можете переключаться между двумя версиями этого файла так часто, как вам хочется и делать коммиты в каждый из них независимо.
  40
  41 === Грязная работа ===
  42
  43 [[branch]]
  44
  45 Допустим, вы работаете над созданием какой-либо функции, и по каким-то причинам необходимо вернуться назад к
  46 старой версии и временно загрузить старый код, чтобы посмотреть как что-либо работало, тогда введите:
  47
  48  $ git commit -a
  49  $ git checkout SHA1_HASH
  50
  51 Теперь вы можете добавить везде, где необходимо, временный  черновой код. Можно даже сделать коммит изменений. Когда закончите, выполните:
  52
  53  $ git checkout master
  54
  55 чтобы вернуться к исходной работе. Заметьте, что любые изменения, не внесенные в коммит, будут перенесены.
  56
  57 А что, если вы все-таки хотели сохранить временные изменения? Пожалуйста:
  58
  59  $ git checkout -b dirty
  60
  61 а затем сделайте коммит перед тем, как переключетесь на ветвь master. Всякий раз когда вы захотите вернуться к черновым изменениям, просто выполните:
  62
  63  $ git checkout dirty
  64
  65 Мы говорили об этой команде ранее, в другой главе, когда обсуждали загрузку старых состояний. Теперь у нас перед глазами полная картина: файлы меняются на нужное состояние, но мы должны оставить ветвь master. Любые коммиты, сделанные с этого момента, направят файлы по другому пути, который может быть назван позже.
  66
  67 Другими словами, после переключения с более старого состояния, Git автоматически направляет вас в новую еще не названную ветвь, которой можно дать имя и сохранить с помощью *git checkout -b*.
  68
  69 === Быстрые исправления ===
  70
  71 Ваша работа в самом разгаре, когда вдруг выясняется, что нужно все бросить и исправить только что обнаруженную ошибку:
  72
  73  $ git commit -a
  74  $ git checkout -b fixes SHA1_HASH
  75
  76 Затем, после того, как вы исправили ошибку:
  77
  78  $ git commit -a -m "Ошибка исправлена"
  79  $ git push # в центральный репозиторий
  80  $ git checkout master
  81
  82 и вернитесь к работе над вашими исходными задачами.
  83
  84 === Бесперебойный рабочий процесс ===
  85
  86 В некоторых проектах необходимо проверять код до того, как выложить его. Чтобы облегчить задачу другим разработчикам, которые будут проверять ваш код, при внесении значительных изменений, разбивайте измененный проект на 2 или более частей и выкладывайте по одной для проверки.
  87
  88 А что, если вторую часть нельзя записать до того, как первая часть проверена и принята? Во многих системах управления версиями отправить на рассмотрение вторую часть можно только после утверждения первой части.
  89
  90 На самом деле это не совсем правда, но необходимость в таких системах редактировать часть II перед тем, как отправить часть I, связана с трудностями и неудобствами. В Git, ветвление и слияние гораздо безболезненней (говоря техническим языком - это можно сделать быстрее и на локальном уровне). Поэтому, после того, как вы сделали коммит первой части, и направили его для рассмотрения:
  91
  92  $ git checkout -b part2
  93
  94 Далее, можно изменять вторую часть, не ожидая принятия первой части. После того, как первая часть утверждена и выложена,
  95
  96  $ git checkout master
  97  $ git merge part2
  98  $ git branch -d part2 # эта ветка больше не нужна
  99
 100 и вторая часть правок готова к проверке.
 101
 102 Однако не торопитесь! Что, если не все так просто? Что, если в первой части вы сделали ошибку, которую необходимо было исправить до отправки. Запросто! Во-первых, вернитесь в master-ветвь с помощью:
 103
 104  $ git checkout master
 105
 106 Исправьте изменения в первой части и отправьте на проверку. Если же они не будут приняты, можно просто повторить этот шаг. Вы, вероятно, также захотите произвести слияние исправлений части I с частью II, тогда выполните:
 107
 108  $ git checkout part2
 109  $ git merge master
 110
 111 И теперь - тоже самое. После того, как первая часть утверждена и выложена:
 112
 113  $ git checkout master
 114  $ git merge part2
 115  $ git branch -d part2
 116
 117 и снова, вторая часть готова к проверке.
 118
 119 Вы можете легко использовать этот трюк для любого количества частей.
 120
 121 === Собрать все в кучу ===
 122
 123 Предположим, вам нравится работать над всеми аспектами проекта в одной и той же ветке. Вы хотите закрыть свой рабочий процесс от других, чтобы все видели ваши коммиты только после того, как они будут хорошо оформлены. Создайте несколько веток:
 124
 125  $ git checkout -b sanitized
 126  $ git checkout -b medley
 127
 128 Далее, работайте над чем угодно: исправляйте ошибки, добавляйте новые функции, добавляйте временный код и т.д., при этом постоянно выполняя коммиты. Затем:
 129
 130  $ git checkout sanitized
 131  $ git cherry-pick SHA1_HASH
 132
 133 применит данный коммит для ветви"sanitized". С правильно выбранными элементами вы сможете собрать ветвь, которая будет содержать только проверенный код и соответствующие коммиты, сгруппированные вместе.
 134
 135 === Управление Ветками ===
 136
 137 Для просмотра списка всех веток наберите:
 138
 139  $ git branch
 140
 141 Здесь всегда будет ветка с названием "master", с нее вы начинаете работать по умолчанию. Кому-то нравится оставлять ветку "master" нетронутой и создавать новые ветки со своими изменениями.
 142
 143 Опции *-d* и *-m* позволяют удалять и перемещать (переименовывать) ветки.
 144
 145 См. *git help branch*.
 146
 147 Ветка "master" - это полезная традиция. Все считают очевидным то, что ваш репозиторий должен содержать ветку с таким именем, и эта ветка содержит официальную версию проекта. Вы можете переименовать или удалить ветку "master", однако лучше соблюсти всеобщую традицию.
 148
 149 === Временные Ветки ===
 150
 151 Через какое-то время вы можете обнаружить, что создаете множество временных веток для одной и той краткосрочной цели: нужно сохранить текущее состояние, чтобы была возможность вернуться назад и исправить грубую ошибку или сделать что-то еще.
 152
 153 Это похоже на то, как вы переключаете телевизионные каналы, чтобы посмотреть что показывают по другим. Но здесь, вместо того, чтобы нажать на пару кнопок на пульте, нужно будет создать, сделать отладку, а затем удалить временные ветки и коммиты. К счастью, в Git есть удобные ярлыки, имитирующие работу дистанционного пульта правления.
 154
 155  $ git stash
 156
 157 Это сохраняет текущее состояние в во временном месте ('копилке') и востанавливает предыдущее состояние. Ваша директория становиться точно такой, как и была до того, как вы начали редактирование, и вы можете исправить ошибки, загрузить удаленные изменения и прочее. Когда вы хотите вернуться назад в состояние копилки, наберите:
 158
 159  $ git stash apply # Возможно, понадобится устранить какие-либо конфликты.
 160
 161 Можно создавать несколько копилок, приумножать их и использовать по-разному. Смотрите *git help stash*. Как вы могли догадаться, этот чудесный прием возможен благодаря способности Git поддерживать создание закрытых "тайных" веток.
 162
 163 === Работайте как вам нравится ===
 164
 165 Такие приложения как http://www.mozilla.com/[Mozilla Firefox] позволяют открывать несколько вкладок, и несколько окон. Переключение вкладок позволяет обозревать разное содержание в одном и том же окне. Ветки в Git подобны вкладкам для вашей рабочей директории. Если продолжить аналогию, клонирование в Git подобно открытию нового окна. Эти две возможности делают работу в Git удобной и приятной для пользователя.
 166
 167 На более высоком уровне, многие оконные менеджеры Linux поддерживают несколько рабочих столов.
 168
 169 Ветки в Git подобны переключению на другой рабочий стол, а клонирование подобно подключению дополнительно монитора для получения дополнительного рабочего стола.
 170
 171 Другой пример - это утилита http://www.gnu.org/software/screen/[*screen*]. Эта программа позволяет создавать, закрывать и переключаться между множеством терминальных сессий в одном и том же терминале. Вместо открытия нового терминала (операция клонирования), можно использовать этот, запустив *screen* (создать ветвь). На самом деле  у *screen* еще много возможностей, но это уже тема для другой главы.
 172
 173 Наличие возможностей клонирования, ветвления и быстрого локального слияния позволяет вам выбрать комбинировать их так, как удобно и нужно вам. Git позволяет работать именно так, как вам хочется.