GitHub *

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

Если ты начинающий разработчик, то эта статья точно тебе пригодится. А если у тебя огромный опыт и ты думаешь, что тебя уже ничем не удивить, то… Не будем торопиться… Давай проверим?

Жизнь каждого человека начинается со слова "мама".

Дорогой читатель, твой путь начнется со слова "git".

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

В данной статье описывается пошаговая методика развертывания виртуальной машины (ВМ) с установленной операционной системой Windows 10 на сервере с операционной системой Ubuntu. Решение предполагает установку всех необходимых компонентов, настройку виртуализации с помощью QEMU/KVM, а также организацию удалённого доступа к ВМ посредством noVNC.

Прошло два года...

Решение проблемы с младшими чипсетами HM70. Многие мастера уверены, чтобы поставить процессор core i линейки на слабые ноутбуки с hm70 необходимо менять чипсет на более старший, однако это не очень выгодное решение. В недавнем времени нашлось программное решение :-)

Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.

Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.  

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

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

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

Как же иногда хочется закинуть коммиты «Remove debug log», «fix» или «fix fix fix». Такие коммиты как грязные носки под кроватью: их не видно, пока не придёт ревьюер с пристальным взглядом или, что еще хуже, потенциальный работодатель, решивший посмотреть на ваш профиль github.

К счастью, Git предлагает два супер-инструмента для того, чтобы история коммитов выглядела так, будто ты всегда знаешь, что делаешь: git commit --fixup и git rebase --autosquash. И сегодня мы разберем на практике как это применять.

Сейчас вас научу «плохому» — будем поднимать наше веб‑приложение на телефоне. Для этой цели я накидал приложение на go, которое определяет IP адрес, вычисляет город, отправляет запрос во внешний сервис и отдает страницу с данными о погоде в вашей локации.

Так случается, что команда решает вынести часть проекта в open source и использовать ее как внешнюю зависимость. Как правило, это самостоятельный пакет или инструмент, лишенный какой-либо бизнес-специфики, способный принести пользу сообществу и получить дальнейшее развитие. Большинство коммерческих разработчиков имеет персональные профили на открытых платформах и поддерживает собственные портфолио, поэтому при переносе мы хотим сохранить авторство и историю коммитов. Основная сложность здесь в том, что необходимо полностью исключить всю внутреннюю корпоративную информацию: названия репозиториев и проектов, имена и имейлы сотрудников, внутренние идентификаторы тикетов и любые формулировки, отражающие задачи продукта. Важно, чтобы такая информация отсутствовала по всему дереву коммитов. Для этого мы будем пользоваться такими инструментами,

как git grep, git filter-branch и git rebase --interactive. В статье приводятся порядок шагов и общие рекомендации по оформлению открытого проекта.

Я Константин Соколов из бэкенд-разработки в Positive Technologies. Люблю программировать на Go.

Представьте ситуацию: вы нашли критический баг в проекте, исправили его в feature-ветке, но до полного слияния ещё далеко. Или вам срочно нужно перенести одно конкретное изменение из текущей ветки в другую. В таких случаях git cherry-pick становится вашим секретным оружием.

Мне надоело постоянно использовать Google Authenticator и переключаться между ПК и телефоном для подтверждения двухфакторной (мультифакторной) аутентификации. Красивых и функциональных TOTP (Time-based one-time password) хранилок в терминале я не нашел, поэтому сделал эту TUI, которая позволит хранить, управлять, просматривать, копировать 2FA ключ в пару нажатий с поддержкой VIM управления. Ну и просто мне было интересно, какого это создавать свои TUI приложения.

Сегодня я расскажу, как можно создать собственную систему репутации с Telegram на Python. Решение будет легким и красивым, обещаю.

Тренд «Platform Engineering», предложенный аналитическими агентствами, стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.

Меня зовут Денис Макрушин, и вместе с командой SourceCraft я создаю технологии безопасной разработки, чтобы кибербезопасность была драйвером для инноваций, а разработчик мог эффективно использовать свои когнитивные способности. В этой статье я собрал коллекцию интересных уязвимостей и методов атак на пользователей крупной платформы разработки, обзор актуальных методов атак, выявленных в 2024 году. Понимание актуальных угроз позволяет лучше разобраться в необходимости улучшения практик безопасности в такой платформе на примере GitHub. Материал будет полезен как разработчикам, так и специалистам по информационной безопасности для защиты своих проектов.

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

Если интересно, листайте ниже и пользуйтесь!👀

Статья будет полезна разработчикам встраиваемых систем, которые хотят автоматизировать процесс тестирования своих проектов. Отдельный блок посвещен отладке gdb в эмуляторе QEMU. В качестве примера используется библиотека логирования (GitHub, Habr)

Привет, меня зовут Ася Исакова, и я организационный психолог. Возможно, единственный в мире организационный психолог, который умеет создавать пулл-реквесты на GitHub. Как так вышло? Дело в том, что я 2+ года занималась тем, что выстраивала нормальную работу на удаленке без 8 звонков в день для одной распределенной команды, используя GitHub как основной инструмент. Подробности о том, что это, как это было, что получилось и вдруг вам тоже надо, под катом.

Как и многие, я храню свой код на GitHub. Пару лет назад я сделал простой пайплайн для сборки, анализа и тестирования моих веб‑приложений и сервисов. Он выполнял свою задачу, и так как это был мой первый опыт по настройке пайплайна CI/CD на GitHub, он сводился к одному шагу.

build (and deploy)

Со временем я стал замечать, что я стараюсь избегать вносить изменения в код. Будучи счастливым обладателем ADHD, я часто замечаю за собой сложность в решении задач с большим количеством препятствий и одним из них стало то, что выполнение пайплайна занимало больше 5 минут. Я коммитил изменения и шел делать кофе, пока пайплайн тестировал и деплоил код. И не всегда возвращался, отвлекаясь на другие вещи.

Я решил для себя, что максимальное количество времени, которое я готов ждать - 1 минута.