Лучшие практики совместной работы кодеров с использованием Git

Question

У меня проблемы с пониманием принципов командной работы Git.

Рассмотрим команду из двух программистов: A и B. Они работают на Project. Также есть удаленный сервер с репо. A и B сотрудничают удаленно. В репо уже есть код.

У меня есть просьба помочь вам в организации их пошагового рабочего процесса в Git.
1. Должны ли они создавать свои местные филиалы?
2. Как они могли загрузить рабочий код на рабочий сервер? rsync

Любая помощь будет оценена.

Answer 1

Программистам не обязательно создавать собственную ветку для работы. В простейшем случае программисты фиксируют ветку "master" в своем собственном репозитории, а затем git push фиксируют в вышестоящем репозитории.

Для развертывания на рабочем сервере, один из способов сделать это - использовать git clone на рабочем сервере для получения локального репозитория. Затем, чтобы обновить рабочий сервер, войдите в систему и git pull. Будут применены любые изменения, внесенные в основной репозиторий.

Разработчики могут по желанию создавать свои собственные ветви для собственного использования (только в своем локальном хранилище) или для обмена ветвями с другими (путем перемещения ветвей в общий репозиторий).

Answer 2

1. У каждого разработчика будет свой клон репозитория. Они могут создавать ветки для тематической работы как и когда захотят. Их личный клон - это их собственный газон, они могут делать все, что хотят.

2. Каждый разработчик должен иметь свой собственный удаленный общедоступный репозиторий, который он может передавать / извлекать из / в. Как правило, если вы хотите выпустить код, найдется один человек, который, наконец, решит, что будет добавлено в релиз, а что исключено. Удаленный репозиторий этого человека должен иметь ветку, которая представляет стабильные выпуски. Скажем, A - менеджер релизов, который хочет включить работу B в релиз. Затем А будет ждать, пока Б не отправит свою работу в свое удаленное репо. Затем А перенесет работу Б. в свой локальный клон, попробует, объединит, зафиксирует и отправит в свое (А) публичное репо для выпуска.

В (2) я описал только один из множества различных рабочих процессов, доступных для использования с распределенным SCM, таким как git. Есть много других. Эта страница из Pro-Git особенно хороша для описания некоторых других.