Начало с Git и история геймдевера. Часть 1. Что такое Git и как работает?

Здравствуйте! Как и обещал, вот серия статей о Git. В этой части мы поговорим о том, что такое система управления версиями и о Git в частности и почему он необходим любому разработчику (и не только ему, но об этом попозже) так что варите себе чайку, мы идём в мир систем контроля версий...

Что такое система управления версиями?

Перед тем, как мы начнем изучение Git, мы сначала должны узнать что это такое. Git, конечно, не единственная система управления версиями, есть и другие. Но что это в общем?

Система управления версиями (или СУВ) - это система, которая позволяет вам сохранять все изменения в проекте, откатываться до одного маленького изменения, который вы сделали ещё месяц назад, не трогая изменения, которые были совершены после него. Также СУВ позволяет очень удобно работать в команде, даже без необходимости сидеть в одном офисе.

Как работает Git?

Обычно, Git сравнивают с деревом. Ну, это логично, учитывая что в Git есть ветки, которые исходят от других веток. Но ветки деревьев не могут сливаться и вообще яблоки не особо похожи на коммиты.

1) Давайте представим, что у вас есть какой-то проект - например, игра. Вы её разрабатываете, дорабатываете и исправляете баги. Вы создали репозиторий* с проектом и начали записывать изменения в нем.

*Репозиторий - это сама папка с проектом, в котором хранится все файлы, конфигурация Git, все коммиты и т.д. и т.п.

2) Теперь вы начали изменять проект и, например, добавили возможность сохранения игры в XML файл. Как это зафиксировать? Создать коммит* (commit) конечно!

*Коммит - это как сохранение в играх. Он фиксирует изменения в ветке.

Представим это изменение как кружок на нашей диаграмме:

Стрелками мы обозначаем движение (ну или рост) нашей ветки.

3) Так, вы выпустили стабильную версию своей игры. Теперь вы ловите и лечите баги для следующего релиза и вам приходит гениальная мысль добавления возможности кастомизации персонажа. Но вы не хотите портить стабильную версию, да ещё и с уже вылеченными багами. Что же делать? Создать новую ветку*

Ветки - это различные вариации одного и того же проекта, но со своими коммитами и историей, не касающиеся основной или любой другой ветки.

Принято называть и использовать ветки вот так:

1. master - основная ветка, в которой как раз и выкатываются все стабильные релизы и доработанные фичи.
2. dev или development - ветка, в которой ведется основная работа и изменения - баг фиксы, добавление новых фич, исправление недочетов - которые в последствие перейдут в ветку master и выйдут в свет... или не выйдут. (для маленьких проектов можно делать баг фиксы и в master ветке, но тогда следует ставить теги* в местах релизов)
3. feature/*** или dev/*** - эти ветки исходят** из ветки dev. В них ведется работа над добавлением новый фич или больших баг фиксов, которые следует выделить в отдельную ветку.

Для работы над новой фичей создадим новую ветку - dev. В диаграмме для удобства покрасим эту ветку в красный цвет. Вот так это будет выглядеть:

4) Теперь представим, что вы нашли критический баг в вашей программе, который надо срочно передать всем остальным веткам. Для этого используется так называемое действие merge*

Merge или Слияние - это слияние коммитов веток.

Слияние идёт только в одну сторону. Это удобно, если нам надо перенести баг фиксы из master в dev не перенося фичу из dev в master.

Вот так это будет выглядеть:

Теперь в ветке dev есть не только хот баг фикс, но и другие коммиты, предшествующие этому.

На этом первая часть окончена, а в следующей мы поговорим о таких вещах как rebase как альтернатива merge, удаленные и локальные репозитории, а также работе в команде. Спасибо за внимание!