Системы управления версиями *

Git и владение им — неотъемлемая часть профессионального программирования. К старту курса по Fullstack-разработке на Python делимся самыми важными деталями о новом релизе Git прямо из блога его разработчиков.

Мы рады рассказать вам о выходе релиза GitLab 14.6, последнего релиза 2021-го года. В этом релизе появились: упрощённая конфигурация Geo, которая помогает распределённым командам ускорить выполнение git clone или git pull за счёт автоматического использования ближайшего к ним сервера; список действий агента GitLab, который регистрирует в реальном времени такие события, как состояние соединения и токена; различные улучшения для SAST, включая правила выполнения SAST-сканирований и поддержку .NET 6.

Заголовок: Вышел GitLab 14.5 с SAST-сканированием инфраструктуры как кода и групповыми настройками подтверждений мерж-реквестов
Автор оригинала: Jackie Porter, GitLab
Ссылка на оригинал

Мы рады объявить о выходе нового релиза GitLab 14.5, включающего сканирование безопасности инфраструктуры как кода, групповые настройки подтверждения мерж-реквестов (в русской локализации GitLab «запросы на слияние»), GitLab Kubernetes Agent для бесплатных планов, темы проектов и многое другое!

Автор материала изменил инструмент перечисления файлов в NeoVim с fd на git ls-files и заметил, что файлы отображаются быстрее. При этом цель fd — скорость, а Git — это прежде всего система управления исходным кодом, её основная задача — не в перечислении файлов. Интрига заставила провести тесты.

Делимся подробностями и набором разнообразных инструментов в арсенале автора, пока начинается курс по Fullstack-разработке на Python.

Здесь рассказывается про рекомендации, которые позволяют максимально (относительно моих знаний) избавиться от рутинной работы при вёрстке. При этом моя цель заключается в том, чтобы в какой-то мере сохранить нативность и лёгкость кода для дальнейшей доработки под ваши нужды.

Курсивом выделены термины, которые описаны в конце статьи.

P.S. В данной статье вы не узнаете углублённо о каждом описанном инструменте, будет рассказываться поверхностная информация. Далее разделы этих статей будут разветвляться на более глубокие и узконаправленные.

Мы рады представить вам релиз GitLab 14.4 с запуском DAST-сканирований по расписанию, интегрированным в GitLab отслеживанием ошибок без использования отдельного инстанса Sentry, просмотром удалённых GitLab-репозиториев в Visual Studio Code, графиком динамики внедрения DevOps, GitLab Operator в общем доступе и многим другим!

Здравствуй, читатель!

"...Российский GitHub..." - за такую фразу в заголовке на Habr'e однажды зацепился мой взгляд. С предвкушением я нырнул под кат и... Увы, обнаружил лишь поверхностный обзор, щедро сдобренный издёвкой и скриншотами. Но, согласитесь, ведь не каждый день на горизонте событий возникает что-то IT-шное с припиской "российский", посему любопытство грубо вытолкало меня из раковины интроверта и заставило обратиться напрямую к наиболее надежному источнику - команде сервиса GitFlic.

В этой статье я постараюсь рассказать, как на моей работе я реализовал автоматическую генерацию Changelog из коммитов и создание тегов на их основе.

Привет, Хабр! В этой статье я расскажу о Git hooks и о том, как они могут помочь с некоторыми насущными кейсами организации создания commit’ов и commit message. Пост основан на реальном опыте из моей практики: как я упрощал то, что всем надоело делать руками. Я уверен, что хуки могут оказаться полезны почти каждому разработчику. Ведь все мы пишем в сообщении коммита чуть больше, чем «fixed what was broken», верно?

Меня зовут Роман Горбатенко, я Java-разработчик в компании DINS, на момент написания текста тружусь в команде Contact Center. Занимаюсь разработкой больше 3-х лет и прошел путь от личинки стажера до middle разработчика. Считаю Git одним из самых полезных инструментов разработчика. Многие не используют его возможности на полную, возможно, мне удастся это немного исправить.

Мы рады представить вам релиз GitLab 14.3 с правилами запуска сканирований безопасности для проектов, следующим поколением SAST для снижения количества ложных срабатываний в Ruby, установкой разрешений для защищённых окружений на уровне группы, групповым доступом к GitLab Kubernetes Agent и многим другим!

