回答:
私はあなたがリモート側で裸のリポジトリを作成し、ローカル側のリポジトリgit init --bareのプッシュ/プルトラッカーとしてリモート側を追加すると思います（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サーバーをセットアップするには、既存のリポジトリを新しいベアリポジトリ（作業ディレクトリを含まないリポジトリ）にエクスポートする必要があります。これは一般的に簡単です。リポジトリを複製して新しいベアリポジトリを作成するには、--bareオプションを指定してcloneコマンドを実行します。慣例により、ベアリポジトリディレクトリ.gitは次のように終わります：
$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/
このコマンドは、作業ディレクトリなしでGitリポジトリを単独で取得し、それだけのディレクトリを作成します。
これでリポジトリのベアコピーができたので、サーバーに配置してプロトコルを設定するだけです。git.example.comSSHアクセスできるサーバーという名前のサーバーをセットアップし、すべてのGitリポジトリーを/opt/gitディレクトリーの下に保管したいとします。ベアリポジトリを次の場所にコピーして、新しいリポジトリを設定できます。
$ scp -r my_project.git user@git.example.com:/opt/git
この時点で、/opt/gitディレクトリへの読み取りアクセス権を持つ同じサーバーへのSSHアクセス権を持つ他のユーザーは、次のコマンドを実行してリポジトリを複製できます。
$ git clone user@git.example.com:/opt/git/my_project.git
ユーザーがサーバーに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
Gitリポジトリーを取得してベアバージョンを作成し、それをユーザーと共同編集者がSSHアクセスできるサーバーに配置するのは非常に簡単です。これで、同じプロジェクトで共同作業を行う準備ができました。
scpソリューションは、IMOを実際よりもうまく機能させinit --bareます。それでも、最初にローカルでクローンを作成してからサーバーにコピーするのは、醜いハックのような感じがします。
--shared私のために働いたので、これを+1 しました。1つgit init --sharedも作成せずに使用するとどうなるのか--bare...
scpリモートがサポートしていない場合は、リモートへのほうがうまく機能しますgit init --bare（git 1.5.5、2008の場合のように）。これは、リモートにgitがまったくない場合でも機能するはずです。
Windowsでローカルコピーを作成し、Unix行システムで対応するリモートリポジトリを作成したい人向けの注意。テキストファイルは、Unixライクなシステムの開発者がさらにクローンを作成するとLFで終わりますが、WindowsではCRLFで終わります。
行末変換を設定する前にWindowsリポジトリを作成した 場合は、問題があります。Gitのデフォルト設定は変換なしなので、ワーキングセットはCRLFを使用しますが、リポジトリ（つまり、.gitに保存されているデータ）もファイルをCRLFとして保存しました。
リモートにプッシュすると、保存されたファイルがそのままコピーされ、行末変換は行われません。（行末変換は、リポジトリがプッシュされたときではなく、ファイルがリポジトリにコミットされたときに発生します）。UnixライクなリポジトリにCRLFができてしまいます。
リモートリポジトリでLFを取得するには、Windowsリポジトリを再正規化して、LFがローカルリポジトリにあることを確認する必要があります。これはWindowsのワーキングセットに目に見える影響を与えることはなく、CRLFで終了しますが、リモートにプッシュすると、リモートは正しくLFを取得します。
Windowsリポジトリにある行末を簡単に確認できる方法があるかどうかはわかりません。core.autocrlf= falseを設定してクローンを作成することでテストできます（リポジトリにLFの末尾がある場合、クローンにはLFも）。
上記の2つの一般的なソリューションには興味深い違いがあります。
次のようにベアリポジトリを作成すると、
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年8月上旬の執筆時点）で、実際のリポジトリを使用してローカルシステムでテストを行い、結果をファイルごとに比較することで、上記を学びました。だが！私はまだ学んでいるので、もっと正しい方法があるかもしれません。しかし、私のテストは、＃1が現在好まれている方法であると結論付けるのに役立ちました。
リモートリポジトリは通常、ベアリポジトリです。つまり、作業ディレクトリのないGitリポジトリです。リポジトリはコラボレーションポイントとしてのみ使用されるため、ディスク上でスナップショットをチェックアウトする必要はありません。それは単なるGitデータです。簡単に言えば、ベアリポジトリはプロジェクトの.gitディレクトリのコンテンツであり、他には何もありません。
次のコードで裸のgitリポジトリを作成できます。
$ git clone --bare /path/to/project project.git
リモートgitリポジトリを持つための1つのオプションは、SSHプロトコルを使用することです。
セルフホスティングがSSHを介する場合のGitの一般的なトランスポートプロトコル。これは、ほとんどの場所でサーバーへのSSHアクセスが既に設定されているためです。設定されていない場合でも、簡単に設定できます。SSHは認証済みのネットワークプロトコルでもあり、ユビキタスであるため、一般に設定と使用が簡単です。
SSHを介してGitリポジトリのクローンを作成するには、次の
ssh://ようなURL を指定できます。$ git clone ssh://[user@]server/project.gitまたは、SSHプロトコルに短いscpのような構文を使用できます。
$ git clone [user@]server:project.git上記のどちらの場合でも、オプションのユーザー名を指定しない場合、Gitは現在ログインしているユーザーを想定します。
長所
SSHを使用する利点はたくさんあります。まず、SSHは比較的簡単にセットアップできます。SSHデーモンは一般的であり、多くのネットワーク管理者が経験があり、多くのOSディストリビューションがそれらを使用してセットアップされているか、それらを管理するツールを持っています。次に、SSH経由のアクセスは安全です—すべてのデータ転送は暗号化および認証されます。最後に、HTTPS、Git、ローカルプロトコルと同様に、SSHは効率的であり、データを転送する前に可能な限りコンパクトにします。
短所
SSHの欠点は、Gitリポジトリへの匿名アクセスをサポートしていないことです。SSHを使用している場合、ユーザーは読み取り専用の容量でもマシンにSSHアクセスできる必要があります。これにより、SSHは単にリポジトリを複製して調査したいオープンソースプロジェクトには役立ちません。企業ネットワーク内でのみ使用している場合、SSHが処理する必要がある唯一のプロトコルである可能性があります。プロジェクトへの匿名の読み取り専用アクセスを許可し、SSHも使用したい場合は、SSHを設定してプッシュするだけで、他の人がそこからフェッチできるようにする必要があります。
詳細については、リファレンスを確認してください： サーバー上のGit-プロトコル
リモートサーバーにディレクトリを作成する必要があります。次に、「git init」コマンドを使用して、リポジトリとして設定します。これは、持っている新しいプロジェクトごとに行う必要があります（各新しいフォルダー）
すでにsshキーを使用してgitをセットアップして使用していると想定して、作業ディレクトリから実行するとリモートをセットアップし、ディレクトリをgitリポジトリとして初期化する小さなPythonスクリプトを作成しました。もちろん、スクリプトを編集して（一度だけ）、サーバーとすべてのリポジトリのルートパスを指定する必要があります。
通常、initコマンドを使用するだけでgitリポジトリをセットアップできます
git init
あなたの場合、利用可能なリモートにすでにレポがあります。リモートリポジトリへのアクセス方法に応じて（URL内のユーザー名または検証を処理するsshキーを使用）、clone次のコマンドのみを使用します。
git clone git@[my.url.com]:[git-repo-name].git
リポジトリを複製する他の方法もあります。この方法で、リポジトリのプルを検証するsshキー設定がマシンにある場合にそれを呼び出します。リモートリポジトリにログインするために内部にパスワードとユーザー名を含めたい場合は、URLの他の組み合わせがあります。