Я думаю, это будет связано с рабочими процессами git и с тем, как управлять репо в команде разработчиков путем определения различных веток для dev
, mainstream
и т. Д.
Вы можете прочитать об этом здесь .
По сути, команда разработчиков создает дочернюю ветку из стабильной ветви перед началом разработки (назовем это dev-featureX
), и после завершения разработки изменения помещаются в ту же ветку на удаленном сервере (в нашем случае: origin/dev-featureX
).
Сопровождающий Repo (в нашем случае означает, что вы) вытяните все ветви своего клиента:
git pull
оформление заказа на недавно опубликованную ветку:
git checkout dev-featureX
Просмотр и аудит кодов и изменений и, наконец, объединение утвержденных изменений в основную ветку (представьте, в нашем случае, ветку dev):
git merge dev-featureX dev
Обратите внимание, что самый простой для управления рабочий процесс называется Centralized-workflow
, который имеет аналогичный подход к традиционным VCS, таким как SVN.