Вышел GitLab 10.3: статическое тестирование безопасности приложений и тестирование производительности в браузере

https://about.gitlab.com/2017/12/22/gitlab-10-3-released/
  • Перевод

Картинка для привлечения внимания


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



Безопасность и тестирование


Не так давно мы анонсировали амбициозный проект Complete
DevOps
, и в данном релизе мы добавили несколько возможностей, которые способствуют его реализации. Статическое тестирование безопасности приложений и Тестирование производительности в браузере добавляют в конвейеры CI/CD соответственно проверки безопасности и производительности. Тестирование безопасности уже добавлено в Auto DevOps, тестирование производительности будет добавлено в скором времени.


Обсуждения и совместная работа


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


Благодаря нашему MVP, также стало возможным редактирование имени ветки при создании мерж-реквеста из задачи. Теперь вы сможете быстро создавать мерж-реквесты прямо из задач, не нарушая алгоритм создания веток.


Иногда картинка может сказать больше, чем тысячи слов. В версии 10.3 мы добавили в GitLab Flavored Markdown (GFM) с Mermaid поддержку блок-схем, диаграмм последовательностей, а также диаграмм Гантта.


Сборка и релиз


В GitLab 10.3 добавлена поддержка нескольких кластеров Kubernetes в проекте, что позволяет изолировать итоговый (production) кластер от кластеров разработки и тестирования.


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


Артефакты могут быть удалены как вручную, так и автоматически по истечению определенного срока. Мы добавили строгие проверки зависимостей артефактов для того, чтобы работы CI/CD не выполнялись, если необходимые артефакты не были найдены.


Не пропустите новые возможности


В GitLab 10.3 также добавлены улучшения мерж-реквестов, эпиков, майлстоунов, зеркалирования репозиториев, интерфейса, Geo, Runner, защищенных веток, быстрых действий и досок задач.


Далее в статье мы подробнее остановимся на этих и других нововведениях GitLab 10.3.


Большое вам спасибо за то, что помогали нам создавать отличный софт с GitLab в ушедшем году! Мы желаем вам счастливого нового года, полного приятных сюрпризов! С праздником!


Приглашаем на наши встречи!


MVP месяца — Виталий 'blackst0ne' Клачков


Виталию не привыкать к таким почестям — он уже становился MVP релиза 10.1. Для релиза 10.3 он добавил восемь мерж-реквестов, в том числе возможность редактирования имени ветки при ее создании из задачи в веб-интерфейсе и поддержку Mermaid для редактора Markdown.


Спасибо (еще раз), Виталий!


Статическое тестирование безопасности приложений (SAST) (EEU)


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


В GitLab 10.3 система статического тестирования безопасности приложений (Static Application Security Testing — SAST) проверяет ваш код (статический анализ) на наличие известных проблем безопасности, которые могут быть использованы в нехороших целях, например, непропатченные внешние зависимости или уязвимости межсайтовых скриптов. Данная система автоматически распознает самые распространенные языки (на данный момент поддерживаются Ruby, JavaScript и Python). Результаты ее работы отображаются прямо на странице мерж-реквеста, так что ваша команда всегда будет в курсе потенциальных проблем безопасности перед мержем кода в master и последующим развертыванием. SAST является частью Auto
DevOps
, благодаря чему данная функциональность работает автоматически.


Иллюстрация к Static Application Security Testing (SAST)


Документация по статическому тестированию безопасности приложений (SAST).


Тестирование производительности в браузере (EEP)


В GitLab уже существует возможность отслеживания производительности итогового приложения, но, помимо этого, очень важно быть уверенным в том, что введение нового кода не приведет к ухудшению производительности. Примером таких ситуаций может быть добавление несжатого образа или добавление новой библиотеки JavaScript прямо в <head>, что замедлит загрузку страницы. Поиск таких погрешностей вручную может оказаться трудоемким и неблагодарным процессом.


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


Иллюстрация к Browser Performance Testing


Документация по тестированию производительности в браузере.


