Можно ли хранить два разных вида кода в одном репозитории git? [закрыто]
Я начинаю новый проект и пытаюсь решить, как организовать код в Bitbucket. Я работаю в стартапе, где у всех нас есть технический опыт, но никто из нас не работал в компаниях по разработке программного обеспечения. Мы спорили о том, как лучше организовать наш код в наших репозиториях bitbucket.
У нас есть некоторый PHP-код для передней части нашего веб-сайта и немного Matlab для бэкенда (Matlab выполняется для работы с PHP, но я не думаю, что уместно). PHP-код используется исключительно для веб-сайта, но над Matlab работают многие разработчики, внося изменения, некоторые из которых имеют отношение к веб-сайту, а некоторые нет.
Мы разработали три схемы организации кода:
Схема 1: Поместите Matlab и PHP в один репозиторий. Разделите Matlab на "Веб-сайт" (он же стабильная основная ветвь), "Develop1", "Develop2" и т. Д. Разработчики работают над своей собственной ветвью, и периодически мы объединяем ветви разработки в ветку Веб-сайта.
Схема 2: Поместите Matlab и PHP в один репозиторий. Разработчики, которые хотят работать с Matlab, разветвляют Matlab на другие репозитории, а затем отправляют запросы на извлечение, когда они хотят, чтобы их код был объединен с кодом Matlab веб-сайта.
Схема 3: Поместите PHP в один репозиторий, а Matlab - в другой. Затем разработчики разветвляются или разветвляются, как описано выше.
О чем вы думаете? Администратор базы данных в нашей компании говорит, что это ужасная идея - ставить два типа кода в одном репозитории (и в какой-то момент их будет три, так как мы будем замедлять переход кода Matlab на C или какой-либо другой язык). С другой стороны, я беспокоюсь, что будет трудно отслеживать, какие версии работали друг с другом для PHP и Matlab, если они находятся в отдельных репозиториях.
Я прочитал несколько сообщений о переполнении стека, которые частично ответили на мои вопросы:
Это помогло мне понять разницу между ветвями и вилки - мне кажется, что ветви просто требуют большего доверия к разработчикам, поскольку они могут объединяться без разрешения или проверки кода.
Ветвь Git, вилка, извлечение, слияние, перебазирование и клонирование, в чем разница?
Это кажется очень близким к моему вопросу, хотя, когда я показал его администратору базы данных, он сказал, что это не очень хороший пример, так как Java и Javascript очень похожи. Однако ответ, написанный здесь, похоже, указывает на мою схему 1.
Как это сделать организуйте общий код/ресурсы в проектах с помощью репозиториев git
Это также помогло мне лучше понять ветви и git в целом.
Http://tom.preston-werner.com/2009/05/19/the-git-parable.html
Этот ответ также, по-видимому, предполагает, что даже код, который не использует общие файлы, должен находиться в одном хранилище, если он является частью одного и того же проекта.
1 answers
Используйте только один репозиторий. Нет абсолютно никакой причины создавать два хранилища только из-за языков. В большинстве проектов в любом случае используется более одного языка (например, веб-приложение будет иметь некоторую серверную часть, скажем, Java или Go, некоторые файлы HTML, CSS и JavaScript, несколько сценариев оболочки, некоторые сценарии SQL, несколько используемых утилит и т. Д.). Используйте два репозитория, только если вы можете использовать один без другого каким-либо образом, и вы указали чистый интерфейс между ними ( в в этом случае, возможно, было бы полезно создать два хранилища, но это, очевидно, не ваш случай). Ваша забота верна: синхронизировать отдельные репозитории - это кошмар.
И ветви вообще не используются для разделения языков. Они используются для того, чтобы у вас были разные версии всего вашего кода (разработка новой функции, хранение выпущенной версии, чтобы вы могли вернуться к ней для исправления, наличие выделенной более проверенной ветви для производства, и т.д.).
Обратите также внимание, что у вас могут быть клоны репозитория (помните: git распространяется ), вы даже можете решить, что есть один репозиторий, в котором только несколько сопровождающих имеют доступ на запись, и они извлекают данные из других репозиториев. Но в этот момент, с вашим опытом, вы можете захотеть использовать решение, построенное на git, а не на чистом базовом git, будь то коммерческое (ищите Atlassian, GitHub и т. Д.) Или бесплатное (например, gitolite).