回答:
次の状況を想像してください。
社内の開発者が会社に損害を与えたい（上司が妻と寝ているため給料が不足していると考えているため、理由は関係ない）それを消去します。次のコミット、驚きで、プロジェクトのすべてのソースコードが失われます（ただし、バックアップを行い、テストしましたか？）
または、同じ開発者は、リポジトリのバックアップが同じマシンで構成されていることに気付きます。彼は単体テストでこの構成を変更し、バックアップに別のリポジトリが含まれるようになり、1か月（バックアップが保持される時間）待機します。すべてのバックアップが破損したので、彼はサーバーからソースコードを消去するユニットテストをコミットできます。
または、インターンがソースコードを競合他社に販売したいと考えています。アクセスを注意深く設定し、彼が作業に必要なものだけに制限しました。同時に、彼は単体テストを通じてリポジトリ自体に無制限にアクセスでき、完全なダンプを実行できます。
ユニットテストが制限された権限のコンテキストで実行され、テストに必要なディレクトリとファイル以外にアクセスできない場合を除き、CIサーバーとリポジトリを保持するサーバーを混在させることは実際に危険です。
もう1つの問題は、バージョン管理サーバーの高速化が期待されていることです。同じマシンにインストールされたCIサーバーにより、コミットが遅くなる場合があります。
git用の中央の「すべてを知っている」サーバーが存在しないことを考えると、これは他のソースコード管理システムの場合のように悪いことではありません。
他のgitサーバー（テスト済み）へのオフサイトでのgitサーバーの自動sykが提供されていれば（小規模な会社ではこのセットアップについて心配する必要はありません）。
理想的には、開発者がオフセットサーバーgitサーバーに変更をプッシュし、CIサーバーがオフセットサーバーから料金を引き出すことを望んでいます。これにより、すべてのチェックインが完了するとオフサイトサーバーがテストされます。
その後、開発者が常に時間を節約するためにオンサイトサーバーからプルする場合、それは問題ではありません。