Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

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

  • Loading branch information...
commit bb48bf21b01bd0ed1266f2f594627be9b1a5372b 1 parent 465ddea
@VBoden authored
Showing with 192 additions and 0 deletions.
  1. +192 −0 uk/branch.txt
View
192 uk/branch.txt
@@ -0,0 +1,192 @@
+== Чудеса розгалуження ==
+
+Можливості миттєвого розгалуження і злиття - найкращі особливості Git.
+
+*Завдання*: зовнішні фактори неминуче тягнуть переключення уваги. Серйозна помилка в уже випущеній версії виявляється без попередження. Термін здачі певної функціональності наближається. Розробник, допомога якого потрібна вам в роботі над ключовою частиною проекту, збирається у відпустку. Одним словом, вам потрібно терміново кинути все, над чим ви працюєте в даний момент, і переключитися на зовсім інші завдання.
+
+Переривання ходу ваших думок може серйозно знизити ефективність роботи, і чим складніше перемикання між процесами, тим більшою буде втрата. При централізованому управлінні версіями ми змушені завантажувати свіжу робочу копію з центрального сервера. Розподілена система краще: ми можемо клонувати потрібну версію локально.
+
+Проте клонування все ж передбачає копіювання всього робочого каталогу, як і всієї історії змін до теперішнього моменту. Хоча Git і знижує витратність цієї дії за рахунок можливості спільного використання файлів і жорстких посилань, але всі файли проекту доведеться повністю відтворити в новому робочому каталозі.
+
+*Розв'язання*: у Git є більш зручний інструмент для таких випадків, який заощадить і час, і дисковий простір в порівнянні з клонуванням - це *git branch* (branch - гілка, прим. пер.).
+
+Цим чарівним словом файли в вашому каталозі миттєво перетворяться від однієї версії до іншої. Ця зміна дозволяє зробити набагато більше, ніж просто повернутися назад або просунутися вперед в історії. Ваші файли можуть зміниться з останньої випущеної версії на експериментальну, з експериментальної - на поточну версію у розробці, з неї - на версію вашого друга і так далі.
+
+=== Кнопка боса ===
+
+Грали коли-небудь в одну з таких ігор, де при натисканні певної клавіші (``кнопки боса''), на екрані миттєво відображається таблиця або щось на зразок того? Тобто, якщо в офіс зайшов начальник, а ви граєте в гру, ви можете швидко її приховати.
+
+У якомусь каталозі:
+
+ $ echo "Я хитріший за мого боса" > myfile.txt
+ $ git init
+ $ git add .
+ $ git commit -m "Початковий комміт"
+
+Ми створили сховище Git, що містить один текстовий файл з певним повідомленням. Тепер виконайте
+
+ $ git checkout -b boss # ймовірно, це остання зміна
+ $ echo "Мій бос розумніший за мене" > myfile.txt
+ $ git commit -a -m "Інший комміт"
+
+Це виглядає так, ніби ми тільки що перезаписали файл і зробили комміт. Але це ілюзія. Наберіть
+
+ $ git checkout master # переключитися на оригінальну версію файлу
+
+Вуаля! Текстовий файл відновлений. А якщо бос вирішить сунути ніс в цей каталог, запустіть
+
+ $ git checkout boss # перейти на версію, яка підходить для очей боса
+
+Ви можете переключатися між двома версіями цього файлу так часто, як вам хочеться і робити комміти кожної з них незалежно.
+
+=== Грязная работа ===
+
+[[branch]]
+Допустим, вы работаете над некой функцией, и вам зачем-то понадобилось вернуться на три версии назад и временно добавить несколько операторов вывода, чтобы посмотреть как что-либо работает. Тогда введите
+
+ $ git commit -a
+ $ git checkout HEAD~3
+
+Теперь вы можете добавлять временный черновой код в любых местах. Можно даже закоммитить эти изменения. Когда закончите, выполните
+
+ $ git checkout master
+
+чтобы вернуться к исходной работе. Заметьте, что любые изменения, не внесенные в коммит, будут перенесены.
+
+А что, если вы все-таки хотели сохранить временные изменения? Запросто:
+
+ $ git checkout -b dirty
+
+а затем сделайте коммит перед возвращением в ветку master. Всякий раз, когда вы захотите вернуться к черновым изменениям, просто выполните
+
+ $ git checkout dirty
+
+Мы говорили об этой команде в одной из предыдущих глав, когда обсуждали загрузку старых состояний. Теперь у нас перед глазами полная картина: файлы изменились к нужному состоянию, но мы должны покинуть главную ветку. Любые коммиты, сделанные с этого момента, направят файлы по другому пути, к которому можно будет вернуться позже.
+
+Другими словами, после переключения на более старое состояние Git автоматически направляет вас по новой безымянной ветке, которой можно дать имя и сохранить ее с помощью *git checkout -b*.
+
+=== Быстрые исправления ===
+
+Ваша работа в самом разгаре, когда вдруг выясняется, что нужно все бросить и исправить только что обнаруженную ошибку в коммите «1b6d…»:
+
+ $ git commit -a
+ $ git checkout -b fixes 1b6d
+
+После исправления ошибки сделайте
+
+ $ git commit -a -m "Ошибка исправлена"
+ $ git checkout master
+
+и вернитесь к работе над вашими исходными задачами.
+
+Вы можете даже «влить» только что сделанное исправление ошибки в основную ветку:
+
+ $ git merge fixes
+
+=== Слияния ===
+
+В некоторых системах управления версиями создавать ветки легко, а вот сливать их воедино трудно. В Git слияние столь тривиально, что вы можете его не заметить.
+
+На самом деле мы сталкивались со слияниями уже давно. Команда *pull* по сути получает коммиты, а затем сливает их с вашей текущей веткой. Если у вас нет локальных изменений, слияние произойдет само собой, как вырожденный случай вроде получения последней версии в централизованной системе управления версиями. Если же у вас есть локальные изменения, Git автоматически произведет слияние и сообщит о любых конфликтах.
+
+Обычно у коммита есть один «родитель», а именно предыдущий коммит. Слияние веток приводит к коммиту как минимум с двумя родителями. Отсюда возникает вопрос: к какому коммиту на самом деле отсылает HEAD~10? Коммит может иметь несколько родителей, так за которым из них следовать далее?
+
+Оказывается, такая запись всегда выбирает первого родителя. Это хороший выбор, потому что текущая ветка становятся первым родителем во время слияния. Часто вас интересуют только изменения, сделанные вами в текущей ветке, а не те, которые влились из других веток.
+
+Вы можете обращаться к конкретному родителю с помощью символа «^». Например, чтобы показать запись в журнале от второго родителя, наберите
+
+ $ git log HEAD^2
+
+Для первого родителя номер можно опустить. Например, чтобы показать разницу с первым родителем, введите
+
+ $ git diff HEAD^
+
+Вы можете сочетать такую запись с другими. Например,
+
+ $ git checkout 1b6d^^2~10 -b ancient
+
+создаст новую ветку «ancient» («древняя», прим. пер.), отражающую состояние на десять коммитов назад от второго родителя первого родителя коммита, начинающегося с 1b6d.
+
+=== Непрерывный рабочий процесс ===
+
+В производстве техники часто бывает, что второй шаг плана должен ждать завершения первого шага. Автомобиль, нуждающийся в ремонте, может тихо стоять в гараже до прибытия с завода конкретной детали. Прототип может ждать производства чипа, прежде чем разработка будет продолжена.
+
+И в разработке ПО может быть то же. Вторая порция новой функциональности может быть вынуждена ожидать выпуска и тестирования первой части. Некоторые проекты требуют проверки вашего кода перед его принятием, так что вы должны дождаться утверждения первой части, прежде чем начинать вторую.
+
+Благодаря безболезненным ветвлению и слиянию, мы можем изменить правила и работать над второй частью до того, как первая официально будет готова. Допустим, вы закоммитили первую часть и выслали ее на проверку. Скажем, вы в ветке master. Теперь смените ветку:
+
+ $ git checkout -b part2 # часть2
+
+Затем работайте над второй частью, попутно внося коммиты ваших изменений. Человеку свойственно ошибаться, и часто вы хотите вернуться и поправить что-то в первой части. Если вы везучи или очень искусны, можете пропустить эти строки.
+
+ $ git checkout master # Возвращаемся к первой части.
+ $ вносим_исправления
+ $ git commit -a # Фиксируем изменения
+ $ git checkout part2 # Возвращаемся ко второй части.
+ $ git merge master # Вливаем сделанные исправления.
+
+В конечном счете, первая часть утверждена:
+
+ $ git checkout master # Возвращаемся к первой части.
+ $ отправка файлов # Выпускаем в мир!
+ $ git merge part2 # Вливаем вторую часть.
+ $ git branch -d part2 # Удаляем ветку part2.
+
+Теперь вы снова в ветке master, а вторая часть — в вашем рабочем каталоге.
+
+Этот прием легко расширить на любое количество частей. Столь же легко сменить ветку задним числом. Предположим, вы слишком поздно обнаружили, что должны были создать ветку семь коммитов назад. Тогда введите:
+
+ $ git branch -m master part2 # Переименовываем ветку master в part2.
+ $ git branch master HEAD~7 # Создаем новую ветку master семью коммитами выше.
+
+Теперь ветка master содержит только первую часть, а ветка part2 — всё остальное. В последней мы и находимся. Мы создали ветку master, не переключаясь на нее, потому что хотим продолжить работу над part2. Это непривычно: до сих пор мы переключались на ветки сразу же после их создания, вот так:
+
+ $ git checkout HEAD~7 -b master # Создаем ветку и переключаемся на нее.
+
+=== Изменяем состав смеси ===
+
+Предположим, вам нравится работать над всеми аспектами проекта в одной и той же ветке. Вы хотите закрыть свой рабочий процесс от других, чтобы все видели ваши коммиты только после того, как они будут хорошо оформлены. Создайте пару веток:
+
+ $ git branch sanitized # Создаем ветку для очищенных коммитов.
+ $ git checkout -b medley # Создаем ветку для работы и переключаемся на нее.
+
+Далее делайте всё что нужно: исправляйте ошибки, добавляйте новые функции, добавляйте временный код и так далее, при этом почаще выполняя коммиты. После этого
+
+ $ git checkout sanitized
+ $ git cherry-pick medley^^
+
+применит коммит «пра-родителя» головы ветки «medley» к ветке «sanitized». Правильно подбирая элементы, вы сможете создать ветку, в которой будет лишь окончательный код, а связанные между собой коммиты будут собраны вместе.
+
+=== Управление Ветками ===
+
+Для просмотра списка всех веток наберите
+
+ $ git branch
+
+По умолчанию вы начинаете с ветки под названием «master». Кому-то нравится оставлять ветку «master» нетронутой и создавать новые ветки со своими изменениями.
+
+Опции *-d* и *-m* позволяют удалять и перемещать (переименовывать) ветки. Смотрите *git help branch*.
+
+Ветка «master» — это удобная традиция. Другие могут предполагать, что в вашем хранилище есть ветка с таким именем и что она содержит официальную версию проекта. Хотя вы можете переименовать или уничтожить ветку «master», лучше соблюсти общее соглашение.
+
+=== Временные Ветки ===
+
+Через какое-то время вы можете обнаружить, что создаете множество временных веток для одной и той же краткосрочной цели: каждая такая ветка всего лишь сохраняет текущее состояние, чтобы вы могли вернуться назад и исправить серьезную ошибку или сделать что-то еще.
+
+Это похоже на то, как вы переключаете телевизионные каналы, чтобы посмотреть что показывают по другим. Но вместо того, чтобы нажать на пару кнопок, вам нужно создавать, выбирать (checkout), сливать (merge) а затем удалять временные ветки. К счастью, в Git есть сокращенная команда, столь же удобная, как пульт дистанционного управления.
+
+ $ git stash
+
+Эта команда сохранит текущее состояние в во временном месте («тайнике», stash) и востановит предыдущее состояние. Ваш каталог становиться точно таким, каким был до начала редактирования, и вы можете исправить ошибки, загрузить удаленные изменения и тому подобное. Когда вы хотите вернуться назад в состояние «тайника», наберите:
+
+ $ git stash apply # Возможно, понадобится устранить возникшие конфликты.
+
+Можно создавать несколько тайников, используя их по-разному. Смотрите *git help stash*. Как вы могли догадаться, Git оставляет ветки «за кадром» при выполнении этого чудесного приема.
+
+=== Работайте как вам нравится ===
+
+Возможно, вы сомневаетесь, стоят ли ветки таких хлопот. В конце концов, клоны почти столь же быстрые и вы можете переключаться между ними с помощью *cd* вместо загадочных команд Git.
+
+Посмотрим на веб-браузеры. Зачем нужна поддержка вкладок вдобавок к окнам? Поддержка и тех, и других позволяет приспособиться к широкому разнообразию стилей работы. Некоторым пользователям нравится держать открытым единственное окно и использовать вкладки для множества веб-страниц. Другие могут впасть в другую крайность: множество окон без вкладок вообще. Третьи предпочтут нечто среднее.
+
+Ветки похожи на вкладки для рабочего каталога, а клоны — на новые окна браузера. Эти операции быстры и выполняются локально, так почему бы не поэкспериментировать и не найти наиболее удобную для себя комбинацию? Git позволяет работать в точности так, как вам нравится.
Please sign in to comment.
Something went wrong with that request. Please try again.