синхронізація сховища git між комп’ютерами, коли пересуваєтесь?


89

Скажімо, у мене є настільний ПК і ноутбук, і іноді я працюю на настільному комп'ютері, а іноді - на ноутбуці.

Який найпростіший спосіб переміщати сховище git вперед і назад?

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

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

Дякую Йохане

Примітка: Я знаю, як це зробити за допомогою SubVersion, але мені цікаво, як це буде працювати з git. Якщо це простіше, я можу використовувати третій ПК як класичний сервер, проти якого два ПК: s можуть синхронізуватися.

Примітка: Обидва комп’ютери працюють під управлінням Linux.


Оновлення :

Тож спробуємо ідею XANI: s з оголеним репозитарієм git на сервері та синтаксисом команди push від KingCrunch. У цьому прикладі є два клієнти та один сервер.

Тож давайте спочатку створимо серверну частину.

ssh user@server
mkdir -p ~/git_test/workspace
cd ~/git_test/workspace
git --bare init

Тоді з одного з інших комп’ютерів я намагаюся отримати копію репо з клоном:

git clone user@server:~/git_test/workspace/
Initialized empty Git repository in /home/user/git_test/repo1/workspace/.git/
warning: You appear to have cloned an empty repository.

Потім зайдіть у це репо та додайте файл:

cd workspace/
echo "test1" > testfile1.txt
git add testfile1.txt
git commit testfile1.txt -m "Added file testfile1.txt"
git push origin master

Тепер сервер оновлено за допомогою testfile1.txt.

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

mkdir -p ~/git_test/repo2
cd ~/git_test/repo2
git clone user@server:~/git_test/workspace/
cd workspace/
git pull

І тепер ми можемо побачити тестовий файл.

На даний момент ми можемо відредагувати його з додатковим вмістом і знову оновити сервер.

echo "test2" >> testfile1.txt
git add testfile1.txt
git commit -m "Test2"
git push origin master

Потім ми повертаємось до першого клієнта і робимо git pull, щоб побачити оновлений файл. І тепер я можу пересуватись між двома комп’ютерами і додавати третій, якщо хочу.


Синхронізаційний скрипт для автоматизації процесу використання git для синхронізації з PC1 на PC2 швидко і з низьким використанням даних, навіть через точку доступу Wi-Fi стільникового телефону (у сотні разів швидше, ніж rsync для цього випадку використання): stackoverflow.com/questions / 4948190 /…
Габріель Стейплз,

Відповіді:


27

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

У мене є один нетбук як цілодобовий сервер, який містить кілька сховищ git. Звідти / туди я натискаю і тягну зміни через SSH. Для доступу ззовні я використовую dyndns.org. Це чудово працює, особливо тому, що у мене більше двох систем, які потребують доступу до деяких сховищ.

Оновлення: Невеликий приклад. Скажімо, мій нетбук називається "нетбуком". Я створюю там сховище

$ ssh username@netbook.local
$ cd ~/git
$ mkdir newThing
$ cd newThing
$ git init --bare

На своєму робочому столі я буду створювати його клон. Можливо, я також додаю деякі файли

$ git clone username@netbook.local:/home/username/git/newThing
$ git add .
$ git commit -m "Initial"
$ git push origin master

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

$ git clone username@netbook.local:/home/username/git/newThing
$ git remote add externalName username@mydyndns.home-ip.org:/home/username/git/newThing
$ git pull externalName master

Це просто спосіб роботи git (/ git workflows). Ви можете додати скільки завгодно віддалених сховищ. Не має значення, якщо два або більше посилаються на однакові "фізичні" сховища. Вам не потрібен власний локальний "сервер", ви можете використовувати будь-який загальнодоступний сервер, до якого у вас доступ SSH. І звичайно, вам взагалі не потрібен загальнодоступний сервер, якщо вам не потрібен доступ ззовні. Голе сховище також може бути в робочій системі, і тоді ви можете створити робоче-копію-сховище в локальній файловій системі.

$ mkdir myRepo; cd myRepo
$ git init --bare
$ cd /path/to/myProject
$ git remote add origin /path/to/myRepo
$ git add .; git commit -m "Initial"; git push origin master

