В нашем блоге на Хабре мы рассказываем о различных технологиях из мира IaaS и не только. Например, недавно мы публиковали материал по программным реализациям VPN [Часть 1; Часть 2], а также рассказывали о DNS. Сегодня нам бы хотелось углубиться в тему разработки приложений и сервисов и поговорить о такой вещи, как Git, в частности, о способах оптимизации работы с ним.
/ фото hackNY.org CC
Хотелось бы начать с самого начала – что же такое Git? Git – это одна из систем управления версиями (version control system, или VCS), на основе которой построены несколько сервисов, таких как GitHub или GitLab. С помощью Git было разработано большое количество программного обеспечения, которое, вероятно, вам хорошо знакомо: это и ядро Linux, Firefox, а также Chrome.
Если вы работали в команде над каким-нибудь программным продуктом, то представляете, как все происходит. У вас имеется определенная версия вашего проекта, которую вы отправляете своим коллегам. Они вносят изменения в код и отсылают их обратно. Вы же встраиваете их в свою кодовую базу и получаете новую версию проекта.
Одна из основных задач Git – избежать ситуации c путаницей между версиями продукта, когда появляются файлы с именами вроде project_betterVersion.kdenlive или project_FINAL-alternateVersion.kdenlive и т. д.
Чтобы упростить работу с этими файлами и нужны системы VCS. Так каждый член команды имеет возможность работать над последней версией проекта, вносить свои изменения и сообщать об этом коллегам.
Системы контроля позволяют хранить несколько вариаций одного и того же документа и при необходимости «откатывать» его до более ранней реализации. То есть вы можете сделать копию репозитория и работать с ней локально, а затем при помощи специальных команд внедрить свои правки (push) в основную версию или извлечь (pull) изменения, сделанные коллегами.
При работе над большими продуктами постоянно происходит переименование исходников, выделение новых веток, выполняется сравнение с прошлыми версиями. Потому в достаточно больших проектах может наблюдаться снижение производительности работы Git. С такими проблемами как-то раз столкнулась даже компания Facebook.
Тогда сложности в работе они объяснили тем, что при любом изменении исходных файлов происходило переписывание индексного файла, а в большом проекте его размер превышал 100 МБ. Это и привело к замедлению работы (кстати, вот одно интересное решение уже другой проблемы с производительностью систем управления версиями Facebook, предложенное инженерами компании).
Чтобы ускорить работу с Git, разработчиками применяются различные техники, утилиты и решения. Одним из вариантов может быть уменьшение размеров репозитория.
RoR-разработчик Стив Лорек (Steve Lorek) в своем блоге пишет о том, что ему удалось сократить размер репозитория с 180 МБ до 7 МБ. Для этого он сперва создал локальную копию Git, а затем нашел файлы, занимающие слишком много места в хранилище. Здесь на помощь пришел bash-скрипт Энтони Стаббса (Antony Stubbs), который находит 10 самых крупных и ненужных файлов.
После этого он удалил эти файлы, воспользовавшись серией команд:
После этого Стив отправил изменения в удаленный репозиторий, чтобы больше никому не пришлось скачивать для работы 180 мегабайт.
Это еще одно решение, которое пригодится организациям, насчитывающим несколько сотен разработчиков. Многие члены таких команд работают удаленно и из разных стран, что приводит к задержкам при загрузке данных из репозиториев. Бывает доходит до того, что сотрудники пересылают друг другу жёсткие диски по почте.
При зеркалировании настраивается один или несколько активных зеркальных серверов, которые исполняют только операции чтения копий репозиториев и синхронизируются с основным экземпляром. Такой подход позволяет сократить время передачи копии репозитория на 5 ГБ примерно в 25 раз.
Из-за того что каждый разработчик хранит на своем компьютере всю историю изменений, размер репозиториев Git растет быстро. Однако есть ряд утилит, решающих эти проблемы. Например, git-annex позволяет хранить вместо целого файла символьную ссылку (symlink) на него.
Также стоит отметить расширение Git Large File Storage (Git LFS), которое пишет в репозиторий указатели на файлы. Операции с этими файлами отслеживаются с помощью фильтров clean и smudge, а их содержимое хранится на удаленном сервере GitHub.com или GitHub Enterprise. Описание нескольких других утилит вы можете найти по ссылке.
Этот совет связан не столько с производительностью Git и скоростью загрузки файлов, сколько с удобством работы. Определение псевдонимов способно значительно повысить скорость работы с Git и упростить множество операций. Псевдонимы настраиваются с помощью файла конфигураций:
Интересно, что таким образом можно создавать собственные команды, которых по умолчанию нет в системе, например:
Конкретно в этом случае вы получите возможность выводить логи в строчку и в графическом виде командой git l.
Эти небольшие советы могут помочь упростить работу с большими репозиториями и облегчить жизнь командам разработчиков. А это большое дело в плане качества и скорости выполнения важных проектов компании.
P.S. А еще мы пишем о создании нашего IaaS-провайдера 1cloud:
/ фото hackNY.org CC
Хотелось бы начать с самого начала – что же такое Git? Git – это одна из систем управления версиями (version control system, или VCS), на основе которой построены несколько сервисов, таких как GitHub или GitLab. С помощью Git было разработано большое количество программного обеспечения, которое, вероятно, вам хорошо знакомо: это и ядро Linux, Firefox, а также Chrome.
Если вы работали в команде над каким-нибудь программным продуктом, то представляете, как все происходит. У вас имеется определенная версия вашего проекта, которую вы отправляете своим коллегам. Они вносят изменения в код и отсылают их обратно. Вы же встраиваете их в свою кодовую базу и получаете новую версию проекта.
Одна из основных задач Git – избежать ситуации c путаницей между версиями продукта, когда появляются файлы с именами вроде project_betterVersion.kdenlive или project_FINAL-alternateVersion.kdenlive и т. д.
Чтобы упростить работу с этими файлами и нужны системы VCS. Так каждый член команды имеет возможность работать над последней версией проекта, вносить свои изменения и сообщать об этом коллегам.
Системы контроля позволяют хранить несколько вариаций одного и того же документа и при необходимости «откатывать» его до более ранней реализации. То есть вы можете сделать копию репозитория и работать с ней локально, а затем при помощи специальных команд внедрить свои правки (push) в основную версию или извлечь (pull) изменения, сделанные коллегами.
Повышение производительности
При работе над большими продуктами постоянно происходит переименование исходников, выделение новых веток, выполняется сравнение с прошлыми версиями. Потому в достаточно больших проектах может наблюдаться снижение производительности работы Git. С такими проблемами как-то раз столкнулась даже компания Facebook.
Тогда сложности в работе они объяснили тем, что при любом изменении исходных файлов происходило переписывание индексного файла, а в большом проекте его размер превышал 100 МБ. Это и привело к замедлению работы (кстати, вот одно интересное решение уже другой проблемы с производительностью систем управления версиями Facebook, предложенное инженерами компании).
Чтобы ускорить работу с Git, разработчиками применяются различные техники, утилиты и решения. Одним из вариантов может быть уменьшение размеров репозитория.
Уменьшение репозитория
RoR-разработчик Стив Лорек (Steve Lorek) в своем блоге пишет о том, что ему удалось сократить размер репозитория с 180 МБ до 7 МБ. Для этого он сперва создал локальную копию Git, а затем нашел файлы, занимающие слишком много места в хранилище. Здесь на помощь пришел bash-скрипт Энтони Стаббса (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 мегабайт.
Умное зеркалирование
Это еще одно решение, которое пригодится организациям, насчитывающим несколько сотен разработчиков. Многие члены таких команд работают удаленно и из разных стран, что приводит к задержкам при загрузке данных из репозиториев. Бывает доходит до того, что сотрудники пересылают друг другу жёсткие диски по почте.
При зеркалировании настраивается один или несколько активных зеркальных серверов, которые исполняют только операции чтения копий репозиториев и синхронизируются с основным экземпляром. Такой подход позволяет сократить время передачи копии репозитория на 5 ГБ примерно в 25 раз.
Иной подход к хранению крупных файлов
Из-за того что каждый разработчик хранит на своем компьютере всю историю изменений, размер репозиториев Git растет быстро. Однако есть ряд утилит, решающих эти проблемы. Например, git-annex позволяет хранить вместо целого файла символьную ссылку (symlink) на него.
Также стоит отметить расширение Git Large File Storage (Git LFS), которое пишет в репозиторий указатели на файлы. Операции с этими файлами отслеживаются с помощью фильтров clean и smudge, а их содержимое хранится на удаленном сервере GitHub.com или GitHub Enterprise. Описание нескольких других утилит вы можете найти по ссылке.
Использование псевдонимов
Этот совет связан не столько с производительностью 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:
