Git *

Пайплайн зелёный, а релиз не состоялся. Образ на всех этапах один и тот же, но это не точно. Отдельные хуки и скрипты вместо единого конвейера .gitlab-ci.yml. Привычный CI/CD с GitOps перестаёт существовать.

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

Привет, Хабр! Меня зовут Никита Калганов, я ведущий системный инженер данных в X5 Tech. Мы с командой проектируем и развиваем высоконагруженную систему потоков данных и поддерживаем её в условиях постоянного роста, как по числу потоков, так и по количеству команд, которые с ней работают.

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

С ростом количества кластеров Kubernetes и управлять ими становится сложнее. GitOps и FluxCD меняют хрупкую push-модель на более безопасную pull-модель. Однако инженерам особо не легче. Они часто сталкиваются с путаницей в зависимостях и, как следствие, неожиданным поведением контроллеров. 

Привет! На связи Константин Копыло́в, системный администратор в Selectel. Сегодня разберем частые ошибки и посмотрим на лучшие практики. Статья будет интересна администраторам Kubernetes, которые хотят внедрить GitOps, а также архитекторам и тимлидам, проектирующим инфраструктуру для новых проектов.

Уход ключевого разработчика может обнажить проблему, которая годами оставалась незаметной: команда формально владеет модулями, но фактически не знает, как с ними работать. История Git позволяет оценить концентрацию авторства и заранее увидеть, какие файлы останутся без активного автора, если уйдёт лидер. В статье разбираем методику расчёта truck factor, шесть типичных управленческих ошибок и то, как AI‑агенты дополнительно усложняют оценку распределения знаний.

Почти весь код своего проекта kb-engine я писал вместе с ИИ-агентом и быстро понял: правило, которое можно пропустить, когда неудобно, никто соблюдать не будет. Работает только то, что проверяет код.

Сейчас в проекте 21 автоматическая проверка. Вот пять историй, и в нескольких из них проверка была зеленой и при этом ничего не проверяла.

В этой статье мы рассмотрим подход как просто, эффективно и, самое главное, бесплатно отслеживать изменения групповой политики (GPO) Active Directory.

Если вы не единственный системный администратор в компании, своевременно ли вы узнаете, что кто-то из коллег изменил групповую политику? Обычно утром кто-то звонит и спрашивает - “А кто-то что-то менял в политике? У меня не работает/не подключается…”

Хорошо когда для мониторинга есть отдельный продукт, а если нет?
Использование репозитория git поможет легко и наглядно следить за изменениями объектов.

TLDR;
Идея: регулярно экспортировать GPO в xml и загружать на сервер git
Результат: бесплатный мониторинг изменений политики с минимальными трудозатратами

Две команды git notes add добавляют заметки к двум разным коммитам одновременно. Обе завершаются с кодом 0, но одна заметка исчезает: на обычной Linux-машине — в 25 запусках из 30. Фарид Закария нашёл эту гонку своей детерминированной виртуальной машиной Rewind VM и показывает, как тремя вопросами к записанным прогонам дойти от «тест иногда падает» до одной строки в notes-utils.c, которая обновляет ссылку refs/notes/commits без проверки, что её не успел изменить соседний процесс. Патч уже отправлен в рассылку git.

Конфликты при слиянии веток в Git часто обнаруживаются в самый неподходящий момент — когда изменения уже готовы к интеграции. Но что, если результат merge можно проверить заранее, не затрагивая рабочую директорию и текущую ветку? Разбираемся, как с помощью git merge-tree увидеть потенциальные конфликты ещё до слияния и что для этого умеет сам Git.

Почему в git fetch origin master пробел, а в git switch -c my-feature origin/master слеш? Алексей Кладов (matklad) много лет пользовался Git, представляя его контентно-адресуемой базой коммитов, и только недавно разглядел рядом с ней обычное изменяемое хранилище «ключ — значение» — ссылки в .git/refs. Разворачиваем сокращения fetch до полной формы refs/heads/master:refs/remotes/origin/master, разбираемся, зачем Git держит у себя копию чужих веток и почему git switch -c refs/heads/x создаёт refs/heads/refs/heads/x.

Если вы работаете в стиле «одна задача — свой worktree», у вас наверняка скопилась папка, где рядом лежат полдюжины чекаутов одного проекта. Я в какой-то момент устал бегать по ним с git status и написал lsw — это «ls» для worktree. Одна команда показывает все репозитории и worktree вокруг: ветку каждого, есть ли незакоммиченные правки, насколько ветка ушла от origin. Read-only, без зависимостей, один бинарник.

