Skip to content
This repository
Browse code

частково перекладено (до 40 рядка) файл uk/branch.txt

  • Loading branch information...
commit bb48bf21b01bd0ed1266f2f594627be9b1a5372b 1 parent 465ddea
Volodymyr Bodenchuk authored September 25, 2012

Showing 1 changed file with 192 additions and 0 deletions. Show diff stats Hide diff stats

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

0 notes on commit bb48bf2

Please sign in to comment.
Something went wrong with that request. Please try again.