- PVSM.RU - https://www.pvsm.ru -
В нашем блоге на Хабре мы рассказываем о различных технологиях из мира IaaS и не только. Например, недавно мы публиковали материал по программным реализациям VPN [Часть 1 [1]; Часть 2 [2]], а также рассказывали о DNS [3]. Сегодня нам бы хотелось углубиться в тему разработки приложений и сервисов и поговорить о такой вещи, как Git, в частности, о способах оптимизации работы с ним.
[4]
/ фото hackNY.org [5] CC [6]
Хотелось бы начать с самого начала – что же такое Git? Git – это одна из систем управления версиями (version control system, или VCS), на основе которой построены несколько сервисов, таких как GitHub или GitLab. С помощью Git было разработано [7] большое количество программного обеспечения, которое, вероятно, вам хорошо знакомо: это и ядро Linux, Firefox, а также Chrome.
Если вы работали в команде над каким-нибудь программным продуктом, то представляете, как все происходит. У вас имеется определенная версия вашего проекта, которую вы отправляете своим коллегам. Они вносят изменения в код и отсылают их обратно. Вы же встраиваете их в свою кодовую базу и получаете новую версию проекта.
Одна из основных задач Git – избежать ситуации c путаницей между версиями продукта, когда появляются файлы с именами вроде project_betterVersion.kdenlive или project_FINAL-alternateVersion.kdenlive и т. д.
Чтобы упростить работу с этими файлами и нужны системы VCS. Так каждый член команды имеет возможность работать над последней версией проекта, вносить свои изменения и сообщать об этом коллегам.
Системы контроля позволяют хранить несколько вариаций одного и того же документа и при необходимости «откатывать» его до более ранней реализации. То есть вы можете сделать копию репозитория и работать с ней локально, а затем при помощи специальных команд внедрить свои правки (push) в основную версию или извлечь (pull) изменения, сделанные коллегами.
При работе над большими продуктами постоянно происходит переименование исходников, выделение новых веток, выполняется сравнение с прошлыми версиями. Потому в достаточно больших проектах может наблюдаться снижение производительности работы Git. С такими проблемами как-то раз столкнулась даже компания Facebook.
Тогда сложности в работе они объяснили [8] тем, что при любом изменении исходных файлов происходило переписывание индексного файла, а в большом проекте его размер превышал 100 МБ. Это и привело к замедлению работы (кстати, вот одно интересное решение [9] уже другой проблемы с производительностью систем управления версиями Facebook, предложенное инженерами компании).
Чтобы ускорить работу с Git, разработчиками применяются различные техники, утилиты и решения. Одним из вариантов может быть уменьшение размеров репозитория.
RoR-разработчик Стив Лорек (Steve Lorek) в своем блоге пишет [10] о том, что ему удалось сократить размер репозитория с 180 МБ до 7 МБ. Для этого он сперва создал локальную копию Git, а затем нашел файлы, занимающие слишком много места в хранилище. Здесь на помощь пришел bash-скрипт [11] Энтони Стаббса (Antony Stubbs), который находит 10 самых крупных и ненужных файлов.
После этого он удалил эти файлы, воспользовавшись серией команд:
$ git filter-branch --tag-name-filter cat --index-filter 'git rm -r --cached --ignore-unmatch filename' --prune-empty -f -- --all
$ rm -rf .git/refs/original
$ git reflog expire --expire=now –all
$ git gc --prune=now
$ git gc --aggressive --prune=now
После этого Стив отправил изменения в удаленный репозиторий, чтобы больше никому не пришлось скачивать для работы 180 мегабайт.
Это еще одно решение, которое пригодится организациям, насчитывающим несколько сотен разработчиков. Многие члены таких команд работают удаленно и из разных стран, что приводит к задержкам при загрузке данных из репозиториев. Бывает доходит до того, что сотрудники пересылают [12] друг другу жёсткие диски по почте.
При зеркалировании настраивается один или несколько активных зеркальных серверов, которые исполняют только операции чтения копий репозиториев и синхронизируются с основным экземпляром. Такой подход позволяет [13] сократить время передачи копии репозитория на 5 ГБ примерно в 25 раз.
Из-за того что каждый разработчик хранит на своем компьютере всю историю изменений, размер репозиториев Git растет быстро. Однако есть ряд утилит [14], решающих эти проблемы. Например, git-annex [15] позволяет хранить вместо целого файла символьную ссылку (symlink) на него.
Также стоит отметить расширение Git Large File Storage (Git LFS [16]), которое пишет в репозиторий указатели на файлы. Операции с этими файлами отслеживаются с помощью фильтров [17] clean и smudge, а их содержимое хранится на удаленном сервере GitHub.com или GitHub Enterprise. Описание нескольких других утилит вы можете найти по ссылке [14].
Этот совет связан не столько с производительностью Git и скоростью загрузки файлов, сколько с удобством работы. Определение псевдонимов способно значительно повысить скорость работы с Git и упростить множество операций. Псевдонимы настраиваются с помощью файла конфигураций:
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
Интересно, что таким образом можно создавать собственные команды, которых по умолчанию нет в системе, например:
git config --global alias.l "log --oneline --graph"
Конкретно в этом случае вы получите возможность выводить логи в строчку и в графическом виде командой git l.
Эти небольшие советы могут помочь упростить работу с большими репозиториями и облегчить жизнь командам разработчиков. А это большое дело в плане качества и скорости выполнения важных проектов компании.
P.S. А еще мы пишем о создании нашего IaaS-провайдера 1cloud:
Автор: 1cloud.ru
Источник [21]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/git/190281
Ссылки в тексте:
[1] Часть 1: https://habrahabr.ru/company/1cloud/blog/307280/
[2] Часть 2: https://habrahabr.ru/company/1cloud/blog/308870/
[3] рассказывали о DNS: https://habrahabr.ru/company/1cloud/blog/309018/
[4] Image: https://habrahabr.ru/company/1cloud/blog/309704/
[5] hackNY.org: https://www.flickr.com/photos/hackny/
[6] CC: https://creativecommons.org/licenses/by-sa/2.0/
[7] разработано: https://opensource.com/resources/what-is-git
[8] объяснили: http://news.ycombinator.com/item?id=3549679
[9] решение: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook
[10] пишет: http://stevelorek.com/how-to-shrink-a-git-repository.html
[11] bash-скрипт: https://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-objects-and-trim-your-waist-line/
[12] пересылают: https://cloud.google.com/storage/docs/offline-media-import-export
[13] позволяет: http://blogs.atlassian.com/2016/02/smart-mirroring-cures-poor-git-performance/
[14] утилит: http://blog.deveo.com/storing-large-binary-files-in-git-repositories/
[15] git-annex: https://git-annex.branchable.com/
[16] Git LFS: https://git-lfs.github.com/
[17] фильтров: https://git-scm.com/docs/gitattributes#__code_filter_code
[18] Как создать провайдера виртуальной инфраструктуры: https://1cloud.ru/news/how-to-create-iaas-provider
[19] Как выбрать направление для развития ИТ-проекта: https://1cloud.ru/news/it-project-area-choice
[20] Что нужно знать об IaaS-провайдере до начала работы: https://1cloud.ru/news/21-question-to-iaas-provider
[21] Источник: https://habrahabr.ru/post/309704/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.