Git *

Привет, Хабр! Значю, что вам на это плевать и вы не хотите это читать, но я все равно продолжу это писать:) В общем, Sheet-Native Computing Foundation продолжает цвести и пахнуть и у нас даже есть сторонние контрибьюторы. А чего добились вы?

Итак, вот что теперь можно сделать в таблице: запушить в неё настоящий OCI-образ контейнера и вытянуть его обратно. Не ссылку на образ, не метаданные о нём — сами слои, хранящиеся как base64 по ячейкам, с адресацией по sha256, собирающиеся байт-в-байт на выходе. У SheetHub — нашего форжа в стиле GitLab, который работает на Google-таблице — появился реестр контейнеров, и он целиком живёт в ячейках.

Этот пост — про то, как это всё устроено.

Как завести свой Git на небольшом VPS и не превратить его обслуживание в отдельный проект? Показываю свой путь с Gitea: настройку пользователей и SSH, перенос репозиториев из GitHub и подключение CI через Gitea Actions. А затем проверяю бэкап делом - восстанавливаю из внешней копии. С командами, ошибками и оговорками по безопасности - для личных проектов и небольших команд.

Секрет попадает в репозиторий почти всегда одинаково. Разработчик случайно коммитит файл с ключом доступа, замечает это, удаляет файл, делает коммит «убрал лишнее» и выдыхает.

Ключ при этом остаётся на месте: он лежит в объектах истории и достаётся одной командой. У всех, кто успел склонировать, — тоже.

Случалось ли вам добавлять в Git что-нибудь по ошибке? Если это было что-то вроде функции для дебага, некорректного комментария или случайно скопированного файла, то можно это исправить следующим коммитом. Но сработает ли такое исправление, если вы (или ваш коллега) случайно добавили в репозиторий какой-нибудь секрет? Ключ от стороннего сервиса, логин/пароль от интеграции или даже дамп базы данных или всю папку /private/uploads? На первый взгляд - да, сработает, можно сделать новый коммит и удалить то, что было добавлено по ошибке. Но дело в том, что эти данные все равно останутся в репозитории. По истории коммитов можно вернуться назад во времени (до исправления) и увидеть данные, которых уже нет в последней версии репозитория.

Всем привет!

Почти каждый, кто работал с Git больше пары недель, хоть раз сталкивался с одной и той же путаницей: почему git add — это не сохранение, зачем нужен какой‑то отдельный индекс, если есть коммит, откуда вообще берутся конфликты при мерже, если мы просто оба поправили один файл. И почему иногда git status показывает файл как изменённый, хотя вы точно ничего не трогали.

Если вы так же знакомы с этими проблемами, а также с другими проблемами при работе с Git — эта статья для вас.

В этой статье cначала покажем, как Git на самом деле хранит файлы и их изменения, что такое индекс и почему он существует отдельно от рабочей директории и коммитов. Далее — как устроены ветки на уровне данных, а не только как указатель текущей линии разработки. После этого разберём, как Git определяет, какие именно строки поменялись, и как из этого механизма следует слияние т.е merge и, самое главное, конфликты при слиянии.

Изучив модель, пройдёмся по основным командам работы с файлами: add, rm, mv, restore, diff, log, stash, работу с .gitignore и с большими файлами.

А в конце мы вам покажем, как это всё применяется на практике.

Разговор с Claude Code остаётся на той машине, где начат. Разбираю, почему облачная папка эту задачу не решает, и шесть граблей, на которые я наступил, пока делал перенос сессий, памяти и инструментов между Linux, Windows и macOS.

Какое-то время назад я выкладывал статью на Хабр про свое obsidian хранилище.

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

Кроме простой структуризации и удаления лишнего, я также провел некоторые махинации над кодом dataviewjs своей библиотеки книг и доделал свою домашнюю страницу, добавив интеграцию со своей основной библиотекой и поработав на css составляющей. В общем-то были еще некоторые изменения, но об этом всем будет далее.

Coding agent может написать технически правильный код и всё равно сделать неправильное изменение. Причина не обязательно в модели или промпте. Репозиторий может содержать несколько правдоподобных источников, неявный ownership, устаревшие артефакты или доказательство, которое относится не к той ревизии. Для человека часть этих противоречий компенсируется контекстом команды. У агента этого контекста может не быть.

Разбираю, почему репозиторий становится частью среды исполнения, где заканчиваются возможности AGENTS.md и файлов инструкций и как из этой проблемы появился open-source framework AIRepo.

Пайплайн у вас есть. Он есть у всех: CI перестал быть предметом споров примерно тогда же, когда Docker перестал быть новостью. Именно поэтому разговор пора вести другой - не “зачем вам CI”, а можно ли верить вашему зелёному пайплайну, сколько он стоит и кто им владеет. Разбор в формате “зачем - как - чем - цена отказа” - пилот рубрики: дальше в ней будут другие практики, формат останется.

Сделал Status Line для тех, кто пользуется Claude Code CLI

Если вы работаете с клодом в терминале, то в одном месте он показывает:

