Репозитории, проблемы, множественные разработчики и форкинг в Github - лучшие практики для рабочих процессов

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

У нас есть аккаунт организации на github с частными репозиториями. Мы хотим использовать встроенные функции github для задач / запросов на получение запросов (запросы на получение запросов - это в основном именно то , что нам нужно, когда речь идет о проверке кода и обсуждении функций). Мы нашли инструментальный хаб по defunkt, у которого есть замечательная небольшая особенность, заключающаяся в возможности преобразования существующей проблемы в запрос на извлечение и автоматической привязки текущей ветки к ней.

Мне интересно, лучше ли, чтобы каждый разработчик в организации раскладывал репозиторий организации для выполнения своей работы над функциями / исправления ошибок / и т.д. Это выглядит довольно солидным рабочим процессом (так как это в основном то, что делает каждый проект с открытым исходным кодом на github), но мы хотим быть уверены, что сможем отслеживать проблемы и получать запросы из ОДНОГО источника, хранилища организации.

Итак, у меня есть несколько вопросов:

1. Подходит ли в этом случае подход «форк на разработчика»? Кажется, это может быть немного излишним. Я не уверен, что нам нужен ответвление для каждого разработчика, если только мы не представим разработчиков, у которых нет прямого доступа с принудительной рассылкой и которым требуется пересмотреть весь их код. В этом случае мы хотели бы установить такую ​​политику только для тех разработчиков. Итак, что лучше? Все разработчики в одном репозитории или форк для всех?
2. У кого-нибудь есть опыт работы с инструментом-хабом, в частности с функцией pull-request? Если мы сделаем разветвление для разработчика (или даже для разработчиков с менее привилегированными правами), будет ли функция извлечения запросов в хабе работать с запросами извлечения из основного основного репозитория (репозитория организации?) Или у него будет другое поведение?

РЕДАКТИРОВАТЬ
Я провел некоторое тестирование с проблемами, вилками и запросами на получение и нашел это. Если вы создаете проблему в репозитории своей организации, затем раскошлите репозиторий из вашей организации в свою собственную учетную запись github, внесите некоторые изменения и объединитесь с главной веткой вашего форка. При попытке запустить hub -i <issue #>вы получаете сообщение об ошибке User is not authorized to modify the issue. Таким образом, очевидно, что рабочий процесс не будет работать.

Подходит ли в этом случае подход «форк на разработчика»? Кажется, это может быть немного излишним. Я не уверен, что нам нужен ответвление для каждого разработчика, если только мы не представим разработчиков, у которых нет прямого доступа с принудительной рассылкой и которым требуется пересмотреть весь их код. В этом случае мы хотели бы установить такую ​​политику только для тех разработчиков. Итак, что лучше? Все разработчики в одном репозитории или форк для всех?

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

Однако теперь я регулярно участвую в более крупном проекте с открытым исходным кодом, где несколько десятков человек имеют доступ к центральному репо. Мы по-прежнему делаем все основные разработки в личных репозиториях и предоставляем PR для функций, чтобы можно было просмотреть код, хотя исправления могут быть переданы напрямую. Основное репо несет только ветки master и release, сохраняя его свободным от беспорядка. Ветви объектов находятся в личных репозиториях, поэтому их все равно могут видеть другие (создание ранних PR для них предупредит других в команде, что работа над функцией продолжается). Я могу рекомендовать этот рабочий процесс для любого проекта с более чем несколькими разработчиками; Единственным недостатком является работа с несколькими пультами.

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

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

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

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

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

Основным моментом контроля источника является то, что вы можете видеть, возвращать, отменять и т. Д. Изменения. Делать большое количество разветвлений и веток в вашей ситуации - ИМХО.

Я бы зарезервировал ветки для таких вещей, как: обновление версий, изменение одного из технологических компонентов, работа над подмодулем в течение 3 месяцев, который имеет мало общего с основной базой.

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

Я бы переключил ваше внимание на тестирование и проверку кода. Люди пишут тесты? Они хорошие? Проверки кода выполнены?