Git-Tutorial/git-tutorial.lyx

3452 lines
97 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

#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} % Красная строка
\sloppy % русские переносы
% содержание и нумерация
\setcounter{tocdepth}{4} % table of contents depth
\setcounter{secnumdepth}{4} % numbering depth
\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 "Git-tutorial"
\pdf_author "Kolan Sh, InSys Ltd, Moscow"
\pdf_subject "Git"
\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
Версия 1.1.0
\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 Standard
В Git имеется встроенная справка по всем командам, достаточно набрать
\end_layout
\begin_layout LyX-Code
git help command
\end_layout
\begin_layout Standard
Для большинства опций имеются их сокращённые аналоги, например,
\end_layout
\begin_layout LyX-Code
git rebase -i -p # эквивалентно git rebase --interactive --preserve-merges
\end_layout
\begin_layout Standard
и значения по умолчанию:
\end_layout
\begin_layout LyX-Code
git log --decorate # эквивалентно git log --decorate=short
\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
\end_layout
\begin_layout LyX-Code
diff --git a/git-tutorial.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 Subsubsection
Статус текущих
\begin_inset Quotes eld
\end_inset
незакоммиченных
\begin_inset Quotes erd
\end_inset
изменений
\end_layout
\begin_layout Standard
Текущее состояние рабочей директории можно посмотреть командой status:
\end_layout
\begin_layout LyX-Code
$ git status # вывести текущие изменения
\end_layout
\begin_layout LyX-Code
# On branch #238feature
\end_layout
\begin_layout LyX-Code
# Changes not staged for commit:
\end_layout
\begin_layout LyX-Code
# (use "git add <file>..." to update what will be committed)
\end_layout
\begin_layout LyX-Code
# (use "git checkout -- <file>..." to discard changes in working directory)
\end_layout
\begin_layout LyX-Code
#
\end_layout
\begin_layout LyX-Code
# modified: git-tutorial.lyx
\end_layout
\begin_layout LyX-Code
#
\end_layout
\begin_layout LyX-Code
# Untracked files:
\end_layout
\begin_layout LyX-Code
# (use "git add <file>..." to include in what will be committed)
\end_layout
\begin_layout LyX-Code
#
\end_layout
\begin_layout LyX-Code
# #git-tutorial.lyx#
\end_layout
\begin_layout LyX-Code
# git-tutorial.lyx~
\end_layout
\begin_layout LyX-Code
# git-tutorial.pdf
\end_layout
\begin_layout LyX-Code
no changes added to commit (use "git add" and/or "git commit -a")
\end_layout
\begin_layout LyX-Code
$ git status -s # использовать сокращённую запись
\end_layout
\begin_layout LyX-Code
M git-tutorial.lyx
\end_layout
\begin_layout LyX-Code
?? #git-tutorial.lyx#
\end_layout
\begin_layout LyX-Code
?? git-tutorial.lyx~
\end_layout
\begin_layout LyX-Code
?? git-tutorial.pdf
\end_layout
\begin_layout Standard
Сами изменения можно посмотреть командой diff:
\end_layout
\begin_layout LyX-Code
git diff # вывести изменения рабочей директории
\end_layout
\begin_layout LyX-Code
git diff --staged # вывести изменения, добавленные в индекс
\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
При работе с системами управления проектами (ChilliProject, Redmine, Trac)
по завершении работы с ветвью имеет смысл добавлять в сообщение коммита
отметку о решении/закрытии бага/фичи.
Система управления проектами автоматически пометит тикет как решённый и
свяжет его с указанным коммитом, так что любой может определить какие изменения
были внесены для решения конкретной задачи.
Пример:
\end_layout
\begin_layout LyX-Code
git commit -m
\begin_inset Quotes eld
\end_inset
Feature A implemented.
Closes #238.
\begin_inset Quotes erd
\end_inset
\end_layout
\begin_layout LyX-Code
git commit -m
\begin_inset Quotes eld
\end_inset
Bug B fixed.
Fixes #239.
\begin_inset Quotes erd
\end_inset
\end_layout
\begin_layout Standard
Также возможно слияние изменений без создания нового коммита (следует отметить,
что хеш последнего коммита всё-равно изменится, а с ним изменится и история)
посредством команды:
\end_layout
\begin_layout LyX-Code
git merge --squash
\end_layout
\begin_layout Standard
Иногда в списке удалённых веток (git branch -r) остаются несуществующие
ссылки в результате того, что кто-то удалил эту ветвь или несколько веток
ссылок указывали на одну удалённую ветвь.
Обновить список можно командой fetch:
\end_layout
\begin_layout LyX-Code
git fetch
\end_layout
\begin_layout LyX-Code
git fetch github
\end_layout
\begin_layout Standard
или вручную удалить невалидную ссылку:
\end_layout
\begin_layout LyX-Code
git branch -d -r origin/invalid_branch
\end_layout
\begin_layout LyX-Code
git branch -d -r github/invalid_branch2
\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 Standard
Если репозиторий содержит субрепозитории (submodules) необходимо их инициализиро
вать и синхронизировать:
\end_layout
\begin_layout LyX-Code
git submodule update --init --recursive
\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 Subsubsection
format-patch - создание патча
\end_layout
\begin_layout Standard
Когда лень делать удалённый клон в Gitorious с pull-request-ом и есть уверенност
ь, что Ваш патч примут сразу, а не спустя длительное время, когда в основном
дереве накопится изменений, конфликтующих с патчем, можно использовать
быстрое создание патча:
\end_layout
\begin_layout LyX-Code
git checkout -b fix_the_bug master # создаём ответвление от master
\end_layout
\begin_layout LyX-Code
...
edit ...
\end_layout
\begin_layout LyX-Code
git commit -am
\begin_inset Quotes eld
\end_inset
The bug fixed.
\begin_inset Quotes erd
\end_inset
\end_layout
\begin_layout LyX-Code
git format-patch master # создать патч, включающий отличия текущей ревизии
от ветки master
\end_layout
\begin_layout Standard
Далее полученный патч может быть отправлен по email или прямо в окно Jabber-клие
нта.
Можно создать патч и отправить его по email одной командой:
\end_layout
\begin_layout LyX-Code
git format-patch master --stdout | mail -s 'Please apply this patch, Leo'
leo@matrix.org
\end_layout
\begin_layout Standard
Применить полученный патч можно командой apply:
\end_layout
\begin_layout LyX-Code
git apply --check the_bug_fixed.patch # тест на конфликты
\end_layout
\begin_layout LyX-Code
git apply --stat # применение патча с включением в историю текущей ветви
\end_layout
\begin_layout LyX-Code
# и выводом статистики изменений
\end_layout
\begin_layout Subsection
Анализ истории, сравнение, поиск и фильтрация
\end_layout
\begin_layout Subsubsection
Список ветвей
\end_layout
\begin_layout Standard
Выводится командой branch
\end_layout
\begin_layout LyX-Code
git branch # список локальных веток
\end_layout
\begin_layout LyX-Code
git branch -r # список удалённых веток
\end_layout
\begin_layout LyX-Code
git branch -a # список всех веток, включая удалённые
\end_layout
\begin_layout LyX-Code
\end_layout
\begin_layout Standard
За более полным списком опций следует обратиться к справке по команде branch
(git help branch).
\end_layout
\begin_layout Subsubsection
Лог истории
\end_layout
\begin_layout Standard
Наболее полную информацию об истории изменений можно получить командой
\end_layout
\begin_layout LyX-Code
git log --graph --decorate --stat
\end_layout
\begin_layout Standard
- Git выведет графическое изображение дерева истории, включая слияния, подписи
и статистику изменений по каждому коммиту, где:
\end_layout
\begin_layout Itemize
-
\begin_inset space \thinspace{}
\end_inset
-graph -- выводить графическое дерево;
\end_layout
\begin_layout Itemize
-
\begin_inset space \thinspace{}
\end_inset
-decorate -- выводить у коммитов имена ссылок (ref names), например master,
origin/develop;
\end_layout
\begin_layout Itemize
-
\begin_inset space \thinspace{}
\end_inset
-stat -- печатать статистику по изменениям в каждом файле.
\end_layout
\begin_layout Standard
Если нужно вывести лог на определённом временном промежутке, через две точки
вводится начало и конец:
\end_layout
\begin_layout LyX-Code
git log master..develop
\end_layout
\begin_layout LyX-Code
git log f8a32c..3ab98c
\end_layout
\begin_layout Standard
Можно исключать из выводимого списка коммиты, входящие в какую-либо ветвь,
например следующая команда выведет список коммитов из develop, не вошедшие
в master:
\end_layout
\begin_layout LyX-Code
git log develop ^master
\end_layout
\begin_layout Standard
Более полный список опций описан в руководстве (git help log).
\end_layout
\begin_layout Subsubsection
Сравнение ревизий
\end_layout
\begin_layout Standard
Сравнение производится командой git diff.
Примеры:
\end_layout
\begin_layout LyX-Code
git diff # показать текущие изменения в рабочей директории
\end_layout
\begin_layout LyX-Code
git diff --staged # показать текущие изменения в рабочей директории, добавленные
в индекс
\end_layout
\begin_layout LyX-Code
git diff master..develop main.c # показать разницу main.c между двумя ветвями
\end_layout
\begin_layout LyX-Code
git diff 581a32..8f292a --stat # показать статистику различий между ревизиями
\end_layout
\begin_layout Subsubsection
Поиск и фильтрация
\end_layout
\begin_layout Standard
Для поиска используется всё та же команда log, но с параметрами:
\end_layout
\begin_layout LyX-Code
git log --author=
\begin_inset Quotes erd
\end_inset
Vasya Pupkin
\begin_inset Quotes erd
\end_inset
# поиск по автору
\end_layout
\begin_layout LyX-Code
git log --author="
\backslash
(Adam
\backslash
)
\backslash
|
\backslash
(Jon
\backslash
)" # поиск по одному из авторов
\end_layout
\begin_layout LyX-Code
git log -Ssome_string --source --all # поиск по строке some_string с выводом
ссылок на
\end_layout
\begin_layout LyX-Code
# удалённые репозитории, из которых
достижима ревизия
\end_layout
\begin_layout LyX-Code
git log path/to/file # коммиты, затрагивающие данный файл
\end_layout
\begin_layout LyX-Code
git log --grep=feature # коммиты с сообщениями о фичах
\end_layout
\begin_layout LyX-Code
\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 # применить их к рабочей директории и удалить
их из stash-списка
\end_layout
\begin_layout LyX-Code
git stash --keep-index # спрятать изменения, не добавленные в индекс
\end_layout
\begin_layout LyX-Code
git stash drop #
\begin_inset Quotes eld
\end_inset
выбросить
\begin_inset Quotes erd
\end_inset
спрятанные изменения
\end_layout
\begin_layout LyX-Code
git stash save --keep-index # спрятать изменения, не добавленные в индекс
\end_layout
\begin_layout LyX-Code
git stash apply # применить спрятанные изменения, не удаляя
их из stash-списка
\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 LyX-Code
git checkout .
# получить из головы (HEAD) содержимое текущей директории
\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 Standard
Вся история команд работы с Git хранится в локальном списке reflog:
\end_layout
\begin_layout LyX-Code
$ git reflog
\end_layout
\begin_layout LyX-Code
39b103b HEAD@{2}: commit: Adding feature #238...
\end_layout
\begin_layout LyX-Code
8958552 HEAD@{3}: reset: moving to develop
\end_layout
\begin_layout LyX-Code
7e3dca9 HEAD@{4}: commit: akt_half_tv3-117vm-00.lyx added.
\end_layout
\begin_layout LyX-Code
8958552 HEAD@{5}: reset: moving to develop
\end_layout
\begin_layout Standard
так, что имеется возможность локального восстановления в истории случайно
удалённого коммита.
Можно, к примеру, откатить голову (HEAD) ветки develop к моменту, когда
был добавлен lyx-файл:
\end_layout
\begin_layout LyX-Code
git checkout develop
\end_layout
\begin_layout LyX-Code
git reset --hard 7e3dca9
\end_layout
\begin_layout LyX-Code
git push -f origin develop
\end_layout
\begin_layout Standard
или просто получить в рабочей директории прежнее состояние, не изменяя истории:
\end_layout
\begin_layout LyX-Code
git checkout 7e3dca9
\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 Subsubsection
Редактирование недавних коммитов
\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 Subsubsection
Редактирование коммита в глубинах истории
\end_layout
\begin_layout Standard
Для редактирования коммита, совершённого на более ранних этапах следует
прибегнуть к команде rebase:
\end_layout
\begin_layout LyX-Code
git rebase bbc643cd^ --interactive --preserve-merges # редактировать коммит
bbc643cd
\end_layout
\begin_layout LyX-Code
# --preserve-merges - пытаться сохранять точки слияния во время
перестройки истории
\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 Standard
Также, в некоторых случаях бывает необходимо отредактировать самый первый
коммит (root-commit):
\end_layout
\begin_layout LyX-Code
git rebase -i -p --root # редактировать самый первый коммит
\end_layout
\begin_layout LyX-Code
mkdir tmp && mv * tmp # разобьём первый коммит на 2
\end_layout
\begin_layout LyX-Code
touch README && git add README # и добавим README-файл
\end_layout
\begin_layout LyX-Code
git commit -am
\begin_inset Quotes eld
\end_inset
Initial commit.
\begin_inset Quotes erd
\end_inset
\end_layout
\begin_layout LyX-Code
mv tmp/* .
&& rmdir tmp && git add .
# добавим то, что было прежде 1-ым коммитом
\end_layout
\begin_layout LyX-Code
git commit -m
\begin_inset Quotes eld
\end_inset
2nd commit.
\begin_inset Quotes erd
\end_inset
# во второй коммит.
\end_layout
\begin_layout Subsubsection
Выделение поддиректории в отдельный репозиторий
\end_layout
\begin_layout Standard
Информация взята со
\begin_inset CommandInset href
LatexCommand href
name "stackoverflow.com"
target "http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository"
\end_inset
.
\end_layout
\begin_layout Standard
Предположим, имеется репозиторий со структурой директорий
\end_layout
\begin_layout LyX-Code
XYZ/
\end_layout
\begin_deeper
\begin_layout LyX-Code
.git/
\end_layout
\begin_layout LyX-Code
XY1/
\end_layout
\begin_layout LyX-Code
ABC/
\end_layout
\begin_layout LyX-Code
XY2/
\end_layout
\end_deeper
\begin_layout Standard
и требуется его разбить на 2 репозитория, чтобы истории их не пересекались:
\end_layout
\begin_layout LyX-Code
XYZ/
\end_layout
\begin_deeper
\begin_layout LyX-Code
.git/
\end_layout
\begin_layout LyX-Code
XY1/
\end_layout
\begin_layout LyX-Code
XY2/
\end_layout
\end_deeper
\begin_layout LyX-Code
ABC/
\end_layout
\begin_deeper
\begin_layout LyX-Code
.git/
\end_layout
\begin_layout LyX-Code
ABC/
\end_layout
\end_deeper
\begin_layout Standard
Для этого воспользуемся командой filter-branch, изменяющей историю.
\end_layout
\begin_layout LyX-Code
git clone XYZ ABC # клонируем XYZ в ABC
\end_layout
\begin_layout LyX-Code
for branch in develop master; do git branch -t $branch origin/$branch; done
# интересующие
\end_layout
\begin_layout LyX-Code
# нас ветви
\end_layout
\begin_layout LyX-Code
git remote rm origin # удаляем ссылку на родительский репозиторий,
\end_layout
\begin_layout LyX-Code
# чтобы обезопасить себя от изменений
в нём
\end_layout
\begin_layout LyX-Code
git filter-branch --index-filter "git rm -r -f --cached --ignore-unmatch
XY1 XY2"
\backslash
\end_layout
\begin_layout LyX-Code
--prune-empty --tag-name-filter cat -- --all # удалить из истории дир-рии
XY1 и XY2,
\end_layout
\begin_layout LyX-Code
# оставив ABC
\end_layout
\begin_layout Standard
Аналогично создаётся репозиторий для XYZ
\end_layout
\begin_layout LyX-Code
git clone XYZ XYZ-new && cd XYZ-new
\end_layout
\begin_layout LyX-Code
for branch in develop master; do git branch -t $branch origin/$branch; done
\end_layout
\begin_layout LyX-Code
git remote rm origin
\end_layout
\begin_layout LyX-Code
git filter-branch --index-filter "git rm -r -f --cached --ignore-unmatch
ABC"
\backslash
\end_layout
\begin_layout LyX-Code
--prune-empty --tag-name-filter cat -- --all
\end_layout
\begin_layout Standard
По опциям команды filter-branch смотрите документацию (git help filter-branch).
\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 Subsection
Двоичный поиск ошибок
\end_layout
\begin_layout Standard
Выполняется командой bisect, пример:
\end_layout
\begin_layout LyX-Code
git bisect start
\end_layout
\begin_layout LyX-Code
git bisect bad # текущая ревизия плохая
\end_layout
\begin_layout LyX-Code
git bisect good v1.0.3 # в версии 1.0.3 проблема не наблюдалась
\end_layout
\begin_layout LyX-Code
...
\end_layout
\begin_layout LyX-Code
git bisect bad # пометить текущую ревизию как плохую
\end_layout
\begin_layout LyX-Code
git bisect good # пометить текущую ревизию как хорошую
\end_layout
\begin_layout LyX-Code
git bisect skip # пропустить текущую ревизию
\end_layout
\begin_layout LyX-Code
...
\end_layout
\begin_layout LyX-Code
git bisect reset # закончить двоичный поиск
\end_layout
\begin_layout Standard
Как только bisect нашёл источник ошибки - ревизию, в которой она была внесена,
для нахождения ошибки остаётся проанализировать изменения в одном текущем
коммите.
\end_layout
\begin_layout Standard
Дальнейшие действия зависят от вкусов/стиля разработки:
\end_layout
\begin_layout Itemize
ошибка может быть исправлена прямо в текущей ревизии и
\begin_inset Quotes eld
\end_inset
смержена
\begin_inset Quotes erd
\end_inset
в нужные ветви;
\end_layout
\begin_layout Itemize
может быть сделано ответвление от ветки develop или исправлено прямо в ней;
\end_layout
\begin_layout Itemize
может быть сделан хотфикс (hotfix) ответвлением от master с последующим
выпуском новой версии и слиянием исправлений в master и develop.
\end_layout
\begin_layout Subsection
cherry-pick - обмен коммитами между ветками
\end_layout
\begin_layout Standard
Команда cherry-pick позволяет скопировать определённые коммиты из одной
ветки в другую как если бы они были созданы изначально в ней.
Например:
\end_layout
\begin_layout LyX-Code
git cherry-pick master # скопирует последний коммит из master в текущую
ветвь
\end_layout
\begin_layout LyX-Code
git cherry-pick ..master # применить все коммиты из master, отсутствующие
в текущей ветке
\end_layout
\begin_layout LyX-Code
git cherry-pick master~4 master~2 # скопировать 2 коммита из master
\end_layout
\begin_layout LyX-Code
# (3-ий и 4-ый, начиная с головы)
\end_layout
\begin_layout LyX-Code
git cherry-pick -n master~1 next # применить предпоследний из master и
последний из next коммиты
\end_layout
\begin_layout LyX-Code
# к рабочей директории и индексу, не создавая
новой ревизии
\end_layout
\begin_layout LyX-Code
git cherry-pick --ff ..next # если история линейная и HEAD является
предшественником master,
\end_layout
\begin_layout LyX-Code
# обновить рабочую директорию и переустановить
HEAD на последний
\end_layout
\begin_layout LyX-Code
# коммит master, в противном случае -
скопировать все коммиты
\end_layout
\begin_layout LyX-Code
# из master
\end_layout
\begin_layout LyX-Code
git rev-list --reverse master -- README | git cherry-pick -n --stdin #
вывести хеши ревизий
\end_layout
\begin_layout LyX-Code
# в master, затрагивающие файл README и применить их одним коммитом
к текущей ветви
\end_layout
\begin_layout Subsection
Субрепозитории
\end_layout
\begin_layout Standard
Или так называемые Git submodules.
Применяются для включения одних проектов в другие или для создания суперпроекто
в.
При этом обновления в подпроектах не затрагивают основной проект до тех
пор, пока владелец проекта не захочет это сделать явно, убедившись, что
эти изменения оставляют проект в рабочем состоянии.
\end_layout
\begin_layout Standard
Создать Git submodule очень просто, например добавим в некоторый проект
my-project библиотеку my-lib:
\end_layout
\begin_layout LyX-Code
cd my-project
\end_layout
\begin_layout LyX-Code
git submodule add git@git.github.com:mynickname/my-lib.git
\end_layout
\begin_layout LyX-Code
git commit -m
\begin_inset Quotes eld
\end_inset
Added my-lib submodule.
\begin_inset Quotes erd
\end_inset
\end_layout
\begin_layout LyX-Code
git push
\end_layout
\begin_layout Standard
Команда
\end_layout
\begin_layout LyX-Code
git submodule update --init --recursive
\end_layout
\begin_layout Standard
рекурсивно обновляет всем субмодули, которые в свою очередь могут содержать
другие субмодули из origin remote.
Следует отметить, что после выполнения данной команды сурепозитории могут
оказаться в
\begin_inset Quotes eld
\end_inset
detached state
\begin_inset Quotes erd
\end_inset
, то есть не привязанными к какой-либо ветке.
\end_layout
\begin_layout Standard
Если требуется внести изменения в субрепозиторий, то это делается как и
с обычным проектом (edit, commit, push).
Важно отметить, что изменения в субрепозитории не влияют на главный репозиторий
до тех пор, пока в нём это явно не будет указано:
\end_layout
\begin_layout LyX-Code
git add my-lib
\end_layout
\begin_layout LyX-Code
git commit -m
\begin_inset Quotes eld
\end_inset
my-lib submodule updated.
\begin_inset Quotes erd
\end_inset
\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 80
\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
\begin_layout Section
Рекомендуемая литература
\end_layout
\begin_layout Enumerate
Документация на официальном сайте Git (англ.)
\begin_inset Flex URL
status open
\begin_layout Plain Layout
http://git-scm.com/documentation
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset Newpage pagebreak
\end_inset
\end_layout
\begin_layout Section
\start_of_appendix
Пример Git-конфигурации ~/.gitconfig
\end_layout
\begin_layout Standard
Приведём пример типичного файла конфигурации.
Все опции могут быть вписаны вручную, но могут быть заданы через команду
git config, например:
\end_layout
\begin_layout LyX-Code
git config --global user.email "you@example.com"
\end_layout
\begin_layout LyX-Code
git config --global user.name "Your Name"
\end_layout
\begin_layout Standard
Опция --global указывает, что настройки должны быть применены глобально,
а не только к текущему репозиторию.
\end_layout
\begin_layout Standard
Пример файла конфигурации, расположенного в домашней директории пользователя
~/.gitconfig:
\end_layout
\begin_layout LyX-Code
[user]
\end_layout
\begin_deeper
\begin_layout LyX-Code
email = vasya.pupkin@gmail.com
\end_layout
\begin_layout LyX-Code
name = Vasya P
\end_layout
\end_deeper
\begin_layout LyX-Code
[color]
\end_layout
\begin_deeper
\begin_layout LyX-Code
ui = auto
\end_layout
\begin_layout LyX-Code
branch = auto
\end_layout
\begin_layout LyX-Code
diff = auto
\end_layout
\begin_layout LyX-Code
status = auto
\end_layout
\end_deeper
\begin_layout LyX-Code
[color "branch"]
\end_layout
\begin_deeper
\begin_layout LyX-Code
current = yellow reverse
\end_layout
\begin_layout LyX-Code
local = yellow
\end_layout
\begin_layout LyX-Code
remote = green
\end_layout
\end_deeper
\begin_layout LyX-Code
[color "diff"]
\end_layout
\begin_deeper
\begin_layout LyX-Code
meta = yellow bold
\end_layout
\begin_layout LyX-Code
frag = magenta bold
\end_layout
\begin_layout LyX-Code
old = red bold
\end_layout
\begin_layout LyX-Code
new = green bold
\end_layout
\end_deeper
\begin_layout LyX-Code
[color "status"]
\end_layout
\begin_deeper
\begin_layout LyX-Code
added = yellow
\end_layout
\begin_layout LyX-Code
changed = green
\end_layout
\begin_layout LyX-Code
untracked = cyan
\end_layout
\end_deeper
\begin_layout LyX-Code
[alias]
\end_layout
\begin_deeper
\begin_layout LyX-Code
unstage = reset HEAD --
\end_layout
\begin_layout LyX-Code
st = status
\end_layout
\begin_layout LyX-Code
s = status -uno
\end_layout
\begin_layout LyX-Code
ci = commit
\end_layout
\begin_layout LyX-Code
di = diff -b
\end_layout
\begin_layout LyX-Code
co = checkout
\end_layout
\begin_layout LyX-Code
up = checkout
\end_layout
\begin_layout LyX-Code
update = checkout
\end_layout
\begin_layout LyX-Code
l = log
\end_layout
\begin_layout LyX-Code
hgrevert = checkout
\end_layout
\begin_layout LyX-Code
strip = reset --hard
\end_layout
\begin_layout LyX-Code
branches = branch -a
\end_layout
\begin_layout LyX-Code
pull = fetch
\end_layout
\end_deeper
\begin_layout LyX-Code
[instaweb]
\end_layout
\begin_deeper
\begin_layout LyX-Code
local = true
\end_layout
\begin_layout LyX-Code
httpd = lighttpd -f
\end_layout
\begin_layout LyX-Code
port = 4321
\end_layout
\begin_layout LyX-Code
browser = firefox
\end_layout
\end_deeper
\begin_layout LyX-Code
[merge]
\end_layout
\begin_deeper
\begin_layout LyX-Code
tool = vimdiff
\end_layout
\end_deeper
\begin_layout LyX-Code
[core]
\end_layout
\begin_deeper
\begin_layout LyX-Code
quotepath = false
\end_layout
\end_deeper
\begin_layout LyX-Code
[push]
\end_layout
\begin_deeper
\begin_layout LyX-Code
default = matching
\end_layout
\end_deeper
\begin_layout Standard
\end_layout
\end_body
\end_document