Git *

Docker Gitlab + Gitlab runners на Fedora 44. Как настраивал у себя и немного каких приколов может быть.

В предыдущих статьях мы разобрались, c Linux и Bash.

Следующая ступенька — Git.

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

На самом деле сегодня Git используют практически все инженеры, работающие с инфраструктурой. В Git хранят не только исходный код приложений, но и Dockerfile, Kubernetes-манифесты, Terraform-конфигурации, Ansible Playbook, Bash-скрипты и CI/CD-конвейеры.

Фактически Git стал центральной точкой любого современного проекта.

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

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

Познакомился я с ним ещё в универе. Сначала зацепили граф связей и нормальная работа с LaTeX. Кто учил билеты по физике, тот поймёт: формулы, ссылки между темами и быстрый поиск реально спасали.

С вышматом вышло хуже. Возможностей встроенного LaTeX мне уже не хватало, поэтому часть билетов я всё равно расписывал в тетради. В общем, Obsidian с вышматом не справился. Я, если честно, тоже не сразу.

Но к тому моменту программа уже прижилась.

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

Теперь захотелось проверить, можно ли приспособить Obsidian ещё и к работе.

Если вы применяете в своей инфраструктуре GitOps-подход, то вам точно знакомы такие решения по автоматизации доставки для Kubernetes, как FluxCD и ArgoCD. Это популярные инструменты, которые позволяют синхронизировать наполнение отслеживаемого Git-репозитория и отобразить его в кластере Kubernetes.

Сегодня воздержимся от их сравнения и сконцентрируемся на разговоре о том, какие удобства при работе может предоставить FluxCD.

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

Конфликты в Git заставляют немного паниковать, пока не научишься понимать, что именно происходит. Почему возник конфликт? Что я сделал не так? Не потеряю ли я свои изменения? И как теперь продолжить работу?

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

Что такое Git-конфликт?

Во-первых, Git позволяет нам, разработчикам, независимо работать над одним проектом в отдельных ветках. Пока изменения затрагивают разные файлы или разные независимые участки одного файла, Git обычно способен объединить их автоматически. Но что произойдет, если они затронут одинаковый участок файла? Давайте разберемся.

Статья получилась большой: практик много, и каждая из них важна по-своему. Я собрал материал как набор best practices: не все пункты нужны каждому проекту, но почти каждый пункт однажды всплывает на ревью, при оптимизации медленного пайплайна, при разборе утечки секрета или после тяжелого инцидента.

Я старался писать для разных грейдов: от базовой гигиены вроде workflow:rules, cache, artifacts и needs до более продакшеновых тем вроде OIDC, Vault, CI_JOB_TOKEN, защищённых окружений, ревью-окружений, очередей слияния, BuildKit без root-прав, CI/CD-компонентов и усиления защиты раннеров.

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

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

Оглавление:

1. Зачем вообще думать о GitLab CI/CD

2. Архитектура пайплайна и базовая YAML-гигиена

3. rules, workflow:rules и управление созданием пайплайна

4. DAG, needs, параллелизм, матрицы и быстрые пров...

Всем привет от команды DFIR JetCSIRT! Хотим поделиться с вами одним интересным кейсом, эмоции от которого прекрасно описывает обложка...

Заказчик заводит запрос на расследование, в котором говорит, что учетная запись разработчика пушит непонятные коммиты в GitLab. По почте они установили, что пользователь выпустил себе несколько access-токенов, при этом новых входов в веб GitLab в этот период зафиксировано не было.  Подозревают, что скомпрометирован личный комп пользователя, с которого он работает с GitLab. Важное дополнение: в коммитах они видят заголовок X-BugBounty, но, со слов Заказчика, они не участвуют в программе багбаунти, поэтому уверены, что так маскируется злоумышленник. Заблокировали учетку разработчика и начали собирать триаж с его АРМ на анализ...

Что будет, если взять один 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.