GitLab: есть ли способ присвоить статус/комментарий ветке?

Я планирую использовать GitLab для управления репозиториями Git (в основном ядра Linux от разных поставщиков оборудования).

В настоящее время я использую Gitolite для управления пользователями на сервере Git и MediaWiki, чтобы иметь то, что называется "таблицей ветвей"; другими словами, таблица, в которой сообщают одиночные пользователи:

  • имя ветки (например, xboard-feat-i2c2)
  • поддерживающий ветвь
  • краткое описание ветвления (например, "начато с версии 2.0.0, ветвь функции для реализации драйвера i2c2 на пользовательском хосте X" )
  • статус ветки (WIP, тестирование, готовность к слиянию, прерывание)
  • сообщите более подробную информацию (например, "чтобы построить эту ветку, вы должны изменить это и сделать это (в отношении инструкции по умолчанию). В настоящее время у нас есть проблема с этим.." и т.д.). В этом разделе я также обычно пишу ссылку на тестовый набор/тестовый набор, используемый для тестирования этого конкретного программного обеспечения.

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

Мне интересно, есть ли место в GitLab (или аналогичном инструменте) для вставки этой части информации.

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

ОТВЕТЫ

Ответ 1

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

  • создать проблему для всего (ошибка, новая функция ecc). Опишите проблему/идею, а не то, как вы ее решаете.
  • при запуске создания нового MR (это можно сделать с помощью кнопки в самой проблеме). Это генерирует как рабочую ветвь, так и MR (как WIP).
  • объясните, что вы делаете в MR
  • После завершения работы удалите WIP из заголовка и:
  • объединить MR и удалить ветвь
  • или: закройте MR и удалите ветвь, если она не полезна.

Обратите внимание, что даже если вы закроете MR и удалите ветвь, фиксация останется там (даже если не "напрямую" доступна через git), поэтому вы не потеряете ничего из своей работы.

Вы также можете использовать тот же рабочий процесс, когда "перерабатываете" ветку: я не хочу пропустить оригинальную реализацию (потому что я могу добавлять ошибки/проблемы во время переделки), поэтому:  - создать новую ветвь с суффиксом ревизии (например, -v1, -v2 и т.д.),  - создайте новый MR для этой ветки, записывая, что вы делаете, перерабатываете/проверяете  - прокомментируйте оригинал MR или новый (это не имеет значения) со ссылкой на другое MR (поэтому они "связаны" )  - закрыть оригинальное MR и удалить его ветвь

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

Ответ 2

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

  • Задайте проблему для каждой задачи.
    • Назовите проблему после задачи, что-то читаемое человеком.
    • Поставьте описание задачи и любую другую информацию в проблеме.
    • Присвойте конструктору ветвления проблему.
  • Создайте ветку для этой задачи, используя номер проблемы. git branch issue/123
    • Если вы хотите использовать схему именования fancier, поместите имя ветки в проблему (я бы рекомендовал против нее, сохраните ее просто).
  • Используйте систему комментариев к проблеме для обсуждения ветки/задачи.
  • Использовать метки эмиссии для любой информации о статусе или категории.
  • Когда он готов к объединению, сделайте запрос на вытягивание.
    • Следуйте обычным процедурам запроса на тягу.
  • Когда он сливается...
    • Удалить ветвь.
    • Закройте проблему.

Это помогает отслеживать проблему с GitLab хорошей интеграцией с кодом. Проблемы доступны для поиска, они прикрепляют беседы, на них можно ссылаться в commits (и наоборот), и они архивируются после их закрытия. Схема наименования веток проста и позволяет будущим разработчикам легко отследить старую ветку в истории развития (имя ветки остается в объединении после удаления, поэтому обязательно git merge --no-ff).