Рекомендации по использованию репозиториев GitHub для развилки или создания новой ветви
Я ищу наилучшую практику, раздвоение против ветвления на GitHub. Я читал этораздвоение против ветвления в GitHub , но это не имеет отношения к делу.
Наша команда из 5 человек работает над одним и тем же репозиторием, и мы хотели бы избежать слияния проблем, конфликтов или регрессии в коде. Цель состоит в том, чтобы 5 человек работали над разными частями проекта, часто над одним и тем же файлом.
Я хотел бы знать, стоит ли это того, чтобы:
- развилка проекта, работайте и создавайте запросы на вытягивание, чтобы каждый человек мог легко просмотреть код, или
- создайте новую ветвь-работу и объедините на master, когда работа будет выполнена.
6 ответов:
На мой взгляд, наилучшей практикой при работе с проектом с несколькими разработчиками является использование gitflow модель ветвления.
Во-первых, главная ветвь теперь будет использоваться только для отслеживания выпусков вашего приложения, основных, второстепенных или патч-версий, следующих за семантической версией .Ветвь разработки будет ядром вашего проекта, так как она станет мостом между различными функциями и вашими релизами.
Эта система помогает чтобы уменьшить количество слияний, как это делает простая ветвящаяся система, но добавьте семантическую логику и дружественные и простые команды, которые идут с ней.
Для получения дополнительной информации о gitflow вы можете перейти по ссылке .
Поддержание вилок вводит дополнительные накладные расходы, поскольку каждая вилка должна вытягивать изменения из восходящего потока. Я не вижу никакой пользы в этом, когда каждый разработчик может иметь доступ к общему хранилищу.
Запросы на вытягивание могут быть очень полезным механизмом для проверки кода, но они не требуют использования форков. Вы можете создавать ветви в одном репозитории и использовать запросы pull для управления их объединением в главную ветвь.
В моем офисе мы имеем аналогичную ситуацию: большой проект, в котором пять или более разработчиков имеют доступ к commit, и, как правило, по крайней мере трое работают над ним в любое время. Мы управляем всем, используя один репозиторий с ответвлениями и запросами pull, и у нас не было никаких проблем (которые были вызваны нашей настройкой системы управления версиями).
Запросы на вытягивание-это отличный способ запрашивать обзоры кода у других разработчиков, что особенно важно, когда те же самые разработчики могут быть работа с вашим кодом на следующий день. Форкинг, с другой стороны, на самом деле не дает никакой выгоды; это решение проблемы предоставления более широкого доступа к контролируемой кодовой базе, и эта проблема просто не существует, когда все имеют фиксированный доступ к РЕПО.
Компании Atlassian имеет отличную напишу о различиях между разветвлением и другие рабочие процессы Git на своей странице в учебники ЖКТ. (См. Forking Workflow / Atlassian Git Tutorial)
Соответствующие цитаты:
Главное преимущество раздвоения рабочего процесса заключается в том, что вклады могут быть интегрированы без необходимости для всех толкать к единому центральному хранилищу. Разработчики толкают к своим собственным серверным репозиториям, и только сопровождающий проекта может толкать к своим собственным серверным репозиториям. официальное хранилище. Это позволяет сопровождающему принимать коммиты от любого разработчика, не предоставляя ему доступа на запись к официальной кодовой базе.
...
Важно понимать, что понятие "официального" репозитория в рабочем процессе разветвления является всего лишь условностью. С технической точки зрения Git не видит никакой разницы между публичным репозиторием каждого разработчика и официальным. На самом деле, единственное, что делает официальный репозиторий таким официальным, это что это публичное хранилище сопровождающего проекта.
...
Все эти личные публичные репозитории на самом деле просто удобный способ поделиться ветками с другими разработчиками. Все должны по-прежнему использовать ветви для изоляции отдельных объектов, как в рабочих процессах ветвей функций и GitFlow. Единственная разница заключается в том, как эти ветви становятся общими. В процессе разветвления они втягиваются в локальный репозиторий другого разработчика, в то время как в ветвь функций и рабочие процессы Gitflow они перемещаются в официальный репозиторий.
Я бы работал "централизованно", то есть, имея основное РЕПО, которое каждый виляет, каждый разработчик будет совершать свое собственное РЕПО, что упрощает процесс проверки кода. После завершения проверки кода Вы можете объединить изменения с основным РЕПО.
Это только основная идея...
Вам также потребуется настроить стратегии ветвления. Я бы рекомендовал Модель Nvie
Я чувствую, что узкое место не разветвляется и не разветвляется. В обоих подходах требуется ручное вмешательство слияния / пересмотра изменений.,
Таким образом, узким местом является подход к разработке приложений. Я вижу проблему, когда команда работает над одним и тем же файлом. При правильном архитектурном дизайне, можно ли разделить его на отдельные модули с отдельными файлами ? Во время выполнения или сборки отдельные модули (или файлы) могут быть объединены, чтобы сформировать весь компонент (или один файл).
Если бы мы могли решить ее на этом уровне, как только размер команды увеличивается или сложность объекта увеличивается, все будет гладко масштабироваться.