Обсуждения коммитов мерж-реквестов (CE, EES, EEP)


GitLab отлично подходит для рабочих процессов, в которых команды комментируют и обсуждают каждую новую версию мерж-реквестов.


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


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


Иллюстрация к Merge Request Commit Discussions


Документация по обсуждениям коммитов мерж-реквестов.


Редактирование имени ветки при создании мерж-реквеста из задачи (CE, EES, EEP)


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


Спасибо blackst0ne за вклад в эту работу!


Иллюстрация к Customize branch name when creating merge request from issue


Документация по созданию мерж-реквеста из задачи.


Блок-схемы, диаграммы последовательностей и диаграммы Гантта в GitLab Flavored Markdown (GFM) при помощи Mermaid (CE, EES, EEP)


С выходом данного релиза вы сможете создавать красивые блок-схемы, диаграммы последовательностей и диаграммы Гантта в описаниях и комментариях задач и мерж-реквестов. Для их создания используется GitLab Flavored Markdown (GFM). Для этого просто используйте несложный синтаксис Mermaid, который теперь поддерживается в GFM.


Спасибо blackst0ne за вклад в эту работу!


Иллюстрация к Flow charts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid


Документация по поддержке Mermaid в GFM.


Поддержка нескольких кластеров Kubernetes для одного проекта (бета-версия) (EEP)


GitLab может с легкостью проводить развертывание вашего приложения на различные среды с использованием кластера Kubernetes. Зачастую публикация Development, Staging, Production и Review Apps происходит одним и тем же способом. До сих пор все они существовали в одном кластере. Однако, вам может понадобиться разграничение данных и доступа, например, при наличии необходимости хранения данных production физически в другом месте.


С выходом GitLab 10.3 стало возможным настраивать для одного проекта по несколько кластеров Kubernetes, каждый из которых связан с определенной средой. Благодаря этому при публикации вашего приложения конвейеры CI/CD автоматически используют нужный кластер.


Иллюстрация к Multiple Kubernetes clusters per project (Beta)


Документация по поддержке нескольких кластеров Kubernetes для одного проекта.


Автоматический запуск первого конвейера при включении Auto DevOps (CE, EES, EEP)


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


С выходом GitLab 10.3 запуск конвейера вашего проекта происходит сразу же после включения Auto DevOps в настройках проекта, благодаря чему больше не нужно пушить еще один коммит для начала работы конвейера.


Документация по подключению Auto DevOps.


Строгие проверки зависимостей артефактов (CE, EES, EEP)


При работе с конвейерами CI/CD нередки ситуации, в которых артефакты создаются в одной работе, а используются в другой. При помощи ключевого слова dependencies (зависимости) вы можете указать, какие артефакты из предыдущих этапов вам нужны. Однако, когда работы уже завершены, эти артефакты могут быть недоступны, например, у них мог закончиться срок давности, или они могли быть удалены вручную. Это может привести к ситуациям, в которых ваш код пытается обратиться к ресурсам, которые уже недоступны, что ведет к ошибкам, которые довольно непросто обнаружить и отладить.


В GitLab 10.3 мы вводим строгие проверки таких зависимостей. Теперь работы не будут выполняться, если все их зависимости не найдены. Благодаря такому подходу вы сразу узнаете, если какой-то необходимый артефакт отсутствует, и сможете принять необходимые меры, например, запустить абсолютно новый конвейер.


Документация по строгим проверкам зависимостей артефактов.


Ограничения для удаления логов работ CI/CD (CE, EES, EEP)


Логи выполнения работ CI/CD хранятся в GitLab и являются доступными для дальнейшего анализа пользователями, имеющими доступ к проекту. Эти логи могут быть удалены для предотвращения утечек информации или же просто для освобождения места.


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


Документация по модели доступа CI/CD.


Улучшение интеграции с существующими кластерами (бета-версия) (CE, EES, EEP)


Ранее настройка проекта для использования уже существующего кластера Kubernetes происходила через страницу интеграции сервиса в настройках проекта. Такой подход диссонирует с подходом к поддержке кластеров, введенном в версии 10.1.


