Git *

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

Реализация построена на FluxCD с использованием директивы postBuild для шаблонизации манифестов через переменные. Каждое окружение получает собственный namespace, базу данных, TLS‑сертификат и уникальный URL — и всё это без ручного вмешательства. Разбираем структуру CI/CD пайплайна, слоёвую организацию GitOps‑репозитория и автообновление образов через ImagePolicy.

Представьте, что завтра из нашего мира исчезнут все проекты Линуса Торвальдса. Ваш смартфон на Android моментально превратится в кирпич, интернет ляжет, а вся командная разработка ПО намертво встанет без Git. Удивительно, но вся современная цифровая инфраструктура держится на решениях, которые были придуманы одним человеком не ради миллиардов или славы, а просто из любопытства. В этой статье вспоминаем путь главного интроверта IT: от попыток починить старый Commodore до создания ядра Linux, победы над Microsoft и революции в Open Source.

Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными разработчиками !

Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.

В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.

Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.

Если вы работаете в большой компании и одновременно живёте там, где есть какие-то региональные ограничения на сервисы, у вас почти наверняка две VPN-конфигурации:

рабочая — для доступа к внутренним ресурсам (GitLab, Jira, Confluence и т.д.)

личная — для личных целей

И постоянное переключение между ними — это, мягко говоря, неудобно.

Всем снова привет!

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

В этой статье мы разберём, как действовать и, главное, мыслить в таких ситуациях. Проблема в том, что конфликтов в git может случиться куча: может сломаться ручной git merge, при git pull, может полететь при git rebase , git cherry-pick и т.д. Из-за этого одного конкретного решения нет, но зато есть общий принцип решения.

Командная разработка в 1С не обязана держаться на блокировках, непрозрачной истории и ручном разборе изменений.

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

Привет, Хабр! Хочется поделиться инструментами и практиками для работы с GIT, о которых не все знают, но которые сильно упрощают жизнь вам и вашей команде. Если кто-то хочет чтобы ваша история коммитов была читаемой, легкой для понимания и с возможностью заглянуть в любой коммит и понять, какие были произведены изменения, то эта статья для вас.
Здесь не будет базовых понятий и терминов, так как предполагается, что с основами GIT вы уже знакомы. 

Привет, Хабр! Сегодня мы часто говорим про разные тренды в разработке — ИИ‑агентов, тестирование на ранних стадиях, прослеживаемость изменений, автоматизацию пайплайнов… Все эти тренды звучат убедительно, пока не упираются в реальность: требования лежат в на общих дисках, схемы — в картинках, контракты — в разных версиях, а история изменений размазана по инструментам.

Что делать с этим?

Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, чем полезен в этом случае подход GitOps и о том, как и в каких случаях это может упростить жизнь команде.

21 мая 2026 года вышел мажорный релиз, переосмысляющий то, как платформа управляет жизненным циклом от идеи до деплоя.

Основной повесткой как уже принято стал ИИ, в Gitlab уделили этому особое внимание.
ИИ уже генерирует больше кода, чем успевают проверять инженеры. Merge Request'ы накапливаются, конфликты разрастаются, секреты утекают в переменные окружения, а зависимости с уязвимостями тихо живут в requirements.txt. GitLab 19.0 отвечает на этот вызов не просто набором фич, а сменой парадигмы: платформа берёт на себя операционную работу, оставляя командам только решения, требующие человеческого суждения.

Ниже я разберу релиз подробно, постараюсь описать примеры конфигурации, архитектурные схемы и дам выводы, таким образом как я это понял)

CI/CD-пайплайн, который хранит секреты, — это риск. В безопасной модели он получает доступ к чувствительным данным только на время выполнения задачи и строго в рамках своих прав.

Разбираем, почему GitLab CI/CD Variables — это не хранилище секретов, какие подводные камни ждут при самодельной интеграции GitLab CE с HashiCorp Vault и как связка Deckhouse Code и Stronghold закрывает эти проблемы без Bash-портянок в before_script.

«Релиз» — слово, от которого у многих тимлидов подскакивает артериальное давление. Ведь за ним часто стоит ночь без сна: кто-то внёс правку в последний момент, тесты упали, а в проде уже ждут обновления. Знакомо?

