Каков наилучший принцип загрузки проекта на gitlab для больших команд?

Question

Каков наилучший подход для загрузки проекта на Gitlab? Предположим, что вы 10 разработчиков, над которыми вы работаете. главный человек - "Maintainer" на git, а остальные - разработчики должны ли они иметь свои собственные ветви? или все должны работать на ветке? Как они должны исправлять конфликты?

Answer 1

Боюсь, что ваш вопрос - это вопрос, основанный на мнении.Но вот мои 10 центов:

Есть несколько «лучших» подходов для вашей команды:

• Ветвление, основанное на элементах , где каждая функциянаходится в своей собственной ветви, и после того, как работа разработчика завершена (будь то от 1 разработчика или N разработчиков), ветвь затем перебазируется с помощью master, разрешает конфликты, если таковые имеются, тестирование интеграции и, наконец, объединение и удаление.Я считаю это лучшим.

• Разветвление на основе разработчика, где у каждого разработчика есть своя версия репозитория, и они разрабатывают свою собственную работу над ним.Как только разработчик закончил, он перезагружается с основной веткой (например, master), тестом интеграции и, наконец, объединяется.Интеграционный тест должен быть быстрым, в противном случае, если main получил новые обновления, он должен будет выполнить повторную перезагрузку, чтобы сохранить синхронизацию.

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

Answer 2

Рекомендуемая схема в гибких средах: Разработка на основе магистрали . То есть все участники часто совершают коммиты и объединяются в одну ветку .