Каждый более-менее серьёзный программист пользуется системой контроля версий. Но мало кто осознаёт, что эту же систему можно применять не только для программирования, но и в любых других областях.
Данный материал предназначен для тех, кто не пользовался раньше системами контроля версий.
Что такое контроль версий?
Когда вы пишете код (на самом деле необязательно код, можно писать книги или даже музыку), то у вас естественным образом возникает несколько версий вашего продукта.
Эти версии выглядят обычно так:
- Документ.doc
- Документ1.doc
- Документ~~~2.doc
- Документ_правки-20221101.doc
и т.д.
У вас накапливается несколько разных версий одного проекта, которые обычно (если вы не человек железной воли) поименованы как попало.
Со временем становится трудно разобраться в том, где какая версия, что в них было, и т.д. Но что более страшно – вы можете легко перепутать файл и удалить не ту версию, или отредактировать не ту версию. Если вы внесли изменения в файл и сохранили его, то обратно эти изменения откатить уже нельзя.
Когда вы собираетесь внести в проект значительные изменения, то естественно становится страшно – а что, если всё сломается? Тогда вы вдобавок ко всему создаёте резервную копию проекта. А потом ещё одну. И начинаете путаться уже в них.
Постепенно вы теряете контроль над версиями. И тут на помощь должна прийти
Система контроля версий
Она позволяет вам избавиться от всей рутины и неразберихи, связанной с версиями файлов. Система гарантирует, что
- ничего не потеряется
- ничего не перепутается
- вы всегда можете вернуться к любой старой версии
- вы всегда можете отменить любые изменения в текущей версии
Таких систем несколько – CVS, SVN, Mercurial и т.д., но больше всего на слуху Git.
Все они устроены по одному принципу.
Ствол
Сдуру, как говорится, можно и кое-что сломать, поэтому никакая система контроля не сможет вас защитить от потери файлов, если вы не будете понимать, как она работает.
Работает она довольно просто и логично. У неё есть собственное хранилище файлов, куда вам лезть совершенно не нужно. В этом хранилище система сама ведёт учёт – какие файлы, когда и кем менялись.
Версия в понятиях системы это ветка. Первоначально есть одна ветка, которая называется главной, она же ствол дерева.
Вы можете начать с пустой ветки, или сразу загрузить туда те файлы, которые уже есть. Это первичное состояние, с которого вы начинаете работу.
Когда вы вносите правки в это первичное состояние, они накапливаются и отслеживаются системой. Вам не нужно переименовывать файлы, создавать резервные копии и т.д.
Вы всегда можете откатить любой из изменённых файлов к его первичному состоянию. Но что, если вы хотите вернуться не к первичному состоянию, а к тому прогрессу, который был сделан час назад?
Для этого – и это уже полностью ваша ответственность – прогресс надо фиксировать. Откатиться можно к любому состоянию, которое было зафиксировано ранее.
Акт фиксации называется "коммитом" (commit). Вы сообщаете системе: все правки, которые сделаны, нужно внести в ветку.
Система вносит правки, и на стволе дерева образуется новый "узел". Ствол как бы вырастает на один сегмент.
От этого узла вы продолжаете работу дальше. Теперь вы можете вернуться не только к исходному состоянию, но и к любому узлу (проще говоря – коммиту).
Ветки
Если у вас очень простой проект, вам достаточно время от времени просто фиксировать состояния в главной ветке.
Но обычно методология использования несколько другая.
Главная ветка считается главной потому, что в ней находится рабочая версия проекта, которая уже отлажена, которую можно взять и сразу использовать.
Если же вы будете делать коммиты в главную ветку в процессе работы каждый раз, чтобы зафиксировать состояние, то это состояние может ещё содержать какие-то ошибки. То есть в главную ветку попадёт нерабочая версия.
Как у дерева из ствола растут ветки, так же и вы создаёте в системе новую ветку, которая растёт из главной. Эта ветка – отдельная версия. В ней вы делаете все изменения.
Посмотрим на иллюстрацию:
Здесь есть главная ветка серого цвета под названием master. (Раньше главные ветки в Git назывались master, но это начало оскорблять негров, поэтому они теперь называются main.)
Мы видим, что в ветке master было сделано 4 коммита, а затем от последнего коммита были созданы 2 новые ветки. Одна синяя, которая называется add-clothes-shop, вторая жёлтая, которая называется add-waiting-room. В каждой из этих веток есть также по 2-3 коммита, но они пока не зафиксированы в главной.
Да, вы можете создать сколько угодно новых веток из любого узла главной ветки, а также создавать новые ветки из новых веток, и т.д.
Злоупотреблять этим, впрочем, не стоит, да практически никогда и не требуется.
Таким образом, вы можете вести разработку во всех параллельных ветках одновременно, если понадобится. В одной ветке делать одно, в другой другое и т.п. Основное преимущество здесь заключается в коллективной разработке, где у каждого участника может быть своя ветка.
Переключение
Вы всегда находитесь в одном из узлов дерева. Это может быть где угодно: в главной ветке, в какой-то другой ветке, в начале, в конце и т.д.
Соответственно, вы всегда имеете именно то состояние проекта, которое зафиксировано в этом узле.
Чтобы изменить состояние, нужно просто переключиться в другой узел. Вам не нужно копировать резервные файлы или менять папки, вы просто переключаете узел и получаете актуальное состояние. Очень удобно.
Слияние
Когда мы поработали с отдельной веткой и решили, что она достаточно стабильна, мы решаем зафиксировать изменения в главной ветке. Для этого текущую ветку нужно обратно слить с главной.
Слияние (merge) происходит по команде, система сама внесёт все необходимые изменения в главную ветку и конечно создаст при этом новый узел, так что мы ничего не потеряем из того, что было раньше.
Слияние ветки будет выглядеть так:
Здесь ветка зелёного цвета была начата из красной, в ней были сделаны два коммита, и далее она была слита обратно с красной.
Это не значит, что ветка после слияния закончилась. В ней можно продолжать делать коммиты и потом повторно сливать накопленные изменения. Или для новых изменений можно начинать новые ветки.
Дерево может выглядеть так:
Здесь видно, что из красной (главной) ветки начались одновременно зелёная и сиреневая. Затем сиреневая была слита с зелёной. Затем из зелёной несколько раз начинались сиреневые ветки (это всё новые ветки, просто одного цвета) и сливались обратно с зелёной. Но также один раз сиреневая была слита и с зелёной, и с красной. Далее из зелёной вместе с сиреневой стартовала ещё одна салатовая ветка и была слита назад в зелёную. Наконец, зелёная была слита с красной.
В результате все изменения из сиреневой, зелёной и салатовой веток попали в красную.
Обратите внимание, что у веток есть названия, а у каждого коммита есть комментарий. И названия, и комментарии придумываете вы сами, так что впоследствии вы можете разобраться, за что отвечает каждая ветка и в чём была суть коммита.
На иллюстрации показан довольно простой пример, но даже он может показаться какой-то сложной шахматной партией.
В целом вам не нужно ничего усложнять. Если вы работаете методом "сделал одну ветку, внёс изменения, слил", то этого в принципе хватит в 99% случаев.
Как это всё запустить?
При вроде бы хорошем потенциале идея может показаться трудноосуществимой из-за опасений "что это за Git", "там что, регистрироваться надо", "слишком сложно" и т.п.
Но нет, всё гораздо проще, чем кажется.
Конкретно про установку Git и его использование мы поговорим в следующий раз.
Читайте дальше:
