§ Зачем нужны системы управления версиями

Представьте себе такую ситуацию. Вы — программист, верстальщик, копирайтер, студент или профессор — не имеет значения, но вы храните на своём жестком диске те материалы, с которыми работаете. Далее я буду рассказывать от лица программиста, потому что я сам программист, и как бы я видел ту или иную ситуацию.
Вот, мы пишем код и доводим этот код до того состояния, что он начал работать как полагается. Что нам остается сделать? Конечно же, мы показали его заказчику. Он остался доволен и все счастливы.
Спустя время заказчик, в процессе использования великолепной программы, которую мы написали, говорит что надо доработать по некоторым пунктам, но это неточно. В процессе бурной беседы, выясняется, что он просто предположил, что надо бы это сделать, а если не заработает, то вернем как было.
Какой у нас остается вариант? Первое, что приходит в голову — это скопировать весь код в другую папку, назвать ее версия 1 и начать доделывать новую версию. Если код небольшой, то такое копирование займет не очень много места. А что если он большой? Это еще полбеды. Что, если после каждой доработки придется постоянно и постоянно копировать код в новые папки. В итоге, на диске у нас 50 папок с почти что одинаковым кодом в них. И это неудобно, потому что это мало что занимает места, так еще и неизвестно, что именно там было изменено с предыдущей версии до следующей, какие файлы были затронуты и что именно там было изменено. Конечно, можно дополнительно держать отдельный файл для записи таких данных, но вести вручную его не будет представляться никакой возможности, эта работа будет слишком трудной и кропотливой.
И вот как раз для решения этой проблемы и были придуманы так называемые системы управления версиями (versioning control).

§ Командная работа

А теперь еще усложним и без того непростую ситуацию. Можно заметить, какие сложности уже возникают при работе с версиями у одного человека. А что, если будет два, три, десять, пятьдесят? Каждый будет вести собственные папки с версиями, в которых будет очень легко запутаться.
Представим ситуацию. Есть заказчик и два программиста. Один занимается своей частью кода, другой - своей. Один из программистов свою часть закончил допустим, а второй - нет. Тогда первый программист стал заниматься другой версией кода, при этом он скопировал в папку куда-нибудь свои изменения. Когда второй программист закончил свою часть, они решают объединить код... И вот тут начинается веселье, сопряженное с багами.
Первый программист еще не доделал свой второй код, а второй говорит, что надо объединить с его предыдущей версией... И что тогда? Первый программист отсылает весь свой код по email второму, а второй пытается догадаться, где поменялись файлы, и какие именно файлы поменялись, чтобы не затереть их. В процессе огромного трудоемкого процесса сравнения, он, наконец, объединяет код и отсылает копию кода первого программисту.
А первый программист, приняв версию от второго, пытается уже объединить этот код со своими последними изменениями и тратит кучу времени, чтобы понять, что изменилось с предыдущего раза так, чтобы свой текущий код не поломать. И будет большой удачей, если он будет внимательно все делать, а не ночью или в пять утра, когда голова вообще не работает.
Сложно даже представить, что будет, если таким вот образом будет работать команда из тридцати человек! В итоге, это будет не написание кода, а бесконечный ад, который закончится только тем, что фирма разорится и уйдет с рынка.
Поэтому, будучи проблемой, ее постарались решить и создали множество вариантов систем управления версиями, которые решали какие-то свои определенные задачи с переменным успехом. Кое-какие системы ушли в прошлое, какие-то остались актуальными. Самой известной из них является Git и SVN, хотя, существуют еще и другие системы.