Git *

git commit -m "WIP" — три слова, после которых начинается настоящий ад.

Доброго времени суток. Такая технология как Git в представлении не нуждается. Все знают add, commit, push — это как азбука. Но что делать, когда что‑то пошло не так? Ошибочный коммит прокатился по ветке? Надо срочно переключиться, но незавершенные правки мешают? Нужно перенести только одно исправление из другой ветки?

Знакомая ситауция? Тогда давайте разберем 5 команд, которые выходят за рамки базового workflow и реально спасают репутацию (и ваши нервные клетки).

Изначально я занимался одним проектом со стороны тестирования в роли старшего тестировщика. У нас микросервисная архитектура — около 15 сервисов хранится в Git. Для тестирования на стенде нужно развернуть примерно 5–7 сервисов за один релиз. Всего стендов два, и после тестирования их же нужно деплоить в продакшн.

Проблема в том, что у нас практически нет системы мониторинга состояния сервисов. Я не получал автоматической информации о том, что происходит с каждым из них, а расспросы коллег не давали ясных ответов.

Со временем мне стало важно быстро понимать, какие ветки задеплоены на конкретных стендах для всех сервисов, входящих в релиз. В Git такой возможности прямо из коробки нет — нельзя выбрать сразу список сервисов из разных проектов и посмотреть их окружения в виде таблицы или списка.

Поэтому мне приходилось делать так: заходить в каждый проект, открывать репозиторий сервиса, искать меню «Operate», затем «Environments» и там уже смотреть нужный стенд. И так — для каждого сервиса при деплое на тестовый стенд, при обновлении в продакшн или во время тестирования.

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

Экосистема продуктов 1С содержит много различных полезных инструментов разработки. Одним из них является 1C:EDT (1C:Enterprise Development Tools) — расширяемая среда разработки прикладных решений, созданная на основе свободной интегрированной среды разработки модульных кроссплатформенных приложений Eclipse.

1C:EDT поддерживает ключевые принципы создания прикладных решений на платформе «1С:Предприятие 8» и содержит большое количество инструментов автоматизации разработки, делающих работу программиста более быстрой и комфортной, а также позволяет расширять функциональность инструментов разработки с помощью технологии плагинов.

В этой статье мы поговорим о том, как интегрировать 1С:EDT с системой контроля версий Git для того, чтобы сделать разработку более эффективной.

Ходит легенда, что однажды разработчики GitLab закупились шапками, сделанными из переработанных крышечек от бутылок. И их настолько вдохновила идея повторного использования, что они решили добавить такую возможность и в свой продукт. Подкрепив это всё стандартизацией CI, они представили комьюнити новый механизм — GitLab CI/CD components.

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

Когда я был еще джуном, старшие разработчики настоятельно советовали мне перейти на zsh. Я помню, что я так и не получил никакой аргументации, чем zsh лучше привычного bash, и какую конкретно пользу я получу от перехода.
Что ж, в этой статье я хочу ответить на эти вопросы тем, кто еще только задается этим вопросом, с небольшим уклоном к PHP разработке

Zsh это командная оболочка, то есть программа, которая получает от пользователя команду в текстовом виде и выполняет соответствующие исполняемые файлы, найденные по путям, указанным в переменной окружения PATH.
Zsh является дефолтной оболочкой для macOS, на linux дефолт - bash. Zsh лучше, чем bash в основном благодаря своей очень обширной системе плагинов, модулей, различных тем и т. д.

Например, установив вот такой плагин.

Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.

По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.

Раскрываем Docs as Code: как этот подход меняет создание документации, какие инструменты стоит изучить в первую очередь, и с чего начать внедрение.

Вышел релиз GitLab 18.1 с бета-версией виртуальных реестров Maven и Duo Code Review в общем доступе.
Мы с радостью объявляем о релизе GitLab 18.1 с бета-версией виртуальных реестров Maven, фичей Duo Code Review в общем доступе, выявлением скомпрометированных паролей и компонентами CI/CD для достижения SLSA 1 уровня! Это лишь несколько из более 110 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.

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