From 9f25549dbe9067dcc4031d1aaf09a0eb4bdaf1c7 Mon Sep 17 00:00:00 2001 From: Tikhon Tarnavsky Date: Thu, 8 Jul 2010 11:35:08 +0300 Subject: [PATCH] ru/branch.txt: "Uninterrupted Workflow" chapter translated --- ru/branch.txt | 44 +++++++++++++++++++++----------------------- 1 file changed, 21 insertions(+), 23 deletions(-) diff --git a/ru/branch.txt b/ru/branch.txt index c115a54..ec1a2df 100644 --- a/ru/branch.txt +++ b/ru/branch.txt @@ -116,40 +116,38 @@ === Непрерывный рабочий процесс === -В некоторых проектах ваш код должен быть проверен, прежде чем будет принят. Если вы сделали значительные изменения, то для облегчения задачи тем, кто будет проверять ваш код, разбивайте ваши изменения на 2 или более частей и выкладывайте по одной для проверки. +В производстве техники часто бывает, что второй шаг плана должен ждать завершения первого шага. Автомобиль, нуждающийся в ремонте, может тихо стоять в гараже до прибытия с завода конкретной детали. Прототип может ждать производства чипа, прежде чем разработка будет продолжена. -А что, если вторую часть нельзя записать до того, как первая часть проверена и принята? Во многих системах управления версиями отправить на рассмотрение вторую часть можно только после утверждения первой части. +И в разработке ПО может быть то же. Вторая часть нового функционала может быть вынуждена ожидать выпуска и тестирования первой части. Некоторые проекты требуют проверки вашего кода перед его принятием, так что вы должны дождаться утверждения первой части прежде чем начинать вторую. -На самом деле это не совсем правда, но необходимость в таких системах редактировать часть II перед тем, как отправить часть I, связана с трудностями и неудобствами. В Git ветвление и слияние безболезненно (это техническая аллегория для «быстрее и на локальном уровне»). Поэтому, после создания коммита первой части и направления его для рассмотрения сделайте +Благодаря безболезненному ветвлению и слиянию мы может изменить правила и работать над второй частью до того, как первая официально будет готова. Допустим, вы закоммитили первую часть и выслали её на проверку. Скажем, вы в ветке master. Теперь смените ветку: - $ git checkout -b part2 + $ git checkout -b part2 # часть2 -Теперь пишите вторую часть, не ожидая принятия первой. После того, как первая часть утверждена и выложена, +Затем работайте над второй частью, попутно внося коммиты ваших изменений. Человеку свойственно ошибаться, и часто вы хотите вернуться и поправить что-то в первой части. Если вы везучи или оченрь искусны, можете пропустить эти строки. - $ git checkout master - $ git merge part2 - $ git branch -d part2 # эта ветка больше не нужна + $ git checkout master # Возвращаемся к первой части. + $ edit files # Исправляем её. + $ git checkout part2 # Возвращаемся ко второй части. + $ git merge master # Вливаем сделанные исправления. -и вторая часть правок готова к проверке. + В конечном счёте, первая часть утверждена: -Но стоп! Что, если не все так просто? Скажем, в первой части вы сделали ошибку, которую нужно было исправить до отправки. Запросто! Во-первых, вернитесь в ветку master с помощью - - $ git checkout master - -Исправьте найденное в первой части и отправьте на проверку. Если же её не примут, можно просто повторить этот шаг. Вы, вероятно, также захотите влить исправления части I в часть II: - - $ git checkout part2 - $ git merge master + $ git checkout master # Возвращаемся к первой части. + $ некая_команда # Некая команда, которую вам нужно выполнить + # когда текущий рабочий каталог формально готов. + $ git merge part2 # Вливаем вторую часть. + $ git branch -d part2 -Теперь они такие же, как раньше. После того, как первая часть утверждена и выложена, +Теперь вы снова в ветке master, а вторая часть — в вашем рабочем каталоге. - $ git checkout master - $ git merge part2 - $ git branch -d part2 +Этот приём легко расширить на любое количество частей. Столь же легко сменрить ветку задним числом: предположим, вы заметили с опозданием, что должны были создать ветку семь коммитов назад. Тогда введите: -и вторая часть, как и в прошлый раз, готова к проверке. + $ git branch -m master part2 + $ # Переименовываем ветку master в part2. + $ git checkout HEAD~7 -b master -Вы можете легко использовать этот трюк для любого количества частей. +Теперь ветка master содержит только первую часть, а ветка part2 — всё остальное. === Изменяем состав смеси === -- 2.11.4.GIT