Git *

Pre-commit — must have утилита любого проекта

Бывает, смотришь на код и сразу видно, что код плохой. Признаков может быть множество:
— разные куски кода по-разному отформатированы;
— импорты в файлах никак не структурированы;
— используются вперемешку синтаксис старых и новых версий питона;
— где-то видны зачатки использования типов, но не везде;
— где-то docstring есть, где-то нет;
Всё это характеризуется так: нет единого стиля в написании кода. Проблема становится особенно актуальной, когда над проектом трудится несколько разработчиков.

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

Для решения всех обозначенных проблем есть замечательная утилита — pre-commit. Один раз в конфиге прописываете, какие анализаторы кода нужно запускать, и далее при любом коммите они будут запускаться автоматически. С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.

В DevFM пишу о полезном для разработчика.

Для тех, кто хочет распилить монорепу на подмодули или уже сделал это. Задача со звёздочкой.

Дано: в репозитории около 50 подмодулей,  текущие ветки у них имеют разные названия. Джун Вася создал в каждом подмодуле новую ветку и внёс минорные правки. Чтобы провести ревью, миддл Серёжа получил Васины изменения, переключил ветки родительского репозитория и выполнил команду:

git submodule update --init --recursive

После ревью Вася пошёл исправлять замечания, а Серёжа вернулся к разработке своей фичи, вот только подмодули теперь в состоянии head detached.

Вопрос: как быстро подгорит у программистов из-за необходимости выставлять подмодули из состояния head detached в соответствующие feature-ветки, если процесс повторять?

Решение: использовать команду:

git submodule foreach --recursive 'git name-rev --name-only $sha1 | xargs git checkout'

По хешу команда найдёт указатель и на него переключится. Если есть несколько указателей для текущего коммита, будет выбрано имя ветки первое по алфавиту.
Если на текущий коммит подмодуля никакая ветка не указывает, получим head detached. Рекурсивно (если у подмодулей есть подмодули) тоже работает.

Ответ: так и живём.

Всем DevOps! Автоматизация проверки одобрений merge requests с помощью GitLab CI/CD и GitLab API — это классный способ без лишних затрат оптимизировать процесс управления кодом в вашей команде.

Наш DevOps-инженер Виктор рассказал, как он смог настроить approve rules для merge request в бесплатной версии GitLab CE.

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

💻 Если ещё не читали — тогда вам сюда!

Российские IT-компании готовятся к массовому отключению иностранных сервисов. Большинство привычных сервисов могу скоро просто отвалиться.

Все из-за санкций Минфина США, которые запрещают предоставление услуг в сфере программного обеспечения, IT-консультирования и проектирования на территории РФ.

Российские IT-конторы, соответственно, вынуждены искать бесплатные альтернативы с открытым кодом, на которые не распространяется запрет, а облачные хранилища теперь — только российские.

Кстати, как я смотрю, Сбер очень активно к этому готовился. У них и IDE на базе PyCharm— GIGA IDE, и гит-платформа GitVerse (полный аналог GitHub), и куча еще всего.

Я пока не особо тестил GIGA IDE, т.к. полностью перешел на майковский VS Code. Но он на базе комьюнити версии, только с разными плюшками и ИИ. А гит-платформа выглядит симпатично, ничего больше сказать не могу. Вероятно, всё это имеет очень хороший смысл, если трудишься полностью в их экосистеме.

В любом случае, молодцы, что предоставляют альтернативу.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.46.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 746 изменений,
подготовленных при участии 96 разработчиков, из которых 31 впервые
участвуют в разработке.

Основные изменения:

• добавлена экспериментальная поддержка нового вида битовых карт — «pseudo‑merge reachability bitmap», в которых в отличие от структуры «reachability bitmap» данные о наборах объектов, имеющих отношение к коммитам, хранятся в привязке сразу к нескольким коммитам.

• реализован интерфейс командной строки для команды «git config», в котором вместо разрозненных опций для просмотра, переименования и удаления настроек и секций, таких как «‑get», «‑get‑all», «‑unset» и «‑remove‑section», предложен набор отдельных субкоманд.

