如何从本地创建一个远程Git存储库?

Nip*_*ips 220 git installation

我有一个本地Git存储库.我想在远程的,支持ssh的服务器上使用它.我该怎么做呢?

Ker*_* SB 265

我认为你在远程端创建一个裸存储库,将远程端git init --bare添加为本地存储库的推/拉跟踪器(git remote add origin URL),然后在本地你只是说git push origin master.现在任何其他存储库都可以pull来自远程存储库.

  • @KerrekSB可以在我本地运行git push origin master时自动在服务器上创建一个裸仓库 (6认同)
  • 如果`git push origin master`失败并显示"找不到存储库"错误,请在远程端尝试`git update-server-info`,在那里你做了`git init --bare` (4认同)

Bin*_*abu 74

为了初始设置任何Git服务器,您必须将现有存储库导出到新的裸存储库 - 不包含工作目录的存储库.这通常很简单.要克隆存储库以创建新的裸存储库,请使用该--bare选项运行clone命令.按照惯例,裸存储库目录结束.git,如下所示:

$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/
Run Code Online (Sandbox Code Playgroud)

此命令单独获取Git存储库,没有工作目录,并专门为其创建一个目录.

既然您拥有存储库的裸副本,那么您需要做的就是将其放在服务器上并设置协议.假设您已经设置了一个名为git.example.comSSH 的服务器,并且您希望将所有Git存储库存储在该/opt/git目录下.您可以通过将裸存储库复制到以下来设置新存储库:

$ scp -r my_project.git user@git.example.com:/opt/git
Run Code Online (Sandbox Code Playgroud)

此时,对具有对/opt/git目录具有读访问权限的同一服务器具有SSH访问权限的其他用户可以通过运行来克隆您的存储库

$ git clone user@git.example.com:/opt/git/my_project.git
Run Code Online (Sandbox Code Playgroud)

如果用户通过SSH连接到服务器并具有对/opt/git/my_project.git目录的写访问权限,则他们也将自动具有推送访问权限.如果您使用该--shared选项运行git init命令,Git将自动正确地向存储库添加组写入权限.

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared
Run Code Online (Sandbox Code Playgroud)

获取Git存储库,创建裸版并将其放置在您和您的协作者可以访问SSH的服务器上非常容易.现在,您已准备好在同一个项目上进行协作.

  • `scp`解决方案在实践中比`init --bare`更好地运行IMO.虽然首先在本地克隆,然后复制到服务器,但它仍然感觉有点难看.希望git有一个命令一次完成. (5认同)
  • 在本地创建一个裸存储库,如果远程不支持“git init --bare”(就像我使用 git 1.5.5, 2008 的情况一样),则“scp”在远程会更好地工作。我认为即使远程根本没有 git,这也应该可以工作。 (2认同)
  • 参考:https://git-scm.com/book/en/v1/Git-on-the-Server-Getting-Git-on-a-Server (2认同)

use*_*620 8

适用于在Windows上创建本地副本并希望在Unix系统上创建相应远程存储库的人员的注释,其中文本文件在类Unix系统上由开发人员在其他克隆上获得LF结尾,但在Windows上的CRLF结尾.

如果您在设置行结束转换之前创建了Windows存储库, 那么您就遇到了问题.Git的默认设置是无翻译,因此您的工作集使用CRLF但您的存储库(即存储在.git下的数据)也将文件保存为CRLF.

当您按下遥控器时,保存的文件按原样复制,不会发生行结束转换.(当文件提交到存储库时,不会在推送存储库时发生行结束转换).您最终在类Unix的存储库中使用CRLF,这不是您想要的.

要在远程存储库中获取LF,您必须首先通过重新规范Windows存储库来确保LF位于本地存储库中.这对您的Windows工作集没有明显的影响,它仍然具有CRLF结尾,但是当您推送到远程时,遥控器将正确获得LF.

我不确定是否有一种简单的方法可以告诉你在Windows资源库中有哪些行结尾 - 我猜你可以通过设置core.autocrlf = false然后克隆来测试它(如果repo有LF结尾,那么克隆就会有LF也).


V. *_*ler 6

上述两种流行的解决方案之间有一个有趣的区别:

  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
Run Code Online (Sandbox Code Playgroud)

然后 git 在“original_repo”中使用这种关系设置配置:

original_repo origin --> /outside_of_any_repo/my_remote.git/
Run Code Online (Sandbox Code Playgroud)

后者作为上游远程。并且上游遥控器在其配置中没有任何其他遥控器。

  1. 但是,如果你反过来做:

    (来自目录 original_repo)
    光盘..
    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 似乎是一种更直接的方法来创建源自本地的“中央裸共享存储库”,适用于移动到服务器,涉及的步骤更少。我认为这取决于您希望远程仓库扮演的角色。(是的,这与此处的文档冲突。)

警告:我通过在我的本地系统上使用真实的 repo 进行测试,然后对结果进行逐个文件的比较,了解了上述内容(在 2019 年 8 月上旬撰写本文时)。但!我还在学习,所以可能有更正确的方法。但我的测试帮助我得出结论,#1 是我目前首选的方法。


Ami*_*n72 5

远程仓库一般是裸仓库?——没有工作目录的 Git 仓库。由于存储库仅用作协作点,因此没有理由在磁盘上检出快照;这只是 Git 数据。用最简单的术语来说,裸存储库是项目 .git 目录的内容,没有别的。

您可以使用以下代码创建一个裸 git 存储库:

$ git clone --bare /path/to/project project.git
Run Code Online (Sandbox Code Playgroud)

拥有远程 git 存储库的一种选择是使用 SSH 协议:

当自托管通过 SSH 时,Git 的通用传输协议。这是因为在大多数地方已经设置了对服务器的 SSH 访问?-?如果没有,很容易做到。SSH 也是一种经过身份验证的网络协议,因为它无处不在,所以通常很容易设置和使用。

要通过 SSH 克隆 Git 存储库,您可以指定如下ssh://URL:

$ git clone ssh://[user@]server/project.git
Run Code Online (Sandbox Code Playgroud)

或者,您可以对 SSH 协议使用更短的类似 scp 的语法:

$ git clone [user@]server:project.git
Run Code Online (Sandbox Code Playgroud)

在上述两种情况下,如果您没有指定可选的用户名,Git 会假定您当前登录的用户身份。

优点

使用 SSH 的优点很多。首先,SSH 相对容易设置?—?SSH 守护进程很常见,许多网络管理员都有使用它们的经验,许多操作系统发行版都设置了它们或有工具来管理它们。其次,通过 SSH 访问是安全的吗?——所有数据传输都经过加密和验证。最后,与 HTTPS、Git 和本地协议一样,SSH 是高效的,可以在传输数据之前使数据尽可能紧凑。

缺点

SSH 的不利方面是它不支持匿名访问您的 Git 存储库。如果您使用 SSH,人们必须能够 SSH 访问您的机器,即使是只读容量,这不会使 SSH 有利于人们可能只想克隆您的存储库来检查它的开源项目。如果您仅在公司网络中使用它,则 SSH 可能是您需要处理的唯一协议。如果您想允许对您的项目进行匿名只读访问并且还想使用 SSH,则必须设置 SSH 以供您推送,但其他人可以从中获取其他内容。

有关更多信息,请查看参考: 服务器上的 Git - 协议