Как вы структурируете свой рабочий процесс Git-репозитория? - PullRequest
9 голосов
/ 21 января 2009

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

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

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

Ответы [ 3 ]

17 голосов
/ 21 января 2009

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

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

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

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

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

4 голосов
/ 15 июля 2010

взгляните на хороший блог http://nvie.com/git-model и комментарии

2 голосов
/ 20 июля 2012

Посмотрите на рабочий процесс, используемый командой Github:

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

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

...