diff --git a/git-tutorial.lyx b/git-tutorial.lyx
new file mode 100644
index 0000000..cde158d
--- /dev/null
+++ b/git-tutorial.lyx
@@ -0,0 +1,2206 @@
+#LyX 2.0 created this file. For more info see http://www.lyx.org/
+\lyxformat 413
+\begin_document
+\begin_header
+\textclass article
+\begin_preamble
+\let\stdpart\part
+\renewcommand\part{\newpage\stdpart}
+
+\usepackage{indentfirst}
+\end_preamble
+\use_default_options true
+\begin_modules
+customHeadersFooters
+enumitem
+fixltx2e
+fix-cm
+braille
+initials
+figs-within-sections
+tabs-within-sections
+eqs-within-sections
+endnotes
+foottoend
+\end_modules
+\maintain_unincluded_children false
+\language russian
+\language_package default
+\inputencoding utf8
+\fontencoding global
+\font_roman default
+\font_sans default
+\font_typewriter default
+\font_default_family default
+\use_non_tex_fonts false
+\font_sc false
+\font_osf false
+\font_sf_scale 100
+\font_tt_scale 100
+
+\graphics default
+\default_output_format default
+\output_sync 0
+\bibtex_command default
+\index_command default
+\paperfontsize default
+\spacing single
+\use_hyperref true
+\pdf_title "Документация по системе генерации протоколов “TeXReport” в LaTeX-формате"
+\pdf_author "Kolan Sh, InSys Ltd, Moscow"
+\pdf_subject "TeXReport"
+\pdf_keywords "tex,lyx,latex,texreport,texparser"
+\pdf_bookmarks true
+\pdf_bookmarksnumbered false
+\pdf_bookmarksopen false
+\pdf_bookmarksopenlevel 1
+\pdf_breaklinks false
+\pdf_pdfborder false
+\pdf_colorlinks false
+\pdf_backref false
+\pdf_pdfusetitle true
+\papersize default
+\use_geometry true
+\use_amsmath 1
+\use_esint 1
+\use_mhchem 1
+\use_mathdots 1
+\cite_engine basic
+\use_bibtopic false
+\use_indices false
+\paperorientation portrait
+\suppress_date false
+\use_refstyle 1
+\index Index
+\shortcut idx
+\color #008000
+\end_index
+\leftmargin 2cm
+\topmargin 1.5cm
+\rightmargin 1cm
+\bottommargin 2cm
+\secnumdepth 3
+\tocdepth 3
+\paragraph_separation indent
+\paragraph_indentation default
+\quotes_language english
+\papercolumns 1
+\papersides 1
+\paperpagestyle default
+\tracking_changes false
+\output_changes false
+\html_math_output 0
+\html_css_as_file 0
+\html_be_strict false
+\end_header
+
+\begin_body
+
+\begin_layout Title
+Краткое введение в Git
+\end_layout
+
+\begin_layout Author
+Working horsy
+\begin_inset Newline newline
+\end_inset
+
+ InSys Ltd, Moscow
+\end_layout
+
+\begin_layout Date
+February 27, 2013
+\end_layout
+
+\begin_layout Date
+Версия 0.0.1
+\end_layout
+
+\begin_layout Standard
+\begin_inset ERT
+status open
+
+\begin_layout Plain Layout
+
+
+\backslash
+thispagestyle{empty}
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+
+\lang english
+\begin_inset Newpage newpage
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+
+\lang english
+\begin_inset CommandInset toc
+LatexCommand tableofcontents
+
+\end_inset
+
+
+\lang russian
+
+\begin_inset Newpage newpage
+\end_inset
+
+
+\end_layout
+
+\begin_layout Section
+Начало работы
+\end_layout
+
+\begin_layout Subsection
+Регистрация в Gitorious
+\end_layout
+
+\begin_layout Subsubsection
+Создание нового пользователя
+\end_layout
+
+\begin_layout Standard
+Для регистрации нужно перейти по ссылке 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+https://git.insysltd.ru/users/new
+\end_layout
+
+\end_inset
+
+.
+ Будет предложено ввести логин, Email и пароль.
+ Эти данные требуются исключительно для доступа к репозиториям и проектам
+ Gitorious посредством Web-интерфейса.
+ Вместо этих данных возможно использование OpenID (
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://ru.wikipedia.org/wiki/OpenID
+\end_layout
+
+\end_inset
+
+).
+\end_layout
+
+\begin_layout Subsubsection
+Подтверждение регистрации
+\end_layout
+
+\begin_layout Standard
+Для подтверждения вновь созданной учётной записи необходимо обратиться к
+ любому из администраторов ресурса.
+ Данная необходимость обусловлена защитой от несанкционированных регистраций
+ со стороны калифорнийских школьников.
+\end_layout
+
+\begin_layout Subsubsection
+Загрузка OpenSSH-ключа
+\end_layout
+
+\begin_layout Standard
+Данный ключ требуется для защищённой передачи данных между Git-клиентом
+ и Git-сервером.
+\end_layout
+
+\begin_layout Standard
+Сгенерировать пару ключей (приватный/общедоступный) можно посредством команды
+\end_layout
+
+\begin_layout LyX-Code
+ssh-keygen -t rsa
+\end_layout
+
+\begin_layout Standard
+из пакета OpenSSH 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://www.openssh.org/
+\end_layout
+
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Standard
+Установочный файл для Windows может быть найден по ссылке 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://sourceforge.net/projects/sshwindows/files/OpenSSH%20for%20Windows%20-%20Re
+lease/
+\end_layout
+
+\end_inset
+
+.
+ Полученный приватный ключ id_rsa следует хранить в безопасном от чужих
+ глаз месте (в случае получения доступа к нему 3-их лиц следует сгенерировать
+ новый, а старый - удалить с Git-сервера).
+\end_layout
+
+\begin_layout Standard
+Загрузка публичного ключа id_rsa.pub выполняется в Web-интерфейсе профиля
+ пользователя Gitorious\SpecialChar \menuseparator
+Dashboard\SpecialChar \menuseparator
+Manage SSH keys\SpecialChar \menuseparator
+Add SSH Key.
+\end_layout
+
+\begin_layout Subsection
+Создание нового репозитория
+\end_layout
+
+\begin_layout Standard
+Если репозиторий добавляется в уже существующий проект, то на вкладке проекта
+ в Web-интерфейсе Gitorious достаточно нажать кнопку Add Repository, ввести
+ имя и описание.
+\end_layout
+
+\begin_layout Standard
+Если требуется создать новый проект, то в Web-интерфейсе Gitorious нужно
+ выбрать Gitorious\SpecialChar \menuseparator
+Projects\SpecialChar \menuseparator
+Create a new project, ввести обязательные поля
+ Title(имя проекта), Slug(идентификатор, генерируется автоматически), Descriptio
+n(описание).
+ При необходимости могут быть заданы Labels(метки для быстрого поиска),
+ Owner(владелец проекта), License(лицензия), Home URL(домашняя страница
+ проекта), Mailinglist URL(список рассылки), Bugtracker URL(баг-трекер).
+ После нажатия кнопки Create project будет создан новый проект с указанными
+ параметрами и предложено создать в нём первый репозиторий.
+\end_layout
+
+\begin_layout Subsubsection
+Первый коммит
+\end_layout
+
+\begin_layout Standard
+Хорошей практикой считается при создании репозитория включение первым делом
+ в него файла README с пусть даже минимальным описанием того, для чего он
+ создан, какую цель преследует.
+\end_layout
+
+\begin_layout LyX-Code
+echo 
+\begin_inset Quotes eld
+\end_inset
+
+This is my project for tests.
+\begin_inset Quotes erd
+\end_inset
+
+ > README
+\end_layout
+
+\begin_layout LyX-Code
+git add README
+\end_layout
+
+\begin_layout LyX-Code
+git commit -m 
+\begin_inset Quotes eld
+\end_inset
+
+Initial commit.
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Itemize
+Здесь мы создали файл с именем README;
+\end_layout
+
+\begin_layout Itemize
+Добавили этот файл в индекс Git для включения его в ближайший коммит;
+\end_layout
+
+\begin_layout Itemize
+Сделали коммит 
+\begin_inset Quotes eld
+\end_inset
+
+Initial commit.
+\begin_inset Quotes erd
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Standard
+Индексом в Git называется промежуточное хранилище изменений, попадающих
+ в ближайший коммит.
+ Таким образом, Git даёт возможность избирательно включать те или иные изменения
+ вплоть до отдельных частей файла.
+ Пример:
+\end_layout
+
+\begin_layout LyX-Code
+git add -p git-tutorial.lyx                                             
+                                                                       
+                                                                       
+                                  (git)-[git-tutorial]  diff --git a/git-tutoria
+l.lyx b/git-tutorial.lyx
+\end_layout
+
+\begin_layout LyX-Code
+index 8c6fa34..3aaafde 100644
+\end_layout
+
+\begin_layout LyX-Code
+--- a/git-tutorial.lyx
+\end_layout
+
+\begin_layout LyX-Code
++++ b/git-tutorial.lyx
+\end_layout
+
+\begin_layout LyX-Code
+@@ -365,7 +365,10 @@ Initial commit.
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+end_layout    
+\backslash
+begin_layout Standard -В качестве
+\end_layout
+
+\begin_layout LyX-Code
++Индексом в Git называется промежуточное хранилище изменений, попадающих
+\end_layout
+
+\begin_layout LyX-Code
++ в ближайший коммит.
+\end_layout
+
+\begin_layout LyX-Code
++ Таким образом, Git даёт возможность избирательно включать те или иные
+ изменения
+\end_layout
+
+\begin_layout LyX-Code
++ вплоть до отдельных частей файла.
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+end_layout
+\end_layout
+
+\begin_layout LyX-Code
+
+\end_layout
+
+\begin_layout LyX-Code
+
+\backslash
+begin_layout Subsubsection
+\end_layout
+
+\begin_layout LyX-Code
+Stage this hunk [y,n,q,a,d,/,e,?]? y
+\end_layout
+
+\begin_layout Standard
+Параметр -m у команды commit указывает на то, что следующим аргументом команды
+ следует описание коммита, что удобно, когда нужно коммит сделать быстро.
+ Без указания этого параметра откроется окно редактора, куда требуется внести
+ описание изменений.
+\end_layout
+
+\begin_layout Standard
+Также, у команды commit помимо параметра -m можно указывать параметр -a,
+ чтобы в коммит добавились все изменения, в том числе и не включенные в
+ индекс.
+ Таким образом, последовательность команд
+\end_layout
+
+\begin_layout LyX-Code
+vim main.c # editing staged C-file...
+\end_layout
+
+\begin_layout LyX-Code
+vim main.h # editing staged H-file...
+\end_layout
+
+\begin_layout LyX-Code
+git commit -am 
+\begin_inset Quotes eld
+\end_inset
+
+Both source and header files are changed.
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+эквивалентна
+\end_layout
+
+\begin_layout LyX-Code
+vim main.c # editing staged C-file...
+\end_layout
+
+\begin_layout LyX-Code
+vim main.h # editing staged H-file...
+\end_layout
+
+\begin_layout LyX-Code
+git add main.c main.h
+\end_layout
+
+\begin_layout LyX-Code
+git commit -m 
+\begin_inset Quotes eld
+\end_inset
+
+Both source and header files are changed.
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Subsection
+Синхронизация с Git-сервером
+\end_layout
+
+\begin_layout Subsubsection
+Добавление удалённого репозитория
+\end_layout
+
+\begin_layout Standard
+Для синхронизации с Git-сервером необходимо его добавить в список remote:
+\end_layout
+
+\begin_layout LyX-Code
+git remote add origin git@git.insysltd.ru:test_project/test_repo.git
+\end_layout
+
+\begin_layout Standard
+origin является удалённым репозиторием по умолчанию при выполнении команд
+ синхронизации и может быть опущен.
+\end_layout
+
+\begin_layout Standard
+Нормальной практикой является добавление нескольких удалённых веток, например:
+\end_layout
+
+\begin_layout LyX-Code
+git remote add origin git@git.insysltd.ru:test_project/test_repo.git
+\end_layout
+
+\begin_layout LyX-Code
+git remote add github git@github.com:test_repo.git
+\end_layout
+
+\begin_layout LyX-Code
+git remote add usb /media/usb_stick/projects/test_repo.git
+\end_layout
+
+\begin_layout Subsubsection
+Принятие изменений, сделанных другими пользователями
+\end_layout
+
+\begin_layout Standard
+В отличие от других систем управления исходным кодом Git работает со слияниями
+ гибче.
+ Поддерживаются так называемые fast-forward слияния (рис.
+ 
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "fig:fast-forward-слияния"
+
+\end_inset
+
+).
+\end_layout
+
+\begin_layout Standard
+\begin_inset Float figure
+placement H
+wide false
+sideways false
+status collapsed
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/vRdkr.png
+	scale 50
+	rotateOrigin center
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+\begin_inset CommandInset label
+LatexCommand label
+name "fig:fast-forward-слияния"
+
+\end_inset
+
+fast-forward слияния
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+При выполнении команды git pull скачиваются удалённые изменения (git fetch)
+ и выполняется слияние (git merge).
+ При указании опции --rebase коммиты из удалённого репозитория займут своё
+ место перед локальными коммитами - теми, которые ещё не были отправлены
+ на Git-сервер.
+\end_layout
+
+\begin_layout LyX-Code
+git pull --rebase
+\end_layout
+
+\begin_layout Standard
+Это даёт возможность пользователям работать, не мешая друг-другу, выполняя
+ при этом коммиты тогда, когда хочется пользователю, а не тогда, когда доступен
+ главный репозиторий.
+\end_layout
+
+\begin_layout Standard
+Иногда более целесообразно указывать, из какой удалённо ветки требуется
+ произвести слияние коммитов:
+\end_layout
+
+\begin_layout LyX-Code
+git pull --rebase origin develop
+\end_layout
+
+\begin_layout Subsubsection
+Слияние веток
+\end_layout
+
+\begin_layout Standard
+Как правило, слияние веток необходимо по завершении той или иной фичи (от
+ англ.
+ feature) или исправления бага (от англ.
+ bug).
+ Приведём возможный сценарий для реализации некоторой возможности featureA.
+\end_layout
+
+\begin_layout LyX-Code
+git checkout -b featureA develop # ответвление featureA от develop
+\end_layout
+
+\begin_layout LyX-Code
+...
+ edit ...
+ commit ...
+\end_layout
+
+\begin_layout LyX-Code
+...
+ edit ...
+ commit ...
+\end_layout
+
+\begin_layout LyX-Code
+...
+ edit ...
+ commit ...
+\end_layout
+
+\begin_layout LyX-Code
+git reset --soft develop # вместо develop может быть хеш коммита
+\end_layout
+
+\begin_layout LyX-Code
+git commit -m 
+\begin_inset Quotes eld
+\end_inset
+
+Feature A implemented.
+\begin_inset Quotes erd
+\end_inset
+
+ # получение из нескольких коммитов одного
+\end_layout
+
+\begin_layout LyX-Code
+git checkout develop # возврат в ветку разработки develop
+\end_layout
+
+\begin_layout LyX-Code
+git merge --no-ff featureA # слияние без --no-ff, если предпочитаете линейную
+ историю
+\end_layout
+
+\begin_layout LyX-Code
+git branch -d featureA # удаление 
+\begin_inset Quotes eld
+\end_inset
+
+слитой
+\begin_inset Quotes erd
+\end_inset
+
+ ветки featureA
+\end_layout
+
+\begin_layout Standard
+Также возможно слияние изменений без создания нового коммита (следует отметить,
+ что хеш последнего коммита всё-равно изменится, а с ним изменится и история)
+ посредством команды:
+\end_layout
+
+\begin_layout LyX-Code
+git merge --squash
+\end_layout
+
+\begin_layout Subsubsection
+Отправка изменений на сервер
+\end_layout
+
+\begin_layout Standard
+Для отправки локальных изменений из текущей ветки в репозиторий по умолчанию
+ (origin) необходимо выполнить команду
+\end_layout
+
+\begin_layout LyX-Code
+git push
+\end_layout
+
+\begin_layout Standard
+Также возможны более сложные операции, к примеру:
+\end_layout
+
+\begin_layout LyX-Code
+git push github # отправит изменения всех веток, которые есть в локальном
+\end_layout
+
+\begin_layout LyX-Code
+                # и удалённом (в данном случае GitHub) репозиториях
+\end_layout
+
+\begin_layout LyX-Code
+git push origin featureA # отправит в origin изменения в ветке featureA
+\end_layout
+
+\begin_layout LyX-Code
+git push origin localA:featureA # отправит в origin изменения локальной
+\end_layout
+
+\begin_layout LyX-Code
+                                # ветки localA в удалённую featureA
+\end_layout
+
+\begin_layout LyX-Code
+git push origin master develop featureB # отправит 3 указанные ветки
+\end_layout
+
+\begin_layout LyX-Code
+git push origin :featureC # удалит в удалённом репозитории ветку featureC
+\end_layout
+
+\begin_layout LyX-Code
+git push origin :v1.0.3 # удалит в origin тег v1.0.3
+\end_layout
+
+\begin_layout LyX-Code
+
+\end_layout
+
+\begin_layout Subsubsection
+Права доступа в Gitorious
+\end_layout
+
+\begin_layout Standard
+В Web-интерфейсе Gitorious на вкладке управления проектом есть кнопка Manage
+ Access\SpecialChar \menuseparator
+Make private, позволяющая сделать репозиторий 
+\begin_inset Quotes eld
+\end_inset
+
+закрытым от посторонних глаз
+\begin_inset Quotes erd
+\end_inset
+
+ и разрешить выборочный доступ на чтение для отдельных лиц или групп.
+ В этом случае все репозитории, входящие в данный проект также становятся
+ недоступными всем лицам, кроме одобренных одним из владельцев проекта/репозитор
+ия.
+\end_layout
+
+\begin_layout Standard
+Для репозитория, как и для проекта, также возможна установка разрешений.
+ Для этого есть кнопка Manage Read Access\SpecialChar \menuseparator
+Make private.
+\end_layout
+
+\begin_layout Standard
+Для возможности внесения изменений в репозиторий несколькими разработчиками
+ требуется добавить этих разработчиков/группы в список разрешения Manage
+ collaborators\SpecialChar \menuseparator
+Add collaborators и установить для добавленных пользователей/групп
+ их разрешения: Review, Commit, Administer.
+\end_layout
+
+\begin_layout Subsection
+Работа с чужим репозиторием, pull-requests
+\end_layout
+
+\begin_layout Standard
+Политика распределённого хранилища подразумевает возможность независимой
+ работы с клонами без вмешательства в репозитории других пользователей.
+\end_layout
+
+\begin_layout Standard
+Как правило, у отдельно взятого репозитория имеется один или несколько коммитеро
+в, которым разрешён полный доступ и на ком лежит ответственность за поддержание
+ данного репозитория в рабочем состоянии.
+ Все остальные, кто имеет доступ на чтение данного репозитория реализуют
+ фичи (feature) в своих клонах.
+ По завершении работы над фичей отправляется pull-request разработчику основного
+ репозитория, который осуществляет слияние, когда у него есть на то свободное
+ время.
+ Таким образом разработчики делают каждый свою работу, не мешая друг другу.
+\end_layout
+
+\begin_layout Standard
+Приведём пример такой работы.
+\end_layout
+
+\begin_layout Subsubsection
+Получение информации о репозитории
+\end_layout
+
+\begin_layout Standard
+Общая информация о репозитории может быть получена уже из Web-интерфейса
+ Gitorious, включая ветки, список коммитов, граф коммитов, pull-реквесты
+ и т.п.
+\end_layout
+
+\begin_layout Subsubsection
+Клонирование
+\end_layout
+
+\begin_layout Standard
+Более подробная информация, включая поиск по коммитам возможна после клонировани
+я репозитория.
+ Если Вы не хотите отвлекать от работы владельца репозитория, но при этом
+ хотите коммитить, будет удобно сделать удалённый клон в Gitorious (кнопка
+ Clone repository у любого проекта в Web-интерфейсе).
+ Будет предложено ввести имя клона, которое будет уже заполнено по умолчанию
+ (в начало), так что его можно не менять.
+\end_layout
+
+\begin_layout Standard
+Далее выполняется стандартная процедура клонирования удалённого клона на
+ локальный диск:
+\end_layout
+
+\begin_layout LyX-Code
+git clone git@git.insysltd.ru:~user1/test_project/user1-test_repo.git
+\end_layout
+
+\begin_layout Subsubsection
+pull-request
+\end_layout
+
+\begin_layout Standard
+По завершении работы (реализации фичи или устранения бага) нужно залить
+ в свой удалённый клон, при необходимости, обновив его (git pull --rebase)
+ из исходного репозитория.
+\end_layout
+
+\begin_layout Standard
+Далее в Web-интерфейсе клона нажать кнопку Request merge, добавить описание
+ pull-запроса, указать исходный репозиторий и ветки.
+ Ваш запрос на слияние появится в списке входящих сообщений пользователя,
+ владеющего оригиналом репозитория.
+\end_layout
+
+\begin_layout Section
+Удобство в работе
+\end_layout
+
+\begin_layout Subsection
+Индекс, откат, временное хранилище
+\end_layout
+
+\begin_layout Standard
+В Git имеются команды, делающие работу более удобной.
+ Так, в частности, можно спрятать все незакомиченные изменения рабочей директори
+и и достать их в любой момент обратно:
+\end_layout
+
+\begin_layout LyX-Code
+git stash     # спрятать изменения
+\end_layout
+
+\begin_layout LyX-Code
+git stash pop # применить их к рабочей директории
+\end_layout
+
+\begin_layout Standard
+Можно получить любую версию файла посредством команды checkout:
+\end_layout
+
+\begin_layout LyX-Code
+git checkout README # получить README-файл, отменив изменения после последнего
+ коммита
+\end_layout
+
+\begin_layout LyX-Code
+git checkout main.c 3f89a7f # получить main.c из ревизии 3f89a7f
+\end_layout
+
+\begin_layout Standard
+Можно отменить изменения, попавшие в индекс для следующего коммита:
+\end_layout
+
+\begin_layout LyX-Code
+git reset         # очистить индекс
+\end_layout
+
+\begin_layout LyX-Code
+git reset main.h  # убрать из индекса main.h
+\end_layout
+
+\begin_layout Subsection
+Теги и версии
+\end_layout
+
+\begin_layout Standard
+Как правило, теги создаются для определённых версий проекта, но могут и
+ не следовать этому правилу.
+\end_layout
+
+\begin_layout Standard
+В случае создания новой версии проекта, хорошим стилем является обновление
+ записи о версии внутри проекта, например version.h с последющим коммитом.
+\end_layout
+
+\begin_layout Standard
+Приведём типичный пример:
+\end_layout
+
+\begin_layout LyX-Code
+git checkout -b release-1.0.0 develop
+\end_layout
+
+\begin_layout LyX-Code
+vim version.h # update version number
+\end_layout
+
+\begin_layout LyX-Code
+git commit -am 
+\begin_inset Quotes eld
+\end_inset
+
+Bumped version number to 1.0.0
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout LyX-Code
+git checkout master
+\end_layout
+
+\begin_layout LyX-Code
+git merge --no-ff release-1.0.0
+\end_layout
+
+\begin_layout LyX-Code
+git tag v1.0.0
+\end_layout
+
+\begin_layout LyX-Code
+git checkout develop
+\end_layout
+
+\begin_layout LyX-Code
+git merge --no-ff release-1.0.0
+\end_layout
+
+\begin_layout LyX-Code
+git branch -d release-1.0.0
+\end_layout
+
+\begin_layout LyX-Code
+git push origin master develop --tags
+\end_layout
+
+\begin_layout Subsection
+Редактирование истории
+\end_layout
+
+\begin_layout Standard
+Изменение сообщения последнего коммита выполняется командой
+\end_layout
+
+\begin_layout LyX-Code
+git commit --amend
+\end_layout
+
+\begin_layout Standard
+- откроется текстовый редактор, в котором следует отредактировать сообщение
+ последнего коммита.
+\end_layout
+
+\begin_layout Standard
+Для отмены последних нескольких коммитов в текущей ветви требуется выполнить
+ команду
+\end_layout
+
+\begin_layout LyX-Code
+git reset --hard HEAD~3 # отменит последние 3 коммита
+\end_layout
+
+\begin_layout LyX-Code
+git push -f             # и удалит их с центрального репозитория
+\end_layout
+
+\begin_layout Standard
+Для редактирования коммита, совершённого на более ранних этапах следует
+ прибегнуть к команде rebase:
+\end_layout
+
+\begin_layout LyX-Code
+git rebase bbc643cd^ --interactive # редактировать коммит bbc643cd
+\end_layout
+
+\begin_layout LyX-Code
+vim main.c # редактирование main.c
+\end_layout
+
+\begin_layout LyX-Code
+vim main.h # редактирование main.h
+\end_layout
+
+\begin_layout LyX-Code
+git add main.c main.h # добавление main.c and main.h в индекс
+\end_layout
+
+\begin_layout LyX-Code
+git commit --amend # обновление коммита bbc643cd (теперь у него новый хеш)
+\end_layout
+
+\begin_layout LyX-Code
+git rebase --continue # обновить все последующие коммиты в данной ветке
+\end_layout
+
+\begin_layout LyX-Code
+git push -f # отправить изменённую ветвь на Git-сервер
+\end_layout
+
+\begin_layout Subsection
+Пример использования gitflow
+\end_layout
+
+\begin_layout LyX-Code
+# Создание веток master/developer/release/hotfix
+\end_layout
+
+\begin_layout LyX-Code
+$ git flow init
+\end_layout
+
+\begin_layout LyX-Code
+ 
+\end_layout
+
+\begin_layout LyX-Code
+# Начинаем работать над функционалом feature1 (ответвление от develop)
+\end_layout
+
+\begin_layout LyX-Code
+$ git flow feature start feature1
+\end_layout
+
+\begin_layout LyX-Code
+# делаем изменения
+\end_layout
+
+\begin_layout LyX-Code
+$ git add ...изменения...
+\end_layout
+
+\begin_layout LyX-Code
+$ git commit -m "изменения для feature1"
+\end_layout
+
+\begin_layout LyX-Code
+ 
+\end_layout
+
+\begin_layout LyX-Code
+# Эта команда сделает слияние feature1 с develop и удалит ветку
+\end_layout
+
+\begin_layout LyX-Code
+$ git flow feature finish feature1
+\end_layout
+
+\begin_layout LyX-Code
+ 
+\end_layout
+
+\begin_layout LyX-Code
+# Давайте начнём работу над релизом
+\end_layout
+
+\begin_layout LyX-Code
+$ git flow release start release1
+\end_layout
+
+\begin_layout LyX-Code
+# делаем изменения
+\end_layout
+
+\begin_layout LyX-Code
+$ git add ...изменения...
+\end_layout
+
+\begin_layout LyX-Code
+$ git commit -m "release1"
+\end_layout
+
+\begin_layout LyX-Code
+ 
+\end_layout
+
+\begin_layout LyX-Code
+# Эта команда сделает слияние release1 с master
+\end_layout
+
+\begin_layout LyX-Code
+$ git flow release finish release1 
+\end_layout
+
+\begin_layout Section
+Удачная модель ветвления
+\end_layout
+
+\begin_layout Standard
+Материал взят с 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://habrahabr.ru/post/106912/
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+В этой статье я представляю модель разработки, которую использую для всех
+ моих проектов (как рабочих, так и частных) уже в течение года, и которая
+ показала себя с хорошей стороны.
+ Я давно собирался написать о ней, но до сих пор не находил свободного времени.
+ Не буду рассказывать обо всех деталях проекта, коснусь лишь стратегии ветвления
+ и управления релизами.
+\end_layout
+
+\begin_layout Standard
+\begin_inset Float figure
+placement H
+wide false
+sideways false
+status collapsed
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/782a1be3.png
+	scale 50
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+\begin_inset CommandInset label
+LatexCommand label
+name "fig:Удачная-модель-ветвления"
+
+\end_inset
+
+Удачная модель ветвления
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+В качестве инструмента управления версиями всего исходного кода она использует
+ Git.
+\end_layout
+
+\begin_layout Subsection
+Почему Git?
+\end_layout
+
+\begin_layout Standard
+За полноценным обсуждением всех достоинств и недостатков Git в сравнении
+ с централизованными системами контроля версий 
+\begin_inset CommandInset href
+LatexCommand href
+name "обращайтесь"
+target "http://whygitisbetterthanx.com/"
+
+\end_inset
+
+ 
+\begin_inset CommandInset href
+LatexCommand href
+name "к всемирной"
+target "http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table"
+
+\end_inset
+
+ 
+\begin_inset CommandInset href
+LatexCommand href
+name "сети"
+target "http://git.or.cz/gitwiki/GitSvnComparsion"
+
+\end_inset
+
+.
+ Там Вы найдёте достаточное количество споров на эту тему.
+ Лично же я, как разработчик, на данный момент предпочитаю Git всем остальным
+ инструментам.
+ Git реально смог изменить отношение разработчиков к процессам слияния и
+ ветвления.
+ В классическом мире CVS/Subversion, из которого я пришёл, ветвление и слияние
+ обычно считаются опасными («опасайтесь конфликтов слияния, они больно кусаются!
+»), и потому проводятся как можно реже.
+\end_layout
+
+\begin_layout Standard
+Но с Git эти действия становятся исключительно простыми и дешёвыми, и потому
+ на деле они становятся центральными элементами обычного 
+\shape slanted
+ежедневного
+\shape default
+ рабочего процесса.
+ Просто сравните: в 
+\begin_inset CommandInset href
+LatexCommand href
+name "книгах"
+target "http://svnbook.red-bean.com/"
+
+\end_inset
+
+ по CVS/Subversion ветвление и слияние обычно рассматриваются в последних
+ главах (для продвинутых пользователей), в то время как в 
+\begin_inset CommandInset href
+LatexCommand href
+name "любой"
+target "http://book.git-scm.com/"
+
+\end_inset
+
+ 
+\begin_inset CommandInset href
+LatexCommand href
+name "книге"
+target "http://pragprog.com/titles/tsgit/pragmatic-version-control-using-git"
+
+\end_inset
+
+ 
+\begin_inset CommandInset href
+LatexCommand href
+name "про Git"
+target "http://github.com/progit/progit"
+
+\end_inset
+
+ они бывают упомянуты уже к третьей главе (основы).
+\end_layout
+
+\begin_layout Standard
+Благодаря своей простоте и предсказуемости, ветвление и слияние больше не
+ являются действиями, которых стоит опасаться.
+ Теперь инструменты управления версиями способны помочь в ветвлении и слиянии
+ больше, чем какие-либо другие.
+\end_layout
+
+\begin_layout Standard
+Но хватит говорить об инструментах, давайте перейдём к модели разработки.
+ Модель, которую я хочу представить, — это, по сути, просто набор процедур,
+ которые исполняет каждый член команды, чтобы все вместе могли достичь высокой
+ управляемости процесса разработки.
+\end_layout
+
+\begin_layout Subsection
+Децентрализованный, но централизованный
+\end_layout
+
+\begin_layout Standard
+Предлагаемая модель ветвления опирается на конфигурацию проекта, содержащую
+ один центральный «истинный» репозиторий.
+ Замечу, что этот репозиторий только 
+\shape slanted
+считается
+\shape default
+ центральным (так как Git является DVCS, у него нет такой вещи, как главный
+ репозиторий, на техническом уровне).
+ Мы будем называть этот репозиторий термином origin, т.к.
+ это имя и так знакомо всем пользователям Git.
+\end_layout
+
+\begin_layout Standard
+\begin_inset Float figure
+placement H
+wide false
+sideways false
+status collapsed
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/1d1e8f1a.png
+	scale 50
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+Децентрализованный, но централизованный
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+Каждый разработчик забирает и публикует изменения (pull & push) в origin.
+ Но, помимо централизованных отношений push-pull, каждый разработчик также
+ может забирать изменения от остальных коллег внутри своей микро-команды.
+ Например, этот способ может быть удобен в ситуации, когда двое или более
+ разработчиков работают вместе над большой новой фичей, но не могут издать
+ незавершённую работу в origin раньше времени.
+ На картинке выше изображены подгруппы Алисы и Боба, Алисы и Дэвида, Клэр
+ и Дэвида.
+\end_layout
+
+\begin_layout Standard
+Технически это реализуется несложно: Алиса создаёт удалённую ветку Git под
+ названием bob, которая указывает на репозиторий Боба, а Боб делает то же
+ самое с её репозиторием.
+\end_layout
+
+\begin_layout Subsection
+Главные ветви
+\end_layout
+
+\begin_layout Standard
+\begin_inset Wrap figure
+lines 0
+placement R
+overhang 0in
+width "30col%"
+status collapsed
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/00eb029a.png
+	scale 50
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+Главные ветви
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\end_inset
+
+Ядро модели разработки не отличается от большинства существующих моделей.
+ Центральный репозиторий содержит две главные ветки, существующие всё время.
+\end_layout
+
+\begin_layout Itemize
+master
+\end_layout
+
+\begin_layout Itemize
+develop
+\end_layout
+
+\begin_layout Standard
+Ветвь master создаётся при инициализации репозитория, что должно быть знакомо
+ каждому пользователю Git.
+ Параллельно ей также мы создаём ветку для разработки под названием develop.
+\end_layout
+
+\begin_layout Standard
+Мы считаем ветку origin/master главной.
+ То есть, исходный код в ней должен находиться в состоянии 
+\shape slanted
+production-ready
+\shape default
+ в любой произвольный момент времени.
+\end_layout
+
+\begin_layout Standard
+Ветвь origin/develop мы считаем главной ветвью для разработки.
+ Хранящийся в ней код в любой момент времени должен содержать самые последние
+ изданные изменения, необходимые для следующего релиза.
+ Эту ветку также можно назвать «интеграционной».
+ Она служит источником для сборки автоматических ночных билдов.
+\end_layout
+
+\begin_layout Standard
+Когда исходный код в ветви разработки (develop) достигает стабильного состояния
+ и готов к релизу, все изменения должны быть определённым способом влиты
+ в главную ветвь (master) и помечены тегом с номером релиза.
+ Ниже мы рассмотрим этот процесс в деталях.
+\end_layout
+
+\begin_layout Standard
+Следовательно, каждый раз, когда изменения вливаются в главную ветвь (master),
+ мы 
+\shape slanted
+по определению
+\shape default
+ получаем новый релиз.
+ Мы стараемся относиться к этому правилу очень строго, так что, в принципе,
+ мы могли бы использовать хуки Git, чтобы автоматически собирать наши продукты
+ и выкладывать их на рабочие сервера при каждом коммите в главную ветвь
+ (master).
+\end_layout
+
+\begin_layout Subsection
+Вспомогательные ветви
+\end_layout
+
+\begin_layout Standard
+Помимо главных ветвей master и develop, наша модель разработки содержит
+ некоторое количество типов вспомогательных ветвей, которые используются
+ для распараллеливания разработки между членами команды, для упрощения внедрения
+ нового функционала (features), для подготовки релизов и для быстрого исправлени
+я проблем в производственной версии приложения.
+ В отличие от главный ветвей, эти ветви всегда имеют ограниченный срок жизни.
+ Каждая из них в конечном итоге рано или поздно удаляется.
+\end_layout
+
+\begin_layout Standard
+Мы используем следующие типы ветвей:
+\end_layout
+
+\begin_layout Itemize
+Ветви функциональностей (Feature branches)
+\end_layout
+
+\begin_layout Itemize
+Ветви релизов (Release branches)
+\end_layout
+
+\begin_layout Itemize
+Ветви исправлений (Hotfix branches)
+\end_layout
+
+\begin_layout Standard
+У каждого типа ветвей есть своё специфическое назначение и строгий набор
+ правил, от каких ветвей они могут порождаться, и в какие должны вливаться.
+ Сейчас мы рассмотрим их по очереди.
+\end_layout
+
+\begin_layout Standard
+Конечно же, с технической точки зрения, у этих ветвей нет ничего «специфического
+».
+ Разбиение ветвей на категории существует только с точки зрения того, как
+ они используются.
+ А во всём остальном это старые добрые ветви Git.
+\end_layout
+
+\begin_layout Subsubsection
+Ветви функциональностей (feature branches)
+\end_layout
+
+\begin_layout Standard
+\begin_inset Wrap figure
+lines 0
+placement R
+overhang 0in
+width "30col%"
+status collapsed
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/968a9100.png
+	scale 50
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+Ветви функциональностей (feature branches)
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+Могут порождаться от: develop
+\end_layout
+
+\begin_layout Standard
+Должны вливаться в: develop
+\end_layout
+
+\begin_layout Standard
+Соглашение о наименовании: всё, за исключением master, develop, release-*
+ или hotfix-*
+\end_layout
+
+\begin_layout Standard
+Ветви функциональностей (feature branches), также называемые иногда тематическим
+и ветвями (topic branches), используются для разработки новых функций, которые
+ должны появиться в текущем или будущем релизах.
+ При начале работы над функциональностью (фичей) может быть ещё неизвестно,
+ в какой именно релиз она будет добавлена.
+ Смысл существования ветви функциональности (feature branch) состоит в том,
+ что она живёт так долго, сколько продолжается разработка данной функциональност
+и (фичи).
+ Когда работа в ветви завершена, последняя вливается обратно в главную ветвь
+ разработки (что означает, что функциональность будет добавлена в грядущий
+ релиз) или же удаляется (в случае неудачного эксперимента).
+\end_layout
+
+\begin_layout Standard
+Ветви функциональностей (feature branches) обычно существуют в репозиториях
+ разработчиков, но не в главном репозитории (origin).
+\end_layout
+
+\begin_layout Paragraph
+Создание ветви функциональности (feature branch)
+\end_layout
+
+\begin_layout Standard
+При начале работы над новой функциональностью делается ответвление от ветви
+ разработки (develop).
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout -b myfeature develop
+\end_layout
+
+\begin_layout LyX-Code
+Switched to a new branch "myfeature"
+\end_layout
+
+\begin_layout Paragraph
+Добавление завершённой функциональности в develop
+\end_layout
+
+\begin_layout Standard
+Завершённая функциональность (фича) вливается обратно в ветвь разработки
+ (develop) и попадает в следующий релиз.
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout develop
+\end_layout
+
+\begin_layout LyX-Code
+Switched to branch 'develop'
+\end_layout
+
+\begin_layout LyX-Code
+$ git merge --no-ff myfeature
+\end_layout
+
+\begin_layout LyX-Code
+Updating ea1b82a..05e9557
+\end_layout
+
+\begin_layout LyX-Code
+(Отчёт об изменениях)
+\end_layout
+
+\begin_layout LyX-Code
+$ git branch -d myfeature
+\end_layout
+
+\begin_layout LyX-Code
+Deleted branch myfeature (was 05e9557).
+\end_layout
+
+\begin_layout LyX-Code
+$ git push origin develop
+\end_layout
+
+\begin_layout Standard
+Флаг --no-ff вынуждает Git всегда создавать новый объект коммита при слиянии,
+ даже если слияние может быть осуществлено алгоритмом fast-forward.
+ Это позволяет не терять информацию о том, что ветка существовала, и группирует
+ вместе все внесённые изменения.
+ Сравните:
+\end_layout
+
+\begin_layout Standard
+\begin_inset Float figure
+placement H
+wide false
+sideways false
+status collapsed
+
+\begin_layout Plain Layout
+
+\end_layout
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/572137b0.png
+	scale 50
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+no-fast-forward VS fast-forward
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+Во втором случае невозможно увидеть в истории изменений, какие именно объекты
+ коммитов совместно образуют функциональность, — для этого придётся вручную
+ читать все сообщения в коммитах.
+ Отменить функциональность целиком (т.е., группу коммитов) в таком случае
+ невозможно без головной боли, а с флагом --no-ff это делается элементарно.
+\end_layout
+
+\begin_layout Standard
+Конечно, такой подход создаёт некоторое дополнительное количество (пустых)
+ объектов коммитов, но получаемая выгода более чем оправдывает подобную
+ цену.
+\end_layout
+
+\begin_layout Standard
+К сожалению, я ещё не нашёл, как можно настроить Git так, чтобы --no-ff
+ было поведением по-умолчанию при слияниях.
+ Но этот способ должен быть реализован.
+\end_layout
+
+\begin_layout Subsubsection
+Ветви релизов (release branches)
+\end_layout
+
+\begin_layout Standard
+Могут порождаться от: develop
+\end_layout
+
+\begin_layout Standard
+Должны вливаться в: develop и master
+\end_layout
+
+\begin_layout Standard
+Соглашение о наименовании: release-*
+\end_layout
+
+\begin_layout Standard
+Ветви релизов (release branches) используются для подготовки к выпуску новых
+ версий продукта.
+ Они позволяют расставить финальные точки над i перед выпуском новой версии.
+ Кроме того, в них можно добавлять минорные исправления, а также подготавливать
+ метаданные для очередного релиза (номер версии, дата сборки и т.д.).
+ Когда вся эта работа выносится в ветвь релизов, главная ветвь разработки
+ (develop) очищается для добавления последующих фич (которые войдут в следующий
+ большой релиз).
+\end_layout
+
+\begin_layout Standard
+Новую ветку релиза (release branch) надо порождать в тот момент, когда состояние
+ ветви разработки полностью или почти полностью соответствует требованиям,
+ соответствующим новому релизу.
+ По крайней мере, вся необходимая функциональность, предназначенная к этому
+ релизу, уже влита в ветвь разработки (develop).
+ Функциональность, предназначенная к следующим релизам, может быть и не
+ влита.
+ Даже лучше, если ветки для этих функциональностей подождут, пока текущая
+ ветвь релиза не отпочкуется от ветви разработки (develop).
+\end_layout
+
+\begin_layout Standard
+Очередной релиз получает свой номер версии только в тот момент, когда для
+ него создаётся новая ветвь, но ни в коем случае не раньше.
+ Вплоть до этого момента ветвь разработки содержит изменения для «нового
+ релиза», но пока ветка релиза не отделилась, точно неизвестно, будет ли
+ этот релиз иметь версию 0.3, или 1.0, или какую-то другую.
+ Решение принимается при создании новой ветви релиза и зависит от принятых
+ на проекте правил нумерации версий проекта.
+\end_layout
+
+\begin_layout Paragraph
+Создание ветви релиза (release branch)
+\end_layout
+
+\begin_layout Standard
+Ветвь релиза создаётся из ветви разработки (develop).
+ Пускай, например, текущий изданный релиз имеет версию 1.1.5, а на подходе
+ новый большой релиз, полный изменений.
+ Ветвь разработки (develop) готова к «следующему релизу», и мы решаем, что
+ этот релиз будет иметь версию 1.2 (а не 1.1.6 или 2.0).
+ В таком случае мы создаём новую ветвь и даём ей имя, соответствующее новой
+ версии проекта:
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout -b release-1.2 develop
+\end_layout
+
+\begin_layout LyX-Code
+Switched to a new branch "release-1.2"
+\end_layout
+
+\begin_layout LyX-Code
+$ ./bump-version.sh 1.2
+\end_layout
+
+\begin_layout LyX-Code
+Files modified successfully, version bumped to 1.2.
+\end_layout
+
+\begin_layout LyX-Code
+$ git commit -a -m "Bumped version number to 1.2"
+\end_layout
+
+\begin_layout LyX-Code
+[release-1.2 74d9424] Bumped version number to 1.2
+\end_layout
+
+\begin_layout LyX-Code
+1 files changed, 1 insertions(+), 1 deletions(-)
+\end_layout
+
+\begin_layout Standard
+Мы создали новую ветку, переключились в неё, а затем выставили номер версии
+ (bump version number).
+ В нашем примере bump-version.sh — это вымышленный скрипт, который изменяет
+ некоторые файлы в рабочей копии, записывая в них новую версию.
+ (Разумеется, эти изменения можно внести и вручную; я просто обращаю Ваше
+ внимание на то, что 
+\shape slanted
+некоторые
+\shape default
+ файлы изменяются.) Затем мы делаем коммит с указанием новой версии проекта.
+\end_layout
+
+\begin_layout Standard
+Эта новая ветвь может существовать ещё некоторое время, до тех пор, пока
+ новый релиз окончательно не будет готов к выпуску.
+ В течение этого времени к этой ветви (а не к develop) могут быть добавлены
+ исправления найденных багов.
+ Но добавление крупных новых изменений в эту ветвь строго запрещено.
+ Они всегда должны вливаться в ветвь разработки (develop) и ждать следующего
+ большого релиза.
+\end_layout
+
+\begin_layout Paragraph
+Закрытие ветви релиза
+\end_layout
+
+\begin_layout Standard
+Когда мы решаем, что ветвь релиза (release branch) окончательно готова для
+ выпуска, нужно проделать несколько действий.
+ В первую очередь ветвь релиза вливается в главную ветвь (напоминаю, каждый
+ коммит в master — это 
+\shape slanted
+по определению
+\shape default
+ новый релиз).
+ Далее, этот коммит в master должен быть помечен тегом, чтобы в дальнейшем
+ можно было легко обратиться к любой существовавшей версии продукта.
+ И наконец, изменения, сделанные в ветви релиза (release branch), должны
+ быть добавлены обратно в разработку (ветвь develop), чтобы будущие релизы
+ также содержали внесённые исправления багов.
+\end_layout
+
+\begin_layout Standard
+Первые два шага в Git:
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout master
+\end_layout
+
+\begin_layout LyX-Code
+Switched to branch 'master'
+\end_layout
+
+\begin_layout LyX-Code
+$ git merge --no-ff release-1.2
+\end_layout
+
+\begin_layout LyX-Code
+Merge made by recursive.
+\end_layout
+
+\begin_layout LyX-Code
+(Отчёт об изменениях)
+\end_layout
+
+\begin_layout LyX-Code
+$ git tag -a 1.2
+\end_layout
+
+\begin_layout Standard
+Теперь релиз издан и помечен тегом.
+\end_layout
+
+\begin_layout Standard
+
+\series bold
+Замечание: 
+\series default
+при желании, Вы также можете использовать флаги -s или -u <ключ>, чтобы
+ криптографически подписать тег.
+\end_layout
+
+\begin_layout Standard
+Чтобы сохранить изменения и в последующих релизах, мы должны влить эти изменения
+ обратно в разработку.
+ Делаем это так:
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout develop
+\end_layout
+
+\begin_layout LyX-Code
+Switched to branch 'develop'
+\end_layout
+
+\begin_layout LyX-Code
+$ git merge --no-ff release-1.2
+\end_layout
+
+\begin_layout LyX-Code
+Merge made by recursive.
+\end_layout
+
+\begin_layout LyX-Code
+(Отчёт об изменениях)
+\end_layout
+
+\begin_layout Standard
+Этот шаг, в принципе, может привести к конфликту слияния (нередко бывает,
+ что к причиной конфликта является изменение номера версии проекта).
+ Если это произошло, исправьте их и издайте коммит.
+\end_layout
+
+\begin_layout Standard
+Теперь мы окончательно разделались с веткой релиза.
+ Можно её удалять, потому что она нам больше не понадобится:
+\end_layout
+
+\begin_layout LyX-Code
+$ git branch -d release-1.2
+\end_layout
+
+\begin_layout LyX-Code
+Deleted branch release-1.2 (was ff452fe).
+\end_layout
+
+\begin_layout Subsubsection
+Ветви исправлений (hotfix branches)
+\end_layout
+
+\begin_layout Standard
+\begin_inset Wrap figure
+lines 0
+placement R
+overhang 0in
+width "44col%"
+status collapsed
+
+\begin_layout Plain Layout
+\align center
+\begin_inset Graphics
+	filename pic/3f8cbad4.png
+	scale 50
+
+\end_inset
+
+
+\begin_inset Caption
+
+\begin_layout Plain Layout
+Ветви исправлений (hotfix branches)
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+Могут порождаться от: master
+\end_layout
+
+\begin_layout Standard
+Должны вливаться в: develop и master
+\end_layout
+
+\begin_layout Standard
+Соглашение о наименовании: hotfix-*
+\end_layout
+
+\begin_layout Standard
+Ветви для исправлений (hotfix branches) весьма похожи на ветви релизов (release
+ branches), так как они тоже используются для подготовки новых выпусков
+ продукта, разве лишь незапланированных.
+ Они порождаются необходимостью немедленно исправить нежелательное поведение
+ производственной версии продукта.
+ Когда в производственной версии находится баг, требующий немедленного исправлен
+ия, из соответствующего данной версии тега главной ветви (master) порождается
+ новая ветвь для работы над исправлением.
+\end_layout
+
+\begin_layout Standard
+Смысл её существования состоит в том, что работа команды над ветвью разработки
+ (develop) может спокойно продолжаться, в то время как кто-то один готовит
+ быстрое исправление производственной версии.
+\end_layout
+
+\begin_layout Paragraph
+Создание ветви исправлений (hotfix branch)
+\end_layout
+
+\begin_layout Standard
+Ветви исправлений (hotfix branches) создаются из главной (master) ветви.
+ Пускай, например, текущий производственный релиз имеет версию 1.2, и в нём
+ (внезапно!) обнаруживается серьёзный баг.
+ А изменения в ветви разработки (develop) ещё недостаточно стабильны, чтобы
+ их издавать в новый релиз.
+ Но мы можем создать новую ветвь исправлений и начать работать над решением
+ проблемы:
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout -b hotfix-1.2.1 master
+\end_layout
+
+\begin_layout LyX-Code
+Switched to a new branch "hotfix-1.2.1"
+\end_layout
+
+\begin_layout LyX-Code
+$ ./bump-version.sh 1.2.1
+\end_layout
+
+\begin_layout LyX-Code
+Files modified successfully, version bumped to 1.2.1.
+\end_layout
+
+\begin_layout LyX-Code
+$ git commit -a -m "Bumped version number to 1.2.1"
+\end_layout
+
+\begin_layout LyX-Code
+[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
+\end_layout
+
+\begin_layout LyX-Code
+1 files changed, 1 insertions(+), 1 deletions(-)
+\end_layout
+
+\begin_layout Standard
+Не забывайте обновлять номер версии после создания ветви!
+\end_layout
+
+\begin_layout Standard
+Теперь можно исправлять баг, а изменения издавать хоть одним коммитом, хоть
+ несколькими.
+\end_layout
+
+\begin_layout LyX-Code
+$ git commit -m "Fixed severe production problem"
+\end_layout
+
+\begin_layout LyX-Code
+[hotfix-1.2.1 abbe5d6] Fixed severe production problem
+\end_layout
+
+\begin_layout LyX-Code
+5 files changed, 32 insertions(+), 17 deletions(-)
+\end_layout
+
+\begin_layout Paragraph
+Закрытие ветви исправлений
+\end_layout
+
+\begin_layout Standard
+Когда баг исправлен, изменения надо влить обратно в главную ветвь (master),
+ а также в ветвь разработки (develop), чтобы гарантировать, что это исправление
+ окажется и в следующем релизе.
+ Это очень похоже на то, как закрывается ветвь релиза (release branch).
+\end_layout
+
+\begin_layout Standard
+Прежде всего надо обновить главную ветвь (master) и пометить новую версию
+ тегом.
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout master
+\end_layout
+
+\begin_layout LyX-Code
+Switched to branch 'master'
+\end_layout
+
+\begin_layout LyX-Code
+$ git merge --no-ff hotfix-1.2.1 
+\end_layout
+
+\begin_layout LyX-Code
+Merge made by recursive.
+\end_layout
+
+\begin_layout LyX-Code
+(Отчёт об изменениях)
+\end_layout
+
+\begin_layout LyX-Code
+$ git tag -a 1.2.1
+\end_layout
+
+\begin_layout Standard
+
+\series bold
+Замечание:
+\series default
+ при желании, Вы также можете использовать флаги -s или -u <ключ>, чтобы
+ криптографически подписать тэг.
+\end_layout
+
+\begin_layout Standard
+Следующим шагом переносим исправление в ветвь разработки (develop).
+\end_layout
+
+\begin_layout LyX-Code
+$ git checkout develop
+\end_layout
+
+\begin_layout LyX-Code
+Switched to branch 'develop'
+\end_layout
+
+\begin_layout LyX-Code
+$ git merge --no-ff hotfix-1.2.1
+\end_layout
+
+\begin_layout LyX-Code
+Merge made by recursive.
+\end_layout
+
+\begin_layout LyX-Code
+(Отчёт об изменениях)
+\end_layout
+
+\begin_layout Standard
+У этого правила есть одно исключение: 
+\series bold
+если в данный момент существует ветвь релиза (release branch), то ветвь
+ исправления (hotfix branch) должна вливаться в неё, а не в ветвь разработки
+ (develop
+\series default
+).
+ В этом случае исправления войдут в ветвь разработки вместе со всей ветвью
+ релиза, когда та будет закрыта.
+ (Хотя, если работа в develop требует немедленного исправления бага и не
+ может ждать, пока будет завершено издание текущего релиза, Вы всё же можете
+ влить исправления (bugfix) в ветвь разработки (develop), и это будет вполне
+ безопасно).
+\end_layout
+
+\begin_layout Standard
+И наконец, удаляем временную ветвь:
+\end_layout
+
+\begin_layout LyX-Code
+$ git branch -d hotfix-1.2.1
+\end_layout
+
+\begin_layout LyX-Code
+Deleted branch hotfix-1.2.1 (was abbe5d6).
+\end_layout
+
+\begin_layout Subsection
+Заключение
+\end_layout
+
+\begin_layout Standard
+Хотя в этой модели ветвления совершенно нет ничего принципиально нового,
+ «большая картинка», с которой начинается эта статья, зарекомендовала себя
+ в наших проектах с самой лучшей стороны.
+ Она формирует элегантную мысленную модель, которую легко полностью охватить
+ одним взглядом, и которая позволяет сформировать у команды совместное понимание
+ процессов ветвления и слияния, действующих на проекте.
+\end_layout
+
+\begin_layout Standard
+Высококачественная PDF-версия этой картинки свободна для скачивания 
+\begin_inset CommandInset href
+LatexCommand href
+name "здесь"
+target "http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf"
+
+\end_inset
+
+.
+ Распечатайте её и повесьте у себя на стену, чтобы к ней можно было обратиться
+ в любой момент.
+\end_layout
+
+\begin_layout Standard
+
+\series bold
+\shape slanted
+Прим.
+ переводчика:
+\series default
+ статья не новая, ссылка на оригинал 
+\begin_inset CommandInset href
+LatexCommand href
+name "уже появлялась на хабре"
+target "http://habrahabr.ru/blogs/development_tools/104993/"
+
+\end_inset
+
+.
+ Этот перевод — для тех, кому английский ещё даётся не так легко (а также
+ для моих коллег, среди которых я занимаюсь пропагандой, хехе).
+ Для автоматизации описанных в статье процедур автор создал проект gitflow,
+ 
+\begin_inset CommandInset href
+LatexCommand href
+name "который можно найти на github"
+target "http://github.com/nvie/gitflow"
+
+\end_inset
+
+.
+\end_layout
+
+\end_body
+\end_document
diff --git a/pic/00eb029a.png b/pic/00eb029a.png
new file mode 100644
index 0000000..34b85fb
Binary files /dev/null and b/pic/00eb029a.png differ
diff --git a/pic/1d1e8f1a.png b/pic/1d1e8f1a.png
new file mode 100644
index 0000000..c606332
Binary files /dev/null and b/pic/1d1e8f1a.png differ
diff --git a/pic/3f8cbad4.png b/pic/3f8cbad4.png
new file mode 100644
index 0000000..5d7b914
Binary files /dev/null and b/pic/3f8cbad4.png differ
diff --git a/pic/572137b0.png b/pic/572137b0.png
new file mode 100644
index 0000000..5ad3cc3
Binary files /dev/null and b/pic/572137b0.png differ
diff --git a/pic/782a1be3.png b/pic/782a1be3.png
new file mode 100644
index 0000000..3762e6c
Binary files /dev/null and b/pic/782a1be3.png differ
diff --git a/pic/968a9100.png b/pic/968a9100.png
new file mode 100644
index 0000000..b41caf0
Binary files /dev/null and b/pic/968a9100.png differ
diff --git a/pic/vRdkr.png b/pic/vRdkr.png
new file mode 100644
index 0000000..5ad3cc3
Binary files /dev/null and b/pic/vRdkr.png differ