В GitLab 10.3 мы добавили возможность добавления существующих кластеров Kubernetes в проект напрямую со страницы Clusters. Как следствие, предыдущая версия страницы интеграции сервисов теперь становится устаревшей.


Документация по интеграции с кластерами.


Git push и pull при перенаправлении проекта (CE, EES, EEP)


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


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


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


Документация по перенаправлению при изменении пути до репозитория.


Отображение роли члена проекта в списке проектов (CE, EES, EEP)


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


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


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


Иллюстрация к Show project member role on list of projects


Документация по ролям и уровням доступа пользователей GitLab.


Настройка страницы "New Project" (CE, EES, EEP)


Благодаря Markus Koller администраторы GitLab теперь смогут добавлять ваши собственные вспомогательные тексты на страницу создания нового проекта.


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


<img src=«https://about.gitlab.com/images/10_3/custom_new_project_page.png» alt=«Иллюстрация к Customize „New Project“ page» />


Документация по настройке страницы "New Project".


Добавление пользователям или группам доступа к защищенным веткам (CE, EES, EEP)


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


Одна из важнейших возможностей защищенных веток — определять пользователей или группы пользователей, у которых есть разрешение пушить или мержить изменения. Теперь это можно делать через API.


Документация по защищенным веткам.


Переход к эпику из задачи (EEU)


Поскольку одна задача может принадлежать только одному эпику, полезно при взгляде на задачу понимать, принадлежит она уже какому-то эпику или нет. Теперь к эпику задачи можно легко перейти из бокового меню задачи.


Иллюстрация к Navigate to epic from issue


Документация по эпикам.


Прикрепление изображений к эпику (EEU)


Теперь вы можете прикреплять изображения (или любые другие файлы) к эпику через его описание. Работает по аналогии с описанием задачи (и любых других полей в GitLab в разметке Markdown). Это дает больше простора для описания эпиков за счет возможности добавить схему или макет.


Иллюстрация к Attach images to epics


Документация по эпикам.


Отображение ссылок на эпики в разметке GitLab Flavored Markdown (GFM) (EEU)


Ссылки на эпики для полей в GitLab Flavored Markdown (GFM) теперь будут отображаться так же, как и ссылки на задачи, мерж-реквесты и другие объекты в GitLab. В начале стоит групповой путь, затем &, и в конце идентификатор эпика. Во всплывающей подсказке отображается название эпика. Вставляете ссылку на эпик в текстовое поле, и GitLab отображает ее компактно и легко для чтения. Также вы можете ввести короткий путь до эпика прямо в поле GFM (например, gitlab-org&23), и GitLab переведет его в ссылку.


Иллюстрация к Render links to epics in GitLab Flavored Markdown (GFM)


Документация по отображению ссылок на эпики в GFM.


Обновление веса задачи из бокового меню доски задач (CE, EES, EEP)


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


Иллюстрация к Update issue weight from Issue Board sidebar


Документация по доске задач.


Сортировка майлстоунов в списке групповых майлстоунов (CE, EES, EEP)


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


Иллюстрация к Sort milestones on group milestone list


Документация по групповым майлстоунам.


Редизайн навигации по diff-файлу в мерж-реквесте (CE, EES, EEP)


Навигация по diff-файлу мерж-реквеста стала проще. Теперь имя файла отображается на отдельной строке. А если путь к файлу слишком длинный, отображается только его конец.


Иллюстрация к Redesigned merge request diff file navigation


Подробнее о навигации по diff-файлу изменений мерж-реквеста.


Умный автокомплит для быстрых действий с метками (CE, EES, EEP)


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


Спасибо blackst0ne за эту возможность!


Иллюстрация к Smarter autocomplete for label quick action


Документация по быстрым действиям с метками.


Создание мерж-реквестов по email (CE, EES, EEP)


Некоторые люди предпочитают делать максимум работы на инструментах ПК, используя веб-интерфейс GitLab для задач, которые без него не сделать.