Но релиз может стать предсказуемым процессом. В статье на примерах покажу, какие процессы, правила и инструменты помогают команде SourceCraft Security избежать авралов.

Привет, Хабр! Меня зовут Артём Зеленкин, приятно познакомиться! Я работаю техническим писателем около 20 лет, сейчас занимаюсь документированием в подразделении ARMA компании Infowatch. Для создания и поддержки актуальности документации по продуктам линейки ARMA мы используем docs-as-code. Что из этого получается, можно посмотреть на сайте с документацией (там же можно скачать pdf-версию, чтобы сравнить, как оно выглядит в разных форматах при тех же исходных данных).

В данной статье я не пытаюсь рассказать, что такое docs-as-code (думаю, статей по теме достаточно), а рассказываю, как этот принцип реализован у нас. Может, вам тоже пригодится.

Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте

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

Часть 2 серии об осмысленном CI/CD: настраиваем self-hosted GitLab Runner. Пройдем от docker-compose.yml до работающего runner, попутно разбирая ошибки permissions, SELinux context и особенности rootless Podman. Все то же самое актуально и для Docker.

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

Версия 1С Элемент: 8.0 и выше.
Тип установки 1С Элемент: Локальный
Версия Git: 2.45 и выше

Подключение GitLab
Так как мы используем локальную установку 1С Элемент на своем сервере, то первое, что требуется сделать - это на сервере с 1С Элементом установить и настроить Git (система контроля версий).
Как его устанавливать и настраивать - есть отдельная инструкция, которая доступна в справке 1С Элемента в разделе «Руководстве разработчика» →  «Среда разработки» →  «Git». 

Ссылка на справку из 8.0 - https://1cmycloud.com/console/help/element/8.0/docs/topics/git-installation/

После установки Git, в панели управления 1С Элемента станет доступно Хранилище репозиториев.

Практический разбор того, как я вынес security-проверки Java-проектов из разрозненных CI/CD-скриптов в переиспользуемый Gradle plugin

Единый плагин для сканирования на безопасность Java проектов. Maven. Или как проверять кучу микросервисов на безопасность управляя этим в одном месте

29 апреля 2026 года Митчелл Хашимото объявил, что уводит свой Ghostty с GitHub. Цитата ушла на главную Hacker News через статью в The Register: «GitHub больше не место для серьёзной работы, если он каждый день блокирует тебя на часы».

Сам по себе уход одного человека, даже такого, как Хашимото, ещё не новость. Новость в другом: на главной HN на той же неделе оказалось ещё четыре истории про GitHub. Эссе Армина Ронахера про то, как мы жили до GitHub. Манифест команды Tangled про федеративные форджи. Тихий запуск голландской госплатформы для опенсорса на Forgejo. И жёсткий аудит безопасности того же Forgejo от Жюльена Вуазана. Если посмотреть на эти пять текстов вместе, складывается одна история.

Хашимото — не случайный пользователь GitHub. Сооснователь HashiCorp, после ухода оттуда автор Ghostty. И, по его собственным словам, «пользователь GitHub номер 1299, зарегистрирован в феврале 2008-го». Он же говорит про себя как про человека, который «листает задачи на GitHub с тех пор, когда у такого поведения ещё не было названия». Если GitHub для кого-то и был домом, то для него.

Необычным его пост делает разбор последнего месяца. Хашимото вёл журнал дат и ставил «X» против каждого дня, когда GitHub упал и помешал ему работать. «Почти каждый день стоит отметка X», пишет он. «В день, когда я пишу этот пост, я уже два часа не могу сделать ни одного ревью пулл-реквестов, потому что лежат GitHub Actions». The Register заметил, что пост вышел прямо перед инцидентом 28 апреля, когда пулл-реквесты перестали завершаться из-за падения Elasticsearch.

Все русскоязычные гайды по GitLab CI/CD — это «сделай вот так под Node.js/Java/.NET». А как оно вообще работает? Написал подробный туториал: термины, схемы, разбор .gitlab-ci.yml, логи runner’а построчно. Первая часть из трёх — от простейшего pipeline до понимания, что конкретно вам нужно в вашем случае.