Це спосіб, як я з цим справляюся, і у мене це працює цілком чудово (якщо не ідеально;))

Щось прочитати: http://progit.org/ Дійсно хороша книга. -


Як би це виглядало, коли ви використовуєте різні способи репо? Хотіли б уточнити свою відповідь на прикладі?
Йохан

Дякую, ці приклади багато чого пояснили :)
Йохан

6

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

Перейменування пульта дистанційного керування originна ім’я іншого вікна полегшує читання віддалених гілок.

Зверніть увагу, що, просто використовуючи git fetch(і ні git push), це добре працює з непростими сховищами:

[user@foo repo]$ git fetch -v bar

[user@bar repo]$ git fetch -v foo

5

Найпростіший спосіб: центральне репо, створене за допомогою --bare(тому відсутні файли, що перевіряються, лише матеріали .git) або github

"Розподілений" буде виглядати так:

Налаштування:

  1. На ноутбуці: git remote add desktop ssh://user@desktop/home/user/repo/path
  2. На робочому столі: git remote add laptop ssh://user@laptop/home/user/repo/path

Синхронізація:

git pull laptop/desktop (push не буде працювати дуже добре на не оголених репозиторіях, тому що git не буде змінювати перевірені файли при натисканні на віддалене репо)

Або зробіть репо на pendrive;)


Я намагався використовувати репозиторій --bare, але я не можу отримати правильний робочий процес.
Йохан

Я тільки починаю з git, і переходжу від локального git до github і назад, поки що можу це зробити, але метод комп’ютера до комп’ютера я не можу заробити. Тупе запитання - для яких облікових даних я використовую user? Для github мені просто потрібно додати ключі rsa-pub. Я намагався додати rsa-pub для комп'ютера-запитувача клонів до known_hosts, але це не зробило трюку ...
Дейв

Це найпростіший спосіб для мене синхронізувати між двома локальними машинами без постійного удару по віддаленому сервері.
johnzachary

1

Як щодо простого використання rsync?


3
Я роками використовував rsync для синхронізації трьох серверів. Це працює, але rsync не дає вам можливості відкотити зміни після завершення синхронізації. Я також втратив стільки файлів таким чином, тому що я недостатньо прочитав вихідний результат сухого запуску, і rsync було налаштовано на видалення файлів, яких не було на майстрі. З тих пір я перейшов на git і знайшов набагато безпечніший спосіб синхронізувати важливі каталоги.
Cloudkiller

1

Не могли б ви просто створити віддалене сховище на GitHub, BitBucket або GitLab? (Останні дві компанії пропонують необмежену кількість безкоштовних приватних сховищ). Закінчивши робочий день, просто git pushнатисніть, щоб внести зміни до віддаленого репо. Повернувшись додому, просто git pullвитягніть зміни з роботи на домашню машину. Так само, коли ви закінчуєте вдома, робіть, git pushа тоді, коли повертаєтесь на роботу, робіть git pull.


1

Який найпростіший спосіб переміщати сховище git вперед і назад [між 2 комп’ютерами]?

Сценарій 1: Я працюю (редагую код та файли) виключно на PC1, але хочу мати копію файлів (наприклад: для побудови всієї кодової бази) також на PC2.

Синхронізуйте з ПК1 на ПК2 за <1 хвилину через точку доступу Wi-Fi, використовуючи <25 МБ даних:

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

sync_git_repo_from_pc1_to_pc2

Це воно! Зазвичай це займає близько 25 МБ даних і ~ 30 сек до 1 хв, навіть коли використовується точка доступу Wi-Fi стільникового телефону і працює над репо, розмір якого становить десятки гігабайт . Я ssh'ed в PC2, тому я роблю git log -1на PC2, щоб переконатися, що синхронізація спрацювала, тоді я запускаю команду build. Працює ідеально. Спробуй. Детальніше див. Посилання нижче.

