Лучшие практики совместной работы программистов с использованием Git
-
23-09-2019 - |
Вопрос
У меня возникли некоторые проблемы с пониманием принципов работы команды Git.
Рассмотрим команду из двух программистов: A
и B
.Они работают над Project
.Также есть удаленный сервер с репозиторием. A
и B
сотрудничаем удаленно.В репозитории уже есть некоторый код.
У меня есть просьба попросить вас о помощи в организации их пошагового рабочего процесса на Git.
1.Должны ли они создавать свои собственные местные филиалы?
2.Как они могли загрузить рабочий код на рабочий сервер? rsync
?
Любая помощь будет оценена по достоинству.
Решение
Для работы программистам не требуется создавать собственную ветку.В простейшем случае программисты фиксируют «главную» ветку своего собственного репозитория, а затем git push
они фиксируются в вышестоящем репозитории.
Для развертывания на рабочем сервере один из способов сделать это — использовать git clone
на рабочем сервере, чтобы получить локальный репозиторий.Затем, чтобы обновить рабочий сервер, войдите в систему и git pull
.Любые изменения, внесенные в основной репозиторий, будут применены.
Разработчики могут при желании создавать свои собственные ветки для собственного использования (только в своем локальном репозитории) или ветки для совместного использования с другими (путем отправки веток в общий репозиторий).
Другие советы
У каждого разработчика будет свой клон репозитория.Они могут создавать ветки для тематической работы, когда захотят.Их личный клон — это их собственная территория, они могут делать все, что хотят.
У каждого разработчика должен быть свой собственный удаленный общедоступный репозиторий, в который он может отправлять/извлекать данные.Обычно, если вы хотите выпустить код, один человек окончательно решает, что будет включено в релиз, а что будет вырезано.В удаленном репозитории этого человека должна быть ветка, представляющая стабильные выпуски.Допустим, А — менеджер релиза, который хочет включить в релиз работу Б.Затем А подождет, пока Б отправит свою работу в свой удаленный репозиторий.Затем А перенесет работу Б в свой локальный клон, попробует что-то, объединит, зафиксирует и отправит в свой (А) публичный репозиторий для выпуска.
В (2) я описал только один из множества различных рабочих процессов, доступных для использования с распределенным SCM, например git.Есть много других.Этот страница из Pro-Git особенно приятно описывать некоторых других.