Это требует использования GitHub, но также довольно просто и чисто.
===================================================================

дели и смотрели видео о том, как большие распределенные команды используют Git, но как насчет тех из нас, кто не распределен и кто работает в офисе с остальной частью нашей команды? Как мы должны структурировать наш репозиторий (ы) и наш рабочий процесс?

Подумайте о традиционном офисе, который использовал Subversion или CVS в качестве единого авторитета. Конечно, каждая из этих групп могла бы поддерживать свой собственный Git-репозиторий и толкать / тянуть между собой по мере необходимости, что во многих ситуациях быстро превращалось бы в кошмар. Или каждый из них может поддерживать свой собственный репозиторий и синхронизировать его с одним репозиторием, который известен как «главный» для команды. Или может быть любая комбинация рабочих процессов с возможностями, которые открывает DVCS.

Как работает ваша команда? Что вы считаете полезным рабочим процессом?

 как Yahoo! Пользовательский интерфейс (YUI), кажется, работает. Я не в Yahoo и не в этой команде, но их журналы git commit многое раскрывают об их процессе.

Команда YUI поддерживает центральное хранилище, где каждый член команды имеет доступ к коммитам. Периодически после коммитов в этот репозиторий (это может быть после каждого нажатия, но я так не думаю), система сборки запускает, перестраивает YUI и помещает новый тэг коммит в github, где сообщество может форкнуть код и работать над ним. ,

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

«Главный» репозиторий предлагает и другие преимущества, такие как простота непрерывной интеграции, так как триггеры «push / pull» могут быть настроены в «главном» репозитории для запуска модульных тестов и сборки системы. Это также гарантирует, что все знают, где находится самая последняя «хорошо известная» версия репозитория, поэтому, если проект необходимо построить, опубликовать или протестировать, могут быть разумные гарантии того, что «главный» репозиторий готов к этому. ,

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



<http://nvie.com/git-model> и комментарии



<http://scottchacon.com/2011/08/31/github-flow.html>

Это требует использования GitHub, но также довольно просто и чисто.