commonmarker 0.0.1 → 0.1.0

data/test/progit/ru/03-git-branching/01-chapter3.markdown

@@ -0,0 +1,598 @@
+# Ветвление в Git #
+
+Почти каждая СКВ имеет в какой-то форме поддержку ветвления. Ветвление означает, что вы отклоняетесь от основной линии разработки и продолжаете работу, не вмешиваясь в основную линию. Во многих СКВ это в некотором роде дорогостоящий процесс, зачастую требующий от вас создания новой копии каталога с исходным кодом, что может занять продолжительное время для больших проектов.
+
+Некоторые говорят, что модель ветвления Git'а это его “killer feature“ и она безусловно выделяет Git в СКВ-сообществе. Что же в ней такого особенного? Способ ветвления в Git'е чрезвычайно легковесен, что делает операции ветвления практически мгновенными и переключение туда-сюда между ветками обычно так же быстрым. В отличие от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние осуществляется часто, даже по несколько раз в день. Понимание и владение этой функциональностью даёт вам уникальный мощный инструмент и может буквально изменить то, как вы ведёте разработку.
+
+## Что такое ветка? ##
+
+Чтобы на самом деле разобраться в том, как Git работает с ветками, мы должны сделать шаг назад и рассмотреть, как Git хранит свои данные. Как вы, наверное, помните из главы 1, Git хранит данные не как последовательность изменений или дельт, а как последовательность снимков состояния (snapshot).
+
+Когда вы создаёте коммит в Git'е, Git записывает в базу объект-коммит, который содержит указатель на снимок состояния, записанный ранее в индекс, метаданные автора и комментария и ноль и более указателей на коммиты, являющиеся прямыми предками этого коммита: ноль предков для первого коммита, один — для обычного коммита и несколько — для коммита, полученного в результате слияния двух или более веток.
+
+Для наглядности давайте предположим, что у вас есть каталог, содержащий три файла, и вы хотите добавить их все в индекс и сделать коммит. При добавлении файлов в индекс для каждого из них вычислится контрольная сумма (SHA-1 хеш, о котором мы упоминали в главе 1), затем эти версии файлов будут сохранены в Git-репозиторий (Git обращается к ним как к двоичным данным), а их контрольные суммы добавятся в индекс:
+
+	$ git add README test.rb LICENSE
+	$ git commit -m 'initial commit of my project'
+
+Когда вы создаёте коммит, выполняя `git commit`, Git вычисляет контрольную сумму каждого подкаталога (в нашем случае только корневого каталога) и сохраняет эти объекты-деревья в Git-репозиторий. Затем Git создаёт объект для коммита, в котором есть метаданные и указатель на объект-дерево для корня проекта. Таким образом, Git сможет воссоздать текущее состояние, когда будет нужно.
+
+Ваш Git-репозиторий теперь содержит пять объектов: по одному блобу для содержимого каждого из трёх файлов, одно дерево, в котором перечислено содержимое каталога и определено соответствие имён файлов и блобов, и один коммит с указателем на тот самый объект-дерево для корня и со всеми метаданными коммита. Схематично данные в этом Git-репозитории выглядят так, как показано на рисунке 3-1.
+
+Insert 18333fig0301.png 
+Рисунок 3-1. Данные репозитория с единственным коммитом.
+
+Если вы сделаете некоторые изменения и создадите новый коммит, то следующий коммит сохранит указатель на коммит, который шёл непосредственно перед ним. После следующих двух коммитов история может выглядеть, как на рисунке 3-2.
+
+Insert 18333fig0302.png 
+Рисунок 3-2. Данные объектов Git'а для нескольких коммитов.
+
+Ветка в Git'е — это просто легковесный подвижный указатель на один из этих коммитов. Ветка по умолчанию в Git'е называется `master`. Когда вы создаёте коммиты на начальном этапе, вам дана ветка `master`, указывающая на последний сделанный коммит. При каждом новом коммите она сдвигается вперёд автоматически.
+
+Insert 18333fig0303.png 
+Рисунок 3-3. Ветка указывает на историю коммитов.
+
+Что произойдёт, если вы создадите новую ветку? Итак, этим вы создадите новый указатель, который можно будет перемещать. Скажем, создадим новую ветку под названием `testing`. Это делается командой `git branch`:
+
+	$ git branch testing
+
+Эта команда создаст новый указатель на тот самый коммит, на котором вы сейчас находитесь (см. рис. 3-4).
+
+Insert 18333fig0304.png 
+Рисунок 3-4. Несколько веток, указывающих на историю коммитов.
+
+Откуда Git узнает, на какой ветке вы находитесь в данный момент? Он хранит специальный указатель, который называется HEAD (верхушка). Учтите, что это сильно отличается от концепции HEAD в других СКВ, таких как Subversion или CVS, к которым вы, возможно, привыкли. В Git'е это указатель на локальную ветку, на которой вы находитесь. В данный момент вы всё ещё на ветке `master`. Команда `git branch` только создала новую ветку, она не переключила вас на неё (см. рис. 3-5).
+
+Insert 18333fig0305.png 
+Рисунок 3-5. Файл HEAD указывает на текущую ветку.
+
+Чтобы перейти на существующую ветку, вам надо выполнить команду `git checkout`. Давайте перейдём на новую ветку `testing`:
+
+	$ git checkout testing
+
+Это действие передвинет HEAD так, чтобы тот указывал на ветку `testing` (см. рис. 3-6).
+
+Insert 18333fig0306.png
+Рисунок 3-6. HEAD указывает на другую ветку после переключения веток.
+
+В чём же важность этого? Давайте сделаем ещё один коммит:
+
+	$ vim test.rb
+	$ git commit -a -m 'made a change'
+
+На рисунке 3-7 показан результат.
+
+Insert 18333fig0307.png 
+Рисунок 3-7. Ветка, на которую указывает HEAD, движется вперёд с каждым коммитом.
+
+Это интересно, потому что теперь ваша ветка `testing` передвинулась вперёд, но ветка `master` всё ещё указывает на коммит, на котором вы были, когда выполняли `git checkout`, чтобы переключить ветки. Давайте перейдём обратно на ветку `master`:
+
+	$ git checkout master
+
+На рисунке 3-8 можно увидеть результат.
+
+Insert 18333fig0308.png 
+Рисунок 3-8. HEAD перемещается на другую ветку при checkout'е.
+
+Эта команда выполнила два действия. Она передвинула указатель HEAD назад на ветку `master` и вернула файлы в вашем рабочем каталоге назад, в соответствие со снимком состояния, на который указывает `master`. Это также означает, что изменения, которые вы делаете, начиная с этого момента, будут ответвляться от старой версии проекта. Это, по сути, откатывает изменения, которые вы временно делали на ветке `testing`, так что дальше вы можете двигаться в другом направлении.
+
+Давайте снова внесём немного изменений и сделаем коммит:
+
+	$ vim test.rb
+	$ git commit -a -m 'made other changes'
+
+Теперь история вашего проекта разветвилась (см. рис. 3-9). Вы создали новую ветку, перешли на неё, поработали на ней немного, переключились обратно на основную ветку и выполнили другую работу. Оба эти изменения изолированы в отдельных ветках: вы можете переключаться туда и обратно между ветками и слить их, когда будете готовы. И всё это было сделано простыми командами `branch` и `checkout`.
+
+Insert 18333fig0309.png 
+Рисунок 3-9. История с разошедшимися ветками.
+
+Из-за того, что ветка в Git'е на самом деле является простым файлом, который содержит 40 символов контрольной суммы SHA-1 коммита, на который он указывает, создание и удаление веток практически беззатратно. Создание новой ветки настолько же быстрое и простое, как запись 41 байта в файл (40 символов + символ новой строки).
+
+Это разительно отличается от того, как в большинстве СКВ делается ветвление. Там это приводит к копированию всех файлов проекта в другой каталог. Это может занять несколько секунд или даже минут, в зависимости от размера проекта, тогда как в Git'е это всегда происходит моментально. Также благодаря тому, что мы запоминаем предков для каждого коммита, поиск нужной базовой версии для слияния уже автоматически выполнен за нас, и в общем случае слияние делается легко. Эти особенности помогают поощрять разработчиков к частому созданию и использованию веток.
+
+Давайте поймём, почему и вам стоит так делать.
+
+## Основы ветвления и слияния ##
+
+Давайте рассмотрим ветвление и слияние на простом примере с таким процессом работы, который вы могли бы использовать в настоящей разработке. Мы выполним следующие шаги:
+
+1. Поработаем над веб-сайтом.
+2. Создадим ветку для работы над новой задачей.
+3. Выполним некоторую работу на этой ветке.
+
+На этом этапе вам поступит звонок о том, что сейчас критична другая проблема, и её надо срочно решить. Мы сделаем следующее:
+
+1. Вернёмся на ветку для версии в производстве.
+2. Создадим ветку для исправления ошибки.
+3. После тестирования ветки с исправлением сольём её обратно и отправим в продакшн.
+4. Вернёмся к своей исходной задаче и продолжим работать над ней.
+
+### Основы ветвления ###
+
+Для начала представим, что вы работаете над своим проектом и уже имеете пару коммитов (см. рис. 3-10).
+
+Insert 18333fig0310.png 
+Рисунок 3-10. Короткая и простая история коммитов.
+
+Вы решили, что вы будете работать над проблемой №53 из системы отслеживания ошибок, используемой вашей компанией. Разумеется, Git не привязан к какой-то определенной системе отслеживания ошибок. Так как проблема №53 является обособленной задачей, над которой вы собираетесь работать, мы создадим новую ветку и будем работать на ней. Чтобы создать ветку и сразу же перейти на неё, вы можете выполнить команду `git checkout` с ключом `-b`:
+
+	$ git checkout -b iss53
+	Switched to a new branch "iss53"
+
+Это сокращение для:
+
+	$ git branch iss53
+	$ git checkout iss53
+
+Рисунок 3-11 демонстрирует результат.
+
+Insert 18333fig0311.png 
+Рисунок 3-11. Создание новой ветки / указателя.
+
+Во время работы над своим веб-сайтом вы делаете несколько коммитов. Эти действия сдвигают ветку `iss53` вперёд потому, что вы на неё перешли (то есть ваш HEAD указывает на неё; см. рис. 3-12):
+
+	$ vim index.html
+	$ git commit -a -m 'added a new footer [issue 53]'
+
+Insert 18333fig0312.png 
+Рисунок 3-12. Ветка iss53 передвинулась вперёд во время работы.
+
+Теперь вы получаете звонок о том, что есть проблема с веб-сайтом, которую необходимо немедленно устранить. С Git'ом вам нет нужды делать исправления для неё поверх тех изменений, которые вы уже сделали в `iss53`, и нет необходимости прикладывать много усилий для отмены этих изменений перед тем, как вы сможете начать работать над решением срочной проблемы. Всё, что вам нужно сделать, это перейти на ветку `master`.
+
+Однако, прежде чем сделать это, учтите, что если в вашем рабочем каталоге или индексе имеются незафиксированные изменения, которые конфликтуют с веткой, на которую вы переходите, Git не позволит переключить ветки. Лучше всего при переключении веток иметь чистое рабочее состояние. Существует несколько способов добиться этого (а именно, прятанье (stash) работы и правка (amend) коммита), которые мы рассмотрим позже. А на данный момент представим, что все изменения были добавлены в коммит, и теперь вы можете переключиться обратно на ветку `master`:
+
+	$ git checkout master
+	Switched to branch "master"
+
+Теперь рабочий каталог проекта находится точно в таком же состоянии, что и в момент начала работы над проблемой №53, так что вы можете сконцентрироваться на исправлении срочной проблемы. Очень важно запомнить: Git возвращает ваш рабочий каталог к снимку состояния того коммита, на который указывает ветка, на которую вы переходите. Он добавляет, удаляет и изменяет файлы автоматически, чтобы гарантировать, что состояние вашей рабочей копии идентично последнему коммиту на ветке.
+
+Итак, вам надо срочно исправить ошибку. Давайте создадим для этого ветку, на которой вы будете работать (см. рис. 3-13):
+
+	$ git checkout -b hotfix
+	Switched to a new branch "hotfix"
+	$ vim index.html
+	$ git commit -a -m 'fixed the broken email address'
+	[hotfix]: created 3a0874c: "fixed the broken email address"
+	 1 files changed, 0 insertions(+), 1 deletions(-)
+
+Insert 18333fig0313.png 
+Рисунок 3-13. Ветка для решения срочной проблемы базируется на ветке master.
+
+Вы можете запустить тесты, убедиться, что решение работает, и слить (merge) изменения назад в ветку `master`, чтобы включить их в продукт. Это делается с помощью команды `git merge`:
+
+	$ git checkout master
+	$ git merge hotfix
+	Updating f42c576..3a0874c
+	Fast forward
+	 README |    1 -
+	 1 files changed, 0 insertions(+), 1 deletions(-)
+
+Наверное, вы заметили фразу "Fast forward" в этом слиянии. Так как ветка, которую мы слили, указывала на коммит, являющийся прямым родителем коммита, на котором мы сейчас находимся, Git просто сдвинул её указатель вперёд. Иными словами, когда вы пытаетесь слить один коммит с другим таким, которого можно достигнуть, проследовав по истории первого коммита, Git поступает проще, перемещая указатель вперёд, так как нет расходящихся изменений, которые нужно было бы сливать воедино. Это называется "перемотка" (fast forward).
+
+Ваши изменения теперь в снимке состояния коммита, на который указывает ветка `master`, и вы можете включить изменения в продукт (см. рис. 3-14).
+
+Insert 18333fig0314.png 
+Рисунок 3-14. После слияния ветка master указывает туда же, куда и ветка hotfix.
+
+После того как очень важная проблема решена, вы готовы вернуться обратно к тому, над чем вы работали перед тем, как вас прервали. Однако, сначала удалите ветку `hotfix`, так как она больше не нужна — ветка `master` уже указывает на то же место. Вы можете удалить ветку с помощью опции `-d` к `git branch`:
+
+	$ git branch -d hotfix
+	Deleted branch hotfix (3a0874c).
+
+Теперь вы можете вернуться обратно к рабочей ветке для проблемы №53 и продолжить работать над ней (см. рис. 3-15):
+
+	$ git checkout iss53
+	Switched to branch "iss53"
+	$ vim index.html
+	$ git commit -a -m 'finished the new footer [issue 53]'
+	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+Insert 18333fig0315.png 
+Рисунок 3-15. Ветка iss53 может двигаться вперёд независимо.
+
+Стоит напомнить, что работа, сделанная на ветке `hotfix`, не включена в файлы на ветке `iss53`. Если вам это необходимо, вы можете слить ветку `master` в ветку `iss53` посредством команды `git merge master`. Или же вы можете подождать с интеграцией изменений до тех пор, пока не решите включить изменения на `iss53` в продуктовую ветку `master`.
+
+### Основы слияния ###
+
+Допустим, вы разобрались с проблемой №53 и готовы объединить эту ветку и свой `master`. Чтобы сделать это, мы сольём ветку `iss53` в ветку `master` точно так же, как мы делали это ранее с веткой `hotfix`. Всё, что вам нужно сделать, — перейти на ту ветку, в которую вы хотите слить свои изменения, и выполнить команду `git merge`:
+
+	$ git checkout master
+	$ git merge iss53
+	Merge made by recursive.
+	 README |    1 +
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+Это слияние немного отличается от слияния, сделанного ранее для ветки `hotfix`. В данном случае история разработки разделилась в некоторой точке. Так как коммит на той ветке, на которой вы находитесь, не является прямым предком для ветки, которую вы сливаете, Git'у придётся проделать кое-какую работу. В этом случае Git делает простое трёхходовое слияние, используя при этом те два снимка состояния репозитория, на которые указывают вершины веток, и общий для этих двух веток снимок-прародитель. На рисунке 3-16 выделены три снимка состояния, которые Git будет использовать для слияния в данном случае.
+
+Insert 18333fig0316.png
+Рисунок 3-16. Git автоматически определяет наилучшего общего предка для слияния веток.
+
+Вместо того чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый снимок состояния, который является результатом трёхходового слияния, и автоматически создаёт новый коммит, который указывает на этот новый снимок состояния (см. рис. 3-17). Такой коммит называют коммит-слияние, так как он является особенным из-за того, что имеет больше одного предка.
+
+Стоит отметить, что Git сам определяет наилучшего общего предка для слияния веток; в CVS или Subversion (версии ранее 1.5) этого не происходит. Разработчик должен сам указать основу для слияния. Это делает слияние в Git'е гораздо более простым занятием, чем в других системах.
+
+Insert 18333fig0317.png
+Рисунок 3-17. Git автоматически создаёт новый коммит, содержащий результаты слияния.
+
+Теперь, когда вы осуществили слияние ваших наработок, ветка `iss53` вам больше не нужна. Можете удалить её и затем вручную закрыть карточку (ticket) в своей системе:
+
+	$ git branch -d iss53
+
+### Основы конфликтов при слиянии ###
+
+Иногда процесс слияния не идёт гладко. Если вы изменили одну и ту же часть файла по-разному в двух ветках, которые собираетесь слить, Git не сможет сделать это чисто. Если ваше решение проблемы №53 изменяет ту же часть файла, что и `hotfix`, вы получите конфликт слияния, и выглядеть он будет примерно так:
+
+	$ git merge iss53
+	Auto-merging index.html
+	CONFLICT (content): Merge conflict in index.html
+	Automatic merge failed; fix conflicts and then commit the result.
+
+Git не создал новый коммит для слияния. Он приостановил этот процесс до тех пор, пока вы не разрешите конфликт. Если вы хотите посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), выполните команду `git status`:
+
+	[master*]$ git status
+	index.html: needs merge
+	# On branch master
+	# Changes not staged for commit:
+	#   (use "git add <file>..." to update what will be committed)
+	#   (use "git checkout -- <file>..." to discard changes in working directory)
+	#
+	#	unmerged:   index.html
+	#
+
+Всё, что имеет отношение к конфликту слияния и что не было разрешено, отмечено как unmerged. Git добавляет стандартные маркеры к файлам, которые имеют конфликт, так что вы можете открыть их вручную и разрешить эти конфликты. Ваш файл содержит секцию, которая выглядит примерно так:
+
+	<<<<<<< HEAD:index.html
+	<div id="footer">contact : email.support@github.com</div>
+	=======
+	<div id="footer">
+	  please contact us at support@github.com
+	</div>
+	>>>>>>> iss53:index.html
+
+В верхней части блока (всё что выше `=======`) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё, что находится в нижней части — версия в `iss53`. Чтобы разрешить конфликт, вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Например, вы можете разрешить этот конфликт заменой всего блока, показанного выше, следующим блоком:
+
+	<div id="footer">
+	please contact us at email.support@github.com
+	</div>
+
+Это решение содержит понемногу из каждой части, и я полностью удалил строки `<<<<<<<`, `=======` и `>>>>>>>`. После того как вы разобрались с каждой из таких секций в каждом из конфликтных файлов, выполните `git add` для каждого конфликтного файла. Индексирование будет означать для Git'а, что все конфликты в файле теперь разрешены.
+Если вы хотите использовать графические инструменты для разрешения конфликтов, можете выполнить команду `git mergetool`, которая запустит соответствующий графический инструмент и покажет конфликтные ситуации:
+
+	$ git mergetool
+	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
+	Merging the files: index.html
+
+	Normal merge conflict for 'index.html':
+	  {local}: modified
+	  {remote}: modified
+	Hit return to start merge resolution tool (opendiff):
+
+Если вы хотите использовать другой инструмент для слияния, нежели выбираемый по умолчанию (Git выбрал `opendiff` для меня, так как я выполнил команду на Mac'е). Вы можете увидеть все поддерживаемые инструменты, указанные выше после “merge tool candidates”. Укажите название предпочтительного для вас инструмента. В главе 7 мы обсудим, как изменить это значение по умолчанию для вашего окружения.
+
+После того как вы выйдете из инструмента для выполнения слияния, Git спросит вас, было ли оно успешным. Если вы отвечаете, что да — файл индексируется (добавляется в область для коммита), чтобы дать вам понять, что конфликт разрешён.
+
+Можете выполнить `git status` ещё раз, чтобы убедиться, что все конфликты были разрешены:
+
+	$ git status
+	# On branch master
+	# Changes to be committed:
+	#   (use "git reset HEAD <file>..." to unstage)
+	#
+	#	modified:   index.html
+	#
+
+Если вы довольны тем, что получили, и удостоверились, что всё, имевшее конфликты, было проиндексировано, можете выполнить `git commit` для завершения слияния. По умолчанию сообщение коммита будет выглядеть примерно так:
+
+	Merge branch 'iss53'
+
+	Conflicts:
+	  index.html
+	#
+	# It looks like you may be committing a MERGE.
+	# If this is not correct, please remove the file
+	# .git/MERGE_HEAD
+	# and try again.
+	#
+
+Вы можете дополнить это сообщение информацией о том, как вы разрешили конфликт, если считаете, что это может быть полезно для других в будущем. Например, можете указать почему вы сделали то, что сделали, если это не очевидно, конечно.
+
+## Управление ветками ##
+
+Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.
+
+Команда `git branch` делает несколько больше, чем просто создаёт и удаляет ветки. Если вы выполните её без аргументов, то получите простой список имеющихся у вас веток:
+
+	$ git branch
+	  iss53
+	* master
+	  testing
+
+Обратите внимание на символ `*`, стоящий перед веткой `master`: он указывает на ветку, на которой вы находитесь в настоящий момент. Это означает, что если вы сейчас выполните коммит, ветка `master` переместится вперёд в соответствии с вашими последними изменениями. Чтобы посмотреть последний коммит на каждой из веток, выполните команду `git branch -v`:
+
+	$ git branch -v
+	  iss53   93b412c fix javascript issue
+	* master  7a98805 Merge branch 'iss53'
+	  testing 782fd34 add scott to the author list in the readmes
+
+Ещё одна полезная возможность для выяснения состояния веток состоит в том, чтобы оставить в этом списке только те ветки, которые вы слили (или не слили) в ветку, на которой сейчас находитесь. Для этих целей в Git'е есть опции `--merged` и `--no-merged`. Чтобы посмотреть те ветки, которые вы уже слили с текущей, можете выполнить команду `git branch --merged`:
+
+	$ git branch --merged
+	  iss53
+	* master
+
+Из-за того что мы ранее слили `iss53`, мы видим её в этом списке. Те ветки из этого списка, перед которыми нет символа `*`, можно смело удалять командой `git branch -d`; вы уже включили наработки из этих веток в другую ветку, так что вы ничего не потеряете.
+
+Чтобы увидеть все ветки, содержащие наработки, которые вы пока ещё не слили в текущую ветку, выполните команду `git branch --no-merged`:
+
+	$ git branch --no-merged
+	  testing
+
+Вы увидите оставшуюся ветку. Так как она содержит ещё не слитые наработки, попытка удалить её командой `git branch -d` не увенчается успехом:
+
+	$ git branch -d testing
+	error: The branch 'testing' is not an ancestor of your current HEAD.
+	If you are sure you want to delete it, run 'git branch -D testing'.
+
+Если вы действительно хотите удалить ветку и потерять наработки, вы можете сделать это при помощи опции `-D`, как указано в подсказке.
+
+## Приёмы работы с ветками ##
+
+Теперь, когда вы познакомились с основами ветвления и слияния, что вам делать с ветками дальше? В этом разделе мы рассмотрим некоторые стандартные приёмы работы, которые становятся возможными благодаря лёгкости осуществления ветвления. И вы сможете выбрать, включить ли вам какие-то из них в свой цикл разработки.
+
+### Долгоживущие ветки ###
+
+Так как Git использует простое трёхходовое слияние, периодически сливать одну ветку с другой на протяжении большого промежутка времени достаточно просто. Это значит, вы можете иметь несколько веток, которые всегда открыты и которые вы используете для разных стадий вашего цикла разработки; вы можете регулярно сливать их одну в другую.
+
+Многие разработчики Git'а придерживаются такого подхода, при котором ветка `master` содержит исключительно стабильный код — единственный выпускаемый код. Для разработки и тестирования используется параллельная ветка, называемая `develop` или `next`, она может не быть стабильной постоянно, но в стабильные моменты её можно слить в `master`. Эта ветка используется для объединения завершённых задач из тематических веток (временных веток наподобие `iss53`), чтобы удостовериться, что эти изменения проходят все тесты и не вызывают ошибок.
+
+В действительности же, мы говорим об указателях, передвигающихся вверх по линии коммитов, которые вы делаете. Стабильные ветки далеко внизу линии вашей истории коммитов, наиболее свежие ветки находятся ближе к верхушке этой линии (см. рис. 3-18).
+
+Insert 18333fig0318.png 
+Рисунок 3-18. Более стабильные ветки, как правило, находятся дальше в истории коммитов.
+
+В общем, об этом проще думать как о силосных башнях, где набор коммитов переходит в более стабильную башню только тогда, когда он полностью протестирован (см. рис. 3-19).
+
+Insert 18333fig0319.png 
+Рисунок 3-19. Может быть полезным думать о ветках как о силосных башнях.
+
+Вы можете применять эту идею для нескольких разных уровней стабильности. Некоторые большие проекты также имеют ветку `proposed` или `pu` (proposed updates — предлагаемые изменения), которые включают в себя ветки, не готовые для перехода в ветку `next` или `master`. Идея такова, что ваши ветки находятся на разных уровнях стабильности; когда они достигают более высокого уровня стабильности, они сливаются с веткой, стоящей на более высоком уровне.
+Опять-таки, иметь долгоживущие ветки не обязательно, но зачастую это полезно, особенно когда вы имеете дело с очень большими и сложными проектами.
+
+### Тематические ветки ###
+
+Тематические ветки, однако, полезны в проектах любого размера. Тематическая ветка — недолговечная ветка, которую вы создаёте и используете для работы над некоторой отдельной функциональностью или для вспомогательной работы. Это то, чего вы, вероятно, никогда не делали с системами контроля версий раньше, так как создание и слияние веток обычно слишком затратно. Но в Git'е принято создавать ветки, работать над ними, сливать и удалять их по несколько раз в день.
+
+Мы видели подобное в последнем разделе, где вы создавали ветки `iss53` и `hotfix`. Вы сделали всего несколько коммитов на этих ветках и удалили их сразу же после слияния с основной веткой. Такая техника позволяет быстро и полноценно переключать контекст. Ибо когда все изменения разбиты по веткам и определённым темам, намного проще понять, что было сделано, во время проверки и просмотра кода. Вы можете сохранить там изменения на несколько минут, дней или месяцев, а затем, когда они готовы, слить их в основную ветку, независимо от порядка, в котором их создавали или работали над ними.
+
+Рассмотрим пример, когда при выполнении некоторой работы в ветке `master`, делается новая ветка для решения некой проблемы (`iss91`), выполняется немного работы на ней, от неё ответвляется ещё одна ветка для другого пути решения той же задачи (`iss91v2`), потом осуществляется переход назад на основную ветку (`master`), и некоторое время работа ведётся на ней, затем делается ответвление от неё для выполнения чего-то, в чём вы не уверены, что это хорошая идея (ветка `dumbidea`). Ваша история коммитов будет выглядеть примерно так как на рисунке 3-20.
+
+Insert 18333fig0320.png 
+Рисунок 3-20. История коммитов с несколькими тематическими ветками.
+
+Теперь представим, вы решили, что вам больше нравится второе решение для вашей задачи (`iss91v2`); и вы показываете ветку `dumbidea` вашим коллегам и оказывается, что она просто гениальна. Так что вы можете выбросить оригинальную ветку `iss91` (теряя при этом коммиты C5 и C6) и слить две другие. Тогда ваша история будет выглядеть как на рисунке 3-21.
+
+Insert 18333fig0321.png 
+Рисунок 3-21. Ваша история после слияния dumbidea и iss91v2.
+
+Важно запомнить, что когда вы выполняете все эти действия, ветки являются полностью локальными. Когда вы выполняете ветвление и слияние, всё происходит только в вашем репозитории — связь с сервером не осуществляется.
+
+## Удалённые ветки ##
+
+Удалённые ветки — это ссылки на состояние веток в ваших удалённых репозиториях. Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
+
+Они выглядят как `(имя удал. репоз.)/(ветка)`. Например, если вы хотите посмотреть, как выглядела ветка `master` на сервере `origin` во время последнего соединения с ним, проверьте ветку `origin/master`. Если вы с партнёром работали над одной проблемой, и он выложил ветку `iss53`, у вас может быть своя локальная ветка `iss53`; но та ветка на сервере будет указывать на коммит в `origin/iss53`.
+
+Всё это, возможно, сбивает с толку, поэтому давайте рассмотрим пример. Скажем, у вас в сети есть свой Git-сервер на `git.ourcompany.com`. Если вы с него что-то склонируете (clone), Git автоматически назовёт его `origin`, заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка `master`, и назовёт его локально `origin/master` (но вы не можете его двигать). Git также сделает вам вашу собственную ветку `master`, которая будет начинаться там же, где и ветка `master` в origin, так что вам будет с чем работать (см. рис. 3-22).
+
+Insert 18333fig0322.png 
+Рисунок 3-22. Клонирование Git-проекта даёт вам собственную ветку master и origin/master, указывающий на ветку master в origin.
+
+Если вы сделаете что-то в своей локальной ветке `master`, а тем временем кто-то ещё отправит (push) изменения на `git.ourcompany.com` и обновит там ветку `master`, то ваши истории продолжатся по-разному. Ещё, до тех пор, пока вы не свяжетесь с сервером origin, ваш указатель `origin/master` не будет сдвигаться (см. рис. 3-23).
+
+Insert 18333fig0323.png 
+Рисунок 3-23. При выполнении локальной работы и отправке кем-то изменений на удалённый сервер каждая история продолжается по-разному.
+
+Для синхронизации вашей работы выполняется команда `git fetch origin`. Эта команда ищет, какому серверу соответствует origin (в нашем случае это `git.ourcompany.com`); извлекает оттуда все данные, которых у вас ещё нет, и обновляет ваше локальное хранилище данных; сдвигает указатель `origin/master` на новую позицию (см. рис. 3-24).
+
+Insert 18333fig0324.png 
+Рисунок 3-24. Команда git fetch обновляет ваши удалённые ссылки.
+
+Чтобы продемонстрировать то, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на `git.team1.ourcompany.com`. Вы можете добавить его в качестве новой удалённой ссылки на проект, над которым вы сейчас работаете с помощью команды `git remote add` так же, как было описано в главе 2. Дайте этому удалённому серверу имя `teamone`, которое будет сокращением для полного URL (см. рис. 3-25).
+
+Insert 18333fig0325.png 
+Рисунок 3-25. Добавление дополнительного удалённого сервера.
+
+Теперь можете выполнить `git fetch teamone`, чтобы извлечь всё, что есть на сервере и нет у вас. Так как в данный момент на этом сервере есть только часть данных, которые есть на сервере `origin`, Git не получает никаких данных, но выставляет удалённую ветку с именем `teamone/master`, которая указывает на тот же коммит, что и ветка `master` на сервере `teamone` (см. рис. 3-26).
+
+Insert 18333fig0326.png 
+Рисунок 3-26. У вас появилась локальная ссылка на ветку master на teamone-е.
+
+### Отправка изменений ###
+
+Когда вы хотите поделиться веткой с окружающими, вам необходимо отправить (push) её на удалённый сервер, на котором у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными серверами — вам нужно явно отправить те ветки, которыми вы хотите поделиться. Таким образом, вы можете использовать свои личные ветки для работы, которую вы не хотите показывать, и отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.
+
+Если у вас есть ветка `serverfix`, над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните `git push (удал. сервер) (ветка)`:
+
+	$ git push origin serverfix
+	Counting objects: 20, done.
+	Compressing objects: 100% (14/14), done.
+	Writing objects: 100% (15/15), 1.74 KiB, done.
+	Total 15 (delta 5), reused 0 (delta 0)
+	To git@github.com:schacon/simplegit.git
+	 * [new branch]      serverfix -> serverfix
+
+Это в некотором роде сокращение. Git автоматически разворачивает имя ветки `serverfix` до `refs/heads/serverfix:refs/heads/serverfix`, что означает “возьми мою локальную ветку serverfix и обнови из неё удалённую ветку serverfix”. Мы подробно обсудим часть с `refs/heads/` в главе 9, но обычно её можно опустить. Вы также можете выполнить `git push origin serverfix:serverfix` — произойдёт то же самое — здесь говорится “возьми мой serverfix и сделай его удалённым serverfix”. Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы ветка называлась `serverfix` на удалённом сервере, то вместо предыдущей команды выполните `git push origin serverfix:awesomebranch`. Так ваша локальная ветка `serverfix` отправится в ветку `awesomebranch` удалённого проекта.
+
+В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает `serverfix` на сервере, как удалённую ветку `origin/serverfix`:
+
+	$ git fetch origin
+	remote: Counting objects: 20, done.
+	remote: Compressing objects: 100% (14/14), done.
+	remote: Total 15 (delta 5), reused 0 (delta 0)
+	Unpacking objects: 100% (15/15), done.
+	From git@github.com:schacon/simplegit
+	 * [new branch]      serverfix    -> origin/serverfix
+
+Важно отметить, что когда при получении данных у вас появляются новые удалённые ветки, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку `serverfix` — только указатель `origin/serverfix`, который вы не можете менять.
+
+Чтобы слить эти наработки в свою текущую рабочую ветку, выполните `git merge origin/serverfix`. Если вам нужна своя собственная ветка `serverfix`, над которой вы сможете работать, то вы можете создать её на основе удалённой ветки:
+
+	$ git checkout -b serverfix origin/serverfix
+	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
+	Switched to a new branch "serverfix"
+
+Это даст вам локальную ветку, на которой можно работать. Она будет начинаться там, где и `origin/serverfix`.
+
+### Отслеживание веток ###
+
+Получение локальной ветки с помощью `git checkout` из удалённой ветки автоматически создаёт то, что называется _отслеживаемой веткой_. Отслеживаемые ветки — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на отслеживаемой ветке, вы наберёте `git push`, Git уже будет знать, на какой сервер и в какую ветку отправлять изменения. Аналогично выполнение `git pull` на одной из таких веток сначала получает все удалённые ссылки, а затем автоматически делает слияние с соответствующей удалённой веткой.
+
+При клонировании репозитория, как правило, автоматически создаётся ветка `master`, которая отслеживает `origin/master`, поэтому `git push` и `git pull` работают для этой ветки "из коробки" и не требуют дополнительных аргументов. Однако, вы можете настроить отслеживание и других веток удалённого репозитория. Простой пример, как это сделать, вы увидели только что — `git checkout -b [ветка] [удал. сервер]/[ветка]`. Если вы используете Git версии 1.6.2 или более позднюю, можете также воспользоваться сокращением `--track`:
+
+	$ git checkout --track origin/serverfix
+	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
+	Switched to a new branch "serverfix"
+
+Чтобы настроить локальную ветку с именем, отличным от имени удалённой ветки, вы можете легко использовать первую версию с другим именем локальной ветки:
+
+	$ git checkout -b sf origin/serverfix
+	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
+	Switched to a new branch "sf"
+
+Теперь ваша локальная ветка sf будет автоматически отправлять (push) и получать (pull) изменения из origin/serverfix.
+
+### Удаление веток на удалённом сервере ###
+
+Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку `master` на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере, используя несколько бестолковый синтаксис `git push [удал. сервер] :[ветка]`. Чтобы удалить ветку `serverfix` на сервере, выполните следующее:
+
+	$ git push origin :serverfix
+	To git@github.com:schacon/simplegit.git
+	 - [deleted]         serverfix
+
+Хлоп. Нет больше ветки на вашем сервере. Вам может захотеться сделать закладку на текущей странице, так как эта команда вам понадобится, а синтаксис вы, скорее всего, забудете. Можно запомнить эту команду вернувшись к синтаксису `git push [удал. сервер] [лок. ветка]:[удал. ветка]`, который мы рассматривали немного раньше. Опуская часть `[лок. ветка]`, вы, по сути, говорите “возьми ничто в моём репозитории и сделай так, чтобы в `[удал. ветка]` было то же самое”.
+
+## Перемещение ##
+
+В Git'е есть два способа включить изменения из одной ветки в другую: `merge` (слияние) и `rebase` (перемещение). В этом разделе вы узнаете, что такое перемещение, как его осуществлять, почему это удивительный инструмент и в каких случаях вам не следует его использовать.
+
+### Основы перемещения ###
+
+Если мы вернёмся назад к одному из ранних примеров из раздела про слияние (см. рис. 3-27), увидим, что мы разделили свою работу на два направления и сделали коммиты на двух разных ветках.
+
+Insert 18333fig0327.png
+Рисунок 3-27. Впервые разделенная история коммитов.
+
+Наиболее простое решение для объединения веток, как мы уже выяснили, команда `merge`. Эта команда выполняет трёхходовое слияние между двумя последними снимками состояний из веток (C3 и C4) и последним общим предком этих двух веток (C2), создавая новый снимок состояния (и коммит), как показано на рисунке 3-28.
+
+Insert 18333fig0328.png
+Рисунок 3-28. Слияние ветки для объединения разделившейся истории разработки.
+
+Однако, есть и другой путь: вы можете взять изменения, представленные в C3, и применить их поверх C4. В Git'е это называется _перемещение_ (rebasing). При помощи команды `rebase` вы можете взять все изменения, которые попали в коммиты на одной из веток, и повторить их на другой.
+
+Для этого примера надо выполнить следующее:
+
+	$ git checkout experiment
+	$ git rebase master
+	First, rewinding head to replay your work on top of it...
+	Applying: added staged command
+
+Перемещение работает следующим образом: находится общий предок для двух веток (на которой вы находитесь сейчас и на которую вы выполняете перемещение); для каждого из коммитов в текущей ветке берётся его дельта и сохраняется во временный файл; текущая ветка устанавливается на тот же коммит, что и ветка, на которую выполняется перемещение; и, наконец, одно за другим применяются все изменения. Рисунок 3-29 иллюстрирует этот процесс.
+
+Insert 18333fig0329.png
+Рисунок 3-29. Перемещение изменений, сделанных в C3, на C4.
+
+На этом этапе можно переключиться на ветку `master` и выполнить слияние-перемотку (fast-forward merge) (см. рис. 3-30).
+
+Insert 18333fig0330.png
+Рисунок 3-30. Перемотка ветки master.
+
+Теперь снимок состояния, на который указывает C3', точно такой же, как тот, на который указывал C5 в примере со слиянием. Нет никакой разницы в конечном результате объединения, но перемещение выполняется для того, чтобы история была более аккуратной. Если вы посмотрите лог для перемещённой ветки, то увидите, что он выглядит как линейная история работы: выходит, что вся работа выполнялась последовательно, когда в действительности она выполнялась параллельно.
+
+Часто вы будете делать это, чтобы удостовериться, что ваши коммиты правильно применяются для удалённых веток — возможно для проекта, владельцем которого вы не являетесь, но в который вы хотите внести свой вклад. В этом случае вы будете выполнять работу в какой-нибудь ветке, а затем, когда будете готовы внести свои изменения в основной проект, выполните перемещение вашей работы на `origin/master`. Таким образом, владельцу проекта не придётся делать никаких действий по объединению — просто перемотка (fast-forward) или чистое применение патчей.
+
+Заметьте, что снимок состояния, на который указывает последний коммит, который у вас получился, является ли этот коммит последним перемещённым коммитом (для случая выполнения перемещения) или итоговым коммитом слияния (для случая выполнения слияния), есть один и тот же снимок — разной будет только история. Перемещение применяет изменения из одной линии разработки в другую в том порядке, в котором они были представлены, тогда как слияние объединяет вместе конечные точки двух веток.
+
+### Более интересные перемещения ###
+
+Можно также сделать так, чтобы при перемещении воспроизведение коммитов начиналось не от той ветки, на которую делается перемещение. Возьмём, например, историю разработки как на рис. 3-31. Вы создали тематическую ветку (`server`), чтобы добавить в проект некоторый функционал для серверной части, и сделали коммит. Затем вы выполнили ответвление, чтобы сделать изменения для клиентской части, и несколько раз выполнили коммиты. Наконец, вы вернулись на ветку `server` и сделали ещё несколько коммитов.
+
+Insert 18333fig0331.png
+Рисунок 3-31. История разработки с тематической веткой, ответвлённой от другой тематической ветки.
+
+Предположим, вы решили, что хотите внести свои изменения для клиентской части в основную линию разработки для релиза, но при этом хотите оставить в стороне изменения для серверной части, пока они не будут полностью протестированы. Вы можете взять изменения из ветки `client`, которых нет в `server` (C8 и C9), и применить их на ветке `master` при помощи опции `--onto` команды `git rebase`:
+
+	$ git rebase --onto master server client
+
+По сути, это указание “переключиться на ветку `client`, взять изменения от общего предка веток `client` и `server` и повторить их на `master`”. Это немного сложно; но результат, показанный на рисунке 3-32, довольно классный.
+
+Insert 18333fig0332.png
+Рисунок 3-32. Перемещение тематической ветки, ответвлённой от другой тематической ветки.
+
+Теперь вы можете выполнить перемотку (fast-forward) для ветки `master` (см. рис. 3-33):
+
+	$ git checkout master
+	$ git merge client
+
+Insert 18333fig0333.png
+Рисунок 3-33. Перемотка ветки master для добавления изменений из ветки client.
+
+Представим, что вы решили включить работу и из ветки `server` тоже. Вы можете выполнить перемещение ветки `server` на ветку `master` без предварительного переключения на эту ветку при помощи команды `git rebase [осн. ветка] [тем. ветка]` — которая устанавливает тематическую ветку (в данном случае `server`) как текущую и применяет её изменения на основной ветке (`master`):
+
+	$ git rebase master server
+
+Эта команда применит изменения из вашей работы над веткой `server` на вершину ветки `master`, как показано на рисунке 3-34.
+
+Insert 18333fig0334.png
+Рисунок 3-34. Перемещение ветки server на вершину ветки master.
+
+Затем вы можете выполнить перемотку основной ветки (`master`):
+
+	$ git checkout master
+	$ git merge server
+
+Вы можете удалить ветки `client` и `server`, так как вся работа из них включена в основную линию разработки и они вам больше не нужны. При этом полная история вашего рабочего процесса выглядит как на рисунке 3-35:
+
+	$ git branch -d client
+	$ git branch -d server
+
+Insert 18333fig0335.png
+Рисунок 3-35. Финальная история коммитов.
+
+### Возможные риски перемещения ###
+
+Всё бы хорошо, но кое-что омрачает всю прелесть использования перемещения. Это выражается одной строчкой:
+
+**Не перемещайте коммиты, которые вы уже отправили в публичный репозиторий.**
+
+Если вы будете следовать этому указанию, всё будет хорошо. Если нет — люди возненавидят вас, вас будут презирать ваши друзья и семья.
+
+Когда вы что-то перемещаете, вы отменяете существующие коммиты и создаёте новые, которые похожи на старые, но являются другими. Если вы выкладываете (push) свои коммиты куда-нибудь, и другие забирают (pull) их себе и в дальнейшем основывают на них свою работу, а затем вы переделываете эти коммиты командой `git rebase` и выкладываете их снова, ваши коллеги будут вынуждены заново выполнять слияние для своих наработок. В итоге вы получите путаницу, когда в очередной раз попытаетесь включить их работу в свою.
+
+Давайте рассмотрим пример того, как перемещение публично доступных наработок может вызвать проблемы. Представьте себе, что вы склонировали себе репозиторий с центрального сервера и поработали в нём. И ваша история коммитов выглядит как на рисунке 3-36.
+
+Insert 18333fig0336.png
+Рисунок 3-36. Клонирование репозитория и выполнение в нём какой-то работы.
+
+Теперь кто-то ещё выполняет работу, причём работа включает в себя и слияние, и отправляет свои изменения на центральный сервер. Вы извлекаете их и сливаете новую удалённую ветку со своей работой. Тогда ваша история выглядит как на рисунке 3-37.
+
+Insert 18333fig0337.png
+Рисунок 3-37. Извлечение коммитов и слияние их со своей работой.
+
+Далее, человек, выложивший коммит, содержащий слияние, решает вернуться и вместо слияния (merge) переместить (rebase) свою работу; он выполняет `git push --force`, чтобы переписать историю на сервере. Затем вы извлекаете изменения с этого сервера, включая и новые коммиты.
+
+Insert 18333fig0338.png
+Рисунок 3-38. Кто-то выложил перемещённые коммиты, отменяя коммиты, на которых вы основывали свою работу.
+
+На этом этапе вы вынуждены объединить эту работу со своей снова, даже если вы уже сделали это ранее. Перемещение изменяет у этих коммитов SHA-1 хеши, так что для Git'а они выглядят как новые коммиты, тогда как на самом деле вы уже располагаете наработками из C4 в своей истории (см. рис. 3-39).
+
+Insert 18333fig0339.png
+Рисунок 3-39. Вы снова выполняете слияние для той же самой работы в новый коммит слияния.
+
+Вы вынуждены объединить эту работу со своей на каком-либо этапе, чтобы иметь возможность продолжать работать с другими разработчиками в будущем. После того, как вы сделаете это, ваша история коммитов будет содержать оба коммита — C4 и C4', которые имеют разные SHA-1 хеши, но представляют собой одинаковые изменения и имеют одинаковые сообщения. Если вы выполните команду `git log`, когда ваша история выглядит таким образом, вы увидите два коммита, которые имеют одинакового автора и одни и те же сообщения. Это сбивает с толку. Более того, если вы отправите такую историю обратно на сервер, вы добавите все эти перемещенные коммиты в репозиторий центрального сервера, что может ещё больше запутать людей.
+
+Если вы рассматриваете перемещение как возможность наведения порядка и работы с коммитами до того, как выложили их, и если вы перемещаете только коммиты, которые никогда не находились в публичном доступе — всё нормально. Если вы перемещаете коммиты, которые уже были представлены для общего доступа, и люди, возможно, основывали свою работу на этих коммитах, тогда вы можете получить наказание за разные неприятные проблемы.
+
+## Итоги ##
+
+Мы рассмотрели основы ветвления и слияния в Git'е. Теперь вы должны чувствовать себя уверенно при создании и переходе на новые ветки, переключении между ветками и слиянии локальных веток. А также вы должны уметь делиться своими ветками, выкладывая их на общий сервер, работать с другими людьми над общими ветками и перемещать свои ветки, пока они не представлены для общего доступа.