Примітка: клоноване репо на PC2 знаходитиметься у гітці з іменем somename_SYNC. Змініть сценарій відповідним чином, якщо ви хочете, щоб він мав одне і те ж ім'я гілки, а не завжди використовував "гілку SYNC". За бажання можна змінити сценарій, щоб отримати ефект, подібний до сценарію 2 нижче. Тим не менше, робити сценарій 2 вручну не складно, тому ви можете просто продовжити робити сценарій 2 вручну. Це сценарій 1, де автоматизований скрипт є найбільш вигідним та економить час, оскільки дозволяє легко і швидко "змінювати, синхронізувати, будувати" робочий процес, де "модифікувати" відбувається на PC1, "синхронізація" запускається з PC1, але також впливає PC2, а "побудова" відбувається на PC2.

Посилання:

  1. Повна інструкція з налаштування та встановлення тут:
    Робота над віддаленим проектом з Eclipse через SSH
  2. Readme, документація та репо тут: https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles/blob/master/useful_scripts/README_git-sync_repo_from_pc1_to_pc2.md .
  3. Точний сценарій, про який йде мова, знаходиться тут:
    https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles/blob/master/useful_scripts/sync_git_repo_from_pc1_to_pc2.sh

Сценарій 2: Я працюю (редагую код і файли) на кількох комп’ютерах і хочу мати можливість редагувати одне і те ж сховище коду з будь-якого комп’ютера у світі:

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

  1. Зайдіть на https://github.com і створіть обліковий запис і, за бажанням (рекомендується), налаштуйте ssh-ключі .

  2. Тепер використовуйте їх веб-інтерфейс для створення нового сховища.

    1. Починаючи з 2020 року або раніше, GitHub також дозволяє безкоштовні приватні сховища , тому це добре працює навіть для приватних проектів із закритим кодом.
  3. Знайдіть нову URL-адресу клону ssh або https-сховища. Наприклад: git@github.com: ElectricRCAircraftGuy / eRCaGuy_dotfiles.git або https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles.git .

  4. Клонуйте проект на ПК1. Приклад:

     git@github.com:ElectricRCAircraftGuy/eRCaGuy_dotfiles.git
     cd eRCaGuy_dotfiles
    
  5. І повторіть ту ж саму команду клонування на PC2.

  6. Тепер на PC1 внесіть деякі зміни, зафіксуйте їх і відправте у своє «віддалене» сховище на github:

     # edit some files, then do the following
     git add -A  # stage ("add") all changed files to be committed 
     git commit  # commit them
     git push    # push them to your remote github repo
    
  7. Тепер на ПК2 внесіть зміни:

     # pull all changes from github (which includes the changes
     # you just pushed from PC1) to PC2
     git pull  
    
  8. Тепер ви можете редагувати файли на PC2, фіксувати їх і надсилати в github, використовуючи команди, показані лише за 2 кроки вище, а потім з PC1 ви можете запустити, git pullщоб втягнути ці зміни з PC2.

  9. Продовжуйте виконувати цей процес, як потрібно, працюючи на ПК1 АБО ПК2, легко обмінюючись файлами та розподіляючи свою роботу між двома комп’ютерами. Тільки пам’ятайте, що всі ваші зміни повинні бути зафіксовані та передані в github на одному ПК, перш ніж ви зможете їх перевірити (витягнути) та продовжити роботу на іншому ПК.

  10. Якщо ви коли-небудь потрапляєте в ситуацію, коли файли дещо не синхронізуються між двома ПК, вам доведеться, можливо, скористатися деякими додатковими гілками, зробити деякі злиття, вирішити конфлікти тощо. Потім це стає більш схожим на робочий з невеликою командою, де ви всі працюєте над одним репо. Google - ваш друг. Git дуже і дуже потужний, і він має команду, набір команд або робочий процес практично для всього.


0

Ну, ви можете натискати та тягнути (через Git) до сервера, який ви потенційно можете встановити. Або ви можете зберігати свої репозиторії на GitHub і використовувати їх як міст синхронізації.


0

Ви можете зробити сховище на будь-якому з своїх комп’ютерів, можливо, на настільному, і натискати / тягнути до нього як з ноутбука, так і з самого себе.

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