Итак, у меня есть проект с клиентскими частями и части сервера. Я бы хотел, чтобы клиент и код сервера были в разных хранилищах Git для четкого разделения кода, однако они делят некоторые файлы и, в идеале, общие файлы всегда будут одинаковыми как на клиенте, так и на сервере.
Как мне это сделать? Лучше ли иметь третий репозиторий для общего кода?
Я не буду давать советы о том, "Как вы должны это делать". Но я объясню, как выполнить интеграцию третьего репозитория с общим кодом в другие репозитории: это работа для подмодулей git. Подмодули git позволяют ссылаться на моментальный снимок репозитория git по указанному пути:
git submodule add git://example.com/repository.git path
Затем создайте фиксацию. Теперь снимок данного репозитория ссылается на path.
git submodule initgit submodule updateКаждый сконфигурированный подмодуль будет обновлен в соответствии с состоянием, которое должно быть похоже.
git pull/git fetch + git checkout, чтобы обновить подмодуль с требуемым фиксатором/тегом.gitmodulesВзгляните на официальное руководство для получения дополнительной информации о подмодулях.
Если они имеют общий код, я вижу два разумных варианта. Разделите общий код на собственный проект или объедините серверные и клиентские репозитории, чтобы упростить работу с ними.
Независимо от того, стоит ли отделять общий код, дополнительные усилия зависят от вас. Имеет ли общий код смысл сам по себе, или это всего лишь куча функций, характерных для этого продукта? Например, если у вас есть общий код синтаксиса SSL или даты, который бы сделал хороший проект. Или, может быть, вы написали специальный код для разбора файла конфигурации, который можно работать автономно, даже если никто, кроме вашего проекта, не будет использовать его. Если вы отключаете общий код только потому, что эти два проекта разделяют его, не беспокойтесь, у него не будет никакого собственного направления. Скручивание этого будет просто препятствием для разработки как для серверных, так и для клиентских команд.
Если вы должны объединить клиент и сервер, это еще одно соображение. Это также сводится к тому, имеет ли смысл рассматривать их как отдельные продукты. Являются ли они полезными в качестве отдельных продуктов? Могут ли разные версии клиента и сервера работать вместе, или они должны быть одной и той же версией? Работают ли разные люди на клиенте по сравнению с сервером? Тот факт, что вы хотите сохранить все вместе в одном супер-хранилище, говорит "нет".
Если вы разделитесь на несколько репозиториев (клиент, сервер, связанные проекты) следуйте за ответом TimWolla.
Если вы не уверены, объедините их все в один репозиторий с server/, client/ и common/ каталогами верхнего уровня. Если их проблемы запутаны, соедините их. Это также облегчит обнаружение и перенос дублированного кода. Вы можете работать над их распутыванием и создавать конкретные "общие" проекты, и в то время их следует выделять в свои репозитории.
Просто используйте подмодули Git для хранения вашего общего кода. Это вариант использования, для которого они предназначены. Существуют и другие варианты, но в основном для репозиториев в одной и той же файловой системе и с небольшим преимуществом при клонировании по сети.
Правильный способ иметь дело с общим кодом обычно submodules или поддерево слияния. Однако, если у вас есть файловые ресурсы, которые (и будут оставаться) идентичными, тогда вы можете использовать символические ссылки в файловых системах, которые их поддерживают. Для этого подхода есть по крайней мере три недостатка:
Вы также можете использовать alternates для обмена объектами между репозиториями в одной и той же файловой системе. В руководстве говорится (внимание мое):
Вы могли бы использовать механизмы objects/info/alternates или $GIT_ALTERNATE_OBJECT_DIRECTORIES для заимствования объектов из других хранилищ объектов. Репозиторий с таким недостроенным хранилищем объектов не подходит для публикации с использованием но в остальном все в порядке, пока объекты/информация/чередуются с объектами, которые он сохраняет.
Такое расширенное использование обычно используется для ускорения работы на таких системах, как Atlassian Stash, а не для обмена конкретными блобами, но инструменты есть, если вы хотите жонглировать бензопилами.