• В команду git добавлена опция «‑no‑advice», отключающая все сообщения с рекомендациями и подсказками, что может оказаться полезным для предотвращения забивания лога лишней информацией при автоматизированном вызове git.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.45.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию Git принято 540 изменений, подготовленных при участии 96 мейнтейнеров проекта, из которых 35 впервые приняли участие в разработке.

Основные изменения:

• добавлена предварительная поддержка бэкенда "reftable" для эффективного хранения в репозитории ссылок на ветки и теги;

• предоставлены средства для обеспечения переносимости между идентификаторами объектов на базе хэшей SHA-1 и SHA-256;

• добавлена новая команда "git reflog list" для показа известных reflog-ов и соответствующих им ссылок на теги и ветки;

• в команде "git checkout -p" разрешено использовать символ "@" в качестве синонима имени "HEAD";

• предоставлена возможность определения альтернативных префиксов для вывода "git diff", отображаемых перед файловым путём;

• добавлен параметр core.commentString для определения строки-разделителя вместо символа "#" для игнорирования комментариев в сообщении для коммита.

Описание и комменты к код ревью

Есть один очень простой, но удивительно эффективный способ ускорить код ревью в команде и сделать этот процесс более приятным.

Выложив Pull Request, напиши к нему описание и оставь комментарии.

Вспомните свои ощущения, когда нужно поделать ревью. Лично я зачастую испытываю лень. Нужно открыть код, разобраться, какую задачу и каким способом он решает, составить собственное мнение, оставить комментарии... Можно устать, просто прочитав это предложение.

Позаботьтесь о своих коллегах. Сделайте короткое описание к PR, расскажите в двух словах о решаемой задаче и способе её решения (что было сделано).

Не нужно растекаться словом по древу. Достаточно буквально 3-5 предложений. Читать огромную портянку текста тоже никто не захочет.

Сделав это, оставьте комментарии к самому коду. На что ревьюерам стоит обратить внимание? Где вы сомневаетесь в своём решении? Если есть доработки какого-то общего кода, то зачем они были сделаны?

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

Больше интересного про жизнь в IT у меня в ТГ

[Отладка] git bisect

Сегодня хочу рассказать об инструменте Git, который может очень помочь при отладке. Этот инструмент называется git bisect.

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

Принцип работы git bisect основан на методе бинарного поиска. Тебе лишь нужно указать «хороший» коммит, в котором ошибка точно отсутствует, и «плохой» коммит, в котором ошибка уже есть. Git bisect автоматически проведет тебя через процесс бинарного поиска между этими двумя точками, поможет постепенно сузить круг «подозреваемых» и найти коммит, начиная с которого стал проявляться баг.

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

Ссылка на доку здесь.

А тут мой тг-канал со свежими новостями из мира мобильной разработки.

Разработчики дистрибутива Arch Linux объявили о завершении миграции системы отслеживания ошибок на платформу GitLab и включении на обслуживающем проект сервере GitLab поддержки запросов на слияние (merge request). Модернизация системы отслеживания ошибок стала следующим шагом после перевода инфраструктуры для разработки пакетов с Subversion на Git и GitLab.

Старый интерфейс отслеживания ошибок в Arch Linux, основанный на платформе Flyspray, будет через какое-то время отключён, но доступ к старым записям планируют сохранить через размещение статической архивной копии сайта bugs.archlinux.org, в которой записи будут доступны по старым ссылкам.

В сообщениях об ошибках, разбиравшихся в процессе миграции, добавлены финальные комментарии, указывающие на новый адрес обсуждения в GitLab. Кнопки уведомления о проблемах, присутствующие на страницах пакетов, перенаправлены на новую систему. Процесс разбора сообщений о проблемах в Arch Linux останется прежним — первичный разбор сообщений осуществляют участники команды Bug Wranglers, после чего проблема перенаправляется для исправления соответствующим сопровождающим.

Источник: OpenNET.

После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.43.

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

По сравнению с прошлым выпуском в версию Git 2.43 внесено и принято 464 изменения, подготовленные при участии 80 разработчиков, из которых 17 программистов впервые приняли участие в разработке, включая:

• в команду "git repack" добавлены опции "--filter" и "--filter-to", позволяющие выполнить переупаковку репозитория c учётом заданного фильтра объектов и при необходимости перенести в отдельное место объекты, не удовлетворяющие заданному фильтру;

