Как обрабатывать общий код с Git в этом сценарии? - PullRequest
6 голосов
/ 26 января 2011

В настоящее время я пытаюсь переключить наш контроль версий на Git (из CVSNT). Удивительно, но у меня были проблемы не с распределенностью, а с концепцией промежуточной площадки. Но у меня возникли некоторые проблемы, связанные с тем, что такие операции AFAICT, как разветвление, слияние и тегирование, всегда применяются на уровне хранилища, а не на уровне файла или каталога ...

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

/Dev
  /Libs
    /LibA
    /LibB
    /LibC
  /Project1
  /Project2
  /Project3
  /WebDev

Теперь предположим, что Project1 зависит от LibA и LibB, Project2 зависит от LibB и LibC, а Project3 не имеет зависимостей lib. Некоторые из этих библиотек позже скомпилированы в DLL (или BPL - наша основная среда разработки - Delphi), другие - просто наборы кода многократного использования, который включается в основные файлы в виде файлов за файлом.

WebDev содержит код для нашего (в основном статического) веб-сайта компании, который также содержит информацию о Проекте 1,2,3 и, следовательно, может быть помечен вместе с ними.

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

Как бы я смоделировал это в Git, и было бы даже целесообразно придерживаться этого способа работы? Я читал о подмодулях git, но до сих пор не вижу, как применить это здесь по нескольким причинам:

  • Насколько я понял, подмодули всегда будут проверяться внутри их соответствующего "суперпроекта". Однако мы обнаружили, что управление несколькими копиями библиотечного кода (во время разработки) с помощью Delphi является королевской PITA, и это одна из причин, по которой мы храним все библиотеки в общем каталоге за пределами отдельных деревьев проекта. Дополнительные копии проверяются только когда-либо автоматизацией сборки, но никогда не выполняются какие-либо реальные действия.

  • На самом деле я не хочу, чтобы библиотеки были «независимыми» от проектов: если я помечаю или разветвляю один из проектов, я всегда хочу пометить или разветвлять соответствующие библиотеки. Когда я хочу вернуться к определенной теговой ревизии основного проекта, я хочу, чтобы библиотеки также были возвращены в это состояние. Если возможно, тегирование / разветвление / извлечение всегда должно происходить за один шаг для проекта и его зависимостей.

Я уже предпринял одну попытку поместить все в один репозиторий Git с библиотечным кодом, в основном управляемым в основной ветке, и «проектами» каждый в своей собственной ветви, но всякий раз, когда я пытаюсь объединить изменения lib между master и проектом он также извлекает все файлы из несвязанных библиотек, чего я совсем не хочу ...

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

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

1 Ответ

3 голосов
/ 26 января 2011
  • Первое: одно Git-репо на компонент (компонентом является Lib или Project, см. Git Limits )
  • Второй: один родительский проект (Dev), в рамках которого вы объявляете все свои подмодули.

Таким образом, вы можете быстро проверить dev, а затем инициализировать / обновить только те подмодули, над которыми вы хотите работать (включая все из них, если необходимо).
При пометке тег, примененный к родительскому репо 'Dev', будет ссылаться на точные коммиты всех подмодулей, что означает: если вы вернетесь к более старой версии, вы вернете точные подмодули в том виде, как они были в указанном предыдущем состоянии.

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

...