我有一个覆盆子，我可以通过ssh通过公钥访问(没有提示密码)。

在覆盆子上，我做到了

mkdir -p /home/pi/my/repo
cd /home/pi/my/repo
git init --bare

在我的笔记本电脑上，我做到了

git clone  ssh://pi@raspberry/home/pi/my/repo
cd myrepo
touch README.md
git add README.md
git commit -m "First commit"
git push

就是这样

对于在Windows上创建本地副本并希望在unix行系统上创建相应远程存储库的人来说，这里的文本文件在类unix系统上的开发人员进一步克隆时得到LF结尾，但在Windows上得到CRLF结尾。

如果你在设置行尾转换之前创建了Windows存储库，那么你就有问题了。Git的默认设置是不翻译，所以您的工作集使用CRLF，但您的存储库(即存储在. Git下的数据)也将文件保存为CRLF。

当您推到远程时，保存的文件将按原样复制，不会发生行尾转换。(行尾转换发生在文件提交到存储库时，而不是推送存储库时)。您最终会在类unix存储库中使用CRLF，这不是您想要的。

为了在远程存储库中获得LF，您必须首先通过重新规范化您的Windows存储库来确保LF在本地存储库中。这将对您的Windows工作集没有明显的影响，它仍然有CRLF结束，但是当您推到远程时，远程将正确地获得LF。

我不确定是否有一种简单的方法来告诉你在你的Windows存储库中有什么行尾-我猜你可以通过设置core来测试它。selflf =false，然后克隆(如果回购有LF结尾，克隆也会有LF结尾)。

我认为你在远程端创建一个裸库，git init——bare，添加远程端作为本地存储库的推/拉跟踪器(git remote add origin URL)，然后在本地输入git push origin master。现在任何其他存储库都可以从远程存储库中提取。

通常你只需要使用init命令就可以建立一个git repo

git init

在您的情况下，已经有一个回购的远程可用。根据您如何访问远程repo (url内的用户名或处理验证的ssh密钥)，只使用clone命令:

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

还有其他方法可以克隆回购。如果您在计算机上设置了ssh密钥，在提取存储库时进行验证，则可以使用这种方法调用它。如果您希望在其中包含密码和用户名以登录到远程存储库，则该url还有其他组合。

我有一个覆盆子，我可以通过ssh通过公钥访问(没有提示密码)。

在覆盆子上，我做到了

mkdir -p /home/pi/my/repo
cd /home/pi/my/repo
git init --bare

在我的笔记本电脑上，我做到了

git clone  ssh://pi@raspberry/home/pi/my/repo
cd myrepo
touch README.md
git add README.md
git commit -m "First commit"
git push

就是这样

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

如果你像这样创建裸库: cd / outside_of_any_repo mkdir my_remote.git cd my_remote.git Git初始化

然后

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/

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

然而，如果你反过来做: (from original_repo目录) cd . . Git克隆——bare original_repo /outside_of_any_repo/my_remote.git

然后“my_remote。Git '最终的配置是将'origin'指向'original_repo'作为一个远程，并将remote.origin.url等同于本地目录路径，如果要将其移动到服务器上，这可能不合适。

While that "remote" reference is easy to get rid of later if it isn't appropriate, 'original_repo' still has to be set up to point to 'my_remote.git' as an up-stream remote (or to wherever it is going to be shared from). So technically, you can arrive at the same result with a few more steps with approach #2. But #1 seems a more direct approach to creating a "central bare shared repo" originating from a local one, appropriate for moving to a server, with fewer steps involved. I think it depends on the role you want the remote repo to play. (And yes, this is in conflict with the documentation here.)

注意:我是在2019年8月初写这篇文章的时候，通过在我的本地系统上用一个真正的repo进行测试，然后在结果之间逐个文件进行比较，才了解到上述情况的。但是!我还在学习中，应该会有更正确的方法。但我的测试帮助我得出结论，#1是我目前首选的方法。