Git *

В вашем ядре сейчас есть баги, которые не найдут в течение многих лет. Я знаю это, потому что проанализировала 125 183 из них, каждый в 20-летней git-истории ядра Linux помечен прослеживаемым тегом Fixes:.

Средний баг ядра существует 2,1 года. А некоторые подсистемы намного хуже: драйверы CAN‑шины [шины сети контроллеров] — в среднем 4,2 года, работа с сетью SCTP — 4,0 года. Самый долгоживущий баг в моём наборе данных — переполнение буфера в ethtool — сохранялся в ядре 20,7 лет. Подробно остановлюсь на утечке памяти из‑за подсчёта ссылок в netfilter, существовавшей 19 лет.

Я создала инструмент, который выявляет 92% исторических багов в отложенном тестовом наборе данных о времени коммита. Вот что я узнала.

Кэш-монтирование в Docker — это мощный инструмент, который может значительно ускорить процесс сборки образов в CI/CD. Но его правильная настройка в GitLab требует понимания не только работы BuildKit, но и особенностей взаимодействия с различными конфигурациями GitLab Runner — DinD и DooD.

В этой статье я расскажу об устройстве кэш-монтирования в Docker и как его использовать в GitLab CI/CD. На примере простой сборки Python-проекта покажу готовые решения для кэширования зависимостей, чтобы оптимизировать сборку Docker-образов.

Entire с его первым тулом под названием CheckPoints решает проблему, которую сам же основатель проекта Томас Домке и создал в Microsoft.

Привет, Хабр, меня зовут Александр Мачулин, я основатель Gramax, open source системы для ведения документации в подходе Docs as Code с визуальным редактором. Gramax хранит контент в git-репозитории. Это означает, что у пользователей могут возникнуть конфликты при синхронизации изменений. Я считаю, что нагружать пользователей решением конфликтов – не очень хорошо и пытаюсь найти решение для этой задачи.

Привет, Хабр! Я Паша, разработчик Gramax — Open Source платформы для управления документацией в подходе Docs as Code.

В прошлой статье я рассказывал о том, как мы переводили наше приложение с Isomorphic Git на libgit2, как засунули его в веб-версию приложения при помощи Emscripten и с какими трудностями столкнулись в процессе.

На этот раз — как мы оптимизировали хранение файлов ресурсов каталога (в большинстве случаев, изображений) при помощи Git LFS, тем самым ускорив его клонирование и синхронизацию.

Привет, Хабр! Недавно GitHub выкатил крупное обновление Copilot CLI — теперь это не просто подсказчик команд, а полноценный агент, который умеет планировать задачи и вести диалог. Разберём, что нового появилось и как с этим работать безопасно.

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

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

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

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

Привычные UI‑автотесты часто проверяют отдельные кнопки и формы, но не отвечают на главный вопрос: работает ли система целиком в реальном пользовательском сценарии. В этой статье я расскажу, как мы в TData строим интеграционные тесты для Web UI, которые проходят путь от создания провайдера и кластера до установки компонентов, настройки конфигурации и проверки, что всё действительно поднялось и работает.

Теперь легко и просто можно попробовать поиграться в упаковку скиллов - до всяких платных Claude Code и Clawdbot/Moltbot. Напомню, что это способ превращать удачные сессии с агентом в переиспользуемые сценарии /воркфлоу для агента: один раз настроили, дальше запускаете по команде и получаете результат в том же стиле.

В Manus это можно попробовать и бесплатно. К тому же, вы можете даже скачать Skill, который вы сделали совместно с Manus, тоже совершенно бесплатно.

Я проверила это на простом и полезном кейсе: агрегатор свежих AI-новостей с Reddit, который делает выжимки под Telegram. Ниже по шагам и со скринами.

Контроль версий долгое время был для меня «чёрным ящиком»: я не понимал, как именно хранятся файлы, как формируются diff’ы и из чего состоят коммиты. А поскольку я люблю изобретать велосипеды, почему бы не попробовать реализовать git самому?

В начале XVI века была издана книга английского юриста и философа Томаса Мора под названием "Утопия", в которой описывалась идеальная по мнению автора структура общества. Название этой книги стало именем нарицательным и дало имя всему жанру подобных трактатов. Книга Мора была далеко не первой: ещё за две тысячи лет до её выхода в свет древнегреческий философ Платон опубликовал трактат "Государство", в котором излагал свои взгляды на общественное устройство. Кто только не создавал своих утопий: например, Карл Маркс с его манифестом коммунизма и диктатурой пролетариата или Карл Поппер с его "Открытым обществом и его врагами". Почему бы не сделать этого и мне?

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

В основании этой метаутопии лежат два инструмента программирования - типизированный язык программирования и система контроля версий. Возьмём для примера в качестве языка программирования TypeScript, а в качестве системы контроля версий - Git. Сегодня на TypeScript пишут и веб-приложения, и мобильные приложения, и программы командной строки, и сервера для приложений. Почему бы не написать на нём государство?

Переработка проекта Mini Tower Kit для Rasberry Pi 5 под Rasberry Pi 4 с приятным тюнингом или когда Pi 5 не завезли, а руки всё равно чешутся

Большие языковые модели по-прежнему часто выдумывают детали, если им не хватает контекста. Чем сложнее проект, тем сильнее это ощущается: ИИ не знает структуру вашего репозитория, не видел свежую документацию библиотеки, не понимает бизнес-ограничения продукта.

В статье разберем, как аккуратно подложить модели нужный контекст: от встроенных механизмов в IDE и Claude до утилит для выгрузки репозитория и MCP-серверов, которые подтягивают актуальные документы и данные.

1. Что сделал?
Переехал с GitLab на свой сервер, написал свой python-скрипт, который мигрирует не просто все репозитории, но и настройки, описания, картинки(done) и мердж/пулл-реквесты(in-progress). Бонусом настроил простой git fetch/push одновременно на все GitLab, GitHub, ... remotes.

2. Зачем?
Локальный сервис независим от РКН, КВН, "чебурнета" и гео-блокировки аккаунта, бэкап под контролем, без опасения утечек из облаков по независящим причинам.

3. Как?
Когда у тебя несколько десятков pet-проектов на Gitlab/Github, для каждого копи-пастить git clone/push --mirror со многими параметрами и вручную копаться в web интерфейсах откровенно "скучно и лениво".

В статье: поиск решения по полной миграции, комментарии по коду и настройки скрипта. Вторую часть по мульти git fetch/push оформляю

Гуглил похожие решения, не нашел. В итоге написал свое.

Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.

А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.

Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.

Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.

Меня зовут Александр Мачулин, я основатель Gramax – open source системы для ведения документации в подходе Docs as Code с визуальным редактором.

Сегодня я расскажу вам идею, как вести всю документацию по проекту и весь цикл разработки в одном Git-репозитории и настроить backward-трассировку требований в Git.

Сейчас все обсуждают Claude Code, Antigravity, Codex, спорят, коллекционируют “скиллы” для агентов. Но на практике у большинства всё ломается на первом шаге: люди пишут “сделай мне приложение” — и получают либо кашу, либо минус лимиты.

Вайбкодинг работает, когда вы управляете процессом, а не просите все и сразу. Базовый рабочий пайплайн простой:

спецификация → план → маленькие итерации → тесты/ревью → фиксация изменений (git)

Ниже - тот самый “скелет”, который можно повторить почти для любого проекта.

Долгие ML-тренировки, срочные PR и боль от git checkout посреди эксперимента – знакомо?
git worktree позволяет держать несколько веток в разных директориях одновременно и не убивать запущенные процессы.
В статье – практический workflow для ML-инженеров: параллельные эксперименты, большие датасеты, изоляция окружений и интеграция с Cursor. Всё – с командами и реальными сценариями.

Прямо сейчас в вашем ядре есть баги, которые не найдут ещё многие годы. Я знаю это, потому что проанализировал 125183 бага с отслеживаемой меткой Fixes: за 20-летнюю историю Git ядра Linux.

Прежде чем баг обнаружат, он в среднем живёт в ядре 2,1 года. Но в некоторых подсистемах ситуация гораздо хуже: для драйверов шины CAN этот срок в среднем составляет 4,2 года, для сетевого протокола SCTP — 4,0 года. Самый долгоживущий баг в моём датасете (переполнение буфера в ethtool) прятался в ядре 20,7 года. Баг, который я проанализирую в статье подробно (утечка refcount в netfilter), прожил 19 лет.

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

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