рабочий процесс команды github - разворачиваться или нет?

Мы небольшая команда веб-разработчиков, в настоящее время использующих Subversion, но вскоре мы переключаемся на GitHub.

Я смотрю на различные типы рабочих процессов GitHub, и мы не уверены, является ли такая концепция разветвления в GitHub для каждого разработчика такой хорошей идеей для нас.

Если мы используем вилки, я понимаю, что у каждого разработчика будут свои собственные удаленные и локальные репозитории. Я волнуюсь, что это сделает толкание наборов изменений сложным и слишком сложным. Кроме того, меня больше всего беспокоит то, что это заставит каждого разработчика иметь 2 пульта: origin (который является удаленным ответвлением) и upstream (который используется для «синхронизации» изменений из основного репозитория). Не уверен, что это так просто.

Это похоже на рабочий процесс, описанный здесь: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

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

Какие-нибудь предложения от команд, которые попробовали оба рабочих процесса?

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

Погрузитесь в него - вы обнаружите, что это действительно здорово! Вам не нужно перегружать (не разветвлять для каждого изменения в каждом файле), но вы можете раскошелиться на функции и вернуться обратно.

Думайте о GitHub как о нескольких версиях, улучшающих многие основные концепции в управлении исходным кодом.

Концепция «стабильной» ветки и «активной разработки» также охватывает многие из этих проблем, если вы не решаетесь пойти на разветвление. :П

Мы попробовали и то, и другое с разработчиками, которые чувствуют себя как дома в SVN. И если вы - группа разработчиков, уже работающих вместе и доверяющих друг другу права коммитов, вам, вероятно, будет проще просто сохранить единственное центральное репо в git и добавить вас всех как соавторов этого репо.

Мы все еще иногда делаем частные вилки, но это обычно для экзотических изменений или тестов с одним человеком, которые обычно не интересуют остальных, но которые мы все равно хотим хранить удаленно.

Я бы начал с одного центрального репо и просто немного поработал с git. Может быть, частная вилка будет расти на вас, а может и нет. Либо в порядке.

В git вилка - это просто еще одна ветка. Используя рабочий процесс fork-for-each-developer, вы фактически обязываете каждого разработчика иметь открытую (удаленную) ветвь для отслеживания своих изменений в разработке. Это полезно для возможности совместной работы (peer-to-peer) между разработчиками. В любом случае вам придется объединить изменения каждого разработчика в центральный репозиторий, поэтому я не думаю, что это приведет к дополнительным накладным расходам.

Для небольшой команды из 2-3 разработчиков можно использовать ветвление репозитория для управления исправлениями и функциями. Проблема в том, что у вас больше разработчиков, чем больше, и больше функций и исправлений, которые разрабатываются.

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

У вас также будут проблемы с совместной работой, когда кто-то принудительно продвигает общую ветку, которая находится в репо. Это означает, что никто не может должным образом сотрудничать в этой отрасли, поскольку принудительный толчок - это переписывание истории.

Форки репо позволяют отслеживать, какие филиалы находятся в стадии разработки, а какие - хороши. Это держит основной репо чище.

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