С этим релизом вы сможете создавать мерж-реквесты по email, расширяя количество разработческих задач, которые вы сможете выполнить с помощью имеющихся инструментов. Отправьте письмо GitLab, указав в теме название ветки исходника — и GitLab автоматически создаст мерж-реквест. Специальный (и уникальный для вас) email определенного проекта вы найдете, перейдя по ссылке внизу страницы мерж-реквестов проекта. Он не меняется, пока вы вручную его не обновите. Поэтому вы смело можете сохранить его в вашем почтовом клиенте.


Для разработчиков, которые разрабатывают в терминале, работают в нем с Git и посылают письма из него же: вы теперь можете делать все вплоть до создания мерж-реквеста, не покидая терминала.


Иллюстрация к Create merge request through email


Документация по созданию мерж-реквестов по email.


Общее время задач в майлстоуне (CE, EES, EEP)


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


Иллюстрация к общему времени задач в майлслоуне


Документация по боковому меню майлстоуна.


Зеркалируются только защищенные ветки (EES, EEP)


При включенном зеркалировании пушей или пуллов репозитория все изменения будут автоматически отражаться в указанный репозиторий Git или копироваться оттуда. Но если в каком-то из пушей была измененная история Git (например, после перебазировки), зеркалирование не выполнится. Обычно никто не перебазирует ключевые ветки — например, master — но это может произойти для ветки с отдельной функциональностью.


Чтобы предотвратить такие ситуации, зеркалировать теперь можно только защищенные ветки.


Документация по зеркалированию репозиториев.


Запуск зеркалирования пуллов через API (EES, EEP)


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


Мы добавили новый API для немедленного пулла изменений. Зеркалирование пулла произойдет в считанные секунды после того, как сработает вебхук события пуша в исходном репозитории.


Документация по запуску зеркалирования пуллов через API.


Немедленное зеркалирование пушей (EES, EEP)


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


Мы изменили ограничение на зеркалирование: изменения теперь пушатся мгновенно, но не чаще, чем один раз в пять минут. Если зеркалирование разрешено только для защищенных веток, ограничение спадает до одного пуша в минуту.


Документация по зеркалированию пушей.


Ограничили зеркалирование репозиториев (EES, EEP)


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


В GitLab 10.3 администраторы могут разрешить доступ к зеркалированию пушей и пуллов только для администраторов, чтобы репозитории в инстанс или из инстанса GitLab не копировались лишний раз.


Документация по ограничению зеркалирования репозиториев.


Улучшен интерфейс работы с нодами Geo (EEP)


Управление нодами Geo и их отслеживание значительно упростились за счет разделения интерфейса на отдельные части: для отслеживания и для добавления и редактирования нода Geo.


Иллюстрация к нодам Geo


Документация по улучшенному отображению нодов Geo.


Упрощена настройка PostgreSQL HA (EEP)


В GitLab 10.2 Postgres HA стала полностью доступна, что упростило настройку кластера базы данных Postgres на продакшене с использованием пакета Omnibus.


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


Документация по упрощенной настройке PostgreSQL HA.


GitLab Mattermost 4.4.5 (CE, EES, EEP)


GitLab 10.3 включает Mattermost 4.4.5, альтернативу Slack с открытым исходным кодом. Новая версия включает бета-релиз поддержки плагинов и многое другое.


Документация по GitLab Mattermost 4.4.5.


GitLab Runner 10.3 (CE, EES, EEP)


Также с этим релизом выходит GitLab Runner 10.3. GitLab Runner — проект с открытым исходным кодом, используемый для запуска работ CI/CD и пересылки результатов обратно в GitLab.


Самые важные изменения:



Полный список изменений в CHANGELOG GitLab Runner.


Документация по GitLab Runner 10.3.


Улучшения Omnibus (CE, EES, EEP)


  • Добавили дополнительные предупреждения для устаревших настроек; они теперь отображаются красным
  • gpgme 2.1.15 теперь включен в пакет Omnibus GitLab, что упрощает использование коммитов с подписью
  • Обновили Git до 2.14.3
  • Обновили Docker Registry до 2.6.2
  • Обновили Redis до 3.2.11

Документация по улучшениям Omnibus.


Обработка устаревших копий с помощью балансировки нагрузки базы данных (EEP)


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


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


Подробнее вы можете прочитать в мерж-реквесте о том, как мы обрабатывали устаревшие копии в балансировщике нагрузки базы данных.


Документация по балансировщику базы данных.


Улучшения производительности (CE, EES, EEP)


С каждым релизом мы делаем огромное количество вещей, направленных на улучшение производительности. Мы считаем, что нужно ускорять не только отдельные инстансы GitLab, но и весь GitLab.com, которым пользуется больше миллиона человек.


В GitLab 10.3 мы выпускаем 24 улучшения производительности для мерж-реквестов, CI/CD, Prometheus, фронтэнда и многого другого. И отдельно хотим упомянуть:



Полный список улучшений производительности.




Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 10.3 released with Static Application Security Testing and Browser Performance Testing.

Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 14
  • 0
    А что с 32-битной версией? Её никогда не будет?
  • 0

    А кто-то дружил auto DevOps или k8s с моно репозиторием (20+ сервисов)?

    • 0
      Надо сказать, что Gitlab AutoDevOps пока находится в состоянии beta. Поэтому официальных пресс-релизов об успешном внедрении в пром и интеграции с k8s у вендора нет. Но будут. Дайте время.
      • 0

        Я не сотрудник GitLab и не отслеживаю планы разработки. Но, как обычный пользователь, сильно сомневаюсь, что когда-либо будет автодевопс для конкретного монолитного репозитория. Это же шаблоны, они рассчитаны на типовое приложение Ruby, типовое приложение Python и т.п.


        Однако вы сами можете написать .gitlab-ci.yml под любое приложение, хоть с десятками сервисов.

      • 0
        Pages на subgroups когда завезут? Ещё в 10.0/10.1 обещали.
        • 0
          Ветка запроса этой функциональности доступна по ссылке
          Точных сроков нет, но, возможно, фича будет реализована в течение полугода.
        • 0
          А могли бы вы добавить в список комитов столбец с порядковым номером? Очень удобро для релизов дабы точно знать с какой точки сборка. Наверняка в базе ведь есть эта инфа.
          • 0
            Честно говоря, я не очень понял, что требуется и как это поможет в управлении релизами. Может приведете скриншот?
            Если чувствуете силу и верите в полезность ваших требований для многих, призываю вас открыть свой кейс на сайте GitLab.
            • 0
              GitLab как рабочее офисное хранилище полностью устраивает. Но к сожалению пользоваться ресурсами поддержки и документации ужасно неудобно. Не ориентированы они на «средний класс».

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

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

              Вполне возможно что это как-то делается через события / прочее. Дописывается в комментарии / ещё куда-то.

              Система в этом плане слишком сложна а времени глубоко копать её нет.
              Спасибо!
              • 0
                Иметь номера комитов против идеологии git-a.

                Думаю вам будет интересно:
                softwareengineering.stackexchange.com/questions/205411/why-does-git-use-hashes-instead-of-revision-numbers
                • 0
                  Не спорю. Но так сложилось что многие идеологии в этом мире сделаны в ущерб удобству. Но хочется иногда иначе.
                • 0

                  Порядковые номера не будут работать, потому что коммиты не делаются строго последовательно. Обычно разработчики делают коммиты в ветки для реализуемых ими задач, а потом сливают эти ветки в основную (например, master). Разработка идёт одновременно и порядковые номера не будут иметь смысла.


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


                  Чтобы удобно и понятно искать, присваивайте коммитам понятные и подробные описания. Подробнее об этом:



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


                  git tag -m'Version 1.0' 1.0

                  Теперь, когда собираете релиз, используйте тег вместо хеша коммита.

                  • 0

                    Пожалуйста, расскажите подробнее, что вы хотите сделать с помощью поддержки и документации и что именно там неудобно?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.