Системы контроля версий

— Привет, Амиго!

— Привет!

— Сегодня я расскажу тебе о системах контроля версий.

Как ты уже, наверное, знаешь, программы часто бывают очень большими и пишутся очень долго. Иногда десятки человек могут писать программу годами.

Проекты с миллионом строк кода – это реальность.

— Ничего себе.

— Это все очень сложно. Люди часто мешают друг другу, часто меняют один и тот же код и т.д. и т.п.

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

Система контроля версий – это программа, представленная в виде клиента и сервера.

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

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

— А можно больше подробностей. Как это все работает?

— Вот представь, что ты – программист и хочешь внести небольшие изменения в исходный код программы, который хранится в репозитории (хранилище) на сервере.

Для этого тебе надо:

1) Залогиниться на сервер (Login).

2) Скопировать последнюю версию всех файлов к себе на компьютер – команда Checkout.

3) Внести изменения в нужные файлы.

4) Запустить программу локально и проверить, что она компилируется и работает.

5) Отправить свои «изменения» на сервер – команда Commit.

— В общем ясно.

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

Тебе же надо работать с последней актуальной версией данных. Тогда ты выполняешь команду Update.

— А в чем ее отличие от Checkout?

— Checkout предназначена для копирования всех файлов репозитория, а команда Update – только для тех файлов, которые обновились на сервере, со времен последней твоей команды Checkout/Update.

Вот как примерно это работает:

Checkout:

Теперь допустим, мы изменили файл B и хотим залить его на сервер. Для этого надо использовать команду Commit:

А вот как работает команда Update:

— Как интересно. А есть еще команды?

— Да, и довольно много. Но они могут быть разные в зависимости от того, какую именно программу контроля версий ты выберешь. Поэтому я стараюсь рассказывать только общие принципы.

Есть еще такая операция, как мэрджинг – объединение двух документов. Допустим, два программиста одновременно меняли один и тот же файл. Тогда программа на сервер не даст обоим его закоммитить. Кто первый – тот и прав.

— А что делать второму?

Второму предложат сделать Update, чтобы забрать к себе последние изменения с сервера. Это кстати хороший стиль – перед коммитом делать Update

Затем, во время исполнения операции Update, программа-клиент попробует объединить локальные изменения с изменениями, полученными с сервера.

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

Такое часто случается, когда например, оба программиста добавили что-то в конец файла.

— Ясно. Разумно, в общем.

— И еще одна вещь – ветки.

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

— Что же делать?

— Для этого в репозиторий добавили ветки (branches). Т.е. грубо говоря – разделили репозиторий на две части. Но не по файлам или директориям, а по версиям.

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

Такой путь – это и есть альтернативная ветка истории.

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

— Ну, так вроде понятнее.

А почему нельзя было просто сказать, что мы скопировали репозиторий?

— Это не есть копирование в чистом виде.

Такие ветки можно не только отделять от ствола (trunk), но и присоединять к нему.

— Т.е. можно какую-то работу выполнить в ветке, а когда она будет закончена – добавить репозиторий-ветку к репозиторию-стволу?

— Ага.

— И что при этом станет с файлами?

— Файлы смерджатся (объединятся).

— Ну, звучит круто, надеюсь так же круто и работает.

— А то. Ладно, давай делать перерыв.

Вот тут очень много полезной информации.