Как вы организуете несколько git-репозиториев, чтобы все они создавались вместе?

Question

С SVN у меня был один большой репозиторий, который я хранил на сервере и извлекал из него на нескольких машинах. Это была довольно хорошая система резервного копирования, которая позволяла мне легко работать на любой машине. Я мог бы оформить заказ на конкретный проект, зафиксировать его и обновить «основной» проект, или я мог бы оформить заказ целиком.

Теперь у меня есть куча git-репозиториев для различных проектов, некоторые из которых находятся на github. У меня также есть упомянутый SVN-репозиторий, импортированный с помощью команды git-svn.

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

Проблема в том, что это частный репозиторий, а git не позволяет извлекать из определенной папки (что я могу отправить в github как отдельный проект, но изменения появятся как в master-repo, так и в суб-репо)

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

В настоящее время у меня есть папка git-repos (например, ~ / code_projects / proj1 / .git / ~ / code_projects / proj2 / .git /), и после внесения изменений в proj1 я делаю git push github, затем я скопируйте файлы в ~ / Documents / code / python / projects / proj1 / и сделайте один коммит (вместо многочисленных в отдельных репозиториях). Затем выполните git push backupdrive1, git push mymemorystick и т. Д.

Итак, вопрос: как ваш личный код и проекты с git-репозиториями, и синхронизировать их и создавать резервные копии?

Answer 1

Я бы настоятельно рекомендовал бы не помещать несвязанные данные в данный Git репозиторий. Затраты на создание новых репозиториев довольно низкий, и это функция , которая позволяет сохранить различные линии совершенно разные.

Борьба с этой идеей означает в конечном итоге ненужную запутанную историю, что делает администрирование более сложным и - более главное - инструменты «археологии» менее полезны из-за разведение. Также, как вы упомянули, Git предполагает, что «единица клонирование "является хранилищем, и практически должен сделать это из-за его распределенная природа.

Одним из решений является сохранение каждого проекта / пакета / и т. Д. как свой голый хранилище (т.е. без рабочего дерева) в благословенной иерархии, как:

/repos/a.git
/repos/b.git
/repos/c.git

Как только несколько конвенций были созданы, это становится тривиальным применять административные операции (резервное копирование, упаковка, веб-публикация) к полная иерархия, которая выполняет роль, не полностью отличную от «Монолитные» хранилища SVN. Работая с этими репозиториями также становится несколько похожим на рабочие процессы SVN, с добавлением, что один может использовать локальные коммиты и ветки:

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

Вы можете иметь несколько пультов в каждом рабочем клоне, для простоты синхронизация между несколькими сторонами:

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

Затем вы можете получать / извлекать из каждого «источника», работать и фиксировать локально, а затем нажмите («резервное копирование») на каждый из этих пультов, когда вы готовы с чем-то вроде (обратите внимание, что это толкает же коммиты и история каждому из пультов!):

$ for remote in origin github memorystick; do git push $remote; done

Самый простой способ превратить существующее рабочее хранилище ~/dev/foo в такое пустое хранилище, вероятно:

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

, который в основном эквивалентен svn import - но не выбрасывает существующая, «местная» история прочь.

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

Answer 2

Я хочу добавить к ответ Дэмиена , где он рекомендует:

$ for remote in origin github memorystick; do git push $remote; done

Вы можете настроить специальный пульт для передачи всех отдельных реальных пультов с помощью 1 команды; Я нашел это в http://marc.info/?l=git&m=116231242118202&w=2:

Так что для "git push" (где это делает смысл толкать одни и те же ветки несколько раз), вы можете сделать что я делаю:

• .git / config содержит:

  [remote "all"]
  url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
  url = login.osdl.org:linux-2.6.git
  

• и теперь git push all master переведет ветвь "master" в обоих
  из этих удаленных репозиториев.

Вы также можете сэкономить, печатая URL-адреса дважды, используя конструкцию:

[url "<actual url base>"]
    insteadOf = <other url base>

Answer 3

Мне также любопытно порекомендовать способы справиться с этим и опишу текущую настройку, которую я использую (с SVN). Я в основном создал хранилище, которое содержит иерархию мини-файловой системы, включая ее собственные каталоги bin и lib. В корне этого дерева есть скрипт, который настроит вашу среду для добавления этих bin, lib и т. Д. ... других каталогов в соответствующие переменные среды. Таким образом, корневой каталог по сути выглядит так:

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

Теперь внутри / bin и / lib есть несколько проектов и соответствующие им библиотеки. Я знаю, что это не стандартный проект, но для кого-то из моей группы очень легко проверить репо, запустить сценарий 'setup_env.bash' и иметь самые свежие версии всех проектов локально проверять, выписываться. Им не нужно беспокоиться об установке / обновлении / usr / bin или / usr / lib, и это позволяет легко иметь несколько проверок и очень локализованную среду для каждой проверки. Кто-то может также просто запустить весь репозиторий и не беспокоиться об удалении каких-либо программ.

Это хорошо работает для нас, и я не уверен, что мы изменим это. Проблема в том, что в этом большом репозитории много проектов. Есть ли в git / Hg / bzr стандартный способ создания такой среды и разбиения проектов на собственные репозитории?

Answer 4

, я еще не пробовал вложить git-репозитории, потому что я не сталкивался с ситуацией, когда мне это нужно. Как я читал на # канале git , git, похоже, запутался, вкладывая репозитории, то есть вы пытаетесь выполнить git-init внутри репозитория git. Единственный способ управлять вложенной структурой git - использовать git-submodule или утилиту Android repo.

Что касается той ответственности за резервное копирование, которую вы описываете, я говорю делегат это ... Для меня я обычно помещаю репозиторий "origin" для каждого проекта на сетевой диск на работе, который регулярно резервируется IT-технологии по своей резервной стратегии выбора. Это просто, и мне не нужно об этом беспокоиться. ;)

Answer 5

Как насчет использования mr для одновременного управления несколькими репозиториями Git:

Команда mr (1) может извлекать, обновлять или выполнять другие действия на набор репозиториев, как если бы они были одним объединенным репозиторием. Это поддерживает любую комбинацию subversion, git, cvs, mercurial, bzr, darcs, cvs, vcsh, ископаемые и правдоподобные репозитории и поддержка другие системы контроля версий могут быть легко добавлены. [...]

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

[...]

• При обновлении репозитория git вытащите два разных апстрима и объедините их вместе.
• Запускать несколько обновлений хранилища параллельно, что значительно ускоряет процесс обновления.
• Помните действия, которые не были выполнены из-за того, что ноутбук находился в автономном режиме, поэтому его можно повторить, когда он вернется в режим онлайн.

Answer 6

Есть еще один способ иметь вложенные репозитории git, но он не решает проблему, которую вы ищете. Тем не менее, для тех, кто ищет решение, я был:

В git-репо верхнего уровня просто скройте папку в .gitignore, содержащую вложенное git-репо. Это позволяет легко иметь два отдельных (но вложенных!) Репозитория git.