• добавлена возможность работы с несколькими pack-файлами с информацией о недостижимых объектах ("cruft packs"), на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги);

• добавлено распознавание попыток выполнения двойной отмены коммита через "git revert" и учёт этого факта при формировании сообщения об отмене;

• Разрешено совместное использование опций "--rfc" и "--subject-prefix".

Источник: OpenNET.

Вышел релиз GitExtensions 4.2, инструмента с графическим интерфейсом для управления репозиториями git, умеющего интегрироваться в системное меню работы с файлами и, через плагины, в IDE (JetBrains, VSCode, MSVS). Код проекта написан на C# и распространяется под лицензией GPLv3.

Основные изменения:

• новый плагин интеграции с GitLab;

• в плагин JIRA добавлена поддержка токенов личного доступа;

• различные улучшения производительности;

• различные улучшения пользовательского интерфейса;

• улучшения в диалоговом окне журнала команд Git и в диалоговом окне «Rebase»;

• разрешено выполнение операции сохранения «Save as...» сразу для нескольких файлов;

• редактор теперь может перемещать строку вверх/вниз с помощью ALT + UP и ALT + DOWN;

• для OpenSSH реализовано выставление переменной окружения SSH_ASKPASS, если запрашивается пароль (требуется OpenSSH 8.4 или выше; не действует для более старых версий OpenSSH);

• обеспечена автоматическая установка GitExtensions в качестве редактора только в текущем окружении;

• разрешён сброс непроиндексированных изменений, не затрагивая промежуточные;

• более удобная обработка ошибок «Не удалось загрузить файл или сборку»;

• вертикальная табуляция (SHIFT + ENTER) теперь рассматривается как перевод строки;

• добавлена поддержка сборки GitExtensions для Windows на системах Arm64 (WoA), однако для этого требуется сборка вручную;

• для скриптов реализована опция "{HEAD}";

• для сборки теперь требуется .NET 6.0 Desktop Runtime v6.0.24 или новее;

• рекомендованная версия Git 2.42.

Источник: OpenNET.

Вышел новый стабильный выпуск системы управления проектами Trac 1.6 с поддержкой Python 3, предоставляющей web-интерфейс для работы с репозиториями Subversion и ​Git, встроенный Wiki, систему отслеживания ошибок и раздел планирования функциональности для новых версий. Код написан на языке Python и распространяется под лицензией BSD. Для хранения данных могут применяться СУБД SQLite, ​PostgreSQL и ​MySQL/MariaDB.

Trac придерживается минималистичного подхода к управлению проектом и позволяет автоматизировать типовые рутинные операции на уже сложившиеся в среде разработчиков процессы и правила. Встроенный wiki-движок даёт возможность использовать wiki-разметку в описаниях проблем, целей и коммитов. Поддерживается создание ссылок и организация связей между сообщениями об ошибках, задачами, изменениями в коде, файлами и wiki-страницами. Для отслеживания всех событий и активности в проекте предлагается интерфейс в виде шкалы времени.

В форме плагинов доступны модули для ведения новостных лент, создания дискуссионной площадки, проведения опросов, взаимодействия с различными системами непрерывной интеграции, генерации документации в Doxygen, управления загрузками, отправки уведомлений через ​Slack, поддержки Subversion и Mercurial.

Источник: OpenNET.

​​Как восстановить удалённый коммит в Git?

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

Потом понял, что закоммитил в мастер, а не в ветку с фичей. Поэтому сделал git reset --soft, чтобы удалить коммит, сохранив все изменённые файлы, и переключился в фича ветку. 

Если ветки сильно отличаются, то иногда приходится делать git clean -fxd, чтобы удалить все ненужные артефакты. И тут я понял, что удалил все свои изменения.

Повезло, что перед этим я закоммитил свои изменения, хотя коммит и был удалён. Ведь git позволяет восстановить удалённые коммиты. Для этого я сделал:

git reflog 

Нашёл в списке хэш моего коммита и перенёс из него все изменения в текущую ветку с помощью: git cherry-pick —no-commit <hash>

https://t.me/cherkashindev/105