В мире существует множество различных систем для хранения кода. Различаются они как протоколом работы: Git, Mercurial, Bazaar, — так и форматом работы (cloud, self-hosted). Но есть и другой важный параметр: степень интеграции с сопутствующим инструментарием: issue tracker, CI/CD, wiki и т.д. Так сложилось, что мы в компании предпочитаем GitLab (вариант on-premise) и по умолчанию, если клиент не против, предлагаем ему это решение. В статье я расскажу про миграцию из Gitea c Jenkins в GitLab и о том, с какими сложностями пришлось столкнуться, а заодно поделюсь Python-скриптами, которые пригодились для успеха этого мероприятия.

Наверняка если вы начали читать эту статью, то знаете, что такое git и для чего он нужен. НО не все используют такую интересную функциональность в git как submodules.

Это дает возможность прицепить к вашему проекту другие проекты и переиспользовать их в вашем. Для примера рассмотрим такую историю.

Есть репозиторий, в котором содержится groovy скрипт, который решает задачу по извлечению из системы хранения чувствительных данных Vault.

За 21 год существования в SuperJob разработали три версии реализации API для интеграций с бэкендом. Во время разработки последней они решили пересмотреть подход к версионированию. Сейчас в актуальной реализации порядка 379 эндпойнтов, более 900 моделей сущностей и 11 поддерживаемых мажорных версий. Когда проект развивается, вместе с ним меняются и требования к API, а значит неизбежно нарушение обратной совместимости.

Опытом решения этой проблемы поделился Антон Золотилин из SuperJob. Вы увидите самые распространенные решения проблемы версионирования web-API и подход, который реализовал у себя SuperJob. А в качестве бонуса узнаете, как это решение помогает значительно сократить рост затрат на тестирование версий с помощью Impact-анализа.

Мы рады представить вам новый релиз GitLab 14.2 с бета-версией Build Cloud для macOS, предварительным просмотром Markdown, расширенной интеграцией Gitpod, новыми метриками внедрения DevOps и многим другим!

Этим летом я по уши увяз в serverless-тематике и даже решил переписать один из своих pet-проектов целиком на serverless. Движок для сайта, поддерживающий бессерверные вычисления и вендор для кэширующей прослойки были найдены быстро - NextJS (с деплоем на Vercel) и Upstash с оплатой за каждую отдельную операцию и байт в хранилище. Камнем преткновения стал выбор провайдера для DBaaS. Мне бы хотелось реализовать всё таким образом, чтобы у проекта было две разных базы данных - для разработки и для production, и мне совсем не хотелось запускать базу данных для разработки на локальной машине. Поверхностное ознакомление с DBaaS провайдерами показало, что за дополнительную базу данных пришлось бы платить вдвое больше несмотря на то, что она использовалась бы дай Бог пару раз в неделю. И я ушёл в просмотр докладов и презентаций на YouTube и это именно тот момент когда я открыл для себя PlanetScale. Хочу поделиться своим открытием с вами.

Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.

Ставили все по официальному гайду. При установке postfix возникли ошибки из-за цифры в имени хоста (решилось переименованием), в остальном сложностей не было. Зато они появились позже: гит-машине перестало хватать памяти на объекты, мы подключили LFS и решили проблему, но потом сломались бэкапы. В общем, было весело. О том, как все это чинили — рассказал под катом.

Мы рады представить вам релиз GitLab 14.1 с возможностью собирать, публиковать и распространять Helm-чарты, создавать правила эскалации для ответственных за страницу, подключать обработчики заданий GitLab к вашим кластерам Kubernetes, обеспечивать соблюдение решений по покрытию кода и многим другим!

Разберем способ удобного хранения 35 000 файлов домашней коллекции, которая используется на 3 ПК и 2 телефонах с использованием git-annex.

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

Когда мы думаем обо всём, что было выпущено за год с момента выхода GitLab 13.0, мы не можем не гордиться нашим сообществом и нашей командой. В этом месяце мы празднуем выход GitLab 14.0, и в связи с этим устроим небольшую ретроспективу. Вместе мы добились такого прогресса за последний год, что нам хочется рассказать обо всём, что потребовалось, чтобы пройти путь до GitLab 14.