📌Всё про сортировку веток Git

Запустив git branch в репозитории, вы обычно получаете список веток в алфавитном порядке. Это может раздражать, когда у вас много веток (если только у вас нет очень жесткой системы именования по номеру тикета или чего-то подобного).
⏩Не проблема, это можно изменить. Выполните в вашем репозитории следующую команду:

git branch --sort=-committerdate

Это отсортирует все ваши ветки по дате их последнего коммита

Для сортировки доступны такие опции:
- authordate
- committerdate
- creatordate
- objectsize
- taggerdate

⏩Кроме того, если хотите всегда сортировать по одному из этих параметров, можно установить это в настройках:

git config --global branch.sort -committerdate

⏩Также можно задать псевдоним:

git config --global alias.brcd "branch --sort=-committerdate".

Подробнее о работе с ветками можно почитать тут, ловите ссылки:
📎 Ветвление Git с примерами из реальной жизни
📎 Как удалить ветку в Git
📎 Как переименовать локальную ветку в Git

@github_code

🖥 Управление GitHub-репозиториями: best practices

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


〰️ Четко придерживайтесь соглашения об именовании репозиториев

⏩Префикс для обозначения проекта или команды. Если в вашей организации есть несколько проектов или команд, названия репозиториев могут начинаться с префиксов, идентифицирующих проект или команду. Например, teamalpha_authentication_service или teambravo_data_pipeline.

⏩Описательные имена. Репозитории должны иметь описательные и конкретные названия, которые подскажут вам, что в них находится. Например, customer_support_ticketing_system или machine_learning_model_trainer.

⏩Указание на основной технологический стек. Это может быть особенно полезно для архитектур микросервисов. Например, image_processor_python или frontend_react_app.

⏩Версии или метки состояния. Если вы поддерживаете разные версии инструмента или библиотеки, или если в репозитории хранится что-то на определенной стадии разработки, укажите это в названии. Например, payment_gateway_v2 или inventory_management_deprecated.

⏩Избегайте специальных символов. Придерживайтесь букв и цифр с дефисами и символами подчеркивания, чтобы сохранить URL-совместимость и избежать путаницы. Например, invoice-generator или invoice_generator.

⏩Указание на юзкейс. Иногда полезно указать, является ли репозиторий библиотекой, сервисом, демо-версией или документацией. Например, authentication_lib, payment_api_service, demo_inventory_app, api_documentation.


〰️ Классифицируйте репозитории по темам

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

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

⏩Сообщество. Указание тем поможет вам познакомиться с людьми, которые интересуются теми же темами. Когда кто-то просматривает репозиторий с определенной темой, он может увидеть другие репозитории с той же темой.

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

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


〰️ Используйте README.md для документирования репозитория

Хорошо написанный файл README.md может вам помочь в следующих вещах:
⏩Привлечение контрибьюторов. Этот файл предоставляет потенциальным контрибьюторам информацию, необходимую для понимания проекта и начала работы с ним.

⏩Онбординг. README.md поможет новым членам команды освоиться в проекте.

⏩Документация. Файл README.md служит документацией для проекта. Он предоставляет пользователям информацию, необходимую для работы с проектом.

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

⏩Стандартизация. README.md помогает стандартизировать способ документирования проектов. Это обеспечивает последовательную структуру документирования проектов.

📎 Ещё 7 полезных советов

@github_code

📌20 полезных, но малоиспользуемых команд Git

Держите, это кликабельный список:
⏩ Git Web — открыть встроенный графический интерфейс
⏩ Git Notes — прикрепить дополнительную информацию к коммитам
⏩ Git Bisect — дебажить как про
⏩ Git Grep — найти что угодно
⏩ Git Archive — сжать проект для шеринга
⏩ Git Submodules — импортировать другие репозитории в ваш
⏩ Git Bugreport — скомпилировать баг-репорт с информацией о системе
⏩ Git Fsck — проверить и восстановить недоступные объекты
⏩ Git Stripspace — удалить пробелы в конце текста
⏩ Git Diff — сравнить изменения между двумя файлами
⏩ Git Hooks — выполнить скрипт при запуске команды git
⏩ Git Blame — показать, кто написал данную строку
⏩ Git Large File Storage — сохранить большие файлы в git
⏩ Git Garbage Collection — оптимизировать git-репо
⏩ Git Show — легко просмотреть любой объект git
⏩ Git Describe — дать читаемое имя на основе последнего тега
⏩ Git Tag — создать метки версий в определенных точках
⏩ Git Reflog — список всех действий, выполненных над репозиторием
⏩ Git Log — просмотреть журнал коммитов и диаграммы ветвей
⏩ Git Cherry Pick — вытащить фичу в вашу ветку
⏩ Git Switch — быстро переключиться между ветками

