Git рекомендуемый рабочий процесс - PullRequest
3 голосов
/ 13 ноября 2008

Я использую git уже несколько месяцев в проекте, разработанном только мной. У меня есть локальный репозиторий, и я регулярно отправляю его на github для резервного копирования.

Я хочу добавить еще одного разработчика в этот проект, однако я буду нести ответственность за интеграцию всего проекта.

Какой рекомендуемый рабочий процесс?

Нужен ли нам частный и общедоступный репозиторий для каждого разработчика?

Если репозиторий github является основным, должен ли другой разработчик клонировать этот репозиторий или репозиторий на моем компьютере?

Должен ли он иметь право вставлять мой репозиторий или я должен вытащить его из репозитория?

Ответы [ 3 ]

8 голосов
/ 13 ноября 2008

Git ориентирован на тянет , а не толкает. В идеале другой разработчик клонировал бы из вашего публичного репо на Github; затем, когда он закончил со своими изменениями, вы либо извлечете из репозитория, который он сделает вам доступным, либо интегрируете его изменения с исправлениями, которые он отправит вам по электронной почте. В любом случае, вы вставите изменения в личное репо на своем компьютере , исправите все ошибки, возникшие в результате слияния, а затем отправите его изменения в ваше публичное репо на Github).

Конечно, нет ничего плохого в том, чтобы предоставить ему доступ к вашему репозиторию Github.

5 голосов
/ 13 ноября 2008

Он может сделать свой собственный ответвление из вашего репозитория github, и когда он почувствует, что готов к интеграции, он может отправлять вам запросы извлечения (где у вас есть общедоступный URL-адрес репозитория в качестве удаленного) или он может отправить вам git format-patch наборы.

Как правило, при таком типе рабочих процессов на него ложится большая ответственность за то, чтобы убедиться, что его исправления применимы к вашему общедоступному мастеру.

2 голосов
/ 14 ноября 2008

Несколько советов ... убедитесь, что вы оба понимаете, какие операции git переписывают историю. Сброс указателей веток, перебазирование, добавление коммитов и т. Д. Перезапишут историю, что нормально, но только для частных веток. Для веток, которыми вы делитесь (нажатием или извлечением), вы должны избегать переписывания истории.

Вот статья о Упаковка программного обеспечения с использованием Git , которую приятно читать. Он предназначен для людей, занимающихся крупномасштабной интеграцией (например, сборкой дистрибутивов Linux), но принципы в целом применимы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...