Рекомендации По Поддержанию Вилок Репозитория Git На Локальном Сервере Azure Devops

У нас есть локальный сервер Azure DevOps, и мы хотели бы использовать рабочий процесс Git «Fork-Clone-Push-PR».

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

Таким образом, решением для размещения всех этих форков может стать специальный проект «Форкс». Но хороший ли это вариант?

Есть ли какие-либо передовые методы или советы и рекомендации о том, как нам следует действовать?

#git #azure-devops

Я думаю, что лучший способ ответить на ваш вопрос — сделать шаг назад и сосредоточиться на своей цели. Учитывая тот факт, что вы используете локальный сервер Azure DevOps, я предполагаю, что вы работаете над проектом с закрытым исходным кодом (приношу извинения, если это предположение неверно). Я считаю, что ваша цель — контролировать качество с помощью PR в этой среде.

Как это Учебник по Атласиану говорится: «Рабочий процесс разветвления чаще всего встречается в проектах с открытым исходным кодом». Причина этого в том, что механизм вилки был создан для очень конкретной проблемы: «Как дать совершенно незнакомым людям возможность внести свой вклад в проект, не предоставляя всему миру разрешения на запись в ваш репозиторий?». Обратите внимание: я иногда использую механизм разветвления и для других, довольно сложных целей, но это его основное применение. Есть замечательная книга под названием Git для команд это очень хорошо описывает рабочие процессы git и их цели.

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

Многие люди ошибочно полагают, что единственный способ создать механизм pull-request — это форк кода, вероятно, потому, что их единственное средство воздействия — это пиар в сообществе открытого исходного кода. Цитируя Microsoft, «Запросы на включение могут исходить от любого тематические ветки или из ветки в форке исходного репозитория". А тематическая ветка это просто причудливый термин для feature / bug /etc ветка. Когда я работаю с группой с закрытым исходным кодом, которая является новой для git, я часто запрещаю разветвления в настройках проекта/репозитория и применяю политика ветвления минимального количества рецензентов для пул-реквеста в главную ветку.

Что касается лучших практик стратегий ветвления в git, упомянутая выше книга — отличный первый шаг. Существует множество стандартных стратегий ветвления, вот несколько примеров:

1. Gitflow который отлично подходит для команд, которые плохо знакомы с git, и имеет несколько замечательных инструменты и многие инструменты включают шаблон gitflow, например исходное дерево.
2. магистральная разработка очень бережливый процесс разработки.

Что касается вашего первоначального вопроса, я подозреваю, что создание нового проекта Azure DevOps для хранения всех этих неприглядных дополнительных репозиториев форков просто усложнит вашу работу. Вам нужно будет обеспечить безопасность для обоих проектов, управлять пользователями и разрешениями для нового проекта и т. д. В этом случае вычитание, вероятно, лучше, чем сложение, я предлагаю удалить разветвление и использовать хорошую стратегию ветвления для вашего проекта (если это возможно). Это существенно упростило бы вашу жизнь.

Пожалуйста, дайте мне знать, если это не ответило на ваш вопрос или если у вас есть дополнительные вопросы.