Пользуйтесь)

@DevOPSitsec

📌Система контроля версий git. Первый проект на GitHub

Есть то, что объединяет всех разработчиков, неважно, на Python вы пишите или на чём-то ещё — это понимание git 🤓
Держите мощный туториал по системе контроля версий git и о его реализации на примере GitHub.
Самое то, если только разбираетесь с этим, да и для GitHub-гуру подойдёт, освежить основные понятия не помешает.

Некоторые факты из статьи:
⏩Ветвление по умолчанию может быть "main" или "master" в зависимости от версии Git и настроек окружения.

⏩Создание новой ветки помогает изолировать изменения от основного кода и решать проблемы.

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

⏩Работа с удаленными репозиториями на GitHub включает создание аккаунта, создание удаленного репозитория, связывание локального репозитория с удаленным и отправку изменений на GitHub.

⏩Pull Requests (запросы на внесение изменений) используются на платформе GitHub для предложения изменений в код проекта и интеграции их в основную кодовую базу.

🖥 Туториал

@python_job_interview

⚡️ tartufo.

• Инструмент Tartufo может сканировать репозитории в поисках случайно оставленных токенов и учетных данных. Может проверить всю историю коммитов для поиска секретов.

• Документация: https://tartufo.readthedocs.io

➡️ https://github.com/godaddy/tartufo

🤓 lazygit для упрощения работы с git

— brew install lazygit

lazygit — это простой интерфейс терминала для команд git.
GUI сделан на основе библиотеки gocui, с помощью которой можно реализовать полноценные окна и взаимодействие с ними в терминале.

lazygit можно гибко настраивать под себя, начиная с цветовой гаммы и заканчивая добавлением новых команд или горячих клавиш. Все настройки лежат в файле config.yml: в Linux — ~/.config/lazygit/config.yml, в MacOS — ~/Library/Application Support/lazygit/config.yml

🖥 GitHub
🟡 Доки
🟡 Статья о lazygit на Хабре

@github_code

🌟 Novu — IaaC инфраструктура уведомлений на основе GitOps. Встроенный центр уведомлений, интеграция с электронной почтой, Push и Slack

Novu — open-source инфраструктура уведомлений;
Novu предоставляет унифицированный API, который упрощает отправку уведомлений по нескольким каналам, включая In-App, Push, Email, SMS и Chat. С Novu можно создавать пользовательские рабочие процессы и определять условия для каждого канала, не беспокоясь, что уведомления будут доставлены наиболее эффективным способом.

🖥 GitHub
🟡 Доки

@DevOPSitsec

💻 Злоумышленники стирают GitHub-репозитории жертв и требуют выкуп за восстановление данных

Исследователи заметили новую вредоносную кампанию, в рамках которой злоумышленники атакуют репозитории на GitHub, уничтожают их содержимое, а затем просят жертв связаться с ними через Telegram для «получения дополнительной информации».

Первым эти атаки заметил специалист чилийской ИБ-компании CronUp Херман Фернандес (Germán Fernández). Исследователь пишет, что эта кампания, вероятно, активна еще с февраля текущего года и уже затронула десятки репозиориев.

Хакеры, стоящие за атаками, используют ник Gitloker в Telegram и представляются ИБ-аналитиками. По данным издания Bleeping Computer, вероятнее всего, они компрометируют чужие учетные записи на GitHub, используя для этого украденные учетные данные.

Сами пострадавшие пишут, что взлом их учетных записей произошел после перехода по вредоносной ссылке в спамерском письме, якобы полученном от рекрутеров GitHub. По данным Фернндеса, злоумышленники использовали для этой кампании два домена: githubcareers[.]online и githubtalentcommunity[.]online.

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

@linuxkalii