Git *

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

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

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в МТС Web Services. Последние несколько лет мне приходилось создавать и адаптировать конвейеры на базе GItLab-CI, изменяя процесс автоматизации под каждую новую команду, стек, продукт и окружения эксплуатации. Чтобы облегчить жизнь себе и коллегам, я сделал небольшой внутренний фреймворк — FundaPipe, значительно упрощающий создание, развитие, переиспользование и применение самих конвейеров разработчиками.

Flutter & GitLab CI/CD. Сборка и подписание мобильных приложений

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. Эта статья является продолжением первой части руководства по настройке GitLab CI/CD для Flutter приложений, в котором мы подробно разобрали настройку физической машины и подготовили GitLab Runner для работы. Теперь, когда инфраструктура готова, перейдем к самому интересному – автоматизации сборки и подписания мобильных приложений.

Готовы превратить сборку мобильных приложений из рутинной задачи в полностью автоматизированный процесс? Тогда начинаем!

Привет, Хабр!

Монорепозитории удобны, пока CI не начинает пробегаться по всему дереву. Сегодня рассмотрим, как на GitLab собрать внятный pipeline для монорепы так, чтобы на каждое изменение реагировали только нужные куски. Базовых кирпичиков тут три: rules:changes, условные include и тонкое клонирование репозитория.

Если вы используете код десктопа, курсор или другие инструменты, то знаете: ИИ уже не просто генерирует код — он читает файлы, делает коммиты, отправляет письма. Эта интеграция работает через протокол MCP, который позволяет подключать серверы буквально в пару кликов. Увидели интересный GitHub-сервер, установили — и готово.

Но у MCP есть обратная сторона: каждый сервер требует широкие права. Gmail-сервер просит полный доступ к почте, GitHub-сервер — ко всем репозиториям, файловый сервер — к домашней папке. Microsoft уже фиксирует рост «теневых MCP-серверов», которые сотрудники ставят без ведома IT-отдела. Palo Alto предупреждает: злоумышленники маскируют вредоносные серверы под полезные.

Мы провели собственное исследование MCP, изучили отчёты Microsoft, Invariant Labs, Trail of Bits и протестировали разные атаки. В этой статье — разбор протокола и ключевых рисков безопасности.

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

А Claude Code, как передовой инструмент AI-программирования, не только полностью совместим с рабочими процессами Git, но и благодаря глубокой интеграции предоставляет разработчикам беспрецедентную автоматизацию и удобство.

Из этой статьи вы получите следующее:

Своевременное выявление уязвимостей в коде является одной из важнейших задач конвейера CI/CD, ведь чем раньше мы обнаружим ошибку в коде, тем дешевле нам обойдется ее исправление. Для решения этой задачи существует множество различных решений. Но если мы используем конвейер CI/CD то нам необходимо интегрировать наш анализатор в этот процесс. Однако, в GitLab имеется своя функциональность для анализа исходного кода. В этой статье мы настроим GitLab SAST для автоматического анализа исходного кода на наличие уязвимостей.

В современном ИТ ландшафте множество методологий имеют в своем названии упоминание Ops: DevOps, ChatOps, MLOps и другие. По сути, все они так или иначе являются порождением философии DevOps и сегодня мы поговорим о GitOps — подходе к управлению инфраструктурой и развёртыванием приложений, который использует репозиторий Git в качестве центрального механизма.

GitOps позволяет командам декларативно определять конфигурацию инфраструктуры и приложений, а затем автоматически развёртывать их. Основная идея GitOps заключается в использовании Git как единого источника данных для декларативной инфраструктуры и приложений.

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

Статья для разработчиков, которые устали от сложностей Git и хотят навести порядок в своих проектах. Я расскажу про Jujutsu (jj) — современную альтернативу, которая меняет подход к контролю версий. Без веток, без stash, без мучительных rebase -i — только чистая история и удобный workflow, который позволит вам фокусироваться на написании кода, а не на борьбе с системой. Готовые примеры и наглядная демонстрация возможностей внутри.

Вышел релиз GitLab 18.2 с Duo Agent Platform в IDE (бета-версия) и настраиваемыми статусами рабочего процесса для тикетов и заданий

git commit -m "WIP" — три слова, после которых начинается настоящий ад.

Доброго времени суток. Такая технология как Git в представлении не нуждается. Все знают add, commit, push — это как азбука. Но что делать, когда что‑то пошло не так? Ошибочный коммит прокатился по ветке? Надо срочно переключиться, но незавершенные правки мешают? Нужно перенести только одно исправление из другой ветки?

Знакомая ситауция? Тогда давайте разберем 5 команд, которые выходят за рамки базового workflow и реально спасают репутацию (и ваши нервные клетки).

