Введение в Git, или «Зачем при разработке нужен контроль версий?»

Что такое Git и что такое «система контроля версий»?
Как Git упростит вам жизнь? И, наконец, как Git избавит вас от страданий при разработке в команде?
Обо всём этом поговорим в данной статье.

Сразу поясню для тех, кто будет критиковать мой материал: статья не претендует на звание полного руководства по использованию Git. Всё, что здесь написано является лишь моим мнением и моим видением ситуации и не претендует на то, чтобы называться истиной.

Ну, а теперь приступим.

История первая

Представим, что некий Вася разрабатывает несомненно крутую и интересную онлайн-стрелялку на bgt.
Вася создал папку где-то на компьютере, в неё положил основной файл сервера, папку includes, а в неё положил ещё 25 файлов с бесспорно очень полезными классами и функциями.
Далее Вася некоторое время разрабатывает сервер и периодически делает резервные копии всей папки с сервером, чтобы, если что-то пойдёт не так, просто вернуться к предыдущей версии, подсмотреть, как было раньше, и что изменилось.
Разработка идёт бодрыми темпами и через полгода у Васи есть, допустим, 50 папок с названиями вроде «Cool-game-server_20.05.2020».
Выглядит уже ужасно и безумно.
Но мы пойдём дальше.
Допустим, Вася понимает, что в коде, отвечающем за класс игрока, возникла ошибка, которой раньше ну 100% не было.
Вася знает, что ошибки точно не было в версии сервера от 20.05.2020, а сейчас актуальной считается версия от 01.12.2020.
Вася последовательно открывает файл с классом игрока в каждой версии и выписывает (или запоминает) все изменения, произошедшие с файлом.
Это довольно легко, если в файле не больше 50 строчек. А если класс игрока уже вырос до 500 строк… Или до 1000?
Вася психует, нервничает, вдохновение пропадает, Вася бежит в аптеку за успокоительным, разработка стоит.

История вторая

Теперь представим, что Вася подружился с неким Петей, который оказался ну очень крутым программистом (конечно же не круче, чем Вася, но тоже неплохим).
И Петя хочет помочь Васе в разработке.
Теперь им вдвоём приходится работать над одним и тем же кодом.
На каком-нибудь облаке создаётся общая папка… Это в лучшем случае. В худшем оба гениальных программиста перекидываются отдельными файлами в мессенджерах.
Вася вносит изменения, звонит Пете и предупреждает об этом.
Петя вносит свои изменения и опять предупреждает об этом…
И всё идёт гладко до тех пор, пока Вася и Петя не начинают одновременно редактировать один и тот же файл…
Пытаются его сохранить…
И получают конфликт в облаке.
Катастрофа! Чьи изменения сохранились, непонятно. Что делать и как восстановить написанный в течение дня код… Тоже непонятно.
Вася и Петя ругаются, ссорятся, разработка опять стоит. Пользователи недовольны.

Магия контроля версий

И тут на помощь им приходит Git.
Для начала разберемся, что такое система контроля версий и почему именно Git?

Система контроля версий — это такое программное решение (утилита, программа, называйте как хотите), которое позволяет хранить историю всех изменений исходного кода, возвращаться к любой записи в истории и сравнивать различные точки в истории изменений.
На самом деле они умеют ещё больше, но это вне рамок данной статьи.

Почему Git?
Во-первых, я работал только с Git, и могу рассуждать только о нём. Во-вторых, насколько я знаю, альтернатива Git, система контроля версий SVN, мало что умеет локально, без подключения к интернету, а это не всегда удобно, особенно для начинающих.

Итак, Git или просто гит (чтобы не переключаться слишком часто на английскую раскладку).

История первая, но с участием гит

Вася разрабатывает игру и сразу помещает её исходники в систему контроля версий.
Вася также создал папку, в ней ещё папки и файлы, но всё это уже под надзором гит.
Разрабатывая сервер, Вася постоянно фиксирует любые значимые изменения в системе контроля версий, пишет корректные и понятные комментарии к каждой фиксации изменений.
Через полгода у Васи есть всё так же одна папка с сервером, которая занимает на диске явно меньше, чем занимали бы 50 резервных копий исходников.
Вася находит баг в классе игрока и понимает, что бага не было примерно 20 мая 2020 года (на улице сейчас первое декабря 2020 года).
Вася даёт команду системе контроля версий: «Покажи мне историю всех изменений файла player.bgt с 20 мая до 1 декабря.»
Вася видит всю историю изменений по файлу: какие строки и в каких местах удалялись, а в каких — добавлялись; какие к этому всему добавлены комментарии.
Вася читает всё это, находит баг, радостно его исправляет, фиксирует изменения под гордым комментарием «Багфикс!» и выкатывает пользователям новую версию сервера, уже без бага.
Хеппиенд во всём его великолепии!

История вторая, магия гит творит чудеса

Вася и Петя договорились вместе делать крутую игру и оба умеют пользоваться гит.
Вася, как владелец игры, создаёт репозиторий для исходников где-нибудь на популярном сервисе (я лично знаю только github и bitbucket), разрешает Пете читать и писать в этом репозитории, и оба гения приступают к разработке.
Вася вносит изменения и отправляет их в общий репозиторий.
Петя после тяжелого дня садится за компьютер, даёт команду «проверь есть ли в общем репозитории изменения и скачай мне их», и начинает работать над самой новой версией кода.
Закончив работу, он отправляет изменения в репозиторий.
А на следующий день Вася и Петя вместе начинают работать над исходниками и одновременно пытаются отправить свои изменения в общий репозиторий.
Один из них получает такое сообщение: «Там в репозитории что-то есть, и оно более новое, чем у тебя. Ты сначала лучше скачай последнюю версию, а затем что-то делай».
Но у Васи (или Пети, это кому не повезло), уже есть свои, локальные правки, которые терять было бы обидно.
Но делать нечего и он даёт команду на скачивание изменений.
Гит, как умная система, понимает, что внесены изменения в один и тот же файл.
Если изменения друг друга не затрагивают, то гит сам, по своим алгоритмам «слепляет» две версии файла в одну, как будто изменения внёс один человек последовательно.
Если же у гит возникают сомнения, он помечает файл как конфликтный и вставляет в него маркер, показывающий, где и какие изменения вызвали конфликт.
Задача Васи (или Пети) устранить конфликт, зафиксировать изменения и отправить их в общий репозиторий.
Немножко сложнее, чем первая ситуация, но всё тоже заканчивается хеппиендом.

Заключение

Думаю, что описанные ситуации знакомы многим, кто начинал разработку своего проекта, не зная о контроле версий.

Система контроля версий вносит некий порядок в историю разработки, позволяет в любой момент вернуться к любому моменту в истории и посмотреть, как было там и как стало здесь.
Позволяет большой команде совместно работать над проектом и не перекидываться файлами и папками каждую минуту.

Я считаю, что гит это хорошо и вообще мастхэв для каждого уважающего себя, своё время и свои нервы разработчика, даже начинающего.

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

Введение в Git, или «Зачем при разработке нужен контроль версий?»: 4 комментария

Добавить комментарий