Днём я занимаюсь корпоративными системами, а по вечерам делаю свои проекты с помощью Claude Code. В какой-то момент я заметил, что пишу код всё меньше, а работаю диспетчером всё больше: напоминаю агенту продолжить, перепроверяю его «готово», а утром обнаруживаю, что в час ночи закончился лимит подписки и всё стояло. Я написал для этого локальный надсмотрщик, AIWorks, а потом отдал ему на сутки его собственный репозиторий. Ниже — как он устроен, что получилось и, главное, что сломалось по дороге.

AI-ревьюер для GitLab, который проверяет не отдельный merge request, а всю задачу сразу, во всех сервисах, которые она задела. И почему для этого понадобился агент, а не анализ diff через API.

В вайбкодинге документацию первым читает агент, и открывает он почти только то, на что ему сослались. По журналам Claude Code одного моего проекта файлы без входящей ссылки агент открывал в среднем 1,2 раза, а 57 из 88 таких не открыл ни разу.

Раньше документацию писали в конце цикла, и читал её человек. В вайбкодинге код пишет агент, и получает он только то, что ему подали. Я посчитал по журналам за пять недель, какие markdown-файлы агент открывал. Точкой входа ниже называю то, чем агента запускают на задачу: файлы слеш-команд в .claude/commands и описания субагентов в .claude/agents. Документы, названные в точке входа, агент открывал в среднем 12,3 раза.

Компании всё активнее пользуются AI‑агентами: Claude Code, Cursor, Codex, Copilot. Вместе с агентами появляются и «скиллы» — инструкции, которые учат агента работать по правилам конкретной компании. Через пару месяцев оказывается, что эти скиллы лежат в Google Docs, Notion, личных папках и десятке git‑репозиториев. У кого‑то версия свежая, у кого‑то устаревшая, а проверял ли их кто‑нибудь на безопасность, никто сказать не может.

В статье разберём, что такое централизованное хранилище скиллов, какие задачи оно решает, и сравним четыре подхода к его построению: от «просто git‑репозитория» до готового SaaS. Статья рассчитана не только на разработчиков: все термины объясняются по ходу, а для менеджеров, аналитиков и специалистов по ИБ есть словарик и раздел «как выбрать».

Агент Claude Code ради одной цифры для статьи запустил платную серию запросов к ИИ-моделям, хотя правило в CLAUDE.md это прямо запрещало: в длинной сессии оно потерялось. Эта ошибка стоила только денег. Ключ в публичном коммите или выкладка без проверки обошлись бы дороже, и такие действия я проверяю хуками — кодом перед каждым вызовом инструмента.

Продолжение статьи о синхронизации Claude Code между машинами через git: пять новых граблей за месяц эксплуатации на двух реальных машинах — от веток в транскрипте сессий до секретов, которые чуть не стёрлись сами.

Мне давно нравится идея хранить заметки обычными Markdown-файлами в своём репозитории на GitHub. Файлы остаются твоими, их можно открыть на github.com или в любом редакторе, а история изменений достаётся даром: это просто коммиты.

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

Я переписал его так, чтобы сервер был не нужен вовсе. Получился Notewing: браузер сам ходит в GitHub API, изменения копятся офлайн и отправляются одним коммитом, а конфликтующие правки не теряются. В статье расскажу, как устроена синхронизация через Git Data API, где были подводные камни и как всё это тестировать, не трогая настоящий GitHub.

Привет! Меня зовут Илья, я занимаюсь автоматизацией разработки аппаратного обеспечения в YADRO. Эта статья будет посвящена масштабированию работающего в Docker контейнере под рабочей нагрузкой инстанса Gitlab. По мере роста команды производительности Gitlab, развернутого в одном Docker‑контейнере, становится мало. И масштабирование работающего под рабочей нагрузкой Gitlab, скажем, на десять контейнеров может стать нетривиальной задачей. Далее я на нашем примере расскажу, как это разумно организовать.

Файлы проекта лежали на диске, но AI-агент получил пустую рабочую копию. Причина нашлась в Git: исходники ещё не были закоммичены, а worktree создавался из HEAD.

На примере VECTA разбираю, что приходится строить вокруг запуска coding agent: снимки текущих файлов, восстановление событий после обрыва связи, права доступа и проверку результата. Объясню, как управлять задачей с другого устройства, почему worktree не заменяет песочницу и чего нельзя обещать от лимита расходов.

Тебе присылают папку с репозиторием. Ты её открываешь, и на твоей машине выполняется чужой код. Ты не набрал ни одной команды.

Это GitSpawn: восемь находок в семи кодинг-агентах. Агентам уже выкатили патчи, и это почти ничего не меняет, потому что твой собственный git status в той же папке по-прежнему выполняет чужой код. Проверял руками на git 2.53.0 и Claude Code 2.1.271.