Як створити віддалений сховище Git з локального?

У мене є місцеве сховище Git. Я хотів би зробити це доступним на віддаленому сервері з підтримкою ssh. Як це зробити?

Я думаю, що ви робите оголене сховище на віддаленій стороні, git init --bareдодаєте віддалену сторону як трекер push / pull для вашого локального сховища ( git remote add origin URL), а потім локально ви просто говорите git push origin master. Тепер будь-яке інше сховище може pullз віддаленого сховища.

Для того, щоб спочатку налаштувати будь-який сервер Git, вам потрібно експортувати наявний сховище в новий голий сховище - сховище, яке не містить робочого каталогу. Це взагалі просто зробити. Для того, щоб клонувати ваше сховище для створення нового голого сховища, ви запускаєте команду clone з --bareможливістю. За умовою, оголені каталоги репозиторію закінчуються .gitтак:

$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/

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

Тепер, коли у вас є гола копія вашого сховища, все, що вам потрібно зробити, - це поставити його на сервер і налаштувати свої протоколи. Скажімо, ви налаштували сервер під назвою, до git.example.comякого у вас є доступ до SSH, і ви хочете зберігати всі свої сховища Git під /opt/gitкаталогом. Ви можете налаштувати своє нове сховище, скопіювавши своє голе сховище на:

$ scp -r my_project.git user@git.example.com:/opt/git

На даний момент інші користувачі, які мають доступ SSH до того ж сервера, який має доступ до читання до /opt/gitкаталогу, можуть клонувати ваше сховище, запустивши

$ git clone user@git.example.com:/opt/git/my_project.git

Якщо користувач SSH входить до сервера і має доступ до запису до /opt/git/my_project.gitкаталогу, він також автоматично матиме push push. Git автоматично додасть дозволи групового запису до сховища належним чином, якщо запустити команду git init з --sharedможливістю вибору.

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared

Дуже легко взяти сховище Git, створити голу версію та розмістити її на сервері, до якого ви та ваші співробітники мають доступ до SSH. Тепер ви готові співпрацювати над тим самим проектом.

Примітка для людей, які створили локальну копію в Windows і хочуть створити відповідне віддалене сховище в системі Unix-line, де текстові файли отримують закінчення LF у подальших клонах розробниками в Unix-подібних системах, але закінчення CRLF у Windows.

Якщо ви створили свій сховище Windows перед тим, як налаштувати переклад на рядок, то у вас є проблема. Налаштування Git за замовчуванням не є перекладом, тому ваш робочий набір використовує CRLF, але ваш сховище (тобто дані, що зберігаються під .git) також зберегло файли як CRLF.

Коли ви натискаєте на пульт дистанційного керування, збережені файли копіюються як є, переклад рядка, що закінчується, не відбувається. (Переклад рядкового закінчення відбувається, коли файли передаються в сховище, а не при натисканні репозиторіїв). У кінцевому сховищі Unix ви описуєтеся CRLF, а це не те, що потрібно.

Щоб отримати LF у віддаленому сховищі, спочатку потрібно переконатися, що LF знаходиться в локальному сховищі, повторно нормалізуючи ваше сховище Windows . Це не матиме видимого ефекту на вашому робочому наборі Windows, який все ще має закінчення CRLF, однак при натисканні на пульт віддалений отримає LF правильно.

Я не впевнений, чи є простий спосіб сказати, які закінчення рядків у вашому сховищі Windows - я думаю, ви можете перевірити це, встановивши core.autocrlf = false, а потім клонувавшись (якщо репо має закінчення LF, у клона буде НЧ теж).

Існує цікава різниця між двома популярними рішеннями вище:

1. Якщо ви створюєте голий сховище так:

   cd / external_of_any_repo
   mkdir my_remote.git
   cd my_remote.git
   git init --баре
   

і потім

cd  /your_path/original_repo
git remote add origin /outside_of_any_repo/my_remote.git
git push --set-upstream origin master

Тоді git встановлює конфігурацію в "original_repo" при цьому співвідношенні:

original_repo origin --> /outside_of_any_repo/my_remote.git/

з останньою як віддалений вище за течією. І пульт дистанційного керування не має інших конфігурацій у своїй конфігурації.

