Я работаю над внедрением Gitlab в моей компании со стратегией рабочего процесса. Моя идея состоит в том, что разработчикам будет предоставлен доступ к репозиториям, но всякий раз, когда они пытаются зафиксировать, их код должен быть пересмотрен.
Я знаю, что могу сделать так, чтобы они создали ветку перед фиксацией, а затем создали запрос на слияние после того, как он был отправлен в репо. Я до сих пор не уверен в некоторых вещах ... Идея, что мы полагаемся на людей, создающих ветку, а затем запрос на слияние, кажется ошибочной, есть ли решение, которое вынуждает какую-то политику, что основная ветвь может оставаться чистой, если только " admin "утверждает код, который собирается в него слиться. Я читал "рабочий процесс команды github", но он не предлагает жизнеспособного решения. Любой совет о процессе или вашей собственной лучшей практике приветствуется. Благодарность!
"The idea that we rely on people to create a branch and then a merge request seems faulty"Мне кажется, что у вас есть большая проблема, чем отсутствие функций в системе контроля версий. Если вам нужно потратить дополнительное время на создание ветки, взгляните на Atlassian Stash и его интеграцию с Jira.Ответы:
Я начал работать с gitlab, читая раздел HELP, предоставляя макет рабочего процесса. На данный момент, это, кажется, лучшее решение моего вопроса. Если у кого-то есть опыт работы с этим рабочим процессом или совет, пожалуйста, добавьте любую дополнительную информацию.
Из раздела ПОМОЩЬ:
Workflow
git clone git@example.com:project-name.gitgit checkout -b $feature_namegit commit -am "My feature is ready"git push origin $feature_nameВ разделе коммитов вашего репозитория вы можете защитить ветки, что заставляет разработчиков следовать описанному выше процессу, создавая ветку и отправляя запрос на слияние.
источник