GIT за 100 минут. Ветвление и управление ветками

Добро пожаловать на третий урок нашего миникурса git за 100 минут

На прошлом занятии мы рассмотрели, как управлять git-ом, добавлять файл в репозиторий, удалять файл из репозитория, откатываться к нужному коммиту. Научились настраивать git, и подошли к самому важному и полезному уроку, без которого управление git-ом не было бы таким замечательным. Это ветвление и управление ветками.

Когда вы создаете какой-либо коммит (первый, второй – неважно), у вас создается некая последовательность коммитов, которую условно можно представить в виде линии. Чем больше коммитов вы делаете, тем длиннее эта линия становится.

Здесь необходимо понять один момент. У всех, кроме первого коммита, есть запись в базе (внутри самого git-а), где указывается «родитель», то есть, у коммита №2 – «родитель» коммит №1. У коммита №3 «родитель» коммит №2. У первого коммита родителя нет, потому что он первый. В БД gita содержатся так называемые «записи», в которых есть сам коммит, его родитель, автор, имейл и т.д; ссылка на еще одну запись в базе, где описывается структура каталога. Если у нас 3 файла, то у нас 5 записей: по одной записи на каждый файл, одна запись на дерево (на структуру нашей папки) и одна запись – коммит, в котором прописан родитель и автор. Но сейчас важно, что у каждого коммита есть «родитель» (кроме первого). Бывает так, что у коммита есть несколько родителей. Происходит это случае, когда коммит является следствием слияния нескольких веток. У вас есть несколько веток, они сливаются в один коммит. Чуть дальше мы более подробно про эту тему поговорим, а сейчас о ветках.

Когда вы только установили git, запустили его, инициализировали в папки, коммиты по умолчанию создаются в ветке «master» (в вашей основной ветке), которая по умолчанию создается, когда вы инициализируете репозиторий. В этой ветке вы совершаете некие действия. Каждый раз, когда вы создаете новый коммит, так называемый заголовок, маркер [head] перемещается дальше по коммитам. [head] находится на самом последнем коммите, который у вас сейчас есть. Сначала был на первом, потом переместился на второй, потом на третий. Все это в рамках одной ветки «master».

Бывает так, что появляется необходимость провести некие изменения в сделанной вами копии. Например, нужно что-то резко пофиксить. Представим живой пример – сайт. Вы делаете сайт. Вы его выпустили. В верхней ветке мастера находится production версия, то бишь чистый код, для публикации на сайте, он уже готов и оттестирован. С каждым новым коммитом вы добавляете в ваш оттестированный рабочий код что-то новое. Потом публикуете в интернете. То есть, это ваш гарантированно рабочий сайт, production версия. Потом выясняется, что на вашем сайте есть какой-то баг, который вам надо подправить. При этом вы работаете над четвертым коммитом, то есть готовите еще одну запись, программируете, что-то дорабатываете. Тут вам звонит клиент и говорит: «У вас баг на сайте». Что вам надо делать. В простом варианте вы бы сохранили работу в том состоянии, в котором она есть. Вернулись бы к старому back-up-у в папочке (предположим, мы не используем СКВ), начали бы в нем что-нибудь делать, забыв про комит 4. И в итоге работа бы немножко тормознулась. Что позволяет сделать git? Git создает еще одну ветку. Веток может быть неограниченное количество. То есть мы пока находимся на этом коммите. Делаем ветку bugfix- фиксим баг. Git создает ответвление от текущего снапшота. То есть, после того, как вы создали ветку, ничего не произошло. У вас просто появился bugfix, который как и мастер, ссылается на снапшот. Ветка – передвижной указатель. Сейчас на третий коммит указывают две ветки: master и bugfix. Как только вы начнете делать коммиты, находясь в ветке bugfix, они пойдут отдельно, будут идти отдельной веткой. Эти изменения останутся незатронутыми. То бишь, мы создали новую ветку bugfix. Она еще находится в рамках текущего снапшота, текущего коммита. Без изменений. Вы внесли изменения. Что-то подправили на сайте, исправили какой-то баг (допустим не работает форма), закоммители, он появился в новой ветке.

Бывает такое: Вы правите баг, а ваш сотрудник работает над CSS, продолжает комментить в мастер ветке. Получается, у вас разделение. Вы пока фиксите баги на отдельной ветке, совершенно не мешая работать с production версией другому вашему сотруднику. Например, у вас есть верстальщик и программист. Вы программист. У вас появился баг. Вы сделали отдельную ветку и начали фиксить баг. При этом в production версии, в мастере продолжает вести работы верстальщик, а вы продолжаете чинить фиксы (исправлять все баги на сайте). Когда вы все сделали, оттестировали, убедились, что сайт исправлен, вы можете сделать слияние, то бишь слить две ветки в одну. Git – система очень умная, она возьмет и все соединения соединит, если у вас нет каких-либо конфликтов, которые мы рассмотрим.

Если в С5 (ветка master) и С4 (ветка bugfix) правился один и тот же кусок – например, в подвале менялся копирайт, то при слиянии у вас будет конфликт, который нужно вручную исправить. Но если правились разные места (например, CSS и PHP файлы), это все одна большая директория проекта. В конце мы просто это сольем. Файлы добавятся нужными кусками, где-то что-то запишется, добавится, что-то уберется. У вас в итоге в ветке «master» сольются все изменения, и вы сможете дальше заниматься production веткой. То бишь, ветвление в git позволяет решать какие-то сторонние задачи, что-то изменять и при этом не мешать друг другу работать.

Один из самых больших плюсов ветвления, то что вы можете создавать таких веток огромное количество, хоть с самой первой. У вас есть, например, master ветка, которая будет являться production. Вы сразу с первым коммитом создаете ветку develop, где у вас находятся все ваши разработки. Коммитете ее, коммитете. Делаете ваши разработки, периодически сливая ее с продакшеном. Сделали, оттестировали, залили в продакшен. Таким образом, у вас в ветке master всегда будет чистый, аккуратный, готовый к публикации исходный код. Притом, у вас может быть ветка develop. От нее ветка fix. От мастера еще может ответвляться ветка hotfix (срочные изменения). Таких веток может быть огромное количество. Они могут сливаться, изменяться. Представляем себе ветку на дереве. То же самое происходит и в git-е.

Давайте пройдем по всем веткам поэтапно, по всем слайдам в процессе работы. Итак, для начала нам необходимо создать несколько коммитов перед тем, как мы начнем ветвление.

Возвращаемся уже в знакомую рабочую машину. В папке «work» уже появился сайт. Там лежит новый git репозиторий, в котором кроме инициализации еще ничего не происходило. Первое, что мы сделаем – посмотрим get status, чтобы разобраться, что у нас происходит в данный момент.

Полностью курс по Git можно скачать здесь.