Ответы:
Я думаю, что вы создаете пустой репозиторий на удаленной стороне, git init --bareдобавляете удаленную сторону в качестве трекера push / pull для вашего локального репозитория ( git remote add origin URL), а затем локально говорите git push origin master. Теперь любой другой репозиторий можно pullиз удаленного репозитория.
git push origin masterпроизойдет сбой с ошибкой «хранилище не найдено», попробуйте git update-server-infoна удаленной стороне, где вы это сделалиgit init --bare
git update-server-infoно я получаю ошибку fatal: Unable to look up Volumes (port 9418) (nodename nor servname provided, or not known)
Для первоначальной настройки любого сервера 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. Теперь вы готовы сотрудничать в одном проекте.
scpРешение работает ИМО на практике лучше , чем init --bare. Тем не менее, он все еще чувствует себя как некрасивый хак: сначала локально клонировать, а затем скопировать на сервер ... если бы у git была команда сделать это за один раз.
--sharedработал на меня. Интересно, что произойдет, если вы используете, git init --sharedне делая ни --bareодного ...
scpэто для удаленного будет работать лучше, если оно не поддерживает git init --bare(как это было в случае с git 1.5.5, 2008). Я думаю, что это должно работать, даже если пульт не имеет мерзавца вообще.
Примечание для людей, которые создали локальную копию в 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-окончания, клон будет иметь НЧ тоже).
Существует интересная разница между двумя популярными решениями выше:
Если вы создаете пустой репозиторий, как это:
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/
с последним в качестве вышестоящего пульта. И у вышестоящего пульта нет других пультов в его конфигурации.
Однако, если вы делаете это наоборот:
(из в каталоге 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, если вы хотите включить свой пароль и имя пользователя для входа в удаленный репозиторий.