Git празднует пятнадцатилетие


    Прошло 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, профессиональной студии по переводу и локализации
    Alconost
    Локализуем на 70 языков, делаем видеоролики для IT

    Комментарии 5

      +8
      которые еще в начале двухтысячных написали книгу «Git для профессионального программиста»

      Интересно, как можно написать книгу о гите в начале 2000-х годов, если его разработка в принципе только началась в 2005 году?

        +5
        Да так же как и требовать 5+ лет опыта для двухлетней технологии.
          0

          Северный коэффициент

          0

          Может, автор мыслит в масштабах тысячелетия (2000-2999).

          0
          По словам Чакона и Штрауба, Git отличается от других СКВ подходом к работе с данными: такие системы, как Subversion, CVS, Perforce и Bazzar, хранят информацию в виде списка изменений в файлах (это также называется контролем версий на основе различий), а Git обрабатывает данные в виде набора снимков.


          Можно дополнить, чтобы не складывалось впечатление, что git самая совершенная система:

          Такие системы как darcs — в виде набора патчей.
          Что имеет преимущества над системой снимков в каких то случаев.

          There are basically two approaches to version control: either snapshot-based (git, mercurial, svn, or their ancestors), or patch-based (darcs). Historically, patch-based systems have been very simple to learn and use, but slow, whereas snapshot-based systems can be extremely fast, but are usually hard to use for more than simple operations. As an example, cherry-picking does not work well in git/mercurial, and merging is sometimes plain wrong.


          In Git, cherry-picking means taking some commits, but not all, from another branch. This causes these commits to be rebased onto the current branch, losing their identity in the process. It usually works fine the first time it’s done, but then creates artificial conflicts if you want to cherry-pick again between the same branches, for no real reason.

          We call that counter-intuitive, because it’s a fairly common workflow: many projects have branches name “stable” and “master”, and backport bugfixes from master into stable.


          Есть и гибридные в этом смысле CVS со своими преимуществами над git. Например, pijul (но он поближе к патчевым):
          Pijul combines these approaches, by representing its data in a more general way than snapshot-based systems, that allows for a patch-based interface.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое