別の場所でホストされているリポジトリを自動的に同期（ミラーリング）するようにgitlabを設定することは可能ですか？
現時点では、これを行うための最も簡単な方法は、2つ（gitlabと他の）リポジトリに手動でプッシュすることですが、これには時間がかかり、エラーが発生しやすくなります。
最大の問題は、2人のユーザーが2つの異なるリポジトリに変更を同時にプッシュすると、ミラーが再同期できることです。この問題を防ぐために私が思いつくことができる最善の方法は、ユーザーがリポジトリの1つにのみプッシュできるようにすることです。
2016年12月の更新：ミラーリングはGitLAb EE 8.2+でサポートされています：「リポジトリミラーリング」を参照してください。
Xiaodong Qiがコメントしたように：
この回答は、コマンドラインを使用せずに簡略化できます（Gitlabリポジトリ管理インターフェイスで設定するだけです）
元の回答（2013年1月）
リモートミラーリポジトリがベアリポジトリである場合は、受信後のフックをgitlabで管理されているリポジトリに追加し、その中のリモートリポジトリにプッシュできます。
#!/bin/bash
git push --mirror slave_user@mirror.host:/path/to/repo.git
Gitolite（Gitlabで使用）が言及しているように：
いくつかの特定のリポジトリにのみフックをインストールする場合は、サーバーに直接インストールします。
これは次のようになります。
~git/repositories/yourRepo.git/hook/post-receive
警告（2014年10月更新）
Ciro Santilliはコメントで指摘しています：
今日（2014年第4四半期）、 GitLabは管理するすべてのリポジトリにgithub.com/gitlabhq/gitlab-shell/tree/…を自動的にシンボリックリンクするため、これは失敗します。
したがって、この変更を行うと、変更するすべてのリポジトリがプッシュを試みます。
アップグレード時に発生する可能性のある競合は言うまでもなくgitlab-shell、現在のスクリプトはbashではなくrubyスクリプトです（削除しないでください）。現在のディレクトリ名を読み取り、それとリモートの間の全単射を確認することでこれを修正できますが、私は人々がそれらのものから遠く離れていることをお勧めします
Feeadback「GitLabリポジトリにプッシュした後のリモートミラーリポジトリへの自動プッシュ」を参照（および投票）してください。
2016年7月の更新：GitLab EE（Enterprise Edition）にこの種の機能が追加されました：MR 249
最近のRemote Mirror Repository（17940号）には注意が必要です。
私は現在、私の会社Lossless GmbH（https://www.npmjs.com/~lossless）のオープンソースnpmモジュールの主な開発をGitHub.comからGitLab.comに移行しようとしています。
GitHubからすべてのリポジトリをインポートしていますが、元のGitHub URLで
Mirror Repositoryスイッチをオフにしてからオンにしようとすると、次のようなエラーが発生します。Remote Mirror Repository
Remote mirrors url is already in use
これが失敗するリポジトリの1つです：https ：//gitlab.com/pushrocks/npmts2 か月前に編集
結局のところ、それは複数のステップを必要とするだけです：
- ミラーリポジトリを無効にする
- 保存を押します
- URlを削除します
- 保存を押します
- 次に、リモートミラーを追加します
独自のGitLabをホストしていない場合は、GitLab.comが回避策なしでこの機能を直接導入していることを知っておく価値があります。
https://yourgithubusername:yourgithubpassword@github.com/agaric/guts_discuss_resource.gitリモートリポジトリからプルしている場合でも、ここで設定されているリモートリポジトリにプッシュされることに注意してください。試したことはありませんが、同じリポジトリにプッシュしたり、同じリポジトリからプルしたりできるはずです。
https://username@github.com/username/repo.gitPushPassword
your_github_tokenhttps://github.com/username/repo.gitPullleave_emptyまた、APIを介してGitLab 6のリポジトリをミラーリングするプロジェクトを作成しました（APIは主にプロジェクトの作成でのみ使用されます）。
今日の最良のオプションは、GitLabCIを使用することです。これは基本的に、Webhook用にすでに実装されているサーバーであり、自動的にクローンを作成し、任意のシェルコマンドを実行できるようにします。次に行う必要があるのはプッシュすることだけです。
サービスは、誰かがそれらを実装する場合に最適なオプションです。サービスはソースツリーに存在し、シングルプッシュを実行し、追加のデプロイメントオーバーヘッドを必要としません。
現在の主な実装の難しさは、プッシュクレデンシャルを安全に保存する方法です。GitHubの最良のオプションは、何らかの方法でキーを取得し（サービスを介したUIのOauthが最適です）、そのプレーンテキストを保存することです。
追加されたばかりの別のオプションは、カスタムフックです。
フックを使用して、コミット後に実行されるスクリプトをカスタマイズできます。これで、新しい変更を別のリポジトリに送信できます。次のページでフックの詳細を確認してください：http：//git-scm.com/book/en/Customizing-Git-Git-Hooks
2020年の更新
ご存知のとおり、外部のプライベートリポジトリの無料Gitlabミラーサポートは3月22日に終了しました。
cronの自動化により、phpの小さなコードがここにあります：-
最良のオプションは、受信後フックを使用しないことですが、rsyncを介して同期を実行するデプロイメントコマンド、Rubyが好きな場合はCapistranoを使用し、 Javascript（Grunt）が好きな場合はShipitを使用します。
GitLab Enterprise Editionは、バージョン8.2からリポジトリミラーリングをサポートするようになりました。これを構成する方法については、リポジトリミラーリングのヘルプトピックを参照してください。
GitBitLabHubを使用すると、単純なWebhookを使用して、Bitbucket / Gitlab/Github間でリポジトリを自動的にミラーリングできます。
ssh-keygen -t rsa -f ~/.ssh/project_id_rsa
docker run -it \
-e SRC_REPO=git@bitbucket.org:vendor/src_repo.git \
-e DEST_REPO=git@gitlab.example.com:2222/vendor/dest_repo.git \
-e SRC_DEPLOY_KEY=base64_encoded_key== \
-e DEST_DEPLOY_KEY=base64_encoded_key== \
-p 8181:8080/tcp \
karser/gitbitlabhub
base64 -w 0 < ~/.ssh/project_id_rsa