Git со многими разработчиками - PullRequest
4 голосов
/ 23 февраля 2012

Я пытаюсь устранить путаницу в том, как работать с более чем 1 разработчиком в репозитории git. Позвольте мне объяснить, как мы работали до сих пор.

У нас есть 3 разработчика, работающих над одним проектом, скажем, dev1, dev2 и dev3. Основная ветвь на git-сервере, и это проверено, что мы делаем, когда разработчик клонирует репо в первый раз, он создает новую ветвь, скажем, branch-dev1 на своей локальной машине, и он работает в этой ветке. И когда все выглядит стабильно, он подталкивает свою ветку к центральному репо. Поэтому его ветвь branch-dev1 доступна на централизованном сервере. Затем менеджер проекта объединяет свой филиал с главной веткой и разрешает конфликт, если таковой имеется. Точно так же dev2, dev3 выдвигают свои ветви branch-dev2, branch-dev3, и снова их ветвь является слиянием и конфликты разрешаются, если таковые имеются. Затем на следующий день каждый из них вытаскивает голову с сервера централизованного сервера и получает коммиты от других разработчиков. И они работают в итерациях.

Что я хочу знать, так это правильный подход?

Ответы [ 2 ]

3 голосов
/ 23 февраля 2012

Одной из неприятных вещей в git является то, что «правильного подхода» НЕ существует.

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

Если для вашей организации целесообразно разделять вклады разработчиков на основной путь разработки, сделайте это. Также нет проблем с несколькими разработчиками, работающими в одной и той же ветке разработки. Или с отдельными небольшими ветками для отдельных функций, над которыми работает каждый разработчик.

2 голосов
/ 23 февраля 2012

Важно знать, что означает upstream с DVCS.
См. « Определение понятий« нисходящий »и« восходящий »».
Как только вы это узнаете, вы поймете, что вы можете иметь много репозиториев от апстрима .

Вы описали только один из возможных рабочих процессов, как описано в « Распределенные рабочие процессы (книга Pro Git) »:

centralized distributed workflow

Это не единственный (как показано на остальной части страницы Pro Git), и он не мешает dev1 регистрировать репо dev2 в качестве нового обратного (удаленного) репо и получать непосредственно оттуда.
Однако, если три разработчика работают над одним и тем же «усилием по разработке», они должны работать (или, по крайней мере, подтолкнуть к ) той же ветви : см. « Когда вы должны филиал ».
Не забывайте, что в случае DVCS (Distributed VCS) концепция ветвления ортогональна публикации (push / pull) .

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