Что будет, если взять один HTML-файл, браузер, localStorage и git-хостинг с CRUD API? Получится мессенджер. Без backend, базы данных, регистрации, npm и WebSocket. В статье показываю, как устроен Macaroni Messenger: хранение сообщений в .macaroni/, outbox, git-agnostic adapters, storage branch, plugin API и опциональное шифрование.
Снаружи всё выглядит технологично: пайплайн анализирует изменения, линтер находит ошибки, а ИИ оставляет замечания к коду. В реальном процессе разработчики продолжают вручную обновлять файлы, применять исправления и заполнять метаданные.
В этой статье разберём четыре сценария псевдоавтоматизации и рассмотрим, где система должна переходить от комментариев к действиям.
Почему в гите нет команды git pull --force.... Зачем она могла бы быть полезна? Смотрите:
Существует прекрасная общепринятая схема работы с контролем версий — у каждого разработчика своя копия проекта, коммиты в ветки, мерж, test‑сервер, pre‑prod, CI/CD.
Для больших проектов все отлично и автоматизировано. Нет никаких сомнений что так и должно быть, НО...
Есть мелкие проекты — какой‑нибудь сайт, где раз в пару месяцев надо внести небольшие правки и заказчик при этом каждый раз нанимает разных фрилансеров.
Приходится работать на общем тестовом сервере, заливать файлы по sFTP и делать коммиты с локалки но как тогда поддерживать актуальность гита на этом самом сервере?
Я больше года не пишу код руками — всё пишет ИИ. Но я не вайбкодер, и это две разные профессии. Рассказываю, в чём разница, почему она скоро будет стоить компаниям дорого, и при чём тут Git-клиент, который я написал, чтобы пройти корпоративную ИБ.
Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).
Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.
Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера.
Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием.
В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?
Привет, Хабр!
В прошлой части мы разобрали основные инструменты приведения истории GIT в порядок, в этот раз мы постараемся ответить на ряд вопросов, которые позволят нам чуть глубже понимать механизмы работы с историей коммитов и даже попытаемся провести настоящее детективное расследование и выйти на авторов, которые внесли те или иные изменения в код!
Дисклаймер: вся статья это мнение автора, если вы не согласны или готовы предложить что-то, то прошу в комментарии.
IT охватывают огромный простор навыков и идей, многие из них специфичны и предназчена для узкого круга профессий. При этом существуют навыки, которые или универсальны для всех, или не будут лишними точно. В данной статье пойдет речь про Git, SQL и NoSQL, Linux, базовый азы алгоритмов и структур данных и о английском языке. Дополнительно поставил себе задачу, добавить как можно больше бесплатных или квази-бесплатных ресурсов.
Вы почти наверняка уже встречались с Conventional Commits. Их уродливые лица можно заметить в changelog опенсорсного проекта, которым вы пользовались. Возможно, это был обязательный формат коммитов опенсорсного проекта, в котором вы были контрибьютором. Многие люди безгранично им верят. Я им безгранично не верю.
Хоть он и применяется в большом количестве разных популярных опенсорсных проектов, Conventional Commits — это глубоко порочный стандарт, стимулирующий фокусироваться не на том и не оправдывающий свои ожидания.
Любой AI-инструмент умеет генерировать commit message. Проблема в том, что он генерирует что-то разумное — но не то, что принято в вашем проекте: не знает ваш формат с тикетами, не вытаскивает номер задачи из ветки, не учитывает какие типы у вас разрешены.
В этой статье я покажу как один раз описать правила своего проекта так, чтобы AI следовал им предсказуемо — каждый раз. Основной пример на Claude Code, но паттерн и готовый скрипт переносятся на любой инструмент: Cursor, Copilot Chat, git hook с API-вызовом.
KODE.market: Как я написал первый в мире поисковик по GitHub и GitLab + P2P-раздатчик open-source кода + Антивирус.
Без модерации, комиссий и SEO-мусора. Мгновенный поиск, проверка идей + гибридная раздача релизов в одном инструменте.
Привет, Хабр! На связи TechnoL0g. Если вы хоть раз пробовали опубликовать своё детище в официальных сторах или годами поддерживали open-source репозиторий, то прекрасно знаете, сколько боли приносит классическая дистрибуция.
Я думал, проект готов к релизу. CI думал иначе — и оказался прав десять раз. История про то, что видно только на чистом раннере.
«Полностью готовый» и локально зелёный проект — а первый же полный прогон CI вскрыл десяток скрытых проблем: версия CMake на Ubuntu 22.04, строгий GCC 11, артефакты с 403 от CDN, ASan под valgrind, недоступный из сети реестр и другие. Показываю каждую проблему с настоящим сообщением об ошибке и решением, а заодно — как поднял свой раннер, выпустил релиз руками без раннеров и ускорил пайплайн с 53 до 15 минут. Мораль: CI ловит ровно то, что невидимо на машине разработчика, — версии инструментов, окружение и сеть.
Когда несколько разработчиков хотят одновременно показать свои изменения — локальной разработки уже недостаточно. В статье разбираем, как автоматически поднимать изолированные окружения в Kubernetes по PR с лейблом и так же автоматически удалять их при закрытии.
Реализация построена на FluxCD с использованием директивы postBuild для шаблонизации манифестов через переменные. Каждое окружение получает собственный namespace, базу данных, TLS‑сертификат и уникальный URL — и всё это без ручного вмешательства. Разбираем структуру CI/CD пайплайна, слоёвую организацию GitOps‑репозитория и автообновление образов через ImagePolicy.
Представьте, что завтра из нашего мира исчезнут все проекты Линуса Торвальдса. Ваш смартфон на Android моментально превратится в кирпич, интернет ляжет, а вся командная разработка ПО намертво встанет без Git. Удивительно, но вся современная цифровая инфраструктура держится на решениях, которые были придуманы одним человеком не ради миллиардов или славы, а просто из любопытства. В этой статье вспоминаем путь главного интроверта IT: от попыток починить старый Commodore до создания ядра Linux, победы над Microsoft и революции в Open Source.
Решил поделиться вполне элементарными, но такими полезными приемами работы с гитом, которые нарушаются постоянно не только новичками или молодыми сотрудниками, но и вполне опытными разработчиками !
Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.
В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.
Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.
Если вы работаете в большой компании и одновременно живёте там, где есть какие-то региональные ограничения на сервисы, у вас почти наверняка две VPN-конфигурации:
рабочая — для доступа к внутренним ресурсам (GitLab, Jira, Confluence и т.д.)
личная — для личных целей
И постоянное переключение между ними — это, мягко говоря, неудобно.
Всем снова привет!
Если вы работаете с Git дольше пары дней и хотя бы иногда подтягиваете чужие изменения, то вы, скорее всего, уже сталкивались с конфликтами.
В этой статье мы разберём, как действовать и, главное, мыслить в таких ситуациях. Проблема в том, что конфликтов в git может случиться куча: может сломаться ручной git merge, при git pull, может полететь при git rebase , git cherry-pick и т.д. Из-за этого одного конкретного решения нет, но зато есть общий принцип решения.
Командная разработка в 1С не обязана держаться на блокировках, непрозрачной истории и ручном разборе изменений.
В статье показываем, как перевести проект в 1С:EDT, настроить Git и Git LFS, организовать ветки для команды и аккуратно работать с конфликтами в XML‑метаданных.
Привет, Хабр! Хочется поделиться инструментами и практиками для работы с GIT, о которых не все знают, но которые сильно упрощают жизнь вам и вашей команде. Если кто-то хочет чтобы ваша история коммитов была читаемой, легкой для понимания и с возможностью заглянуть в любой коммит и понять, какие были произведены изменения, то эта статья для вас.
Здесь не будет базовых понятий и терминов, так как предполагается, что с основами GIT вы уже знакомы.
Привет, Хабр! Сегодня мы часто говорим про разные тренды в разработке — ИИ‑агентов, тестирование на ранних стадиях, прослеживаемость изменений, автоматизацию пайплайнов… Все эти тренды звучат убедительно, пока не упираются в реальность: требования лежат в на общих дисках, схемы — в картинках, контракты — в разных версиях, а история изменений размазана по инструментам.
Что делать с этим?
Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, чем полезен в этом случае подход GitOps и о том, как и в каких случаях это может упростить жизнь команде.
