Проблема резервных копий

Представьте себе, что у вас есть некоторый большой проект. Вы его пишите в какой-то момент достигаете некоторой логической завершенности и выкатываете версию 1.0, которой начинают пользоваться юзеры.

Работа, однако, на этом не заканчивается и вы выкатываете версию 1.1 с исправлением ошибок и дополнениями, потом версию 1.2, потом 1.3, а потом все переписываете заново и объявляете о выходе версии 2.0. Ну и так далее - работа над проектом обычно никогда не заканчивается.

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

Однако, вдруг оказалось, что нельзя просто взять и выкатить версию 2.0, потому что пользователи первой версии возмущаются - они пока не готовы переходить на вторую. Окей, говорите вы, и начинаете работать над второй версией, параллельно выпуская обновления в первую. Ваш проект распадается на две папки - для первой версии и для второй. Также распадается папка для резервного копирования. При этом часть кода первой и второй версии одинаковы. Внося правки в этот код в одной версии проекта, вы должны не забыть внести правки и в другой версии. Вы, однако, иногда забываете это сделать. Появляются странные баги. Работа стоит.

В процессе над версией 2.0 вы решили добавить новую фичу. Однако, делать ее долго и вы решаете разбить вторую версию на две папки, сдублировав код. В первой папке вы будете вести дальнейшую разработку над вашим проектом, а во второй делать придуманную фичу. Наконец, фича доделана. За это время основной проект стал уже версией 2.3. Теперь вам нужно слить код с фичей с основным кодом проекта. Вы начинаете копировать файлы с кодом в основую папку, попутно разруливая конфликты нового кода и старого. Это отнимает у вас три рабочих дня. Работа стоит.

Проект вырос. Вы решаете позвать на помощь друга. Вы выдаете другу задание и присылаете ему архив с проектом. Друг делает задание и возвращает вам архив с новыми файлами, а также со старыми, в которые он внес изменения. Полдня вы тратите на то, чтобы отделить новые файлы от старых. Затем еще день вы тратите на то, чтобы интегрировать изменения в свои файлы.

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

В папке с резервными копиями уже содержатся гигабайты кода. При этом в основном там лежат дубли, ведь поменяв небольшую часть кода, вы все равно сбрасываете весь проект целиком. Вы решаете почистить эту папку, удалив первые сто версий. Через неделю оказывается, что в удаленных версиях был код отдельной фичи, от которой вы тогда отказались, а теперь решили вернуть. Но код с этой фичей уже удален, и его нигде нет. Вы пишите эту фичу заново. Работа стоит.

Звучит не очень, да? Однако, разработчики действительно раньше работали так, как я выше описал. Это, конечно же, было очень неудобно. Поэтому появилась специальная система Git, о возможностях которой мы поговорим в следующем уроке.