<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>1 Работа в централизованном стиле — Документация Bazaar 2.6.0</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '2.6.0',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<script type="text/javascript" src="../_static/translations.js"></script>
<link rel="shortcut icon" href="../_static/bzr.ico"/>
<link rel="top" title="Документация Bazaar 2.6.0" href="../index.html" />
<link rel="prev" title="1 Использование Bazaar с Launchpad" href="using_bazaar_with_launchpad.html" />
</head>
<body>
<div class="related">
<h3>Навигация</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="using_bazaar_with_launchpad.html" title="1 Использование Bazaar с Launchpad"
accesskey="P">назад</a></li>
<li><a href="http://bazaar.canonical.com/">
<img src="../_static/bzr icon 16.png" /> Главная</a> | </li>
<a href="http://doc.bazaar.canonical.com/ru/">Документация</a> | </li>
<li><a href="../index.html">Содержание (2.6.0)</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="id1">
<h1><a class="toc-backref" href="#id20">1 Работа в централизованном стиле</a><a class="headerlink" href="#id1" title="Ссылка на этот заголовок">¶</a></h1>
<div class="section" id="id2">
<h2><a class="toc-backref" href="#id21">1.1 Обзор</a><a class="headerlink" href="#id2" title="Ссылка на этот заголовок">¶</a></h2>
<p>Этот документ описывает один из возможных подходов к использованию
<a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>. А именно, использование распределенной системы контроля версий
<a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>, в централизованном стиле. <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> разработана, что бы быть гибкой
и допускать различные подходы к работе, начиная от полностью
децентрализованного, до практически централизованного. Подход описанный
здесь позволяет новым пользователям проще вникнуть в более продвинутое
использование <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> и смешивать централизованные и децентрализованные
операции.</p>
<p>В общем случае, данный документ интересен для пользователей переходящих с
централизованных систем, таких как CVS, или Subversion. В таких системах
обычно есть единственный центральный сервер на котором хранится код
проекта и участники команды работают над этим кодом, синхронизируя свою
работу. Такой режим так же подходит для разработчика-одиночки,
работающего на нескольких различных машинах.</p>
<div class="contents topic" id="id3">
<p class="topic-title first">Содержание</p>
<ul class="auto-toc simple">
<li><a class="reference internal" href="#id1" id="id20">1 Работа в централизованном стиле</a><ul class="auto-toc">
<li><a class="reference internal" href="#id2" id="id21">1.1 Обзор</a></li>
<li><a class="reference internal" href="#id4" id="id22">1.2 Начальные установки</a><ul class="auto-toc">
<li><a class="reference internal" href="#e-mail" id="id23">1.2.1 Настройка e-mail пользователя</a></li>
<li><a class="reference internal" href="#id5" id="id24">1.2.2 Настройка локального репозитория</a></li>
<li><a class="reference internal" href="#id6" id="id25">1.2.3 Настройка удаленного репозитория</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id7" id="id26">1.3 Миграция рабочего проекта в Bazaar</a><ul class="auto-toc">
<li><a class="reference internal" href="#id9" id="id27">1.3.1 Разработчик 1: Создание первой ревизии</a></li>
<li><a class="reference internal" href="#n" id="id28">1.3.2 Разработчик N: Получение рабочей копии проекта</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id10" id="id29">1.4 Разработка на отдельных ветках</a><ul class="auto-toc">
<li><a class="reference internal" href="#id11" id="id30">1.4.1 Создание и работа на новой ветке</a></li>
<li><a class="reference internal" href="#id14" id="id31">1.4.2 Объединение изменений обратно</a></li>
<li><a class="reference internal" href="#id16" id="id32">1.4.3 Рекомендации по созданию веток</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id18" id="id33">1.5 Глоссарий</a><ul class="auto-toc">
<li><a class="reference internal" href="#id19" id="id34">1.5.1 Разделяемый репозиторий</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
</div>
<div class="section" id="id4">
<h2><a class="toc-backref" href="#id22">1.2 Начальные установки</a><a class="headerlink" href="#id4" title="Ссылка на этот заголовок">¶</a></h2>
<p>В самом начале, для более удобной работы с <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>, желательно осуществить
достаточно простые шаги по настройке.</p>
<div class="section" id="e-mail">
<h3><a class="toc-backref" href="#id23">1.2.1 Настройка e-mail пользователя</a><a class="headerlink" href="#e-mail" title="Ссылка на этот заголовок">¶</a></h3>
<p>Строка идентифицирующая пользователя сохраняется при каждой фиксации. Хотя
она не обязательно должна быть аккуратной или уникальной она будет
использоваться в сообщениях журнала и аннотациях, таким образом лучше что
бы она была похожа на что-то реальное.</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr whoami "Иван Пупкин <ivan@pupkin.ru>"
</pre></div>
</div>
</div>
<div class="section" id="id5">
<h3><a class="toc-backref" href="#id24">1.2.2 Настройка локального репозитория</a><a class="headerlink" href="#id5" title="Ссылка на этот заголовок">¶</a></h3>
<p>В общем случае ветки <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> копируют полную историю изменений вместе с
собой, что, кстати, позволяет работать в полностью децентрализованном
стиле. Как оптимизация для связанных веток возможно объединять их
хранилища таким образом, что отпадает необходимость в копировании полной
истории изменений при создании новой ветки.</p>
<p>Лучший способ сделать это - создать <a class="reference internal" href="#id19">Разделяемый репозиторий</a>. В общем
случае, ветки будут разделять хранилище если они находятся в подкаталоге
этого репозитория. Давайте создадим <a class="reference internal" href="#id19">Разделяемый репозиторий</a> в нашем
домашнем каталоге и таким образом все ветки которые мы будем создавать
под ним будут разделять хранилище истории.</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr init-repo --trees ~
</pre></div>
</div>
</div>
<div class="section" id="id6">
<h3><a class="toc-backref" href="#id25">1.2.3 Настройка удаленного репозитория</a><a class="headerlink" href="#id6" title="Ссылка на этот заголовок">¶</a></h3>
<p>Во многих случаях нужно создавать место где данные хранятся отдельно от
рабочего каталога. Такой подход необходим для централизованных систем
(CVS/SVN). Обычно эти каталоги находятся на различных машинах, хотя и не
всегда. На самом деле это достаточно хороший подход, особенно в рабочей
среде. Так как здесь существует центральная точка, где могут быть сохранены
все данные и даже если что-то случится с машиной разработчика
зафиксированная работа не будет потеряна.</p>
<p>Давайте создадим разделяемое место для нашего проекта на удаленной машине
и назовем его <tt class="docutils literal"><span class="pre">centralhost</span></tt>. Мы снова используем <a class="reference internal" href="#id19">Разделяемый
репозиторий</a> для оптимизации использования дисков.</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr init-repo --no-trees sftp://centralhost/srv/bzr/
</pre></div>
</div>
<p>Можно рассматривать этот шаг как похожий на установку CVSROOT, или
репозитория Subversion. Опция <tt class="docutils literal"><span class="pre">--no-trees</span></tt> указывает Bazaar не
создавать рабочий каталог в репозитории. Нам это подходит, т.к. никто
не будет напрямую что-то изменять на ветках в центральном репозитории.</p>
</div>
</div>
<div class="section" id="id7">
<h2><a class="toc-backref" href="#id26">1.3 Миграция рабочего проекта в Bazaar</a><a class="headerlink" href="#id7" title="Ссылка на этот заголовок">¶</a></h2>
<p>Теперь, когда у нас есть репозиторий давайте создадим проект под контролем
версий. В большинстве случаев у вас уже есть какой-то код с которым вы
работаете и для хранения которого вы хотели бы использовать <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>. Если
код изначально уже был под контролем версий существует много способов
конвертировать проект в <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> без потери истории изменений. Но эти
способы находятся вне тем рассматриваемых в данном документе. Смотрите
<a class="reference external" href="http://wiki.bazaar.canonical.com/TrackingUpstream">Отслеживание изменений на основной ветке</a> для некоторых способов (секция
“Конвертирование и сохранение истории”).</p>
<div class="section" id="id9">
<h3><a class="toc-backref" href="#id27">1.3.1 Разработчик 1: Создание первой ревизии</a><a class="headerlink" href="#id9" title="Ссылка на этот заголовок">¶</a></h3>
<p>Сначала нам нужно создать ветку в нашем удаленном репозитории, там где мы
хотели бы хранить наш проект. Допустим, что у нас уже есть проект “sigil”,
который мы хотели бы хранить под контролем версий.</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr init sftp://centralhost/srv/bzr/sigil
</pre></div>
</div>
<p>Это можно рассматривать как ветку “HEAD” в терминах CVS, или как “trunk” в
терминах Subversion. Назовем это веткой разработки <tt class="docutils literal"><span class="pre">dev</span></tt>.</p>
<p>Я предпочитаю работать в подкаталоге моего домашнего каталога, что бы
избегать коллизий со всеми другими файлами которые в ней находятся. Также
нам понадобится каталог для проекта где мы сможем хранить различные ветки
проекта над которыми работаем.</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~
% mkdir work
% cd work
% mkdir sigil
% cd sigil
% bzr checkout sftp://centralhost/srv/bzr/sigil dev
% cd dev
% cp -ar ~/sigil/* .
% bzr add
% bzr commit -m "Первый импорт Sigil"
</pre></div>
</div>
<p>Выше мы создали пустую ветку <tt class="docutils literal"><span class="pre">/sigil</span></tt> на <tt class="docutils literal"><span class="pre">centralhost</span></tt> и затем
загрузили эту пустую ветку на нашу рабочую машину что бы добавить файлы из
нашего старого проекта. Есть много способов настроить свой рабочий
каталог, но шаги выше упрощают дальнейшую работу с ветками для работы
над ошибками, или новыми функциями. И одна из наиболее сильных сторон
<a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> - это именно отличная работа с ветками.</p>
<p>На этом этапе, т.к. мы создали рабочую копию (checkout) удаленной ветки,
все фиксации которые будут сделаны в <tt class="docutils literal"><span class="pre">~/work/sigil/dev/</span></tt> будут
автоматически сохранены и локально и на <tt class="docutils literal"><span class="pre">centralhost</span></tt>.</p>
</div>
<div class="section" id="n">
<h3><a class="toc-backref" href="#id28">1.3.2 Разработчик N: Получение рабочей копии проекта</a><a class="headerlink" href="#n" title="Ссылка на этот заголовок">¶</a></h3>
<p>Так как первый разработчик проделал всю работу по созданию проекта все
остальные разработчики могут просто получить рабочую копию ветки. Хотя
<strong>они все еще должны следовать</strong> разделам <a class="reference internal" href="#e-mail">Настройка e-mail пользователя</a> и
<a class="reference internal" href="#id5">Настройка локального репозитория</a>.</p>
<p>Получим рабочую копию текущего дерева разработки:</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~/work/sigil
% bzr checkout sftp://centralhost/srv/bzr/sigil dev
</pre></div>
</div>
<p>Теперь, когда два человека имею рабочую копию
<tt class="docutils literal"><span class="pre">sftp://centralhost/srv/bzr/sigil</span></tt> будут ситуации когда одна из копий
будет не синхронизирована с текущей версией. Во время фиксации <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>
проинформирует пользователя об этом и не допустит фиксации. Для получения
последних изменений нужно использовать <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">update</span></tt>. Эта команда может
потребовать разрешения конфликтов если были изменены одни и те же файлы.</p>
</div>
</div>
<div class="section" id="id10">
<h2><a class="toc-backref" href="#id29">1.4 Разработка на отдельных ветках</a><a class="headerlink" href="#id10" title="Ссылка на этот заголовок">¶</a></h2>
<p>До этого момента все работали и фиксировали изменения на одну и ту же
ветку. Это значит, что каждый должен периодически обновлять свою ветку и
иметь дело с изменениями других разработчиков. Так же если один
разработчик фиксирует что-то, что приводит к ошибкам, то после
синхронизации эта проблема коснется каждого.</p>
<p>Обычно лучше вести разработку на различных ветках и затем, как только
изменения достаточно стабильны, интегрировать их обратно на основную
ветку. Это одно из наибольших изменений по сравнению с работой в CVS/SVN.
Обе эти системы позволяют работать с отдельными ветками, но их алгоритмы
объединения достаточно слабы и поэтому с ними сложно держать все
синхронизировано. <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> отслеживает что уже было объединено и может даже
прикладывать изменения к файлам которые были переименованы.</p>
<div class="section" id="id11">
<h3><a class="toc-backref" href="#id30">1.4.1 Создание и работа на новой ветке</a><a class="headerlink" href="#id11" title="Ссылка на этот заголовок">¶</a></h3>
<p>Мы бы хотели, что бы наши изменения были доступны другим даже если они
пока еще не закончены. Таким образом мы создадим новую публичную ветку на
<tt class="docutils literal"><span class="pre">centralhost</span></tt> и будем отслеживать ее локально.</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~/work/sigil
% bzr branch sftp://centralhost/srv/bzr/sigil \
sftp://centralhost/srv/bzr/sigil/doodle-fixes
% bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
% cd doodle-fixes
</pre></div>
</div>
<p>Теперь у нас есть место где мы можем исправлять все ошибки для <tt class="docutils literal"><span class="pre">doodle</span></tt>.
И мы не будем прерывать никого кто работает над другими частями кода. Так
как у нас есть рабочая копия (checkout) все фиксации которые мы делаем на
<tt class="docutils literal"><span class="pre">~/work/sigil/doodle-fixes/</span></tt> так же появятся и на <tt class="docutils literal"><span class="pre">centralhost</span></tt>.
<a class="footnote-reference" href="#nestedbranches" id="id12">[1]</a> Также возможно, что бы два разработчика совместно
работали над одной из этих веток, так же как они совместно работают над
веткой <tt class="docutils literal"><span class="pre">dev</span></tt>. <a class="footnote-reference" href="#cbranch" id="id13">[2]</a></p>
<table class="docutils footnote" frame="void" id="nestedbranches" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id12">[1]</a></td><td>Может показаться странным иметь ветку в подкаталоге
другой ветки. Но это нормально, можно думать об этом как о
иерархическом пространстве имен где вложенная ветка является
производной от внешней ветки.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="cbranch" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label">[2]</td><td><em>(<a class="fn-backref" href="#id13">1</a>, <a class="fn-backref" href="#id17">2</a>)</em> <p>Когда используется множество независимых веток каждый раз
набирать полный URL занимает много времени. Мы рассматриваем различные
методы, что бы обойти это, например псевдонимы для веток и т.п. Но пока
плагин <a class="reference external" href="http://wiki.bazaar.canonical.com/BzrTools">bzrtools</a> предоставляет команду <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">cbranch</span></tt>. Эта команда на
основе базовой ветки создает новую публичную ветку и рабочую копию этой
ветки всего одной командой. Конфигурирование <tt class="docutils literal"><span class="pre">cbranch</span></tt> не входит в
рамки описания этого документа, но финальная команда выглядит следующим
образом:</p>
<div class="last highlight-python"><div class="highlight"><pre>% bzr cbranch dev my-feature-branch
</pre></div>
</div>
</td></tr>
</tbody>
</table>
</div>
<div class="section" id="id14">
<h3><a class="toc-backref" href="#id31">1.4.2 Объединение изменений обратно</a><a class="headerlink" href="#id14" title="Ссылка на этот заголовок">¶</a></h3>
<p>Когда решено что некоторые изменения из <tt class="docutils literal"><span class="pre">doodle-fixes</span></tt> готовы для
объединения на основную ветку нужно просто сделать следующее:</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~/work/sigil/dev
% bzr merge ../doodle-fixes
</pre></div>
</div>
<p>Теперь изменения доступны на ветке <tt class="docutils literal"><span class="pre">dev</span></tt>, но они пока еще не были
зафиксированы. В этот момент нужно просмотреть финальные изменения и
проверить, что код компилируется и проходят все тесты. Команды <tt class="docutils literal"><span class="pre">bzr</span>
<span class="pre">status</span></tt> и <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt> хорошие инструменты для этого. Так же нужно
разрешить возможные конфликты. <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> не допустит фиксации пока не будут
разрешены все конфликты. В этом случае вы случайно не зафиксируете маркеры
конфликта. Команда <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">status</span></tt> покажет конфликты и изменения, или можно
использовать <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">conflicts</span></tt> что бы увидеть только конфликты.
Используйте <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">resolve</span> <span class="pre">file/name</span></tt>, или <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">resolve</span> <span class="pre">--all</span></tt> как
только конфликты были разрешены. <a class="footnote-reference" href="#resolve" id="id15">[3]</a> Если существуют конфликты
которые особенно сложно разрешить можно использовать команду <tt class="docutils literal"><span class="pre">bzr</span>
<span class="pre">remerge</span></tt>. Эта команда позволит использовать другие алгоритмы объединения
и также позволит увидеть строки оригинального кода (<tt class="docutils literal"><span class="pre">--show-base</span></tt>).</p>
<table class="docutils footnote" frame="void" id="resolve" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id15">[3]</a></td><td>Некоторые системы позволяют разрешать конфликты как часть
процесса объединения. Мы обнаружили, что обычно проще разрешать
конфликты когда можно просматривать полное дерево, а не только
отдельные файлы. Это дает намного больше контекста и также позволяет
запускать тесты когда проблема будет решена.</td></tr>
</tbody>
</table>
</div>
<div class="section" id="id16">
<h3><a class="toc-backref" href="#id32">1.4.3 Рекомендации по созданию веток</a><a class="headerlink" href="#id16" title="Ссылка на этот заголовок">¶</a></h3>
<p>Один из часто используемых способов работы с набором веток - это дать
каждому разработчику свою собственную ветку и собственное место для работы
на центральном сервере. Это можно сделать так:</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr branch sftp://centralhost/srv/bzr/sigil \
sftp://centralhost/srv/bzr/sigil/user-a
% bzr branch sftp://centralhost/srv/bzr/sigil \
sftp://centralhost/srv/bzr/sigil/user-b
</pre></div>
</div>
<p>Это дает каждому разработчику собственную ветку для работы. И они смогут
легко создать новые ветки с помощью <a class="footnote-reference" href="#cbranch" id="id17">[2]</a></p>
<div class="highlight-python"><div class="highlight"><pre>% bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
sftp://centralhost/srv/bzr/sigil/user-a/feature
% cd ~/work/sigil
% bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
</pre></div>
</div>
</div>
</div>
<div class="section" id="id18">
<h2><a class="toc-backref" href="#id33">1.5 Глоссарий</a><a class="headerlink" href="#id18" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="id19">
<h3><a class="toc-backref" href="#id34">1.5.1 Разделяемый репозиторий</a><a class="headerlink" href="#id19" title="Ссылка на этот заголовок">¶</a></h3>
<p><a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> поддерживает концепцию “Разделяемый репозиторий”. Эта концепция
похожа на традиционные концепции репозиториев в других системах контроля
версий, таких как CVS, или Subversion. Например, в Subversion у вас есть
удаленный репозиторий, где хранится вся история и локально история не
хранится, а хранится только рабочая копия файлов. Конечно “Разделяемый” в
данном контексте значит, что он разделен между ветками. Он <em>может</em> быть
разделен между людьми, но отдельные ветки также могут быть разделены между
людьми.</p>
<p>В <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> термин “Разделяемый репозиторий” - это место где несколько веток
могут <em>разделять</em> их историю ревизий. Что бы поддерживать
децентрализованную схему работы каждая ветка может хранить свою
собственную историю ревизий. Но часто это не эффективно, т.к. зависимые
ветки разделяют историю и они могут так же разделять и хранилище истории.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../index.html">Оглавление</a></h3>
<ul>
<li><a class="reference internal" href="#">1 Работа в централизованном стиле</a><ul>
<li><a class="reference internal" href="#id2">1.1 Обзор</a></li>
<li><a class="reference internal" href="#id4">1.2 Начальные установки</a><ul>
<li><a class="reference internal" href="#e-mail">1.2.1 Настройка e-mail пользователя</a></li>
<li><a class="reference internal" href="#id5">1.2.2 Настройка локального репозитория</a></li>
<li><a class="reference internal" href="#id6">1.2.3 Настройка удаленного репозитория</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id7">1.3 Миграция рабочего проекта в Bazaar</a><ul>
<li><a class="reference internal" href="#id9">1.3.1 Разработчик 1: Создание первой ревизии</a></li>
<li><a class="reference internal" href="#n">1.3.2 Разработчик N: Получение рабочей копии проекта</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id10">1.4 Разработка на отдельных ветках</a><ul>
<li><a class="reference internal" href="#id11">1.4.1 Создание и работа на новой ветке</a></li>
<li><a class="reference internal" href="#id14">1.4.2 Объединение изменений обратно</a></li>
<li><a class="reference internal" href="#id16">1.4.3 Рекомендации по созданию веток</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id18">1.5 Глоссарий</a><ul>
<li><a class="reference internal" href="#id19">1.5.1 Разделяемый репозиторий</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>Предыдущий раздел</h4>
<p class="topless"><a href="using_bazaar_with_launchpad.html"
title="предыдущая глава">1 Использование Bazaar с Launchpad</a></p>
<h3>Эта страница</h3>
<ul class="this-page-menu">
<li><a href="../_sources/tutorials/centralized_workflow.txt"
rel="nofollow">Исходный текст</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Быстрый поиск</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Искать" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Введите слова для поиска или имя модуля, класса или функции.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Навигация</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="using_bazaar_with_launchpad.html" title="1 Использование Bazaar с Launchpad"
>назад</a></li>
<li><a href="http://bazaar.canonical.com/">
<img src="../_static/bzr icon 16.png" /> Главная</a> | </li>
<a href="http://doc.bazaar.canonical.com/ru/">Документация</a> | </li>
<li><a href="../index.html">Содержание (2.6.0)</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2009-2011 Canonical Ltd.
Создано с помощью <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3.
</div>
</body>
</html>
distrib
>
Mageia
>
5
>
x86_64
>
media
>
core-release
>
by-pkgid
>
4c66e4a74400d106ea54ec458e4c006c
>
files
>
3445