2. Однак якщо ви робите це навпаки:

   (з довідника original_repo)
   cd ..
   git clone - Bare original_repo /outside_of_any_repo/my_remote.git
   

тоді 'my_remote.git' завершує свою конфігурацію, яка має 'origin', що вказує на 'original_repo' як віддалений, a remote.origin.url прирівнюється до локального шляху до каталогу, що може бути невідповідним, якщо він буде переміщений на сервер.

Хоча цю "віддалену" посилання легко позбутися пізніше, якщо вона не підходить, "оригінал_repo" все-таки повинен бути налаштований так, щоб вказувати на "my_remote.git" як віддалений вихідний потік (або туди, куди він рухається). до якого слід ділитися). Тож технічно ви можете досягти того ж результату, виконавши ще кілька кроків із підходом №2. Але здається, що №1 є більш прямим підходом до створення "центральної голої спільної репо", яка походить з локальної, підходящої для переходу на сервер, з меншою кількістю кроків. Я думаю, це залежить від ролі, яку ви хочете відіграти віддаленому репо. (І так, це суперечить документації тут .)

Caveat: Я дізнався вище (про це писав на початку серпня 2019 року), зробивши тест на моїй локальній системі з реальним репо-рентом, а потім зробив порівняння файлів за результатами. Але! Я все ще вчуся, тому може бути більш правильний спосіб. Але мої тести допомогли мені зробити висновок, що №1 - це мій в даний час кращий метод.

Віддалене сховище, як правило, є голим сховищем - сховищем Git, яке не має робочого каталогу. Оскільки сховище використовується лише як точка спільної роботи, немає причин перевіряти знімок на диску; це лише дані Git. Найпростіше кажучи, оголене сховище - це вміст каталогу .git вашого проекту та нічого іншого.

Ви можете створити голое сховище git із таким кодом:

$ git clone --bare /path/to/project project.git

Один з варіантів наявності віддаленого сховища git - це використання протоколу SSH:

Загальний транспортний протокол для Git, коли самостійний хостинг над SSH. Це тому, що доступ SSH до серверів уже налаштований у більшості місць - а якщо це не так, зробити це легко. SSH також є автентифікованим мережевим протоколом, і оскільки він є всюдисущим, його легко налаштувати та використовувати.

Для клонування сховища Git через SSH можна вказати таку ssh://URL-адресу:

$ git clone ssh://[user@]server/project.git

Або ви можете використовувати коротший синтаксис scp-подібного для протоколу SSH:

$ git clone [user@]server:project.git

В обох випадках вище, якщо ви не вказали необов’язкове ім’я користувача, Git передбачає користувача, на який ви ввійшли в систему.

Плюси

Плюсів використання SSH багато. По-перше, налаштування SSH відносно проста - демони SSH є звичайною справою, багато мережевих адміністраторів мають досвід роботи з ними, і багато дистрибутивів ОС налаштовані з ними або мають інструменти для управління ними. Далі, доступ через SSH безпечний - вся передача даних шифрується та аутентифікується. Нарешті, як і протоколи HTTPS, Git та Local, SSH є ефективним, завдяки чому дані є максимально компактними перед передачею.

Мінуси

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

Для отримання додаткової інформації перегляньте посилання: Git on the Server - протоколи

Вам потрібно створити каталог на віддаленому сервері. Потім використовуйте команду "git init", щоб встановити її як сховище. Це потрібно зробити для кожного нового проекту (кожна нова папка)

Припускаючи, що ви вже налаштували та використовували git за допомогою ssh-клавіш, я написав невеликий скрипт Python, який при виконанні з робочого каталогу встановить віддалений і ініціалізує каталог як git repo. Звичайно, вам доведеться відредагувати скрипт (лише один раз), щоб повідомити йому сервер та кореневий шлях для всіх сховищ.

Перевірте тут - https://github.com/skbobade/ocgi

Зазвичай ви можете встановити git repo, просто скориставшись initкомандою

git init

У вашому випадку вже є репо на віддаленому пульті. Залежно від того, як ви отримуєте доступ до віддаленого репо-репортажу (з ім’ям користувача всередині URL-адреси або ключем ssh, який обробляє підтвердження), використовуйте лише cloneкоманду:

git clone git@[my.url.com]:[git-repo-name].git

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