Ветка для каждого разработчика в GIT репо

Question

Я бы хотел перенести свой проект на GitHub из локального хранилища SVN. Несколько разработчиков сейчас работают над этим проектом. Я думал, что у каждого разработчика должна быть своя ветка, в которой они будут вносить изменения. Когда менеджер рассмотрит свою работу, он объединит ее в мастер ветку. Я не хочу отдельного репозитория для каждого разработчика, поскольку GitHub имеет ограниченное количество частных репозиториев.

Это хорошая идея? Какие есть другие альтернативы?

Answer 1

Скотт Чакон проделал большую работу с книгой Pro Git. В главе 5 говорится о распределенных рабочих процессах, и я думаю, что рабочий процесс Integration-Manager соответствует тому, что вы описываете.

Git Pro

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

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

Answer 2

Вам не нужно настраивать разные ветви для каждого разработчика (хотя вы могли бы) в одном проекте, мы настраиваем архитектуру, подобную этой:

master
pre-prod
qa
devel

Разработчики все проверили ветку devel и настаивали на том, чтобы команда QA брала ветку devel каждую ночь и тянула ее в QA и фактически проверяла, что было сделано, и тестировала на аппаратной платформе разработки, тогда был pre-prod вытащил из QA после того, как прошло ~ недель QA или был достигнут рубеж и был протестирован на производственном оборудовании для «внутреннего бета», после того как он был очищен, а затем отправлен в мастер.

Если у вас несколько разработчиков, вы можете просто потратить время на настройку gitolite (или Gitosis) и удаленного репозитория Git. Наличие у каждого разработчика собственного репо, а затем либо ваше репо, являющееся «основным», либо наличие основного репо, которое вы можете извлечь из репо каждого разработчика, является идеальным и прекрасно работает в больших проектах со многими соавторами.

Однако макет ветвления на разработчика в Github также будет работать нормально, в зависимости от того, сколько у вас было разработчиков и насколько велика база кода (только из-за утомительной производительности после ~ 400 МБ или длинной истории (много различий) )

Answer 3

В Git каждый разработчик будет иметь свой собственный репозиторий и ветку по умолчанию, в которую они будут вносить изменения.

Пожалуйста, обратитесь - http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

Answer 4

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

Он известен как рабочий процесс «Децентрализованный с человеческим привратником»: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html (Этот пример с базаром, но он очень хорошо применим к GIT)

То, как вы думаете, тоже хорошо, когда у каждого есть ветка. Децентрализованный с привратником напоминает то, что использует ядро ​​Linux