Рабочий процесс, рекомендуемый Git

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

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

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

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

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

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