Git / Hg репозиторий (ы) со сложной структурой проектов

Question

в настоящее время мы используем SVN (да, я знаю, что это позор :)), и мы проверяем возможность перейти на Git или Hg. На данный момент у нас есть один SVN репо со структурой, подобной этой:

Platform 1-
          . Country 1
                    . Customer A
                               . Project Z
                               . Project Y
                    . Customer B
                               . Project X
          . Country 2
                    . Customer C
                               . Project W
Platform 2 
          . Country 1

и т.д.

У нас есть только 2 «платформы» верхнего уровня, но количество стран, заказчиков и особенно проектов довольно велико (я уверен, что количество проектов> 100). Эта структура очень удобна для нас, так как легко найти нужный проект (так как разработчик знает платформу, страну и заказчика). И, как обычно, разработчик может переключать проект несколько раз в течение одной недели, эта организация очень важна.

Базовый вариант использования:

1. Инженер получает описание проекта (довольно часто кто-то уже работал над проектом)
2. Инженер имеет полную копию репозитория SVN на своем жестком диске. Он переходит в нужную страну / клиента и делает SVN Update для папки «Клиент» (если у него нет проекта) или папки «Проект» (если он уже извлек это ранее).
3. Пользователь работает над проектом и выполняет коммиты, фиксируя всю папку проекта.

Некоторые люди просто просматривают TortoiseSVN Repo Browser, находят необходимый проект и проверяют его.

Так что теперь нам нужно нечто такое же простое, но с Git / Hg. Как я понимаю, в Git очень распространенный паттерн - 1 Repo / 1 Project. Итак, вопросы:

1. Есть ли способ классифицировать репо в Git / Hg?
2. Есть ли способ просмотреть репозитории через GUI (Win) и вытащить нужный?
3. Есть ли у вас какие-либо предложения по организации нашего репо с использованием Git / Hg?

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

Только одно замечание - ветки для нас не очень распространены, поскольку проекты довольно малы с точки зрения разработки.

Answer 1

Как я понимаю в Git, очень распространенный паттерн - 1 Репо / 1 Проект.

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

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

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

Итак, вопросы были:

1. Есть ли способ классифицировать репо в Git / Hg?
2. Есть ли способ просмотреть репозитории через GUI (Win) и вытащить нужный?
3. Есть ли у вас какие-либо предложения по организации нашего репо с использованием Git / Hg?

Подводя итог вышеприведенному ответу: Да, вы можете организовывать репозитории. Вы можете сделать это на уровне файловой системы, поместив их в структуру каталогов, и вы можете сделать это на уровне HTTP с помощью подходящего менеджера хранилища.

Как найти нужные хранилища, будет зависеть от организации. Рекомендуемый способ общего доступа к репозиториям - HTTP, и тогда диалоговое окно «Открыть репозиторий» не позволит вам просматривать папки - поскольку папки существуют только в URL-адресах, обслуживаемых, скажем, Kallithea. Поэтому ваши инженеры, как правило, просматривают структуру хранилища в своем браузере, а затем копируют и вставляют нужный URL в TortoiseHg .

.

Когда они клонируют с сервера, инженер должен затем поместить локальные клоны в иерархию, которая соответствует иерархии на сервере. Эта иерархия будет сделана с каталогами на их локальном диске. Затем они, конечно, могут просматривать эту иерархию в Windows Explorer, как обычно.

Answer 2

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

Преимущество: точно так же, как у вас.Недостаток: для обновления любой части вы обновляете все части хранилища;нет обновления «только здесь», такого как SVN.

Как правило, если платформа, страна и проект полностью независимы, я бы посоветовал вашим инженерам просто создать эту структуру локально, а вы назвали свои репозитории ${platform}-${country}-${project} длясохраните эту деталь.

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

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

Answer 3

Вы хотите один репо на проект. Это позволяет сократить объем данных, которые необходимо поддерживать локальными при работе над проектом, на более низком уровне: в отличие от SVN, у вас есть полная история каждого изменения в каждой копии репо. При выполнении git log s.

он также не позволяет коммитам одного проекта перемежаться с коммитами другого проекта.

Затем вы добавляете репо верхнего уровня для управления вашей структурой верхнего уровня. В этом репо вы добавляете подмодули git для каждого из конечных репозиториев. Люди всегда начинают клонировать / извлекать структуру верхнего уровня, а затем только проверять проекты, в которых они нуждаются, с git submodule update и git pull для проектов.

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

Answer 4

Да, очень распространено и настоятельно рекомендуется иметь репо на проект (репозитории более легки в Git / Hg, чем в SVN).Это сделано для того, чтобы люди, которым нужно оформить заказ (клонировать) только один проект, могут это сделать.В противном случае каждому придется клонировать весь набор проектов.Однако людям, которые хотят всего, придется клонировать по одному.Так что, если вы не рассматриваете наличие веток, вы можете иметь все проекты в одном репо (поскольку ветвление не может быть на уровне проекта, если у вас есть все вместе, и, следовательно, для каждого репо проекта потребуется, если вы выполняли ветвление.)

Распределите по категориям репозитории на основе папки, чтобы URL отображал классификацию, например git@host.com/platform1/Country1/CustomerA/project1.git и т. Д. Обратите внимание, что если у вас есть проекты в одном репо, вы не сможете получить такой URL.У вас будет только git@host.com/repo.git или что-то в этом роде.

Посмотрите на компромиссы и решите или один репо, или несколько репо.Вы можете даже группировать по платформам и т. Д., А не по проектам.

Вы можете использовать веб-интерфейс, например GitWeb или cgit, для просмотра репозиториев.