Git *

Сейчас сложно представить мир разработки программного обеспечения без git – распределенной системы контроля версий. Хотя еще 10 лет назад во многих компаниях использовались другие инструменты: CVS или SVN. Бывали даже такие команды, в которых и вовсе не велось версионирование кода. А 20 лет назад git только-только был создан Линусом Торвальдсом и начал распространяться в среде самых продвинутых разработчиков того времени — участниках опенсорс комьюнити вокруг ядра линукса.

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

Первый коммит гите был сделан 7 апреля 2005 года с описанием: Initial revision of "git", the information manager from hell. В английском языке слово гит означает «неприятный человек», и хотя история благодушно умалчивает, почему Линус назвал свой инструмент именно так, мы можем быть уверены, что в этом названии отражена та сложная обстановка, в которой оказались создатели ядра линукса в начале 21 века. Дело в том, что в начале разработки ядра Linux использовался проприетарный (то есть принадлежащий конкретной компании и не являющийся свободным) инструмент управления версиями под названием BitKeeper. Однако в 2005 году возник конфликт между разработчиками Linux и компанией-разработчиком BitKeeper, в результате которого была отозвана бесплатная лицензия разработчиков ядра.

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

Как-то пару месяцев назад пришел ко мне в гости в коворкинг поработать удаленно мой давний приятель. Он пишет на Java и использует в своей работе IntelliJ IDEA. Помню, он долго восхищался новой на тот момент фичей встроенного AI Assistant - умением генерировать commit message.

На тот момент я как-то не сильно проникся идеей автогенерации сообщения, потому что я, как человек, который ответственен за процесс code-review в своей команде, с трепетом отношусь к описанию коммита. Прошло немного времени, у меня по работе прилетела задача рефакторинга довольно объемного куска кодовой базы. Причем, эта задача была разбита на подзадачи, связанные с микросервисами. Поэтому, мне надо было писать довольно объемные коммит-сообщения по завершении каждой итерации. И тут я вспомнил про своего приятеля, когда он за минуту редактировал сгенерированное сообщение от AI ассистента и экономил немало времени.

Привет! Я старший fullstack-разработчик в крупной b2b-команде, где мы активно развиваем IT турпродукты и сопровождаем легаси-проекты. Недавно мне довелось временно заменить тимлида — он ушёл в отпуск, оставив напоследок фразу: «Ты не будешь деплоить».

Спойлер: деплоил. И не просто деплоил, а чуть не похоронил релиз из-за одного неосторожного git reset --hard. К счастью, всё закончилось хорошо — но пришлось восстановливать ветки из GitLab’а, бороться с удалённой историей и вручную черри-пикать задачи.

Рассказываю, как всё было, какие выводы сделал и чего теперь точно делать не буду. Надеюсь, кому-то это сэкономит пару нервных клеток.

Ваше приложение на Go начало тормозить. Первая мысль? Наверное, база данных медленно отвечает. Вторая? Может, сеть лагает. Мы начинаем строить догадки, добавлять кэши, оптимизировать запросы, переписывать SQL-конструкции, дергать девопсов... и часто бьем мимо цели. Мы тратим часы, а то и дни, на оптимизацию того, что и так работало нормально, в то время как настоящая проблема прячется в совершенно неожиданном месте нашего собственного кода. Знакомая боль, не правда ли? В этой статье мы разбираем как работать со встроенным профайлером в Пo.

Научись использовать Git как профессионал. Эта статья поможет тебе освоить самые популярные команды Git на реальных примерах. Узнай, как добавлять изменения, создавать коммиты, переключаться между ветками, объединять изменения и синхронизировать проект с удалённым репозиторием.

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

Почему «последняя миля» в тестировании безопасности — это провал: статистика OWASP и NIST о том, как 97% приложений содержат уязвимости, а исправление ошибок после релиза обходится в 6 раз дороже.

Как DevSecOps убирает барьеры между командами: интеграция безопасности в CI/CD, автоматизация проверок и сдвиг «влево» (Shift Left) — от теории к реальным кейсам Microsoft, Netflix и Capital One.

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

Вызовы внедрения и пути их преодоления: от сопротивления изменениям до обучения разработчиков — шаги, которые сделают вашу команду готовой к цифровым угрозам будущего.

Статья подойдёт для разработчиков, руководителей IT-команд, специалистов по кибербезопасности и всем, кто хочет превратить уязвимости в прошлое.

18 июня будет два года как я создал сообщество "Код на салфетке". Сразу оговорюсь, что это некоммерческая история и возникло оно как решение важной для меня проблемы: "недостаток информации для начинающего разработчика". В процессе моего обучения и развития я сталкивался с различными нюансами, которые решались достаточно просто, но найти "комплексный ответ" зачастую было очень трудной задачей.

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