• Модель и Effort;
• Текущую рабочую папку и ветку;
• Незакоммиченные изменения в GIT в этой папке;
• Есть ли что в очереди на push и pull;
• Расхождение основных md файлов;
• Текущий размер контекстного окна;
• Кэш: hit rate & TTL;
• Ну и лимиты, конечно же.

Очень удобно это все видеть в одном месте. Рассказываю про него в статье.

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

Суть проекта:

Проект был создан ради того чтобы вопервых заполнить моё портфолио и во вторых - исправить мою забывчивость в синтаксисе гита, т.к я иногда забываю команды для него, что замедляет мой прогресс

Цели проекта:

Привет, Хаброжители! В книге «Java для профи. Инструменты, фреймворки, тестирование, производительность» тандем опытных Java-разработчиков проводит краткий и авторитетный анализ самых распространенных методик, без которых не обойтись в корпоративной Java-разработке. Авторы дают ровно столько теории и примеров, сколько нужно, чтобы книга стала экспертным справочником по аннотациям, фрейм-воркам для логирования, наблюдаемости, настройке производительности, методам тестирования и совместной работе, на которые опирается реальная коммерческая Java-разработка.

«Java для профи» — идеальный выбор для всех, кто уже знаком с языком, но хочет освоить инструменты современной Java-разработки.

Хочу поделится с более конкретным примером и подробным описанием настройки плагинов для ArgoCD чем это описано в их офф документации.

Последние пару месяцев злоумышленник распространял трояны с нескольких npm-учеток: alex05255, mdrafiqulislamrabby, b.w1001, abdev8773 и mollspotwood54400.

Список пакетов:svg-fetcher, tradepilot, polytrade, polymarket-kit, react-svg-chunk, gamified-trading-system, font-huge, font-hub, mdb-vite, router-processor, route-processor.

Код, по классике жанра, навайбкожен. На это указывают избыточные поясняющие комментарии...

В условиях современного развития программного обеспечения и необходимости ускорения выпуска обновлений, автоматизация процессов разработки и доставки (DevOps) становится критически важной. Для экосистемы 1С, характеризующейся сложностью конфигураций, наличием множества расширений и необходимостью строгого контроля качества, ручные операции по сборке, тестированию и развертыванию становятся узким местом.

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

На протяжении многих лет использования git я выявил для себя одну серьезную проблему, которую этот инструмент не дает возможности разрешить удобным способом. Я назвал эту проблему “проблемой длинного прыжка”. Суть такова: у вас есть старая залежавшаяся ветка, которая отстает от main-ветки на сотни и тысячи коммитов. Задача - обновить эту старую ветку до свежего main. Все усугубляется тем, что у вас тяжеловесный репозиторий: гигабайты, десятки или сотни гигабайт.

Около двух лет я использую Obsidian как основное приложение для ведения заметок, планирования и написания статей. В этой статье я хочу поделиться своим полным workflow: от распределения заметок по папкам и горячих клавиш до детального Cheatsheet по хранилищу и организации метода Zettelkasten.

О чём будет статья:

Архитектура папок (где и что хранится, а также подробный Cheatsheet.md, который я составлял для себя).

Плагины, которые я использую.

Настройка Homepage и каталога книг.

Синхронизация ПК + телефон (плагин Git + Termux на телефоне, у меня репозиторий в Gitea).

Сразу уточню: Obsidian становится действительно удобным только тогда, когда человек сам собирает под себя хранилище и находить подходящий ему метод. Ниже я разбираю реализацию по частям, чтобы каждый мог изучить интересующий блок, взять полезные идеи или настроить всё аналогично у себя.

Я Анастасия, ведущий SRE-инженер РСХБ.Цифра. В этой статье я расскажу о том, как мы в App.Farm, PaaS-платформе Россельхозбанка, перешли от одной «большой» Kafka до реализации услуги «Kafka as a Service» c индивидуальными кластерами под ключ. Звучит просто, но за этим кроется сложный путь проб и ошибок. 

Копипаст .gitlab-ci.yml по десяткам сервисов привел к config drift: пайплайны расходились, а правка одной строчки требовала 10+ MR. Вынесли логику CI в отдельный репозиторий модулей, подключаемых через include с версионированием по SemVer — в проекте остается только короткий файл с переменными. В итоге миграция с Kaniko на BuildKit заняла 5 дней вместо 2-3 недель, а типовой багфикс на 20 сервисах — 1 час вместо 11.

По репозиториям на Git часто видно: вложенные пайплайны в GitLab CI остаются редкой экзотикой, а в проде в основном живут линейные сценарии. Тем не менее я убежден, что грамотные downstream'ы прекрасно связывают процессы в единый поток, снимают ручной труд с команды и добавляют архитектуре гибкости. Конечно, запутаться в многоуровневой логике может даже опытный DevOps-инженер или тимлид, но чтобы вы не блуждали в сложной структуре, я подготовил для вас практическую шпаргалку по работе с ними.

Последние несколько лет я занимался сопровождением вендорской разработки, строил CI/CD преимущественно на базе Gitlab CI и мне есть что рассказать. Помните фильм «Начало»? Сегодня он станет нашим наглядным гидом по архитектуре наследуемых пайплайнов и, надеюсь, поможет вам взглянуть на многослойный CI‑конвейер под другим углом.