web-dev-qa-db-ja.com

セカンダリリポジトリをプライマリリポジトリと自動的に同期しますか？

2層のセットアップがあります。

プライマリリポジトリがあります（以下「プライマリ」と呼びます）。

そして、次のように作成されたセカンダリリポジトリ（以下「セカンダリ」と呼びます）：

$ git clone --bare --shared $REPO_A/primary secondary.git

セカンダリリポジトリで作業している人々は、プライマリリポジトリから発生したブランチを読み取り専用として表示しますが、自分のブランチはこれらのブランチに基づいています。

1日1回、セカンダリリポジトリとプライマリリポジトリを同期させたいと考えています。

つまりプライマリにプッシュされたコミットと新しいブランチが、セカンダリリポジトリで作業している人々（次にプルを実行したとき）に表示されるようにします。

これを対称にする必要はありません。つまり、セカンダリリポジトリに対するアクティビティは、プライマリリポジトリで作業している人には表示されません。

理想的には、なんらかの方法でプライマリから新しいデータをフェッチして自動的にセカンダリに含める、裸のセカンダリリポジトリを持つマシンで実行するcronジョブを実行したいと思います。

私はこれを行う簡単な方法があるかもしれないと期待していました（そして私はここの誰かがそこにあると私に教えてくれることを望んでいます）。

私がそれを行うためのスクリプトを書くとしたら、次のようになります。

  • セカンダリの新しいクローンを作成します。

    $ git clone $REPO_B/secondary
$ cd secondary

  • そのすべてのブランチを取得します。

    $ git branch -r | sed 's?.*Origin/??'

  • プライマリリポジトリのすべてのブランチを取得します。

    $ git ls-remote --heads $REPO_A/primary | sed 's?.*refs/heads/??'

  • 対応する二次ブランチがまだない一次ブランチごとに：

    $ git fetch $REPO_A/primary $BRANCHNAME:$BRANCHNAME
$ git Push Origin $BRANCHNAME:refs/heads/$BRANCHNAME

  • 対応する二次ブランチがすでにある一次ブランチごとに：

    $ git checkout -b $BRANCHNAME --track Origin/$BRANCHNAME
$ git pull $REPO_A/primary $BRANCHNAME
$ git Push

私はgitを初めて使用するので、特定の基本的な問題を考慮しなかったとしても驚かないでしょうか？

そして、私が言ったように、これを行う簡単な方法があることを望んでいます。つまり、誰かが「ああ、それをすべて行うのではなく、ただ実行してください...」.

gitsynchronizationrepository
32
George Hawkins

ああ、それをすべて行うのではなく、ただ次のようにしてください。

git --bare fetch

;）

（これを見てください たとえば、古いスレッド ）
関連するリモートの起点 をベアリポジトリに追加した場合、これらの起点のそれぞれを順番にフェッチできます。

30
VonC

git clone --bare --mirrorおよび定期的にgit fetchこれを実現します。

私は gitmirror と呼ばれるツールを使用して本物っぽくしています。私はnode.jsに書いて、自宅のマシンで実行してgithubからWebhookを受け取り、コミットを同期するためのアドホックフックを受け取っています。

Github以外の例では、約1時間に1回コミットされるcouchdbバックアップに使用されるリポジトリがあります。 cronジョブは基本的に次のようになります。

# do some backup stuff
git commit -qam "Backup `date`" >> dump.log 2>&1

そこから、post-commitフック（.git/hooks/post-commit）これは次のようになります。

#!/bin/sh
curl -sS http://my.home.machine/gitmirror/bak/repo-name.git

受信側からプッシュすることでも同じことができます。これには、通常の場合にペイロードを起動して忘れるという利点があります。

12
Dustin

これを標準のGitツールとして見たいと思います。しかし、これらのケースはまれです。多くの場合、それはあなたの環境にいくつかの制限があることを意味します。

私はこの問題のためにいくつかのツールを作成しましたが、そのうちの1つは私のニーズをカバーしています。

ただし、これらのツールにはある程度の知識と経験が必要であることを警告する必要があります。
自分のニーズにのみ適合し、適切に応答するコミュニティがないため、私のドキュメントは貧弱です。そのために残念。あなたは本当にそれに時間を費やす必要があるので、あなたの時間を無駄にしないでください。

gitSync -インストールするだけで（難しい）、使用します。
convention-over-git -ここからアイデアを見つけて、独自のスクリプトまたはツールを書くことができます。

それにもかかわらず、gytSyncは本当に問題を解決してくれます。
私は2017年にgitSyncを作成しました。私たちはそれを常に使用しており、すべてが完璧です。
ええ、私はいくつかのバグを修正しました））

gitSyncは、HTTPを介して任意の2つのリモートgitリポジトリ間のgitブランチを同期します。
同期されたブランチは、命名規則に従う必要があります。

命名規則は私のブログ Convention over Git で説明されています。 （私はgitSyncを作成する前にこの規則を考案しました。）

チームは、同期された同じGitブランチで作業することもできます。全く問題ありません。
gitSync が自動化された競合解決を備えているためです。
競合が発生した場合は、変更を再度コミットする必要がある場合があるため、詳細は Git-conflicts solveing を参照してください。
確かに、さまざまな実行状態をファイルにエクスポートするため、さまざまなメール通知をgitSyncに接続しています。

自動化された競合解決のため、同期されたブランチの両方のリモートリポジトリで誰でもGitマージを実行でき、同期されます。
これは、チームの1つだけがGitマージまたは競合解決を実行できる場合、任意のリポジトリの両方のリポジトリに対して正常に実行できることを意味します。

gitSyncは、時折のGitリポジトリのワイプからの保護さえ備えています。

gitSyncツールは、ネットワーク、IO、およびOSのトラブルに対して回復力があります。 Git自体と、gitSyncに実装された私のアイデアのおかげで。私はそれをgitSyncを作成する前にアーキテクチャに入れました。そして、これは継続的な使用によって証明されました。

GitSymcは、さまざまなcron、PowerShellのスケジュールされたジョブ、Automation Serves（Jenkinsなど）、および手動で実行しています。

0
it3xl