Изначально я занимался одним проектом со стороны тестирования в роли старшего тестировщика. У нас микросервисная архитектура — около 15 сервисов хранится в Git. Для тестирования на стенде нужно развернуть примерно 5–7 сервисов за один релиз. Всего стендов два, и после тестирования их же нужно деплоить в продакшн.

Проблема в том, что у нас практически нет системы мониторинга состояния сервисов. Я не получал автоматической информации о том, что происходит с каждым из них, а расспросы коллег не давали ясных ответов.

Со временем мне стало важно быстро понимать, какие ветки задеплоены на конкретных стендах для всех сервисов, входящих в релиз. В Git такой возможности прямо из коробки нет — нельзя выбрать сразу список сервисов из разных проектов и посмотреть их окружения в виде таблицы или списка.

Поэтому мне приходилось делать так: заходить в каждый проект, открывать репозиторий сервиса, искать меню «Operate», затем «Environments» и там уже смотреть нужный стенд. И так — для каждого сервиса при деплое на тестовый стенд, при обновлении в продакшн или во время тестирования.

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

Экосистема продуктов 1С содержит много различных полезных инструментов разработки. Одним из них является 1C:EDT (1C:Enterprise Development Tools) — расширяемая среда разработки прикладных решений, созданная на основе свободной интегрированной среды разработки модульных кроссплатформенных приложений Eclipse.

1C:EDT поддерживает ключевые принципы создания прикладных решений на платформе «1С:Предприятие 8» и содержит большое количество инструментов автоматизации разработки, делающих работу программиста более быстрой и комфортной, а также позволяет расширять функциональность инструментов разработки с помощью технологии плагинов.

В этой статье мы поговорим о том, как интегрировать 1С:EDT с системой контроля версий Git для того, чтобы сделать разработку более эффективной.

Ходит легенда, что однажды разработчики GitLab закупились шапками, сделанными из переработанных крышечек от бутылок. И их настолько вдохновила идея повторного использования, что они решили добавить такую возможность и в свой продукт. Подкрепив это всё стандартизацией CI, они представили комьюнити новый механизм — GitLab CI/CD components.

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

Когда я был еще джуном, старшие разработчики настоятельно советовали мне перейти на zsh. Я помню, что я так и не получил никакой аргументации, чем zsh лучше привычного bash, и какую конкретно пользу я получу от перехода.
Что ж, в этой статье я хочу ответить на эти вопросы тем, кто еще только задается этим вопросом, с небольшим уклоном к PHP разработке

Zsh это командная оболочка, то есть программа, которая получает от пользователя команду в текстовом виде и выполняет соответствующие исполняемые файлы, найденные по путям, указанным в переменной окружения PATH.
Zsh является дефолтной оболочкой для macOS, на linux дефолт - bash. Zsh лучше, чем bash в основном благодаря своей очень обширной системе плагинов, модулей, различных тем и т. д.

Например, установив вот такой плагин.

Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.

По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.

Раскрываем Docs as Code: как этот подход меняет создание документации, какие инструменты стоит изучить в первую очередь, и с чего начать внедрение.

Вышел релиз GitLab 18.1 с бета-версией виртуальных реестров Maven и Duo Code Review в общем доступе.
Мы с радостью объявляем о релизе GitLab 18.1 с бета-версией виртуальных реестров Maven, фичей Duo Code Review в общем доступе, выявлением скомпрометированных паролей и компонентами CI/CD для достижения SLSA 1 уровня! Это лишь несколько из более 110 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.

Сейчас сложно представить мир разработки программного обеспечения без git – распределенной системы контроля версий. Хотя еще 10 лет назад во многих компаниях использовались другие инструменты: CVS или SVN. Бывали даже такие команды, в которых и вовсе не велось версионирование кода. А 20 лет назад git только-только был создан Линусом Торвальдсом и начал распространяться в среде самых продвинутых разработчиков того времени — участниках опенсорс комьюнити вокруг ядра линукса.

В этой статье мы рассмотрим предпосылки появления git и его современное использование.

Первый коммит гите был сделан 7 апреля 2005 года с описанием: Initial revision of "git", the information manager from hell. В английском языке слово гит означает «неприятный человек», и хотя история благодушно умалчивает, почему Линус назвал свой инструмент именно так, мы можем быть уверены, что в этом названии отражена та сложная обстановка, в которой оказались создатели ядра линукса в начале 21 века. Дело в том, что в начале разработки ядра Linux использовался проприетарный (то есть принадлежащий конкретной компании и не являющийся свободным) инструмент управления версиями под названием BitKeeper. Однако в 2005 году возник конфликт между разработчиками Linux и компанией-разработчиком BitKeeper, в результате которого была отозвана бесплатная лицензия разработчиков ядра.