Рекомендации по совместной работе кодера с использованием Git

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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