Синхронізація зберігання сховищ git на різних хостах


34

Я замислююся про те, щоб розпочати невеликий проект, і хочу зробити його версію з git.

Бітбукет здається хорошим варіантом для мене з їх вільним планом. Я хочу використовувати його як основний інструмент для роботи з git, оскільки у них є приємні інструменти, такі як веб-інтерфейс, клієнт Mac OS тощо. Але, щоб мати більш високий захист від будь-яких випадкових пошкоджень, які можуть бути спричинені використанням стороннього сервісу, я також хочу встановити git у своєму NAS як другу резервну копію сховища.

Тепер моє запитання полягає в тому, чи можна створити сховище на двох різних хостах і потім тримати їх у синхронізації? Наприклад, припустимо, що раз на тиждень я оновлюю сховище в моєму NAS, щоб відповідати тому, що знаходиться в Bitbucket. Потім, якщо щось трапиться з Bitbucket, я все одно матиму повне сховище з повною історією розвитку на своєму локальному сховищі NAS.

І чи є спосіб імпортувати існуючий сховище з повною історією до іншого git-сервісу?


Я думаю, що дзеркальне відображення - це те, що мені потрібно. Ця стаття, здається, описує саме те, що мені потрібно. І це один , а також.

Я вірю, що це зробить повну копію з повною історією і навіть автоматично заповнить нові версії для сховищ на обох хостах автоматично.

Чи правий я?


Я використовую xpdev Мені цікаво у вашій 2 системній ситуації, якою буде bennefit у роблячому git у вашому випадку. просто щоб бути впевненим у кожному остаточному складі, я роблю резервну копію usb. Але в основному версією обробляється whitin xpdev, тому це не є реальною вимогою. До речі, якщо ви володієте неправдоподібним NASS Raid1 або тому ви можете розглянути можливість запуску власної версійної системи, також є кілька
фріонів

Але я хочу мати повну версію доступної у двох місцях. Якщо сторонній хостинг помирає, або компанія, що працює за ним, просто зникає, я хочу мати ще однаковий досвід із усією історією версій ...
BartoNaz

Це означає, що у мене буде Bitbucket для комфорту та роботи в NAS для 99,9% безпеки.
BartoNaz

Що стосується xp-dev, то навряд чи така компанія помирає, вони можуть змінити плани хостингу коду, ціни тощо. Або злитися з іншою компанією. Але це гроші доїння для них. І вони також будуть створювати резервні копії цінних даних. Їх бізнес залишається на місці. Я використовую його з 3 розробниками, і наш код існує на 5 різних машинах, де завжди є локальна копія джерела, яка синхронізується в xp dev. XP dev безкоштовний, якщо у вас є лише кілька проектів.
user613326

1
Звичайно, навряд чи. Але все-таки ти ніколи не можеш бути впевнений на 100% ...
BartoNaz

Відповіді:


19

Так, саме така краса DVCS, як git. Ви можете використовувати будь-яку кількість різних репостів з тим самим станом, що і в bitbucket або github.

Навіть локальна копія (сховище на вашому комп’ютері) зазвичай є повним клоном віддаленого репо.

Єдине, що вам потрібно зробити, щоб синхронізувати кілька репостів, - це витягнути один (як правило, його називають початком або вище) та натиснути на резервні копії.


11
На жаль, все не так блискуче. Дивіться про обережність прийняття KDE біля стихійного лиха . Тобто переконайтесь, що резервна копія не видаляє речі (гілки, сховища тощо), які були видалені на резервному сервері.
Ян Худек

Я досі не впевнений, чи правильно це розумію. Наскільки я розумію, штовхання і тягання працює з певною версією. Але скажімо, у мене на останній версії коду на моїй робочій машині. У мене є сховище git на віддаленому хості (Bitbucket, Github чи будь-що інше), яке має повну історію розробки коду аж до останньої версії, яку я маю на робочій машині (якщо вона була вчинена). І у мене є сховище в NAS, яке порожнє. Чи можу я імпортувати повну історію коду з віддаленого хоста до моєї NAS, щоб у мене було два однакових сховища у двох місцях, і як?
BartoNaz

2
Клоніруйте віддалений сховище, а потім витягуйте всі оновлення (усі гілки) до нього через рівні проміжки часу. Клон git містить історію, він не схожий на замовлення svn, який має лише останню версію.
Вільберт

11

Ось перевірене рішення проблеми: Автоматична синхронізація 2 віддалених сховищ Git

Простий скрипт для синхронізації 2 віддалених сховищ Git

Я шукав в Інтернеті простий сценарій, який буде синхронізуватися. 2 віддалених сховища, але я не зміг знайти такий скрипт, навіть багато хто, здається, шукає його! Тому я створив 2 прості тестові сховища і почав тестувати та створювати такий сценарій.

Що такий сценарій повинен робити?

Ну, загалом, кроки для цього прості: 1. Клоніруйте перше сховище 1. Додайте друге як додаткове віддалене сховище 1. виберіть усе, що є у другому сховищі 1. натисніть оновлений локальний сховище на 2 віддалені сховища.

Залишилося питання - які правильні перемикачі для всіх перерахованих вище команд git?

Так ось це ...

2repos-sync.sh gisp script

# Clear the folder first - please use this carefully
rm -rf $REPO_NAME  
# clone the reposotory
git clone --bare $ORIGIN_URL

# add a remote repository
cd $REPO_NAME
git remote add --mirror=fetch repo1 $REPO1_URL

# update the local copy from the first repository
git fetch origin --tags

# update the local copy with the second repository
git fetch repo1 --tags

# sync back the 2 repositories
git push origin --all
git push origin --tags
git push repo1 --all
git push repo1 --tags

ПРИМІТКА - цей скрипт не вирішує випадків конфліктів між вмістом сховища!


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

Щоб продовжувати це, LibGit2 корисний для подібних речей.
RubberDuck

0

Я використовую приватний GitLab для зберігання всіх моїх сховищ, тому у мене є лише одне походження, яке я натискаю і витягую, поки я займаюся розробкою щодня.

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

Це дозволяє мені ставитись до GitHub як до іншого віддаленого, з якого я можу взяти участь, коли хтось робить внесок - тоді я зливаюся --no-ff локально, і є потік до того, як усі мої первинні та загальнодоступні сховища розподіляють зміни.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.