За эти два года мне в личку и в чат Telegram-канала довольно часто пишут новички и их вопросы можно разделить на две категории:

В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.

Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.

В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.

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

Мы с радостью объявляем о релизе GitLab 18.0 c GitLab Duo в планах Premium и Ultimate, автоматическими ревью мерж-реквестов с Duo Code Review, улучшенным контекстом Duo Code Review, фичей Repository X-Ray, доступной для Gitlab Duo с самостоятельным хостингом и многими другими фичами!

Технические команды часто избегают лишней документации, но информация всё равно каким-то образом передаётся, сохраняется и развивается. В этой статье — попытка разобрать скрытые механизмы общения внутри инженерных команд: как выстраиваются негласные соглашения, каким образом рождаются "внутренние диалекты" и зачем вообще всё это, если есть JIRA, Confluence и куча других инструментов. Много примеров, блоков кода на разных языках и немного личного опыта.

В прошлой своей статье я рассказывал о том, как начинал создавать свой якобы «терминал». Её заметило две с лишним тысячи человек, что для меня уже было каким‑то неплохим числом. Некоторые писали мне различные советы, кто‑то давал критику по статье. И вот, спустя небольшое время работы я снова пишу статью о своем «терминале» под именем Terminode. Вот она вторая часть «новичка пишущего терминал».

Инфраструктура как код, GitOps, автоматизация — все эти слова давно перестали быть модными терминами и стали частью повседневной жизни инженера. Но вместе с этим появляются и вопросы: а всегда ли нужно внедрять тяжелые инструменты? Например, зачем нужен ArgoCD, если можно просто настроить cron с git pull на нужный сервер?

Попробуем разобраться, в чём разница между этими подходами, какие задачи они решают, где их границы применимости и, главное, в каких случаях cron — это «дешево и сердито», а когда он становится «дешево, но больно».

Встроенная командная строка в Windows не устраивает многих разработчиков. У нее скудный функционал, нет «запоминания» и многих других функций, который были бы полезны её пользователям. Поэтому я решил попробовать сделать свою «консоль», с возможностью создания своих модулей для расширения функционала.

Для этого, на языке программирования Python я начал писать своё CLI‑приложение, которое упрощает работу с консолью. И что из этого вышло?

Мы с радостью объявляем о релизе GitLab 17.11 с настраиваемыми фреймворками соответствия требованиям, ещё большим числом ИИ-фич, доступных в GitLab Duo с самостоятельным хостингом, кастомными полями эпиков, тикетов и задач, входными параметрами конвейеров CI/CD , графическим интерфейсом для управления сервисными аккаунтами и многими другими фичами!

Я давний пользователь GitHub. Можно сказать, что на моих глазах он вырос из самобытного GIT-хостинга до внушительной экосистемы для разработчиков под патронажем само́й Microsoft, и по факту стал индустриальным стандартом.

Со временем я стал задаваться вопросом — можем ли мы в своей стране своими силами создать аналогичную экосистему? В которой нет проблем с платежами, не удаляют репозитории и аккаунты из-за поездки в Крым, где российские компании заказчики не опасаются хостить свои коммерческие проекты. В 2023 году я попробовал GitFlic, но не смог им пользоваться из-за нестабильной работы репозиториев. В 2025 году я решил попробовать GitVerse. Проекту уже больше года, и, скорее всего, он созрел для реального применения. В первую очередь меня интересует, есть ли у GitVerse потенциал стать не просто надёжным хостингом для GIT-репозиториев, а развиться в мощную экосистему, не просто повторить функционал GitHub в масштабе 1:43, а реализовать новое поколение индустриальных стандартов для совместного творчества разработчиков и других IT-специалистов.

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

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

На проекте была одна довольно типичная и, мягко говоря, надоедливая проблема: разработчики вручную заполняли CHANGELOG при выкатке новой версии приложения. Иногда информация туда попадала точная и соответствующая реальным изменениям, иногда – частично верная, а иногда и вовсе напрочь забытая.

Решение нашлось довольно элегантное – интегрировать инструмент semantic-release в наш пайплайн CI/CD. Но оказалось, что найти полноценное руководство по его настройке, особенно с учетом корпоративного GitLab и плагина semantic-release/changelog, не так-то просто. Собирал информацию буквально по крупицам из различных источников, и вот теперь делюсь с вами проверенной пошаговой инструкцией.

Пишу про полезные материалы про IT, и собираю свой ламповый нетворкинг тут - https://t.me/+434aQiGpZtAyNTU6. Присоединяйтесь!

Оглавление.

На входе — обычный push. На выходе — коммит, улучшенный с помощью LLM, сохранённый в векторной базе, доступный для поиска и семантического анализа. Пишем простой MCP-сервер для трекинга изменений ваших проектов.