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

Недавно автор решил попробовать что-то помоделить в Blender. На данный момент он ещё только начинает осваиваться в 3D, но имеет небольшой опыт в разработке ПО, преимущественно с использованием Git, потому хотел бы и тут избежать версионирования проектов в духе "projectN_final5_20260305_fix3.blend", который подразумевается при "инкрементальном" сохранении.

На первый взгляд ничего сложного тут быть не должно: в Blender работа ведётся с набором точек-координат-чисел и их связей, настроек модификаторов, ссылок на текстуры и референсы и т.п.; потому всё это должно иметь некоторую стандартизированную структуру, возможно упакованную в ZIP-архив. Файл проекта .blend же является таким ZIP-архивом, ведь так? Распакуем его и просто занесём в Git? Неправильно!

В данном случае придётся прибегнуть к помощи фреймворка OpenUSD. Но для начала хотелось бы рассказать о том, какие проблемы он был изначально призван решить и какими ограничениями обладает.

Как мы превратили стрессовые ручные релизы в предсказуемый one-click процесс с GitOps и автоматикой. 60+ модулей, аудиторы и регуляторика — в едином шаблоне, который масштабировался на 30+ сервисов. Без магии, но с инженерной дисциплиной

Gentoo — один из самых старых дистрибутивов Linux. Он появился в 2002 году и до сих пор работает по тем же принципам: сборка пакетов из исходных текстов, тщательная настройка под любое железо и полное отсутствие компромиссов. В феврале 2026-го появилась новость о начале переноса зеркал репозиториев с GitHub на Codeberg. И это не просто технический маневр, а принципиальный выбор сообщества. 

В чем основные причины ухода, что повлияло на выбор площадки и какие дальнейшие планы у Gentoo — разберемся под катом.

git rebase это отличный способ сделать историю линейной и визуально красивой. Но для каждого коммита, у которого возникает конфликт, приходится его исправлять и делать git rebase --continue. В случае длинных веток таких остановок для исправления конфликтов может быть довольно много. В этой статье я расскажу про нестандартный метод, как можно исправить все эти конфликты разом, что позволяет сделать git rebase быстро и чисто механически.

Сложно поддерживать CI/CD, когда граф пайплайна в GitLab превращается в бесконечную «простыню», параллельные запуски terraform apply приводят к блокировкам, а для игнорирования некритичных ошибок приходится писать || true. 

Может показаться, что для решения этих проблем нужны «костыли» или переход на enterprise-лицензию. На деле же с ними помогут встроенные возможности GitLab CE. В статье разбираем неочевидные ключевые слова .gitlab-ci.yml, которые сэкономят вам время и нервы.

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

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

Чтобы иметь возможность откатиться – необходимо понимать куда откатываться, на какое состояние кода. И по хорошему бы иметь удобную систему контроля состояний, или же систему контроля версий для кода.

От самых базовых "сохранить –> откатиться" мы постепенно эволюционировали до продвинутых инструментов контроля версий. Глобально системы контроля версий можно поделить на три типа:

Кому эта статья может быть полезна?

Многие сегодня припарковали свои проекты на виртуальных серверах типа vps/vds или физическом сервере. И вот, по каким-то причинам, вы не хотели бы показывать свой код напрямую.

Если вы уже знаете про GitLab runner, Docker и registry – то можно пройти мимо и сберечь свое время. А кто не знает - добро пожаловать. Постараюсь, чтобы было не сложно.

Какие могут быть причины?

А есть ли жизнь вне GIT? Что там? Может там летают птеродактили или НЛО? Или там просто пустое поле? Давайте разбираться.

Привет, Хабр. Всех с наступившим Новым Годом.

На днях наткнулся на статью Махмуда Хашеми, в которой обсуждаются некоторые недостатки методологии семантического версионирования (SemVer), и в качестве решения этих недостатков предлагается использовать календарное версионирование (CalVer). В организации, где я работаю, по стандарту разработки требуется обязательно версионировать приложения по SemVer. Из собственного опыта использования SemVer скажу, что нашёл в ней ещё ряд недостатков, для исправления которых пришлось искать новый способ версионирования.

Привет! Меня зовут Егор Сизов, в компании «Цифра» (дивизион Непрерывные производства) я руковожу направлением «Системы управления производством».

За этот год, среди прочего, я занимался двумя крупными проектами: организации сбора библиотеки готовых конфигураций и конвертацией конфигураций PI System в Платформу ZIIoT. 

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

Материал будет полезен прежде всего для тимлидов внедрения, архитекторов решений и руководителей.

Когда я закончил работать над проектом ecosyste-ms/package-manager-resolvers, мне стало интересно, какой алгоритм разрешения зависимостей использует сервис GitHub Actions. Когда вы записываете в файл рабочего потока uses: actions/checkout@v4, то объявляете зависимость. GitHub её разрешает, скачивает и исполняет. Так работает управление пакетами. Я же решил отправится в кодовую базу runner, чтобы увидеть весь этот процесс изнутри. И открытия, скажу я вам, оказались весьма тревожными.

Для разработчиков ПО diff — привычный способ представления изменений: мы используем diff для сравнения различных версий одного файла (например, во время ревью кода или когда мы пытаемся понять историю файла), для визуализации разницы между непроходящим тестом и его ожиданиями или для автоматического применения изменений к файлам исходников.

В каждом моём профессиональном и личном проекте рано или поздно требовался diff для визуализации изменения или применения патча. Однако меня никогда не устраивала ни одна из свободно доступных библиотек diff. В профессиональной деятельности это никогда не вызвало особых проблем, но в личных проектах я копировал и модифицировал из проекта в проект собственную библиотеку. Однажды я рассказал об этом коллеге, и тот наставил меня на путь публикации моей библиотеки на Go (порта библиотеки на C++, которую я раньше копировал и модифицировал). И оказалось, что я сильно недооценивал то, насколько близка моя библиотека к возможности публикации!

Как бы то ни было, я опубликовал её и узнал много нового об алгоритмах diff. Библиотеку можно найти по адресу znkr.io/diff, а в этой статье я расскажу о своих открытиях. Я ещё не завершил освоение, поэтому планирую дополнять статью в процессе изучения.

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

Конвейер непрерывной интеграции и поставки CI/CD является эффективным инструментом быстрого и качественного выпуска программного обеспечения. Разработчики и тестировщики активно используют те преимущества непрерывной разработки, которые дает данный пайплайн. Но экосистема решений 1С тоже позволяет построить конвейер CI/CD.

В этой статье мы рассмотрим построение такого пайплайна на основе инструментов, предлагаемых 1С.

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

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

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

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

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

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

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

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