Як ви впорядковуєте кілька сховищ git, щоб усі вони були резервними копіями?

З 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, потім я копіюю файли в ~ / Документи / код / ​​python / Проекти / proj1 / і виконують єдину комісію (замість численних в окремих репозиціях). Потім зробіть git push backupdrive1, і git push mymemorystickт.д.

Отже, питання: як ваш особистий код та проекти з 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але не відкидає існуючої, "локальної" історії.

Примітка. Підмодулі - це механізм включення спільних пов’язаних ліній, тому я дійсно не вважаю їх відповідним інструментом для проблеми, яку ви намагаєтеся вирішити.

Я хочу додати відповідь Деміена, де він рекомендує:

$ 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>

Мені також цікаво запропоновані способи впоратися з цим і опишу поточну установку, яку я використовую (із SVN). Я в основному створив сховище, що містить ієрархію міні-файлової системи, включаючи власні din та lib dirs. У корені цього дерева є сценарій, який налаштує ваше середовище для додавання цих бін, lib тощо ... інших dir до відповідних змінних умов середовища. Отже, кореневий каталог по суті виглядає так:

./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 створити подібне середовище та розбити проекти у власні сховища?

, Я ще не пробував вкладати git-сховища, бо не потрапив у ситуацію, коли мені потрібно. Як я читав на каналі #git, git, схоже, плутається, вкладаючи сховища, тобто ви намагаєтеся git-init всередині сховища git. Єдиний спосіб управління вкладеною структурою git - це використання git-submoduleабо repoкорисність Android .

Щодо тієї відповідальності за резервну копію, яку ви описуєте, я кажу, делегуйте її ... Для мене я зазвичай ставлю сховище "початковий" для кожного проекту на мережевому диску на роботі, яке регулярно резервується IT-технологіями за їхньою стратегією резервного копіювання. вибір. Це просто, і мені не потрібно про це турбуватися. ;)

Як щодо використання mr для керування вашими кількома репортажами в Git одночасно:

Команда mr (1) може перевіряти, оновлювати чи виконувати інші дії на наборі сховищ, як якщо б вони були одним об'єднаним сховищем. Він підтримує будь-яку комбінацію subversion, git, cvs, mercurial, bzr, darcs, cvs, vcsh, сховища викопних і правдивих даних, а підтримка інших систем контролю ревізії може бути легко додана. [...]

Це надзвичайно конфігурується за допомогою простого сценарію оболонки. Деякі приклади речей, які він може робити, включають:

[...]

• Під час оновлення сховища git витягніть з двох різних вершин і з'єднайте два разом.
• Виконайте паралельно кілька оновлень репозиторію, що значно прискорить процес оновлення.
• Запам’ятайте дії, які не відбулися через відключення ноутбука, тому їх можна буде повторити, коли він повернеться в Інтернет.

Існує ще один метод вкладення git repos, але він не вирішує проблему, яку ви потребуєте. Але для інших, хто шукає рішення, я:

На верхньому рівні git repo просто захойте папку в .gitignore, що містить вкладене git repo. Це полегшує наявність двох окремих (але вкладених!) Git repos.