Git *

гайд по синхронизации obsidian vault через git с шифрованием через git-crypt и gpg (заметки хранятся на сервере в зашифрованном виде, локально обычный markdown )

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

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

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

На своем тг-канале я предлагаю подписчикам выбор, какую бредовую идею запилить следующей. На этот раз подписчики выбрали новый челлендж: сделать Git в Telegram. Чтобы можно было через бота инитить проекты, пушить файлы, коммитить — и всё это в публичном канале с тредами.

С практической точки зрения этот проект нахуй не нужен. Есть гитхаб, есть гитлаб, есть куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Я тогда подумал: «Ну, бот на aiogram, база данных, пара команд — делов то))»

Словари, датаклассы и прочая е*атория

Когда я только начинал, первая мысль была: «Положу всё в JSON, на кой мне база данных?» Ну серьёзно, проектов мало, пользователей немного, файлы текстовые че заморачитватся.

Подергал JSON туда-сюда пару дней и понял: не варик.

Во-первых, конкурентный доступ. Два юзера одновременно коммитят — один из них перезаписывает файл другого. Во-вторых, целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии. В-третьих, версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Короче, JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор пал на SQLite.

Почему:

Это перевод статьи с opensource.com, которая мне показалась особенно полезной и практичной, поэтому решил поделиться адаптированной версией для русскоязычной аудитории. Оригинал доступен по ссылке: https://opensource.com/article/22/10/docs-as-code

В статье разбирается подход Docs as Code — способ встроить документацию в процесс разработки так, чтобы она проходила через Git, ревью и автоматическую сборку вместе с кодом. Материал будет полезен разработчикам, тимлидам и тем, кто выстраивает инженерные процессы в команде.

Краткое пошаговое руководство, как настроить SSH‑подключение к GitHub: от создания ключа до проверки соединения. Подойдёт новичкам, которые хотят избавиться от постоянного ввода логина и пароля и безопасно работать с репозиториями

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

Разговор будет серьёзный. С 1 марта 2026 вся публичная информация для потребителя должна быть на русском — N 168-ФЗ. Пока что разработку это не касается, но стоит быть готовыми. Предлагаю договориться о словаре разработчиков Российской Федерации.

CLI-обёртка над git worktree на чистом Bash. Автоименование worktrees, централизованное хранение в ~/.git-wt/, копирование .env файлов, shell-автодополнение и поддержка AI-агентов через SKILL.md. Сделана для параллельной работы нескольких Claude Code / Cursor / Windsurf на одном репозитории, но полезна и для код-ревью, хотфиксов и тестирования. Ноль зависимостей, установка за 5 секунд.

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

Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис.

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

Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика.

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

Flutter & GitLab CI/CD. Доставка мобильного приложения в Significa, TestFlight и Google Play

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. После успешной настройки сборки и подписания Flutter-приложений во второй части, остался последний, но не менее важный этап — дистрибуция приложения.

В современных условиях автоматизация деплоя на такие платформы, как Google Play, TestFlight и Significa, становится необходимостью. В этой статье мы разберем, как с помощью GitLab CI/CD настроить автоматическую отправку ваших приложений в магазины, чтобы вы могли сосредоточиться на разработке, а не на рутинных задачах.

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

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

Unreal и Unity быстро превращают репозиторий в смесь кода, тяжёлых ассетов и командных привычек — и выбор VCS начинает влиять на работу каждый день. В статье сравниваются SVN и Git именно в контексте UE/Unity: блокировки файлов, права доступа, скорость, ветки и совместимость с CI/CD. Также разберем практические замечания по миграции и тому, как выстроить процесс так, чтобы он был понятен и разработчикам, и людям, которые живут в ассетах.

Прим: Дополняет мою статью "Скрипт полной миграции из GitLab на свой сервер".

После успешной миграции

А что делать со старым репозиторием?
Было бы логично использовать GitLab и другие хостинги в качестве вторичных (запасных).

Но как это делать? И еще не вручную?
Для синхронизации с remotes одновременно на свой Gogs и на все GitLab, GitHub, Bitbucket, ... remotes, об этом и других "хаках" ниже:

Привет! Меня зовут Дима, я руковожу группой прикладной разработки в Naumen. Много лет работаю с командами, которые делают не одноразовые фичи, а долгоживущие системы — те, что развиваются годами, переживают смену людей, требований и контекста.

В этой статье поговорим о декомпозиции: зачем она на самом деле нужна и какую неожиданную роль в этом играют атомарные коммиты.

OpenAI забирает к себе создателя OpenClaw Питера Штайнбергера, а сам OpenClaw переводят в формат независимого фонда и обещают поддерживать как open-source.
На первый взгляд, обычная кадровая новость. Но на самом деле это сигнал: гонка смещается от тех, у кого умнее модель к тем, у кого агент реально делает работу, и, что самое главное, при этом ему можно доверить доступы.

В статье разберем, что именно произошло, почему это удар не только по Claude от Anthropic (но и по нему в частности -ниже расскажу, почему у Anthropic тоже не все гладко), но и по всей экосистеме агентов. И что все это значит для безопасности ваших данных.

Мне 16 лет. Последние 8 месяцев я учусь на Frontend-разработчика. Я решил проверить свои силы и создать инструмент, которым буду пользоваться сам. Но мой путь начался не с мощного ПК и гигабайтов интернета, а с мечты и обычного смартфона.

Мой путь в программировании начался 26 декабря 2024 года. Это была мечта, к которой я шел 5 лет. На тот момент я был «полным нулем»: у меня не было стабильного интернета и я почти ничего не знал о Frontend. Я записался на курсы, даже не до конца понимая, что это такое.

Первые две недели у меня не было ноутбука, и я писал свой первый код прямо на телефоне. Только спустя время у меня появился ноутбук и нормальный доступ к сети, чтобы узнать: что такое Frontend и какие задачи он решает?

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