Как создать удаленный 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каталог, он также автоматически получит принудительный доступ. 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.

Когда вы нажимаете на пульт, сохраненные файлы копируются как есть, перевод строки не заканчивается. (Прекращение перевода строки происходит, когда файлы передаются в хранилище, а не при перемещении хранилищ). В итоге вы получите CRLF в своем Unix-подобном хранилище, а это не то, что вам нужно.

Чтобы получить LF в удаленном репозитории, вы должны сначала убедиться, что LF находится в локальном репозитории, путем повторной нормализации вашего репозитория Windows. . Это не окажет видимого влияния на ваш рабочий набор Windows, у которого все еще есть окончания CRLF, однако, когда вы нажимаете на удаленный, пульт получит LF правильно.

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

Существует интересная разница между двумя популярными решениями выше:

1. Если вы создаете пустой репозиторий, как это:

   cd / outside_of_any_repo
   mkdir my_remote.git
   cd my_remote.git
   git init --bare
   

а потом

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» как удаленный, с remote.origin.url, эквивалентным пути к локальному каталогу, что может быть неуместно, если он будет перемещен на сервер.

Хотя от этой «удаленной» ссылки можно легко избавиться позже, если она не подходит, все же нужно установить «original_repo», чтобы указывать на «my_remote.git» в качестве удаленного по восходящему каналу (или куда бы он ни направлялся) чтобы поделиться с). Технически, вы можете достичь того же результата, сделав еще несколько шагов, используя подход №2. Но # 1 кажется более прямым подходом к созданию «центрального голого общего репо», исходящего из локального, подходящего для перехода на сервер, с меньшим количеством шагов. Я думаю, что это зависит от роли, которую вы хотите играть в удаленном репо. (И да, это противоречит документации здесь .)

Предостережение: я узнал вышеизложенное (на момент написания этой статьи в начале августа 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 на сервере - протоколы

Вам необходимо создать каталог на удаленном сервере. Затем используйте команду "git init", чтобы установить его в качестве хранилища. Это должно быть сделано для каждого нового проекта (каждая новая папка)

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

Проверьте здесь - https://github.com/skbobade/ocgi

Обычно вы можете настроить git-репо, просто используя initкоманду

git init

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

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

Есть и другие способы клонирования репо. Таким образом, вы называете это, если у вас есть настроенный ssh-ключ на вашем компьютере, который проверяет наличие вашего хранилища. Существуют и другие комбинации URL, если вы хотите включить свой пароль и имя пользователя для входа в удаленный репозиторий.