Организация контроля версий проекта с участием нескольких частных лиц

Question

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

Краткое резюме - Наша компания заключила контракт с другой компанией для выполнения работы. Я перешел из нашего общего репозитория в наш частный репозиторий, где у нас есть другие модификации, и создал оттуда продукт релиза. Теперь мы хотим добавить еще 2 подрядчиков (которые являются целыми компаниями, а не просто парнями), которые также могут внести свой вклад, однако у всех подрядчиков есть личная информация, которую я вижу, но она должна быть конфиденциальной от других подрядчиков.

Больше деталей:

Подрядчик А запустил репозиторий Я разослал Подрядчика А моей компании

MyCompany теперь содержит дополнения к ContractorA

До сих пор я справлялся с этим так:

ContractorA отправляет данные ContractorA. На моей локальной машине есть клон MyCompany. У меня есть псевдоним для ContractorA на моей локальной машине. Я извлекаю данные из ContractorA, обрабатываю все конфликты слияний и затем отправляю на MyCompany.

Таким образом, репо MyCompany имеет все изменения от ContractorA и MyCompany.

Это работало идеально для моих нужд, однако теперь ContractorB собирается ввести изображение

У ContractorA есть проприетарные вещи, к которым у ContractorB не может быть доступа, а у ContractorB есть проприетарные вещи, к которым у Contractor A нет доступа.

Существует общий раздел, в который ContractorA будет вносить свой вклад, а MyCompany и ContractorB будут использовать.

Все должно закончиться в MyCompany, так как мы делаем 1 сборку, которая будет включать все - общий код, которым ContractorA изменяет проприетарный код из ContractorA проприетарный код из ContractorB общий код из MyCompany

Есть мысли о том, как справиться с этим?

Поскольку MyCompany является клоном ContractorA, я не могу просто предоставить доступ ContractorB к репо MyCompany, верно? Или есть способ ограничить доступ на основе каталога для каждого пользователя?

Есть ли способ превратить MyCompany в нового репозитория ContractorB и удалить весь собственный код ContractorA так, что ContractorB никогда не сможет увидеть какой-либо собственный код ContractorA. Если это так, могу ли я добавить другой псевдоним на свой локальный компьютер, извлечь из ContractorA, объединить и передать в MyCompany, а затем извлечь из ContractorB, объединить и передать в MyCompany?

Имеет ли это какой-либо смысл вообще?

Спасибо!

Answer 1

Если у вас есть репозиторий Mercurial, вам потребуется полный и полный доступ ко всей истории рабочего каталога. Тем не менее, вы можете hg clone репо и включает только определенные ветви в клоне, и пока вы внимательно следите за тем, как эти ветви взаимодействуют, вы можете достичь своей цели. У вас есть пара вариантов, и я перечислил их в порядке их ранжирования:

1. Каждый выполняет свою работу на отдельных ветках. Вам понадобятся четыре ветки: core, branch-a, branch-b, composed-branch, Все слияния между ветвями должны идти только одним путем: core -> branch-a -> composed-branch,

   • core: общая кодовая база, которая является общей для всех. Все обновления этого кода должны быть сделаны на tip из core так как вы никогда не будете сливать в него другие ветви. Если вы вносите обновления в общую кодовую базу, вы затем объединяете ее с каждой ветвью подрядчика. Если подрядчик делает что-то в своей собственной ветке, которую следует поместить в ядро, вручную обновите ядро ​​с помощью копирования / вставки или патча.
   • branch-a а также branch-b: они проводят независимую работу, выполненную отдельными подрядчиками. В публичном репо, к которому у ContractorA есть доступ (для пуш-апов), будут только изменения core а также branch-a присутствует, так как это единственные предки tip их ветви. Аналогично для РЕПО Подрядчика.
   • composed-branch: это где магия происходит. Вы вытягиваете из branch-a а также branch-b и объединить их в эту ветку, когда вы будете получать обновления от подрядчиков. Здесь вы обрабатываете любые конфликты слияний, а также можете вносить любые дополнительные изменения, чтобы интегрировать работу, выполненную подрядчиками. Это ветвь, которую тянет ваша система сборки.

2. Разбейте ваше текущее репо на несколько меньших репо, если риск неправильного пуша с одним репо слишком велик или если работа каждого подрядчика больше похожа на dll или библиотека, которая может быть построена независимо, может иметь смысл рассматривать их как независимые репозитории. В основном предыдущее предложение, но независимые репо вместо независимых веток. Вы снова разделите вещи на "используемые всеми", "созданные подрядчиком" и "объединенные итоги". Также обратите внимание, что вы можете найти суб-репозиторий hg полезным, хотя это считается "последним средством".

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

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

Примечание: даже если вы hg delete Файлы в репо, они все еще полностью доступны в истории!

Answer 2

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

• Включите расширение MQ в репозитории MyCompany
• Переместите все секретные части каждого подрядчика в отдельный MQ-патч (по одному патчу на подрядчика)
• (Clone | push to repo подрядчика) с применением только его патча (ловушка может помочь с такой проверкой состояния)
• Работа вашего интегратора должна выполняться с обоими исправлениями, примененными к репозиторию MyCompany.