Рекомендации по репозиториям GitHub, виджет или создание нового ветки

Я ищу лучшую практику, разветвляясь против ветвления на GitHub. Я прочитал этот Forking vs. Branching в GitHub, но это не актуально.

Наша команда из 5 человек работает в одном хранилище, и мы хотели бы избежать проблем с объединением, конфликтов или регрессии в коде. Цель состоит в том, чтобы 5 человек работали над различными частями проекта, часто в одном файле.

Я хотел бы знать, стоит ли это:

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Для получения дополнительной информации о gitflow вы можете следовать этой ссылке.

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

В Atlassian есть отличная запись о различиях между forking и другими рабочими процессами git на странице git tutorials. (См. Рабочий процесс Forking | Atlassian git Учебник)

Релевантные кавычки:

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

...

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

...

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

Ответ 5

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

Это только основная идея...

Вам также необходимо будет настроить стратегии по ветвлению. Я бы рекомендовал модель Nvie

Ответ 6

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

Таким образом, узким местом является подход к разработке приложений. Я вижу проблему, когда команда сотрудничает в одном файле. С надлежащим дизайном архитектуры, можно ли разделить его на отдельные модули с отдельными файлами? Во время выполнения или времени сборки отдельные модули (или файлы) могут быть агрегированы для формирования всей функции (или одного файла).

Если мы сможем решить проблему на этом уровне, как только размер команды увеличится или будет возрастать сложность функции, все будет плавно масштабироваться.