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

14

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

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

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

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

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

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

Джим Рубинштейн
источник

Ответы:

6

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

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

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

Фред Фу
источник
2

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

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

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

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

Уилберт
источник
1

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

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

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

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

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

наркоман
источник
1
Мы не так много пишем тесты; мы пересматриваем код друг друга не так часто. Отслеживание ошибок и реализации решений - действительно самое важное для нас сейчас. Я думаю, что все согласятся с тем, что тесты хороши в теории, и их гораздо проще реализовать в проекте, начиная с нуля; но у нас есть много устаревших проектов, которые потребовали бы огромного количества для написания тестов. Я вообще согласен с разветвлением и ветвлением. Мы пришли из HG, поэтому краткосрочные ветки, которые на самом деле не являются частью публичной истории, кажутся нам странными, но я определенно вижу цель.
Джим Рубинштейн
Я на самом деле не вижу проблемы с большой базой кода существующей функциональности. Завтра, когда вы исправите ошибку, напишите тест, а затем для следующей функции напишите тест. Вам не нужно возвращаться и писать старые. Вам просто нужно начать писать новые. Сделайте это достаточно, и есть большая вероятность, что вы напишете тест первым. Это профессиональная разработка программного обеспечения, которая имеет значение.
Junky
Кстати, лично я использую git и нахожу тот факт, что у него есть локальный репозиторий, в отличие от svn скажем, где вы делаете коммит прямо на удаленный (без push / pull), так или иначе, сначала я получаю работу локально. Это проще, потому что я все еще могу добавлять и фиксировать без последнего толчка, пока я не буду готов.
Junky
Если вы не используете динамическое представление ClearCase (которое, если бы вы когда-либо пытались, вы бы знали, что это PITA), вы все разветвитесь, потому что каждая проверка действительно является форком, который не может содержать централизованная система контроля версий. несколько ревизий. В децентрализованных и распределенных системах (git is one) он может и является обычным форком.
Ян Худек