Использование GIT для отслеживания удаленного проекта, но сохранение локальных изменений в секрете

Question

На работе мы участвуем в проекте с открытым исходным кодом, используя git, а также сохраняем локальные правовые изменения (мы также лицензируем его).И то, что я хотел бы сделать, это настроить пустой репозиторий, который является клоном репозитория upstreams.Наши разработчики затем клонировали бы из этого и вернулись к нему, используя больше модели разработки cvs / svn - если Джо работает над чем-то в ветке, а затем уходит, мы бы просто хотели, чтобы Хэнк занял место, проверив ветку.

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

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

Имею ли я svn слишком сильно на меня влияют, как я хотел бы, чтобы наше git репоработа?

Спасибо.

Answer 1

Я предлагаю следующее:

• Отделение GIT UPSTREAM (aka upstream ):
  • master
• ОБЩЕЕ РЕПО КОМПАНИИ (также известное как companygit ) филиалы:
  • Собственность: филиал развития компании
• МЕСТНЫЕ РЕКЛАМНЫЕ филиалы:
  • upstream_master: отслеживает upstream / master
  • проприетарный: отслеживает companygit / проприетарный

Таким образом, новый работник отправит клону companygit на свой компьютер, затем добавьте upstream (git remote add) и извлеките ветку _upstream_master_ оттуда.Локально у него будет ветвь _upstream_master_, которая непосредственно отслеживает upstream / master remote (я думаю, что companygit это не должно волновать), и проприетарная ветка 1034 *, которая следует за веткой companygit .

Время от времени он мог 'git pull upstream_master', оформить заказ, а затем 'git merge upstream_master' (молиться об отсутствии конфликтов :)), чтобы включить новые восходящие коммиты, а затем нажать companygit .

Для того, чтобы отправить ваши конкретные обновления в upstream , я буду использовать 'git cherry-pick' для каждого соответствующего коммита.

Answer 2

Вот одно из решений: иметь где-нибудь непонятный репозиторий, который имеет удаленный доступ как к вашему внутреннему центральному репозиторию, так и к вышестоящему мастеру. Затем вы можете получить задание cron, которое выполняет команду git pull upstream master; git push внутренний мастер: вверх по течению. Это вытянет вышестоящий код, а затем обновит ветку 'upstream' на вашем внутреннем сервере новым кодом.

Оттуда каждый может просто перейти вверх по течению вместе с двумя другими тегами - может быть, «опубликованные» и «внутренние» или что-то в этом роде? - которые представляют работу, которую вы делаете внутри, все из центрального репо. Если вы убедитесь, что что-либо, что будет опубликовано, попадет в опубликованную ветку, вы можете затем отправить это на github или что-то еще, чтобы люди из верхнего уровня могли объединиться, если захотят. Вообще говоря, у вас будет возможность периодически объединять вышестоящий поток с опубликованным и опубликованный с внутренним, чтобы изменения в исходном потоке распространялись должным образом.

Answer 3

Мой совет - использовать CI-сервер, такой как git. Например, у Хадсона есть плагин, который позволяет объединить все ветви, собрать и протестировать его и передать мастеру, когда все будет зеленым.

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

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