Git

Глава 6 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: Git
Автор: Susan Potter
Перевод: А.Панин

6.9. Что дальше?

Как говорилось ранее, основная часть системы Git в сегодняшнем виде создана в соответствии с философией архитектуры тулкита из мира Unix, которая очень хорошо подходит для сценариев, но менее полезна в случае интеграции или связывания с приложениями или службами, работающими в течение длительного периода времени. Хотя поддержка Git на сегодняшний день реализована в множестве интегрированных сред разработки, работа по добавлению кода поддержки и его сопровождению оказывается более сложной, чем работа, связанная с интеграцией кода поддержки других систем контроля версий, которые предоставляют библиотеки для множества платформ, которые упрощают связывание кода и разделение функций.

Для решения этой проблемы Shawn Pearce (из подразделения Google Open Source Programs Office) возглавил проект по созданию библиотеки Git, которая могла связываться с кодом приложений и распространялась под более либеральной лицензией, не препятствующей ее использованию. Эта библиотека получила имя libgit2. Она не получила заметного распространения до того момента, как студент по имени Vincent Marti не выбрал ее для работы в рамках проекта Google Summer of Code в прошлом году. С того момента Vincent Marti и инженеры компании Github продолжили работу над проектом libgit2 и создали биндинги для множества других популярных языков программирования, таких, как Ruby, Python, PHP, языки .NET, Lua и Objective-C.

Shawn Pearce также начал разработку библиотеки с именем JGit на языке Java, которая распространялась под лицензией BSD и поддерживала большое количество стандартных операций, выполняемых при работе с репозиториями Git. На данный момент развитие этой библиотеки поддерживается организацией Eclipse Foundation и она используется для работы среды интегрированной разработки Eclipse с системой Git.

Все эти проекты с открытым исходным кодом развиваются независимо от основного проекта Git.

Как вы видите, на сегодняшний день существует большое количество методов использования формата хранения данных, применяемого в Git. Лицом проекта Git сейчас является не только интерфейс командной строки тулкита, развиваемого в рамках основного проекта Git; это также формат репозитория и протокол, используемый для осуществления обмена данными между репозиториями.

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

6.10. Выученные уроки

При разработке программного обеспечения любое архитектурное решение по своей сути является компромиссом. Наблюдая с позиции опытного пользователя системы контроля версий Git, а также того, кто разрабатывает программное обеспечение для работы с моделью базы данных объектов Git, я испытываю гордость по поводу сегодняшнего состояния системы Git. Система стала такой благодаря урокам, извлеченным при исправлении вызывающих наибольшее количество повторяющихся жалоб недоработок, возникающих в результате принятия архитектурных решений разработчиками основной части проекта Git.

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

Ранее некоторые команды Git были реализованы в форме сценариев оболочки. Эти реализации команд в форме сценариев сделали систему Git менее переносимой, особенно на платформу Windows. Я уверен, что разработчики основной части проекта Git не упустили из вида этот факт, но он в конечном счете негативно повлиял на внедрение Git в крупных организациях ввиду распространенных сложностей, возникавших при переносе системы на другие платформы на ранних стадиях разработки Git. Сегодня существует проект "Git for Windows", реализуемый добровольцами с целью своевременного переноса новых версий Git на платформу Windows.

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

Даже при наличии всех этих жалоб на систему Git, я очень вдохновлена возможностями, которые откроются в ходе процесса разработки проекта Git в будущем, а также в ходе разработки всех связанных проектов с открытым исходным кодом, которые были начаты благодаря появлению Git.

Вернуться к началу статьи.