Git *

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

В статье разберем, как аккуратно подложить модели нужный контекст: от встроенных механизмов в 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% исторических багов в тестовом датасете на этапе коммитов. Ниже я расскажу, какую информацию мне это дало.

В этой статье мы разберём Dokploy — open-source платформу для деплоя приложений. Узнаем, какие задачи она решает, какие функции предлагает и чем отличается от популярного конкурента Coolify. В конце вы поймёте, подходит ли Dokploy для ваших проектов.

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

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

Мне приходилось внедрять ИИ в продакшн-среду в разных доменах — от классических моделей классификации до разворачивания собственных серверов под локальные LLM и интеграции генеративных моделей для усиления командной работы. В каждом случае вывод оказывался одинаковым.

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

Я как-то писала про Claude Code. По ощущениям, многие вайбкодеры сейчас выбирают его как основную CLI-среду для агентского кодинга. Между Codex, Gemini и Claude Code часто выбирают последний- за быстрые итерации и удобство. Собрала в одном месте полезные ресурсы про Claude Code. 

Всем привет!

В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.

В этой части продолжим разбираться с параметрами и особенностями конфигурации: триггеры, job’ы, артефакты и многое другое.

Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

В этой статье мы рассмотрим, как использовать нейросети для описания кода через VS Code и как вносить изменения в описание в репозитории с помощью MCP-сервера GitHub.

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

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

В экосистеме 1С исторически существовало собственное хранилище кода, и Git долгое время казался чужаком. Но прогресс не стоит на месте, сейчас 1C:Enterprise Development Tools умеет работать с Git по дефолту, поддерживает групповую разработку и Git‑хуки. Хуки — это скрипты, которые автоматом выполняются при наступлении определенных событий в репозитории: коммит, пуш, слияние и так далее.

Я Олег Одинцов, платформенный инженер App.Farm. App.Farm — собственная разработка Россельхозбанка, которая используется для стандартизации процессов разработки программного обеспечения и предоставления высокоуровневого интерфейса пользователям для автоматизации их задач. Можно сказать, что App.Farm — это автоматизация «под ключ». Пользователь получает полный цикл управления разработкой от размещения кода до деплоя приложений. Более «смузийное»  название — IDP платформа.

Всем привет!

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

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.

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

Привет, я Павел Таланов из команды Yandex Infrastructure. Вместе с командой мы создаём SourceCraft — платформу для полного цикла разработки IT‑продуктов. Хочу рассказать о прикольной задаче на стыке бэкенда и IDE, которую мы решали, чтобы сделать ещё более удобную навигацию по коду в SourceCraft — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

Расскажу про требования, которые мы выявили для поиска по коду, чуть‑чуть про предметную область, а также о том, какая архитектура индексации у нас в итоге получилась — и почему.

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

Привет, на связи Ксюша, миддл-разработчик Surf. Миддлом я стала недавно. Когда я пришла в компанию, я, конечно, знала, что такое Git. Ну, по крайне мере, я так говорила. 

Как-то я, по чистейшей случайности, разумеется, перезаписала чужую ветку. А потом потратила часов 6, чтобы вернуть всё «как было». Благо, помог наш лид, который показал, что делать.

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