Контроль версий — мегаполезная вещь, когда речь идёт о программировании в команде. Сегодня покажем, что это и как примерно пользоваться.
Зачем нужна система контроля версий
Допустим, у нас есть программист Вася, который пишет весь код у себя на компьютере. Вася — продвинутый программист, поэтому перед каждым большим изменением делает полную резервную копию всего кода. Так он не боится что-то поломать: всегда можно откатиться на предыдущую версию. Резервные копии он хранит на отдельной флешке. Если сгорит компьютер, флешка останется.
Скоро Вася понимает, что следить за изменениями в коде сложно: он не помнит, что менялось от версии к версии. Вася записывает изменения в блокнот, но это скоро перестаёт работать: блокнот не видит конкретные куски программы и не может показать, в каких конкретно местах что поменялось.
Через пару месяцев с блокнотом Вася понимает: надо что-то менять. Он идёт в интернет и читает статью про системы контроля версий (СКВ).
Что это такое
Системы контроля версий — это штуки, которые помогают разработчикам ориентироваться в коде и находить отслеживать изменения. СКВ могут вернуть нужные файлы в исходное состояние или показать вам только те изменения, которые вы сделали за определённое время.
Примерный сценарий: в прошлую пятницу Вася напился и ночью кодил пьяным. Утром в субботу пришли его друзья, он показал им свой код, и один из тимлидов сел переписывать его систему запросов к базе данных. Потом в воскресенье у него было свидание с девушкой, и она показала ему, что можно использовать другой обработчик ошибок.
В понедельник Вася понял, что не всё из того, что произошло на выходных, должно остаться в итоговом коде. Он открывает СКВ и видит все изменения, разложенные по времени, с подсветкой:
«Ага, тут я кодил пьяным. Вот место, которое я переписал. Нормально. Надо только поменять названия переменных».
«Это мои друзья кодили. Сносим всё, чертовы пижоны».
«А новый обработчик ошибок хорош. Возьму этот код в другие проекты».
СКВ прямо показывает: «Тогда-то было сделано такое-то изменение, вот, посмотри».
Как реализована
Сейчас есть три принципиальных модели реализации СКВ: локальная, централизованная и распределенная.
Самая простая реализация СКВ — локальная. Это значит, что все изменения и резервные копии хранятся у вас на компьютере в специальной базе данных. Вы не зависите от интернета, полностью контролируете код и можете разрабатывать секретные вещи.
СКВ посложнее — централизованная. Их придумали, чтобы несколько программистов могли работать над одним проектом не мешая друг другу. Такая система контроля версий состоит из сервера, на котором находится репозиторий, и рабочих станций, которые подключаются к серверу для работы над файлами. Репозиторий — это место, где хранятся все нужные файлы, проще говоря — папка со всеми рабочими файлами по проекту.
Когда над одним файлом или модулем работают несколько программистов, сервер смотрит, какие изменения вносит каждый программист, и если они делают разные вещи в одном и том же месте — выдаёт сообщение или блокирует работу одного из них. Типа: «Вы исправляете один и тот же кусок кода, окститесь».
Можно сделать так, что каждый скачивает себе рабочую копию всего репозитория, работает в нём, а в конце дня отправляет его обратно на сервер. Сервер смотрит, можно ли объединить эти файлы без ошибок, и если нет — показывает конфликтные места, где два программиста написали в одном месте разный код.
С такой организацией уже можно работать командой над одним проектом, но в ней есть одно слабое место — сервер. Если он выйдет из строя, команда потеряет проект.
Распределённые СКВ решают эти проблемы так: каждый разработчик получает не просто несколько нужных для работы файлов, а весь репозиторий целиком. Если сервер выйдет из строя, он просто возьмёт полный репозиторий у любого программиста и скачает его себе. Точно так же и с остальными членами команды — если что-то пошло не так, всегда можно взять актуальные файлы у других.
Совместная работа тоже стала проще: все программисты работают над своим кодом, а потом отправляют изменения на сервер. Но они не попадают сразу в репозиторий, а ждут одобрения главного разработчика или ответственного за продукт. Если он одобряет запрос на добавление кода — этот код становится частью репозитория и сразу доступен для скачивания другими участниками. Таких запросов на добавление может быть много, поэтому нужно постоянно проверять, что же именно делает новый код и нужно ли его добавлять в проект.
Причем тут Git
Git — это очень популярная система контроля версий. Её придумал в 2005 году Линус Торвальдс, разработчик ядра Linux, чтобы вместе с товарищами работать над новой операционной системой.
Основное преимущество Git — скорость работы, простота и работа с большими проектами. В отличие от других систем контроля версий, Git не записывает изменения к каждому файлу, а как бы фотографирует весь проект целиком.
Сам по себе Git — это инструмент для командной строки, у него нет графического интерфейса. Но у него довольно много приложений с графическим интерфейсом, и в них всё бывает довольно красиво. На сайте Git есть ссылки на популярные клиенты:
Не путать с GitHub — это онлайн-сервис, который основан на технологии Git. Он хранит репозитории в интернете, автоматически синхронизирует их с репозиториями у разработчиков, следит за обновлениями кода, позволяет редактировать код прямо в репозитории и копировать себе чужие репозитории. Ещё там есть встроенный трекер задач, система уведомлений, форум, переписка между пользователями и комментариями. А всё потому, что GitHub задумывался как социальная сеть для программистов.
