На вашем git-сервере
- repo init -u https://android.googlesource.com/platform/manifest --mirror # - это ключ
- repo sync
Поскольку вы указали --mirror, все созданные репо будут «голыми» репозиториями, что является правильным способом создания зеркала, если вы не являетесь git uberlord.
На вашем клиенте:
repo init -u git@git.yourserver.com: platform / manifest.git # вы можете использовать другие средства:доступ к вашему git-серверу;Я должен предположить что-то для этого примера.
пока нет синхронизации репо. Возможно, ваш манифест неверен.Посмотрите на символическую ссылку .repo / manifest.xml ... cat и прочитайте вверху <remote fetch="" ... это, вероятно, указывает на android.googlesource.com.но если он говорит «..» Я думаю , что означает «вернуться на мой сервер», так что вы можете перейти к шагу 6).Но если он указывает на другой сервер (не на ваш), перейдите к шагу 3.
- cd .repo / manifest
- vim .repo / manifest / default.xml (или каким бы ни был ваш активный manifest.xml).
- Исправлен файл default.xml
<remote fetch="CHANGE ME", указывающий на ваш git-сервер - попытка синхронизации репо.Это должно тянуть только из вашего хранилища.Если этого не произойдет, остановите синхронизацию репозитория и попробуйте снова исправить файл default.xml.
- После того, как вы увидите работу репозитория на своем тестовом компьютере, зафиксируйте default.xml обратно (
git commit; git push), чтобы другие члены команды имели опыт «без манифеста-редактирования», когда они repo init; repo sync с вашего сервера.
Как только вы увидите работу 'no manifest edit' repo init; repo sync, снова перейдите к своему default.xml и просто начните добавлять новые элементы XML вместе с множеством другихсуществующие элементы проекта Android;эти новые элементы будут указывать на ваши собственные проекты.Для этих новых проектов просто запустите git init, как обычно, и убедитесь, что у них есть ветвь, совпадающая с <default revision="whatever_branch_you_see_here", чтобы repo sync был успешным при обнаружении этих новых проектов.
Если выдействительно установите ветку по умолчанию в элементе manifest <default revision="", а затем просто сделайте так, чтобы все сделали локальную ветвь, установленную для следования удаленной ветке, указанной в атрибуте revisionТак, например, если в вашем манифесте есть <default revision="branch_a", после того, как вы выполните синхронизацию репо, когда вы перейдете в интересующий вас подпроект, выполните:
git checkout -b branch_a origin/branch_a
Затем, если пользователь git push (нет команды repo, чтобы нажать, насколько мне известно), и если кто-то еще делает ./repo sync после этого push, они получат эти изменения от исходного пользователя.... до тех пор, пока вы используете тот же манифест и фактически переходите к версии (ветке) по умолчанию, указанной в этом манифесте.
Это самый простой рецепт.Если вы хотите создавать фактические ветви объектов, вам нужно будет редактировать манифест более регулярно, если вы хотите, чтобы 'repo sync' просто работал ... и , вам придется общаться с остальнымиКоманда, чтобы захватить вашу версию манифеста, когда вы делаете это.В качестве альтернативы, если вы касаетесь только одного или двух репозиториев git, то вы можете просто отказаться от синхронизации репо и git push / pull как обычно в этих репозиториях и игнорировать остальную часть тихого дерева в те моменты, когда вы интенсивно выполняете итерации.Это звучит, в конечном счете, для меня, как более простой путь.Я бы проигнорировал репо как можно больше;использовать его только для синхронизации «всех проектов» и оставлять его в покое на время, когда вы сосредотачиваетесь на 1 или 2 проектах.
Относительно получения обновлений от апстрима.Я думаю, что способ сделать это состоит в том, чтобы изменить ваш default.xml так, чтобы он указывал на исходное местоположение git (например, android.googlesource.com), выполнить синхронизацию репозитория, чтобы все новые вещи слились, и однажды сделать это с помощьюсинхронизировать, зафиксировать обратно в репо.Я еще не сделал этого;поэтому я не могу быть слишком конкретным, но именно так я планирую это сделать.
Я игнорирую вышеприведенные детали администрирования сервера. Например, вам нужно вызвать repo init в определенном каталоге на вашем git-сервере, чтобы сделать его доступным git-репозиторием; Я предполагаю, что вы знаете, как администрировать ваш git-сервер.