Прошло 15 лет с момента выхода распределенной системы контроля версий Git: первую версию Линус Торвальдс, известный как разработчик ядра Linux, выпустил 7 апреля 2005 г.
Сегодня, по утверждению GitLab, это, пожалуй, самая функциональная в мире распределенная система контроля версий (СКВ).
«В XXI веке качество программного обеспечения — это новый стандарт высокого профессионализма, поэтому компаниям крайне важно найти способы быстрого внедрения инноваций. Git позволяет ускорить разработку и начать приносить пользу клиентам быстрее», — говорит Сид Сижбрандиж, генеральный директор GitLab.
История Git
По словам разработчиков Скотта Чакона и Бена Штрауба, которые еще в начале двухтысячных написали книгу «Git для профессионального программиста», в проекте ядра Linux для обслуживания и отслеживания изменений использовалась распределенная СКВ BitKeeper. В 2005 г. BitKeeper стала платной, поэтому сообщество Linux решило разработать собственный инструмент — на основе уже имеющегося опыта работы с СКВ. Была поставлена задача создать быстрый и простой инструмент с хорошей поддержкой нелинейной разработки, полностью распределенный и способный работать с большими проектами. Так родился Git.
«С момента своего появления в 2005 году Git развился в простую в использовании систему, сохранив при этом свои изначальные качества. Он удивительно быстр, эффективен в работе с большими проектами и имеет великолепную систему веток для нелинейной разработки», — пишут в своей книге Чакон и Штрауб.
Системы контроля версий используются для регистрации изменений с течением времени и позволяют вернуться и просмотреть конкретные версии.
«…Система контроля версий (далее СКВ) — как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое. Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить», — рассказывают авторы.
Виды систем контроля версий
Сегодня есть различные виды систем контроля версий. Локальная СКВ — это простая база данных, которая позволяет копировать файлы из каталога в каталог. По словам Чакона и Штрауба, такой подход подвержен ошибкам, потому что легко забыть, куда какие файлы помещаются.
Централизованная СКВ — это сервер, который позволяет работать над проектом совместно. Это лучше, чем локальный вариант, однако настройка и использование такой системы могут вызывать трудности: например, если сервер «упадет», у всех пропадет доступ к проекту, и никто не сможет сохранить никакие изменения.
Распределенная СКВ (например, Git) позволяет держать у себя полную копию репозитория вместе с историей, поэтому его можно сохранить и восстановить, даже если сервер перестанет существовать.
Кроме того, традиционные СКВ не допускали или ограничивали ветвление и слияние, что приводило к поломке сборок, потому что все работали на основной ветви, — параллельная разработка была невозможна.
«В отличие от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день», — пишут Чакон и Штрауб.
Однако поскольку Git — распределенная система, у каждого в итоге оказывается копия репозитория, с которой можно делать всё что угодно. Кроме того, в исходном Git нет средств аутентификации и проверки подлинности, что может приводить к проблемам с безопасностью, — согласно декабрьской публикации в блоге Perforce. Чтобы повысить уровень защиты, можно использовать хостинговые инструменты, оснащенные такими средствами обеспечения безопасности, как аутентификация пользователей и шифрование.
«Git оказал огромное влияние на разработку программного обеспечения с открытым исходным кодом: благодаря децентрализации все получают одни и те же инструменты. Это обеспечило гибкость и прозрачность разработки, которых раньше не было, и позволило легко документировать и совместно разрабатывать самое разное программное обеспечение», — отмечает Джефф Кинг, выдающийся инженер-программист, работающий в GitHub.
По словам Чакона и Штрауба, Git отличается от других СКВ подходом к работе с данными: такие системы, как Subversion, CVS, Perforce и Bazzar, хранят информацию в виде списка изменений в файлах (это также называется контролем версий на основе различий), а Git обрабатывает данные в виде набора снимков.
«Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок. Для увеличения эффективности, если файлы не были изменены, Git не запоминает эти файлы вновь, а только создает ссылку на предыдущую версию идентичного файла, который уже сохранён», — рассказывают авторы.
Git сегодня
Актуальная на сегодня версия — Git 2.26 — вышла месяц назад, и в ней впервые по умолчанию начал использоваться протокол версии 2. Среди других изменений — новые параметры конфигурации, обновления для «git sparse-checkout» и повышение производительности. Кроме того, появилась функция частичного клонирования, которая позволяет улучшить производительность и дает возможность работать без копии репозитория.
В экосистеме этой распределенной СКВ существует множество инструментов и работают самые разные компании: например, GitLab — поставщик инструментов DevOps с менеджером Git-репозитория, или GitHub — хостинг для совместной работы с контролем версий через Git. Недавно Microsoft анонсировала Scalar — приложение .NET Core, предназначенное для повышения производительности команд Git посредством использования рекомендованных значений параметров конфигурации и фонового обслуживания проекта.
«Думаю, самое лучшее у нас еще впереди», — утверждает Джунио Хамано, сопровождающий проекта Git, в интервью с Джеффом Кингом из GitHub. — «Но как сопровождающий больше всего я горжусь тем, какое у нас сложилось сообщество замечательных разработчиков (не буду называть имен) — с самым разным опытом, работающих на разные компании, с разными планами, — и все они трудятся вместе и продвигают проект вперед. Кроме того, я горжусь тем, что и я, и другие давние участники проекта и сами научились, и научили других надлежащим образом описывать вносимые изменения».
Новость переведена в Alconost, профессиональной студии по переводу и локализации
trolley813
Интересно, как можно написать книгу о гите в начале 2000-х годов, если его разработка в принципе только началась в 2005 году?
iproger
Да так же как и требовать 5+ лет опыта для двухлетней технологии.
fshp
Северный коэффициент
Akon32
Может, автор мыслит в масштабах тысячелетия (2000-2999).